(changing the subject to avoid hijacking Paul E.'s thread any further) On Wed, Nov 30, 2005 at 02:48:12PM +0000, Martin Aspeli wrote: > What a pure-play Meld approach doesn't give us, however, is the ability to > modularise and re-use elements of the UI (i.e. if they are to be used in > various > different places at different times), and it makes it difficult to partially > exend the template. At the moment I can write a macro once and use it in > different places, with a single .html template, that becomes a copy-and-paste > job.
Certainly not. Reusing bits of a meld is actually really trivial. (And I'd be surprised if you've never needed to copy and paste a whole third-party ZPT because it didn't give you granular enough macros to do the job. This is *very* common in the CMF and Plone world.) I need to post some reuse examples.... OK, here's a simple one: http://w > The thing that scares me most, though, is that in the Meld scenario, building > the UI for the developer is very "precedural". Yes, by intent. It's definitely a whole different mindset. > ZPT is nice in that it is > declarative: I want this value to go here. If we restrict our thinking to > structural HTML (divs and spans and h1s and such), the output of a ZPT is more > about presentation structure than presentation visuals. I declare a view of > what > a document in my CMS looks like structurally (the header is above the > descriptio > is above the title). > > With python processing of a template, I'd have to build a fairly good mental > model of what that template looked like and perform processing on that node > tree. It's a lot looser than knowing the whole DOM. You just need to know the IDs. And in some cases, only when an id is used in multiple places, you will need to know the id of its parent. That's the only mental model you need. You don't need to have any idea what the tags are or how the page structure is arranged. > The link between my data and where that goes on the page is just a bunch > of python. As a developer, I'd certainly prefer the declarative approach, > where > I can build the structure of the template and specify in it where things go. Note that in the PyMeld / Meld2 approach, I'm hoping that the coupling between document structure and the processing code can be kept pretty loose, so you can redesign the page by moving blocks of html around, and you can move an id from one kind of element to another if you like; and in many cases the python code will still just work; and when it doesn't, it should always be pretty trivial to fix. > Furthermore, I'm a bit unsure where the line goes. If the original template > said > nothing about documents and how they are structured, do I print html from my > python code to inject into that empty "main content" space? (ouch!) Do I get > my > themeing guy to make a brand-new-and-consistent template for each of my > content > types? Playing nice with existing code (e.g. huge amounts of ZPT) is the killer problem here. I haven't thought much about it yet. I'm still in the utopian dreaming phase. First I need to be sure that doing templating this way is actually a good idea at all :-) My intuition is that PyMeld didn't take off at least partly because as written it just wasn't convenient enough to use; I could be wrong about that. > Okay, that was long. I guess the point is that I still think the decoupling > from > developer/page composer to artist/site themer is a useful one, without having > to > restrict developers purely to processing in python. "pure python" processing of x(h)tml is an explicit goal of Meld2, so I guess we disagree. Note that this leaves the door wide open to other processing in the pipeline, e.g. XSLT. -- Paul Winkler http://www.slinkp.com _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests