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

[Stephan Richter]

I largely agree with Martijn's response. Some more comments below.

On Wednesday 08 December 2004 07:56, 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, I was about to suggest the same:

try:
  from zope.i18nmessageid import MessageIdFactory
  _ = MessageIdFactory('domain')
except ImportError:
  _ = unicode

This way you only have a soft dependence of zope.i18nmessageid

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

I agree with Martijn, selecting a domain is part of the I18n process. I have 
two suggestions here:

(a) Use a domain called "global" or "default" by default, to avoid specifying 
a domain.

(b) Use the module path as the domain by default.

> > 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 totally agree. Another layer would be a big burden on the developer and 
anyone who wants to read the code, since they have to look in two places now.

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

This is actually planned for the 3.1 release. We will provide a browser:form 
directive that that is only responsible to display the form based on a schema 
and will leave the `update()` method for the developer to fill out.

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

I think we will discover some of the issues and needs when we implement the 
browser:form directive.

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

No, we are not. I expect the first browser:form implementation to be pretty 
straight forward.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training