Re: [Zope-CMF] Five:traversable and PortalContent
On 11/29/05, Brent Hendricks <[EMAIL PROTECTED]> wrote: > When goldegg was first started, plone had a line like this in configure.zcml: > > class="Products.CMFCore.PortalContent.PortalContent" > /> > > I've noticed that this line causes failures in the CMFCore tests so > I'm taking it out of plone. If it's necessary it should probably go > in CMFCore anyway I think it *is* in the core now. I'm not sure it should be, though. It's there to allow you to make views for objects, and I'm not at all sure it's a good idea to have that feature turned on for everything like that. It has caused me trouble earlier, I know that. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
[Zope-CMF] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open efge - "CMFSetup: provide non-ascii im- and exports", [Accepted] http://www.zope.org/Collectors/CMF/292 jens - "Discussion replies removal", [Accepted] http://www.zope.org/Collectors/CMF/391 mhammond - "Windows DevelopmentMode penalty in CMFCore.DirectoryView", [Accepted] http://www.zope.org/Collectors/CMF/366 regebro - "fiveactionstool broken (Zope 2.9/3.2)", [Accepted] http://www.zope.org/Collectors/CMF/392 Pending / Deferred Issues - "CMFCalendar weekday locale issue", [Pending] http://www.zope.org/Collectors/CMF/237 - "Wrong cache association for FSObject", [Pending] http://www.zope.org/Collectors/CMF/255 - "CMFSetup: Windows exports contain CR/LF, LF and even CR newlines", [Pending] http://www.zope.org/Collectors/CMF/266 - "FSPropertiesObject.py cannot handle multiline input for lines, text attributes", [Pending] http://www.zope.org/Collectors/CMF/271 - "PortalCatalog.ZopeFindAndApply should probably also search in opaqueItems", [Pending] http://www.zope.org/Collectors/CMF/296 - "Can't invalidate skin items in a RAMCacheManager", [Pending] http://www.zope.org/Collectors/CMF/343 - "CMFSetup: Workflow Tool export fails with workflows which have scripts", [Pending] http://www.zope.org/Collectors/CMF/373 - "CMFCore.Skinnable.SkinnableObjectManager can merge skin data", [Pending] http://www.zope.org/Collectors/CMF/375 - "Proxy Roles does't work for a Script using portal_catalog.searchResults", [Pending] http://www.zope.org/Collectors/CMF/380 - "WorkflowAction deprecated warning should not printed for WorkflowMethod", [Pending] http://www.zope.org/Collectors/CMF/388 - "workflow notify success should be after reindex", [Pending] http://www.zope.org/Collectors/CMF/389 - "came_from and VIRTUAL_URL problem", [Pending] http://www.zope.org/Collectors/CMF/393 - "DCWorkflow - Transition Guards - Documentation Bug", [Pending] http://www.zope.org/Collectors/CMF/394 - "PortalFolder.py _verifyObjectPaste ignores executable security", [Pending] http://www.zope.org/Collectors/CMF/396 Pending / Deferred Features - "Favorite.py: queries and anchors in remote_url", [Pending] http://www.zope.org/Collectors/CMF/26 - "Allow flexible date editing in Event.py (CMFCalendar)", [Pending] http://www.zope.org/Collectors/CMF/40 - "DefaultDublinCore should have Creator property", [Pending] http://www.zope.org/Collectors/CMF/61 - "Make changeFromProperties accept sequences too", [Pending] http://www.zope.org/Collectors/CMF/99 - "path criteria on Topic should honor VHM", [Pending] http://www.zope.org/Collectors/CMF/111 - "Document.py: universal newlines", [Pending] http://www.zope.org/Collectors/CMF/174 - "Permissions in PortalFolder: invokeFactory()", [Pending] http://www.zope.org/Collectors/CMF/175 - "Add condition for transition's action like other action", [Pending] http://www.zope.org/Collectors/CMF/207 - "Major action enhancement", [Pending] http://www.zope.org/Collectors/CMF/232 - "portal_type is undefined in initialization code", [Pending] http://www.zope.org/Collectors/CMF/248 - "Action._listsActions() should be more safe", [Pending] http://www.zope.org/Collectors/CMF/253 - "Expose Document text_format metadata", [Pending] http://www.zope.org/Collectors/CMF/285 - "customization of type of homefolder on creation", [Pending] http://www.zope.org/Collectors/CMF/288 - "Allow contentFilter to use review_state", [Pending] http://www.zope.org/Collectors/CMF/294 - "CMFTopic Does Not Cache", [Pending] http://www.zope.org/Collectors/CMF/295 - "Wishlist: a flag that tags the selected action.", [Pending] http://www.zope.org/Collectors/CMF/301 - "CMFDefault should make use of allowCreate()", [Pending] http://www.zope.org/Collectors/CMF/340 - "Nested Skins", [Pending] http://www.zope.org/Collectors/CMF/377 - "CatalogVariableProvider code + tests", [Pending] http://www.zope.org/Collectors/CMF/378 - "manage_doCustomize() : minor additions", [Pending] http://www.zope.org/Collectors/CMF/382 ___ 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
[Zope-CMF] Re: Proposal for hooking rendering
Paul Winkler wrote: On Tue, Nov 29, 2005 at 09:34:09AM +0100, Paul Everitt wrote: Hi all. I'd like to make a small proposal to enable investigation of a larger proposal. I'm generally interested in the ideas of pipelines for markup rendering. Specifically, I'm interested in separating the concerns of skin scripters and corporate ID people into two logical parts: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SiteThemes (snip) Interesting stuff. One thing that immediately occurs to me: """ 4) Opt-in. All templates in all core code and all add-on products have to decipher the under-documented, un-enforced system of macros and slots in order to leverage the corporate id work in main_template. If you want to apply a consistent look and feel on all pages, you should be able to impose it, whether the view template agreed or not 3) Universal. The corporate id is not optional. It gets imposed on every page in a site. """ That goes too far IMO. Opt-in is a pain, but if you remove it, we need to add an "opt-out" feature. Consider for example links that launch pop-ups with some snippet of information in a smaller window. You frequently want these to have a very stripped down look-and-feel. This can be used for e.g. context help. I've seen a lot of sites like this and worked on some. That policy can be implemented in the tool itself. For this small proposal, the change wouldn't care. The tool could just return back the same then passed, unchanged. [wink] http://www.zope.org/Members/zopepaul/zopesitethemesdiagram.png This isn't revolutionary stuff. It's a meme that appears in Typo3 and a few Python templating systems. (snip) At the EuroPython sprint, Tres coded up a nice little ZCML pipeline product that hooked Zope 3.1's publication events. However, this event isn't usable in Five 1.3. Here's my small proposal for a near-term CMF 1.x release: 1) In CMFCore/FSPageTemplate.py, modify its pt_render or _exec. 2) Check to see if there is a configured pipeline tool. 3) If so, run the result of: result = self.pt_render(extra_context=bound_names) ...through the tool and return it. So this wouldn't work for PageTemplate instances in the ZODB, e.g. in portal_skins/custom/ ? Ok, I picked the wrong spot for the proposed implementation. (I'm not a CMF guru, but I'd like to contribute.) Whatever implementation is chosen would need to cover both FS and customized template output. Things I'm not proposing: 1) CMF out-of-the-box contains any tool nor any pipelines. 2) I'm not asking others to do the work on these. I'll learn enough to make some prototypes. Before I write a proper proposal, though, I'd like to find out if there is basic interest: 1) Does the CMF have an interest in experimenting with ideas on splitting corporate ID responsibilities from product skin responsibilities? To me, sure. Anything with the potential to reduce complexity of main_template and increase cohesion is interesting :) Incidentally, I'm intrigued that you latched onto the idea of leveraging pure x(h)tml and just using the "id" attribute to identify the boxes. I don't mean to derail your thread, but I think we're annoyed by some of the same misfeatures of the current big-complex-ZPT approach in CMF, but we go in different directions with our ideas. Yours is focused on leveraging and improving existing work with minimal pain, mine is a bit more pie-in-the sky :) Right. My proposal for the CMF change doesn't require XHTML. That's a policy for whatever tool gets installed and configured. Also, even if you *did* choose what I would like to write, you could output as XHTML or HTML. :^) In some recent discussions(1,2,3) about templating, I've grown increasingly convinced that ZPT is too complex, and that I'd prefer something along the lines of PyMeld(4). Right, saw that and thought it was interesting. Still, I'm hoping that my small, 3-line proposal doesn't get changed into a "let's replace templating systems" discussion. :^) I'm trying to find the smallest necessary part to cover the maximum interest. Again to the CMF community: independent of this proposed solution, is this corporate ID a problem worth supporting investigation? --Paul ___ 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
Re: [Zope-CMF] Re: Proposal for hooking rendering
On Wed, Nov 30, 2005 at 09:40:40AM +0100, Paul Everitt wrote: > Paul Winkler wrote: > > 3) Universal. The corporate id is not optional. It gets imposed on > >every page in a site. > >""" > > > >That goes too far IMO. Opt-in is a pain, but if you remove it, we need > >to add an "opt-out" feature. Consider for example links that launch > >pop-ups with some snippet of information in a smaller window. You > >frequently want these to have a very stripped down look-and-feel. This > >can be used for e.g. context help. I've seen a lot of sites like this > >and worked on some. > > That policy can be implemented in the tool itself. For this small > proposal, the change wouldn't care. The tool could just return back the > same then passed, unchanged. [wink] OK, as long as it's possible somehow :) > >So this wouldn't work for PageTemplate instances in the ZODB, > >e.g. in portal_skins/custom/ ? > > Ok, I picked the wrong spot for the proposed implementation. (I'm not a > CMF guru, but I'd like to contribute.) Whatever implementation is > chosen would need to cover both FS and customized template output. When you customize a FSPageTemplate, you get a plain ZopePageTemplate. So you'll need to find a way to post-process the output of those without requiring a change to core Zope, or this becomes a Zope proposal. Unfortunately I haven't a clue how you could avoid that. (snip) > Still, I'm hoping that my small, 3-line proposal doesn't get changed > into a "let's replace templating systems" discussion. :^) Certainly. I probably shouldn't have posted about that in this thread. -- 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
[Zope-CMF] Re: Proposal for hooking rendering
> 1) Does the CMF have an interest in experimenting with ideas on > splitting corporate ID responsibilities from product skin responsibilities? I certainly do. I'm actually of the opinion that ZPT is a pretty nice way of doing UI re-use and customisation (no-one's shown me anything significantly better yet, at least). However, I think there are two different audiences, as you identify: - The developer who wants to re-use UI as much as possible - The corporate ID person who wants the site to be themed a certain way I think that the main_template-with-slots approach works quite well for the first audience. Most of the time, you just fill the main slot and be done with it. I've seen some attempts at making the re-skinning job easier, but usually it's hard to come up with one approach that fits both audiences, since they have different skills and different needs. - The developer doesn't find ZPT particularly hard to grasp... - ...and want the flexibility of e.g. bypassing main_template entirely - The skinner may not want to learn TAL syntax... - ...but want to do more than what straight CSS can accomplish I'm still not entirely sure how your proposal would deal with cases like moving elements of a page around in a non-trivial way (e.g. changing the way things are nested). Possibly this will just have to do with how carefully the various parts of the site are defined with structural markup (only) and given ids. I'd really like to see a demo, and a more detailed comparison with the current approach and alternative approaches. Martin ___ 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
[Zope-CMF] Re: Proposal for hooking rendering
Paul Winkler <[EMAIL PROTECTED]> writes: > > On Tue, Nov 29, 2005 at 09:34:09AM +0100, Paul Everitt wrote: > > > > Hi all. I'd like to make a small proposal to enable investigation of a > To me, sure. Anything with the potential to reduce complexity of > main_template and increase cohesion is interesting :) > In some recent discussions(1,2,3) about templating, I've grown > increasingly convinced that ZPT is too complex, and that I'd prefer > something along the lines of PyMeld(4). > > But PyMeld (and PyMeldLite as shipped with SpamBayes) has a few serious > practical flaws IMO, so with input from various folks I've whipped up a > proposal(5) and prototype (6) called Meld2. I think the idea that the main template/look-and-feel of the site should be all-HTML is quite a good one, and certainly one likely to please the site designers out there. Note that the decoupling still isn't complete, at least not in the re-theme scenario, because the Meld approach still depends on certain attributes being present (meld:id) and having at least some common structure (e.g. it expects it to be a table). Probably those restrictions are easier to swallow than learning a whole new syntax, though! 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. The thing that scares me most, though, is that in the Meld scenario, building the UI for the developer is very "precedural". 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. 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. 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? That's what makes Paul's proposal attractive to me. These two things are decoupled. Building the data-to-presentation-structure layer is still done declaratively, in ZPT (and with Views in Z3/Five). There are still macros and slots that are used to compose the final page and ensure re-use of most elements on the page. The output is a single, structural view of the page. The site themer then writes a template that transforms the output of my mostly structural idea of presentation into his mostly visual idea: the corporate ID. 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. Martin> > > > I'm generally interested in the ideas of pipelines for markup rendering. > > Specifically, I'm interested in separating the concerns of skin > > scripters and corporate ID people into two logical parts: > > > > > > http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SiteThemes > (snip) > > Interesting stuff. One thing that immediately occurs to me: > """ 4) Opt-in. All templates in all core code and all add-on products have > to decipher the under-documented, un-enforced system of macros and slots > in order to leverage the corporate id work in main_template. If you want > to apply a consistent look and feel on all pages, you should be able to > impose it, whether the view template agreed or not > ... > 3) Universal. The corporate id is not optional. It gets imposed on > every page in a site. > """ > > That goes too far IMO. Opt-in is a pain, but if you remove it, we need > to add an "opt-out" feature. Consider for example links that launch > pop-ups with some snippet of information in a smaller window. You > frequently want these to have a very stripped down look-and-feel. This > can be used for e.g. context help. I've seen a lot of sites like this > and worked on some. > > > http://www.zope.org/Members/zopepaul/zopesitethemesdiagram.png > > > > This isn't revolutionary stuff. It's a meme that appears in Typo3 and a > > few Python templating systems. > > (snip) > > > At the
[Zope-CMF] Meld2, was Re: Proposal for hooking rendering
(changing the subject to avoid hijacking Paul E.'s thread any further) On Wed, Nov 30, 2005 at 02:48:12PM +, 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
[Zope-CMF] Re: Proposal for hooking rendering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Winkler wrote: > On Wed, Nov 30, 2005 at 09:40:40AM +0100, Paul Everitt wrote: > >>Paul Winkler wrote: >> >>>3) Universal. The corporate id is not optional. It gets imposed on >>>every page in a site. >>>""" >>> >>>That goes too far IMO. Opt-in is a pain, but if you remove it, we need >>>to add an "opt-out" feature. Consider for example links that launch >>>pop-ups with some snippet of information in a smaller window. You >>>frequently want these to have a very stripped down look-and-feel. This >>>can be used for e.g. context help. I've seen a lot of sites like this >>>and worked on some. >> >>That policy can be implemented in the tool itself. For this small >>proposal, the change wouldn't care. The tool could just return back the >>same then passed, unchanged. [wink] > > > OK, as long as it's possible somehow :) This should probably be an adapter lookup on the original view. > >>>So this wouldn't work for PageTemplate instances in the ZODB, >>>e.g. in portal_skins/custom/ ? >> >>Ok, I picked the wrong spot for the proposed implementation. (I'm not a >>CMF guru, but I'd like to contribute.) Whatever implementation is >>chosen would need to cover both FS and customized template output. > > > When you customize a FSPageTemplate, you get a plain ZopePageTemplate. > So you'll need to find a way to post-process the output of those > without requiring a change to core Zope, or this becomes a Zope > proposal. Unfortunately I haven't a clue how you could avoid that. I've contemplated changing that, in order (e.g.) to provide a "diff with original source" feature. If we customize *views*, rather than *templates*, then the ZODB-based view could be responsible for hooking up the pipeline. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDjd5o+gerLs4ltQ4RAg1ZAJ0beDRw6OowJ4BL5u3MwauF6bwmHQCeL9Dc JFKigXDLXY3IIf9ien+6ulk= =52HI -END PGP SIGNATURE- ___ 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
Re: [Zope-CMF] Meld2, was Re: Proposal for hooking rendering
On Wed, Nov 30, 2005 at 01:16:08PM -0500, Paul Winkler wrote: > I need to post some reuse examples OK, here's a simple one: > http://w oops, didn't get the URL in. http://slinkp.com/code/zopestuff/templates/examples.tgz -- 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
Re: [Zope-CMF] Re: Proposal for hooking rendering
Paul Winkler wrote at 2005-11-30 10:33 -0500: > ... >When you customize a FSPageTemplate, you get a plain ZopePageTemplate. >So you'll need to find a way to post-process the output of those >without requiring a change to core Zope, or this becomes a Zope >proposal. Unfortunately I haven't a clue how you could avoid that. Instead, you change the "makeZODBClone" (or similar method) of "FSPageTemplate" and create a (new) "CMFPageTemplate". (rather than a plain "ZopePageTemplate"). This would be a good thing (not only in the light of Paul's proposal) as a plain "ZopePageTemplate" behaves too differently from a "FSPageTemplate" (i.e. it is not "Caching Policy Manager" aware). -- Dieter ___ 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
Re: [Zope-CMF] Re: Proposal for hooking rendering
On Wed, Nov 30, 2005 at 08:24:56PM +0100, Dieter Maurer wrote: > Paul Winkler wrote at 2005-11-30 10:33 -0500: > > ... > >When you customize a FSPageTemplate, you get a plain ZopePageTemplate. > >So you'll need to find a way to post-process the output of those > >without requiring a change to core Zope, or this becomes a Zope > >proposal. Unfortunately I haven't a clue how you could avoid that. > > Instead, you change the "makeZODBClone" (or similar method) > of "FSPageTemplate" and create a (new) "CMFPageTemplate". > (rather than a plain "ZopePageTemplate"). > > This would be a good thing (not only in the light of Paul's > proposal) as a plain "ZopePageTemplate" behaves too differently > from a "FSPageTemplate" (i.e. it is not "Caching Policy Manager" aware). Good idea. We'd probably also want a migration script to convert existing ZopePageTemplates under portal_skins into your new CMFPageTemplate. -- 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
Re: [Zope-CMF] Re: Proposal for hooking rendering
On Wed, Nov 30, 2005 at 08:24:56PM +0100, Dieter Maurer wrote: | Paul Winkler wrote at 2005-11-30 10:33 -0500: | > ... | >When you customize a FSPageTemplate, you get a plain ZopePageTemplate. | >So you'll need to find a way to post-process the output of those | >without requiring a change to core Zope, or this becomes a Zope | >proposal. Unfortunately I haven't a clue how you could avoid that. | | Instead, you change the "makeZODBClone" (or similar method) | of "FSPageTemplate" and create a (new) "CMFPageTemplate". | (rather than a plain "ZopePageTemplate"). | | This would be a good thing (not only in the light of Paul's | proposal) as a plain "ZopePageTemplate" behaves too differently | from a "FSPageTemplate" (i.e. it is not "Caching Policy Manager" aware). But then again, neither is FSImage/FSFile and OFS.Image/OFS.File. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.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
[Zope-CMF] Re: Meld2, was Re: Proposal for hooking rendering
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. Okay, so say the template designer has a big where I am to put the document body. There is a different way of displaying that for each content type. Inside that, I need, say, an , a couple of s and whole bunch of structural content for the actual document body. Do I output those variable elements with python with print statements? To be honest, I think I'm just a little uncomfortable with the "procedural" approach to templating, It seems a little poorly structured and prone to error, e.g. if I'd have to manipulate things in loops etc. Basically, instead of relying on syntax (e.g. TAL) that lets me declare what I want (put X here, loop over these), I'd have to rely on patterns and APIs in a fully-featured programming language. It seems a bit easy to miss a tag or treat something as iterable when it wasn't meant to. To that extent, I prefer the separation of concerns in a scenario with Five views (i.e. view classes bound to logic, individually unit testable, well-defined boundary between view logic and presentation) and TAL expressions only. And again, for the "site themer" role, a layer on top of that like what Paul is describing sounds appealing. (then again, I spent today learning Tiles, and either alternative is better than that ;-) That's not to say your work isn't intriguing though. I reserve the right to become convinced. :-) Martin -- (muted) ___ 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
Re: [Zope-CMF] Re: Proposal for hooking rendering
On 11/30/05, Paul Everitt <[EMAIL PROTECTED]> wrote: > Still, I'm hoping that my small, 3-line proposal doesn't get changed > into a "let's replace templating systems" discussion. :^) I'm trying to > find the smallest necessary part to cover the maximum interest. > > Again to the CMF community: independent of this proposed solution, is > this corporate ID a problem worth supporting investigation? Personally I am very much in favour of a small change that makes it more likely that people will experiment with using XSLT or any other system they like. On the other hand, in our work the design part of the process never fits into a workflow like this. We don't ever need to apply a global theme to a core set of templates; rather, the design of entire templates and layouts changes between clients. So FWIW the specific problem as expressed isn't one we need to solve. In short, I strongly agree with every one of your numbered list items except "1) Don't make corporate ID people learn anything new" - I'm not sure I have ever met any corporate ID people. But perhaps that's just us. ___ 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
Re: [Zope-CMF] Re: Meld2, was Re: Proposal for hooking rendering
On Wed, Nov 30, 2005 at 08:54:34PM -, Martin Aspeli wrote: > >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. > > Okay, so say the template designer has a big where > I am to put the document body. There is a different way of displaying that > for each content type. Inside that, I need, say, an , a couple of > s and whole bunch of structural content for the actual document body. > > Do I output those variable elements with python with print statements? Good lord, no! You'd do the same thing you do today with ZPT: Write a template for each content type. Each one would be used by an associated bit of Python code, which in a Zope implementation of Meld2 could be a Script (Python). The script would take nodes from the main template and insert them into the content type template, just like you use ZPT macros. Filling "slots" is easy too. My reuse example was intended to make this clear. If you don't want to grab the tarball I just posted it in a comment here: http://plope.com/Members/slinkp/meld2_update In case it's not clear, the print statements you often see in Meld examples are just for command-line demo purposes. A Meld object can be converted to x(h)tml by treating it as a string. So in my hypothetical Zope / Script (Python) implementation, the script would simply return the Meld object. The template might come from a File instance. Like so: ## Script (Python) "foo_form" from Products.Meld2 import Meld2 foo_form = Meld2(container.foo_form_template()) main = Meld2(context.main_template()) # ... using elements of main template and populating data goes here... return foo_form I think this discussion would be a lot more productive if I had more full-featured examples to share. Working on that. This is all at a *very* early stage. > To be honest, I think I'm just a little uncomfortable with the > "procedural" approach to templating, It seems a little poorly structured > and prone to error, e.g. if I'd have to manipulate things in loops etc. How is a python loop more error-prone than tal:repeat? > Basically, instead of relying on syntax (e.g. TAL) that lets me declare > what I want (put X here, loop over these), I'd have to rely on patterns > and APIs in a fully-featured programming language. It seems a bit easy to > miss a tag or treat something as iterable when it wasn't meant to. I'm having trouble connecting this fear with anything that's actually in Meld2. I don't know what you mean by "miss a tag". And if you treat something as iterable that isn't, you get a TypeError as always in Python code. When do you think that would happen, and how is that harder to debug than ZPT? > To that extent, I prefer the separation of concerns in a scenario with > Five views (i.e. view classes bound to logic, individually unit testable, > well-defined boundary between view logic and presentation) and TAL > expressions only. Hey, I like that stuff too :-) > And again, for the "site themer" role, a layer on top of > that like what Paul is describing sounds appealing. I'm a Paul too :-) > That's not to say your work isn't intriguing though. I reserve the right > to become convinced. :-) I reserve the right to decide it's a terrible idea :-) I think it will take a real project to determine that. And I don't expect this to have rapid uptake in the Zope world. Backward compatibility is king and I don't have a story for leveraging existing ZPT. -- 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
Re: [Zope-CMF] Re: Meld2, was Re: Proposal for hooking rendering
On Wed, Nov 30, 2005 at 08:54:34PM -, Martin Aspeli wrote: > ... And again, for the "site themer" role, a layer on top of > that like what Paul is describing sounds appealing. Just to be clear, I wasn't trying to say that Meld2 serves the same purpose as Paul E's proposal. Rather, I was going off on a tangent about template languages. OTOH, Meld2 fits into a pipeline model much better than ZPT (at least, I've never heard of anybody treating a rendered ZPT as something to feed back into the ZPT engine, and if I did, I'd think they were nuts.). So Meld2 would be one possible way to implement the site theming in Paul E's proposal. But we're pretty thoroughly OT now, and there's nothing CMF-specific about Meld2 (heck there's not even a Zope implementation yet), so I'll stop now :-) -- 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
Re: [Zope-CMF] Five:traversable and PortalContent
On 11/30/05, Lennart Regebro <[EMAIL PROTECTED]> wrote: > I think it *is* in the core now. I'm not sure it should be, though. The only five:traversable declarations I see in the core now are for the workflow and types tools. > It's there to allow you to make views for objects, and I'm not at all > sure it's a good idea to have that feature turned on for everything > like that. It has caused me trouble earlier, I know that. Right. Clearly it messes something up, but I'm not sure what exactly. So for folks working on CMF viewification, have you seen this problem? Or do you declare traversable at some other level? Brent ___ 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
[Zope-CMF] Re: Re: Meld2, was Re: Proposal for hooking rendering
Paul W, I think your proposal sounds interesting, and I'd love to play with some real code in a Zope/CMF/Plone setting. Perhaps my "fears" are irrational, it's a bit too hard to speak to all this since it's just abstract ideas in my mind. I think a demo e.g. with a simple replacement for main_template and the ability to serve up, say, a simple navtree and a Document body would be very instructive. If anything, it's an interesting experiment. Martin ___ 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
[Zope-CMF] Re: Re: Meld2, was Re: Proposal for hooking rendering
Do I output those variable elements with python with print statements? Good lord, no! You'd do the same thing you do today with ZPT: Write a template for each content type. Each one would be used by an associated bit of Python code, which in a Zope implementation of Meld2 could be a Script (Python). The script would take nodes from the main template and insert them into the content type template, just like you use ZPT macros. Filling "slots" is easy too. My reuse example was intended to make this clear. If you don't want to grab the tarball I just posted it in a comment here: http://plope.com/Members/slinkp/meld2_update I had a look at this now. To be honest, I think it's probably a step back from the METAL approach to reuse, because, to my mind, at least, the "template" and "slot" concepts are logically different, but they're marked up the same way, using meld:id. If you look at the reuse_derived.xhtml template, there's no way apart from the comments to realise what's dummy content and what will be integrated into the main page. For the same reason, I find the python confusing - I have to remember to save tag (the title), then replace the bulk of my template, then re-insert the saved tag. This is what I mean by having to learn patterns and not syntax. It seems to me that this pattern would be so common it should be handled by the framework, not by my code, at least. But then you'll start inventing more syntax in the template (probably). The greater point, though, is that the page designer, in your example, would still be thinking just as carefully about how these templates interact as he would using METAL. In that case, having explicit syntax for it is probably better than letting the joining .py script do that logic (to avoid one in a dozen of such scripts for different content types making some silly mistake and compositing it slightly wrong... unless you start factoring out methods to do some of this replacement, but then you are simply displacing complexity, and displacing it away from the place where it logically occurs - in the template compositioning). And if I think about what that syntax may look like, the METAL syntax is actually pretty close to an ideal. That said, this is slighly different from the simpler use case of simply replacing parts of a page. As a thought experiment, consider a system where the templates are like Meld2 XHTML pages with meld:id for placeholders where dynamic content goes, but that also allow the use of METAL for compositioning. Then again, I'm not quite sure how much that gains over using tal:replace="@view/something" and doing away with more the complex parts of TAL. Well, I suppose the complexity of tal:repeat, tal:condition etc. would be moved away from the template designer. Martin -- (muted) ___ 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
[Zope-CMF] Frostbite: New Release
Tres has a new release 0.4 of Frostbite at http://palladion.com/home/tseaver/software/Frostbite that addresses some of these issues. Suresh ___ 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
[Zope-CMF] CookieCrumbler redirects to login page
My site is redirecting logged in users to the login page intermittently without any error message (on the screen, error_log or event.log even with VerboseSecurity installed) when they access certain potions of the site. What changes do I need to make to get the permission that was denied? Can we fix CookieCrumbler to put a portal_status_message and put the full message in the error_log? Suresh ___ 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
