Re: [Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
On Fri, 2007-01-05 at 10:22 -0500, Jim Fulton wrote: > Martijn Faassen wrote: > > > > Just splitting stuff up into little flexible pieces won't attract > > people. If our goal is to attract Zope 3 developers we need to make it > > easy to get started. We can also say that Zope 3 is componentized and > > flexible and all that, and this will attract developers too, but if the > > first bit is too hard all our talk about flexibility will lead to nothing. > > > > So, we need to do both: make it easy to get started, and componentizing > > for greater flexibility later. If we just do the first, we make Zope 2 > > style mistakes and end up with a monolithic system that should be easier > > to develop with. If we just do the latter, we make Zope 3 style mistakes > > and end up with a well componentized system that isn't used a lot. > > Agreed, we need both. We should understand though that the thing I'm > calling (soley for the sake of discussion) is probably not a good > starting point. IMO, it could be if someone was working on it. > I also think that it would be a find project on it's own. Or maybe > there's another project that would serve better. I don't know. I'm coming in to this discussion very late but if one goal is to enable the creation of OFS-like applications on top of an OFS-less application server, does anyone have recipes for building the latter that could be used as a starting point? - Michael R. Bernstein michaelbernstein.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
On Jan 6, 2007, at 7:19 AM, Martijn Faassen wrote: Jim Fulton wrote: Martijn Faassen wrote: [snip] Just splitting stuff up into little flexible pieces won't attract people. If our goal is to attract Zope 3 developers we need to make it easy to get started. We can also say that Zope 3 is componentized and flexible and all that, and this will attract developers too, but if the first bit is too hard all our talk about flexibility will lead to nothing. So, we need to do both: make it easy to get started, and componentizing for greater flexibility later. If we just do the first, we make Zope 2 style mistakes and end up with a monolithic system that should be easier to develop with. If we just do the latter, we make Zope 3 style mistakes and end up with a well componentized system that isn't used a lot. Agreed, we need both. We should understand though that the thing I'm calling (soley for the sake of discussion) is probably not a good starting point. I think I miss a word here; the thing you're calling what? Sorry, OFS IMO, it could be if someone was working on it. I also think that it would be a fine project on it's own. Or maybe there's another project that would serve better. I don't know. I'm trying to understand what you're referring to here. :) I'm referring to the application we've been distributing in Zope 3 releases, which, for the sake of discussion, I've been calling the OFS and you've been calling the ZMI. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
On 1/6/07, Martin Aspeli <[EMAIL PROTECTED]> wrote: Hopefully, we'll see something else emerge as well that is conceptually a combination of the two: End user-oriented and pure Zope 3. The only issue here is whether Zope 3 itself is useful directly to end users, or something built on top (regardless of whether that's the OFS or something else). The issue that seems to be slightly controversial is whether the Zope 3 core developers should be responsible for that application. I don't think anyone's argued otherwise, of course, I'm just pointing to existing wisdom I've received and observed. I think we're all in agreement on this. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Martijn Faassen wrote: Martin Aspeli wrote: [snip] I think your thoughts resonate quite well with my own observations and/or confusion. I would, however, caution against becoming over-zealous in breaking things up. Zope 2, CMF and Plone are successful in large part because people get started quickly. If it takes fifteen trips to the cheese shop to understand how to get a page to say Hello world, I'm not sure people would bother. Most likely, that's solved by having use-case focused (and real-world tested) bundles or distributions that provide meaningful functionality of starting points. It's also solved by having some customisable "best-practice" components that are closer to the user. Learning from such examples is probably the main way people pick up new technologies and conceptualise how they can solve their particular use cases. +1 here. Just splitting stuff up into little flexible pieces won't attract people. If our goal is to attract Zope 3 developers we need to make it easy to get started. We can also say that Zope 3 is componentized and flexible and all that, and this will attract developers too, but if the first bit is too hard all our talk about flexibility will lead to nothing. So, we need to do both: make it easy to get started, and componentizing for greater flexibility later. If we just do the first, we make Zope 2 style mistakes and end up with a monolithic system that should be easier to develop with. If we just do the latter, we make Zope 3 style mistakes and end up with a well componentized system that isn't used a lot. Agreed, we need both. We should understand though that the thing I'm calling (soley for the sake of discussion) is probably not a good starting point. IMO, it could be if someone was working on it. I also think that it would be a find project on it's own. Or maybe there's another project that would serve better. I don't know. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Hi Jim & Martijn, For xParrot we have a case in point where the ZMI both helped and confused us. Because of the way the documentation is 'framed' (where available) it lead us to believe, initially, that ZOPE was the ZMI. The first incarnation of xParrot (an XML/XSLT provider) was intermingled with the ZMI. The next version two was mostly about driving the ZMI out of the equation. The OFS (if I understand correctly we are referring to the file/object representation of ZOPE) is still very valuable for reaching resources. In fact xParrot2 does not use the ZMI at all now but would not be what it was without the OFS. On the other hand for another project I use the ZMI and the Rotterdam skin to develop faster - providing a useful tree interface. The tree is key here. It is obvious reflection/inspection etc. are quite useful too, during development. I would suggest to accentuate the library side of ZOPE and provide the ZMI as a (lesser) example. For ZOPE3 to replace ZOPE2 a new application engine may be an idea. A powerful engine that is better than Rails - with some code generation - should be an enticing goal for some. Because, take it or leave it, programming with ZOPE is still (too) hard. I learnt Ruby on Rails in a few days. With ZOPE3 I often still am in the dire straights (after a year). We use ZOPE3 because of the superior component model and because it looked better for xParrot, at the time. And in fact, we have no regrets there as Andrew designed xParrot so it can be used without any understanding of Python/ZOPE now. So, there you have one great application without the ZMI. Let me wrap up saying that despite my criticisms I think you all did a great job. The stability and robustness of ZOPE3 is legendary. Deployment is a bit odd, but one gets used to that (I agree about the duplication - but then that is configuration too, it is not that bad). A strong 2007 wished for. Pj. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
