-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul, Lot's of nice thougths in here :) Paul Everitt wrote: > > Summary: A discussion of more separation in UI rendering vs. object > model for Z3 ECM. > > Yesterday I sent a pointer to some stuff I'm doing for content > delivery. It's part of a larger design goal, one that went under the > banner of "pipelines" at the Z3 Castle Sprint. > > In this note, I'd like to describe some ideas on this. If there is > legitimate interest in doing this as a *first-class* citizen in Z3 ECM, > then I'll writeup a white paper and continue my prototypes. > yep go ahead -> http://www.z3lab.org > (Note: Enfold is also doing quite a lot on this topic, much more > sophisticated work than mine, but similar ideas.) > pointers ? (Enfold people ?) > Background > ------------------ > > Zope 3 took a big, big step forward in splitting model and views. Its > views are now cleanly separated and can use little controller scripts > to control access to the data, thus lowering the need for logic in > ZPT. The views are also wire-able, allowing creation of new views and > replacement of old views. Also, view names don't clash with > identifiers in content space. > > Thus, Zope 3 has achieved much of a *logical* separation between model > and view. I think there is one step more that can be taken on the > logical part, but then a bunch of possibilities on *physical* separation. > > Logical > ------------ > > Zope 3 retains the basic workflow seen in CMF for how web designers and > site developers interact. In essence, they share a common artifact: > main_template.zpt (sp?). This entry point then has tentacles which > spread into lots of macros, slots, view classes, interface definitions > that wire views together, ZCML that does the same, etc. > > Perhaps we could re-visit this and have a clearer distinction of > responsibilities. Primarily, can we keep the site developer from > touching the artifact of the web designer? This was the original > purpose of the Themes idea in what I sent yesterday. Evan's old TASSL > proposal was similar. > > Also, when it is time to evaluate a view, it's all done in one big > operation. If one part fails, it all fails. (Yes, this doesn't have > to be this way, but the dominant pattern in Zope and add-ons is to not > provide handlers on blocks.) Everybody has to agree to the full > contract of all other parties sharing the view artifact. And too > often, you have to know the details (macros, slots, tal:defines, etc.) > of other artifacts. Jean-Marc did work on this for a while. Did you check its white paper on cpsskins design ? http://www.z3lab.org/sections/front-page/white-papers/white-paper-portlet > > At a minimum, I think we could take the corporate identity (re- > branding, skinning, whatever) part out of the one-big-swoop- evaluation > and we'd have a big win. Apply the look and feel to XHTML just before > it goes out the door. Don't require the corporate ID people to even > *see*, much less learn, something that isn't valid XHTML. "Don't Make > Me Think". > definitely, check Jean-Marc's work. > Physical > -------------- > > This is the more ambitious part, one that I think Z3 ECM has to tackle > to achieve some of its goals. > > Zope 3 views are logically separated from the view, but the view is > still applied in Python, using a Zope template technology, against a > Zope 3 API, which interacts with a Zope database, storing Python > pickles. Some parts of that are pluggable, but usually aren't. "All > Your Bases Are Belong To Us". > > Some conservative ECM customers might take issue with that. > > What are some other choices? > > 1) Put the views in ZServer/Twisted and evaluate presentation-less > content. Have a model-driven approach to pages. A response has to > fulfill a contract represented by a schema. The view template doesn't > talk to the Zope runtime at all. > > 2 Put the views in Apache. This is what I did in Deliverance. The CMS > bakes up a content map describing all its assets and writes it to > disk. The view system, running in Apache, applies presentation and > presentation logic. Notably, content from multiple locations can be > aggregated into one model. > I need to check delivrance. Do you really put your views in Apache already ? > Requests for the content of an individual resource can still go to the > server, but the server's job is to only return the resource's data, not > draw portlets and site menus etc. > > 3) Put the views in the browser. This is Ajax-style development. Get > the model from the server. Each user interaction redraws browser > pixels without making a request to the server. > lots of Javascript right ? > 4) Put the views on your laptop. During UI development, have a static > prototype model. You can develop all of your UI without having a > server. Later, all the component folks have to do is produce content > conforming to the same (verifiable) schema. Quite a productivity > boost, parallel-izing consulting development. right. > > 5) Combination. Keep some of the view in ZPT in the component, some in > a Zope utility, do some in Apache, with a couple of Ajax boxes purring > away in the browser. > sounds fair enough. > > Benefits > --------------- > > 1) We can leverage different talents without throwing them into the > same artifact. > > 2) We can mix-and-match technologies based on different needs: > performance, level of dynamicism (CMS vs. intranet), etc. > > 3) We can leverage labor outside the Zope universe. For example, > libxml2 has had around 1,000x the manhours as the ZPT parser during the > last 3 years. Pass the investment burden to others. > +1 > 4) Market friendly. Some might choose view technologies and > integration technologies that don't generate resistance from > conservative customers. > +1 > 5) Performance. Putting the views in Apache, when coupled with a > static model, means you just add Apaches to boost performance. (The > stateless PHP/MySQL brute-force approach that is well-understood.) > I guess yeah. > 6) Productivity. That's a long topic which I'll handle in a dedicated > note. > > 7) Quality. IMO, the current model of ZPT-based views doesn't fit the > explicit is better than implicit. Trying to find out what drew a > certain pixel on the screen is an epic goose chase, with several > vectors of indirection (macros, slots, interface bindings, ZCML > directives, package rewirings, view classes, etc.) > > The ideas above aren't the only choice for solving explicit vs. > implicit in views, but certainly approach the problem from a clean, > verifiable, and discoverable way to find the pixel. > > Questions > ------------------- > > I'm willing to continue working on this, primarily through writing > white papers, giving demos, and doing hands-on workshops to show the > productivity gain. (Yeah, there's some skepticism on that productivity > claim, but keep an open mind and give me a chance to prove it.) > > I'd like to do this under the Z3 ECM effort. But first, I'd like to > get some feedback and see if there are shared goals: > > 1) Do people want to keep content production and content delivery in > the same system for Z3 ECM, or pursue a choice for splitting? This one is related to twhat you sent yesterday and Florent's already tell you it's really an interesting appoach, isn't it ? :) > > 2) Is there an interest in cleaner separation in the logical parts, aka > pipelines? > yes ! > 3) Would people use work that did rendering in Apache or in the browser? I'll vote for Apache myself I guess. But jut because this Js stuff of yours on the browser that I don't really understand scares me ;) > > 4) If 1-3 were done in XML, XPath, and possibly XSLT, would that be an > automatic disqualifier? :^) NOT AT ALL ;) I personally would like to see this big time. BTW, did you see on the concept map we thought about using XForms for the form engine ? Let's use standards ! It's really important for putting the Z3 ECM on the market. Probably, this work needs to be done as well on the Zope3 layer itself. I made a propsal on the zope3-dev list recently for the inclusion of lxml that will allow us much more XML possiblity (and yeah lxml rocks and supports xpath and xslt !) Open you workspace on the portal and convince people to work with you on this ;) Anyway, keep the good work and writeups on the portal is required now ;) Who's interested about these issues in here ? J. - -- Julien Anguenot | Nuxeo R&D (Paris, France) CPS Plateform : http://www.cps-project.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCjFNbGhoG8MxZ/pIRAsiCAJ9gpccU+VIvuYHAn/+j6zdmAVimaQCdG/ak w8ss0jEnLR4qnBxzll3v4PQ= =Kw+N -----END PGP SIGNATURE-----
Hosting: Nuxeo: Zope service provider