[Zope-CMF] A funding initiative to improve the software stack
Hi, CMF folks. Munwar and I would like to start public discussion about Goldegg, a funding initiative for advancing Zope 3 in the Plone/CMF/Five software stack. In summary, Goldegg provides funding to get Zope 3 into the near-term roadmaps of the stack. Specifically, the funding initiative helps get the leaders of these roadmaps working in coordination on the next releases. As background, a few months ago I circulated a "CMF++" proposal, where money was pooled to produce 2 CMF releases that leveraged some of Zope 3. Munwar Shariff from CIGNEX convinced a Plone customer to spend money on an expanded version of this proposal that included Plone's Zope 3 near-term roadmap. CIGNEX asked me to be project co-coordinator with Munwar. We have talked quite a bit with many of the stack leaders and we're now ready to open up the discussion. We have some content ready and are preparing a small little site for news. The next few emails will discuss the proposed projects for the Goldegg One funding cycle covering the next 3 months. In the coming week we will provide more information about the roadmap items we're helping to support. However, Goldegg isn't a new software effort. Rather, it funds existing efforts. The first cycle of Goldegg funding, in fact, slots most of the money into already-discussed CMF activities. Thus, most of the conversation will happen in the CMF, Five, and Plone mailing lists. We will, though, start talking to other companies that want to pool money. If you make money off of the stack and want to see its architecture improve in the next release cycles, Goldegg is the best chance you'll get to have an impact. Including the impact of shorter release cycles! I'm available to chat to anybody that has questions about this. Munwar and I have listened to lots of people and we're trying hard to do things the best way possible. It's a tough job to balance all the interests while still giving this customer the right outcome. Thus, we need to ask you for patience on things we mess up. We might not get it right the first time, but we'll listen and keep trying. I also need to give huge kudos to CIGNEX for making this happen. They produced the customer funding and even matched it with internal funding. Thus, CIGNEX has primed the pump for a near-term Five-ification roadmap, and they're doing it by giving money to existing leaders for existing ideas. This is a brilliant and generous step. It's up to the rest of us -- businesses with funding contributions, community with code and ideas -- to show whether monetary investment can fill medium-term needs. --Paul and Munwar ___ 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: A funding initiative to improve the software stack
Jens Vagelpohl wrote: On 25 Aug 2005, at 18:27, Paul Everitt wrote: Hi, CMF folks. Munwar and I would like to start public discussion about Goldegg, a funding initiative for advancing Zope 3 in the Plone/CMF/Five software stack. In summary, Goldegg provides funding to get Zope 3 into the near-term roadmaps of the stack. Specifically, the funding initiative helps get the leaders of these roadmaps working in coordination on the next releases. Yeh, yeh, ya got me on that one. :^) Hm. I think we're waiting for more details ;) Ok, here's some more details, sorry for the delay! There is a site: http://www.goldeggstack.org/about/home/ ...with an FAQ: http://www.goldeggstack.org/about/faq ...and a "primer" about the Goldegg funding initiative: http://www.goldeggstack.org/about/primer In a sec I'll send a note about a sprint. The site has other material which I'll be finishing in the coming days and discussing separately. But in general, kudos to the scheme as a whole. It is a fantastic idea to put actual customer funding into the freely available software stack which hasn't seen much of that in its history. Most funding has always gone to specific customer projects where good ideas or software tend to be locked up, out of reach of the core software package. Right, and worse, the funding is almost exclusively to create new software. There isn't much funding for people that guide the whole thing and make long-term decisions. ZC has carried the weight on this throughout the years and we're all lucky for this. Hopefully this initiative will go a step further and fund people in the community that play this role. Let's see how this idea goes. I'm trying to be safe and quiet during this early period while we figure out how to support you guys on the CMF 2.0 release. --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
[Zope-CMF] ANN: CMF/Five sprint, Sep 23-25, Vienna, couple of seats left
Howdy all. There is a castle sprint after the Plone Conference in Vienna. We added a section for the CMF/Five work. Details are here: http://www.goldeggstack.org/events/sprint1/home (Note: I might move this page to zope.org later.) There are 3 spots available on the CMF/Five part of this sprint. As a reminder (and to be extra-honest about the background), some of the CMF/Five sprinters are getting a travel stipend funded by the Goldegg initiative, which is supporting the CMF 2.0 efforts. However, these 3 spots don't come with the stipend, unfortunately, as we reached our budget already. We're particularly looking for people that will become contributors to Five, CMFonFive, CMF 2.0, and friends. If you're interested, please let me know as soon as you can. --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
[Zope-CMF] Re: CMF 1.6
Florent Guillaume wrote: I'd like to have some clarifications from the Plone team about what they expect to do w.r.t. events in CMF 1.6. I see two possibilities: 1. you guys are prepared to do the work needed for Plone products to use super() in manage_afterAdd & co, in which case I can merge my branch into CMF 1.6 2. you feel that's too dangerous and, as Plone intends to use CMF 1.6, I'll merge for CMF 2.0 only. Be aware that if 2. is chosen, you won't be able to use Zope 3 events at all with CMF 1.6. As a bystander, I have a suspicion that this discussion might be helped via an IRC appointment? --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
[Zope-CMF] Proposal for hooking rendering
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 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. 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. 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? 2) Is the idea of a portal tool wired into ZPT rendering a low-impact way to do this experimentation? Downsides: 1) Fundamental changes to the 1.x series might be suspicious. 2) This will, one day, be superseded by event subscribers. 3) Once this door opens, it might quickly turn into a monster (pipeline chains, etc.). --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
[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
[Zope-CMF] Re: Proposal for hooking rendering
Seb Bacon wrote: 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. Right, but I think parts of the motivation are similar. You need a new look-and-feel for each client. The person doing that look-and-feel (perhaps the client, if they already have a look-and-feel) need their work to be part of the processing. Does this happen by: 1) Asking them and the site scripters to share the same artifact? (Perhaps in your case the two roles conflate into the same person.) 2) Segregating the site scripting into one part and the look-and-feel into another part. 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. The motivation I described comes from a fair number of CMS consulting deployments in a different business model than yours, so that's possible. --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
