Tres Seaver wrote:
[snip]
The "just store the XML" scenario is in surprisingly nice. It only needs
attention to encoding and decoding in the always complicated ZPublisher
direct output scenario, and in the edit form scenario.
As you speculated, this is actually my preference, except that I don't
see the need to in scenario D to recode the data and strip the prolog
encoding attribute. Why wouldn't we just use the XML template's own
declared encoding to encode any data subsituted into the template? I
mean, if the user has marked up the document to indicate a "preferred"
encoding, why should we bother storing such an encoding in another location?
Yes, I was thinking along those lines too.
Then the only time we would need to munge the document would be at
inclusion time, which is the only time we actually *need* to have
unicode in hand. We might even elide the decode-recode stage if the
target document uses the same encoding! That such an optimization might
not be worth the complexity, however.
Yes, one complexity is that trying to do this would break the assumption
that ZPT templates always return unicode or pure-ascii strings, not
anything else (such as encoded data). Only at the last phase of the
publisher will it be encoded into something else. I really appreciate
keeping this assumption in place. :)
Note that in the inclusion case (scenario E), we almost certainly
*should* be stripping the *entire* prolog, which is only valid at the
start of the merged document.
If you are including it as a document, yes. If you are included it
quoted, as for instance the contents of a text area allowing you to edit
the XML text directly, then no. This suggests we actually have two
scenarios here.
I guess there is a subscenario, which is
that the "included" document is actually the 'main_template' supplying
the prolog: METAL might should leave the prolog alone, while
'tal:replace' and 'tal:content' (with 'structure') would strip it?
Yay, another scenario. :)
Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
