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
>         zope-cmf@lists.zope.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

Reply via email to