[Zope3-dev] There's something wrong with having message ids in schemas

[Jim Fulton]

Martijn Faassen wrote:
> Jim Fulton wrote:
> 
>>
>> I'd like to use a schema in zope.index.  But, if I do,
>> I'll need to make the field titles and descriptions message ids.
>> This has two problems:
>>
>> 1. It makes zope.index depend on zope.i18nmessageid
> 
> 
> Can't Zope 3 message id imports go through some very small dummy package 
> which provides a dummy message id if i18nmessage id is unavailable? It'd 
> be less painful perhaps to have to just depend on that.

Yes. Piling on a hack would probably make things worse.

>> 2. It forces me to pick a domain, which seems wrong.
> 
> 
> Why does this seem wrong? It's just the domain of the codebase the 
> schema is in, right?

But domains are, IMO, mostly a UI concern.  It means we introduce a UI
concern into something that otherwise has no UI code.

>> We've known for a while that title and description
>> where a little iffy. Title and description are useful
>> for documentation and presentation.  The documentation
>> benefits probably justify having a title and description,
>> however, doc strings might do as well.  Sometimes, we want
>> to use a label that is different than the field title.
> 
> 
> Separating out the documentation concerns might be useful in that case. 
> Though on the other hand they're so close together that it may be only 
> confusing to have to worry about a docstring as well. A docstring is
> developer-level documentation, but how much documentation is necessary 
> if there's already a user-level title and description?

It could be argues that we shouldn't have title and description,
but should just have a doc string.

>> OTOH, there's a lot to be said for the convenience of
>> having this information in the schema.
> 
> 
> Agreed. Introducing another layer might also introduce a lot of 
> developer complexity. We should be careful about that.

Yup.

>> I wonder if there are some other ideas we should consider.
>>
>> For example, I wonder if there is some sort of prsentation
>> component that we could provide for schemas that could
>> capture UI details like default widgets, labels (message ids),
>> order, etc.
> 
> 
> Order is not necessarily only a UI detail; it could for instance be used 
> to order method arguments (if these need to comply to a schema), or
> SQL table column order. The same may be true for some of this other data.

I suspect that, at some point, if we really decide to model arguments,
we should have a specific modeling tool, rather than trying to apply
schemas.

>> Thoughts? I'm just brainstorming. :)
> 
> 
> Basically what you talk about could be considered to be the form. Right 
> now we build up forms dynamically, but forms could have actual data.

Not quite.  Often we develop many forms from the same schema.  One could
manage presentation data for a schema that is shared by multiple forms.
Gary does some of this now. He's developed his own form machinery that
lets you define a field ordering once that is shared by subsequent form
definitions.

> Tied into this, a layer that I miss a bit in the current schema/form 
> system is that the way to construct an actual form is hidden away under 
> a layer of ZCML and automation and becomes rather hard to find. 
> Sometimes you'd like to have just a form without having a content object 
> that complies with a particular schema. I'm not saying we shouldn't have 
> a schema for this form, but the schema is free-standing and not 
> associated with any particular content object. It might be part of the 
> view only.

I'll note that I consider the current form machinery to be a good start
that is actually pretty primitive. I think we can do a lot better and
expect the current system to be superceded by something better some
day.

> If form data is going to be expressed somewhere explicitly, it would 
> also be nice to think a bit more about what a programmer would want from 
> an actual form API. The automation can of course remain, but build on
> this API.

Yup.

> It's quite possible we're not far away from this API already, and I 
> admit I don't keep the current architecture in my mind very completely 
> yet. That may however in itself be an indication that a form abstraction 
> needs to be pulled into clarity a bit more than it is now.

Personally, I see this as being related to the page architecture discussion.

Anyway, we do have a useful low-level form API in zope.app.form.utility that is,
unfortunately, poorly documented.  I think Garrett is planning to work on a .txt
file for this module soon.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org