The repeated "CMF Collector: Open Issues" e-mails always get my hope up that some of the issues I posted will get assigned. :-) What's the typical time it takes for an issue to be accepted and then resolved?
Peace, George On 12/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Send Zope-CMF mailing list submissions to > firstname.lastname@example.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.zope.org/mailman/listinfo/zope-cmf > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Zope-CMF digest..." > > > Today's Topics: > > 1. Re: Five:traversable and PortalContent (yuppie) > 2. Re: Re: Re: Meld2, was Re: Proposal for hooking rendering > (Chris McDonough) > 3. CMF Collector: Open Issues ([EMAIL PROTECTED]) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 01 Dec 2005 17:59:02 +0100 > From: yuppie <[EMAIL PROTECTED]> > Subject: [Zope-CMF] Re: Five:traversable and PortalContent > To: Brent Hendricks <[EMAIL PROTECTED]>, Zope-CMF List > <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi! > > > Brent Hendricks wrote: > > 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. > > Right. > > >> 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? > > This is just a testing issue. The new PlacelessSetup based tests don't > play well with the old tests that depend on Zope2.startup(). > PlacelessSetup tears down stuff that is set up by Zope2.startup(). > > I hope this is fixed now for 1.6 and 2.0, but if the tests in your > sandbox have a different order than in my sandbox you might still see > some broken tests. > > > Cheers, > > Yuppie > > > > > ------------------------------ > > Message: 2 > Date: Thu, 1 Dec 2005 13:03:20 -0500 > From: Chris McDonough <[EMAIL PROTECTED]> > Subject: Re: [Zope-CMF] Re: Re: Meld2, was Re: Proposal for hooking > rendering > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Nov 30, 2005, at 7:33 PM, Martin Aspeli wrote: > > > > >>> 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. > > In general, and this might be totally obvious, but I think the idea > of a meld-like system is to allow for truly minimal markup in html > templates. This was ZPT's original goal, but my experience at least > has shown that even allowing minimal flow control and declaration > inside the template (e.g tal:condition, tal:repeat, tal:define) has > the practical effect of making it unlikely for effective > roundtripping of the template between a designer and a programmer. > > For my projects, I have found that besides filling slots of a main > template with other dynamically generated pieces of HTML, I just > don't use METAL very often. I realize that this is not the case for > systems like Plone, where it's used frequently. But given my minimal > usage, it makes me wonder if there's some "lessons-learned"-derived > pattern/API that would make it dead-easy to define a "main template" > with slots and replace those slots with pieces of meld-derived html, > throwing away the capability to make it easy to allow for arbitrarily- > nested macros as METAL allows. > > - C > > > > ------------------------------ > > Message: 3 > Date: Fri, 02 Dec 2005 04:09:56 -0500 > From: [EMAIL PROTECTED] > Subject: [Zope-CMF] CMF Collector: Open Issues > To: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > > 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 > > http://www.zope.org/Products/PTK/Tracker for bug reports and feature requests > > End of Zope-CMF Digest, Vol 29, Issue 2 > *************************************** > _______________________________________________ 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