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

[Martijn Faassen]

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.

> 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?

> 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?

> 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.

> 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.

> 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.

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.

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.

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.

Regards,

Martijn