[Framework-Team] Re: 3.0 shouldn't just be about the user facing UI
optilude at gmx.net
Mon Mar 13 21:22:52 UTC 2006
> If we move to a meld like solution we may well end up having nobody who
> to work on presentation logic. I certainly have no interest in using
> to manipulate an XML tree in order to do the equivalent of a tal:repeat.
Yep. This is basically why I think Meld is a slightly dangerous route.
> think if we are going to move to some brave new world of designer
> friendliness it should probably to be via generation of semantic XML
> zpts) with XSLT transforms to provide the end-user interface; this would
> allow designers to use the available XSLT generation tools to do all
> of nifty things, while allowing the developers to be removed entirely
> presentation decisions.
XSLT has the benefit that it has a life outside Zope/Plone/Python and has
recognition. It may make the "plays well with others" argument a bit
> This would however seem to make it somewhat more
> difficult to make rich AJAX-y client side applications with Plone, and
> the audience of potential plone design customizers to those with some
> expertise. I seriously doubt this is feasible in the near future, and
> neither is moving to a meld like system. We are stuck with making an
> presentation using zpt (which has no peer for generating markup, IMHO),
> we ought to make the most of it.
This is true - XSLT is no silver bullet, and has its own oddness and
complexity. What I'd like to see would be a slightly stronger promise that
we *can* generate near-100% semantic/structural XHTML. We're not that far
off, and the places where we have to jump through hoops for browsers, it's
probably to limit it to a few patterns that XSLTs can work around.
Take Paul's Deliverance idea - the themeing is done with XSLT selectors
block-replacing from Plone's source XHTML, slotting content, navigation
structures etc. into well-defined places in some static theme HTML file.
The nicer and cleaner our HTML is (with all stylesheets turned off) the
easier that becomes. That themeing layer actually lives outside of Plone,
in Apache/mod_python with a bit of XSLT, though the main way of using it
is to make an HTML template and a rule file, no code in sight. I don't
actually know if this works in real life, and I'm hoping Paul will have
time to do a demo and some exploration if we decide this is a worthwhile
goal. The useful part of this is that themeing (not really UI, but a large
part of the UI to a large group of our users) can actually live outside
Plone and outside Plone-specific technologies.
Will it work? I have no idea - I'm hoping for a demo, but using existing
tools (Five views, ZPTs) to build semantically sensible XHTML for all of
Plone seems a good way to enable such themeing to take place outside of
Plone and make the markup we produce more generally useful.
More information about the Framework-Team