[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Martin Aspeli wrote: The general direction that web frameworks are moving in, led by Rails and to a certain extent Django, Pylons, TurboGears and arguably Plone in some circumstances, is that getting started must be quick, results must be rapid, the tools must support agile working practices and the learning curve must be managable. It was a long time ago and easy to forget, but this was what Zope(2) provided at a time where there was nothing else even close. Suresh ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
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? 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 trying to understand what you're referring to here. :) Anyway, I think Grok is one concrete project that's making it a lot easier to get started with Zope 3 technology. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Martin Aspeli wrote: Jim Fulton wrote: I'll make some small comments below, but I want to make a big comment to start. Zope 2 and Plone are both examples of extensible applications. In my note, I was trying to make the point that I think such applications have value. I'd like to see them exist. I'd like to see them done well. I think Zope 2 did it very well, in it's time. I think Plone and other applications have carried that forward successfully. At ZC, for better or worse, we are no longer in the business of applications that are extensible in that way. We build applications that are used directly by our customers. I think this is true of many Zope developers. *We* use Zope 3 as a library for building applications. Both uses are valuable and should be supported. The application that I've been referring to as the OFS (again, a more or less random name) is a pale imitation of Zope 2. This is very much what I read into your comments and I think it is an impotant architectural decision whether we're building an application or a framework (Plone itself struggles with that decision sometimes); The strong framework leaning that Zope 3 has adopted is probably to its benefit, and is almost certainly the main reason why we are able to benefit from Zope 3 at all today in the Plone universe (via Five). However, Zope 3 should not be and is not just a library that ZC and a few other people with deep investment in the framework use for their applications. To grow, stabilise, mature and become a good vehicle for selling work (I trust you because you're using Zope 3, rather than, I don't trust you becuase you're not using J2EE) the community needs a constant influx of new developers and interested parties - the first instance, users of the framework. The general direction that web frameworks are moving in, led by Rails and to a certain extent Django, Pylons, TurboGears and arguably Plone in some circumstances, is that getting started must be quick, results must be rapid, the tools must support agile working practices and the learning curve must be managable. Most people don't have the time to bet that reading a book or two will be worth the investment (of time) before they start doing something useful and productive. This to me is where we can learn from the success that Zope 2 and Plone have enjoyed (or been the victim of, as it may be architecturally speaking). The main reason people think about building applications in Plone at all (a somewhat self-contradictory notion) is that if they can re-use all the pretty UI and HTML/CSS primitives and user management and navigation elements and security and workflow from Plone, turning off the portlets and content types and junk they don't need and turning on the custom look-and-feel and extra content types and portlets and forms they *do* need, they get something up and running quicker, to a higher standard, than if they start from a palette of components and a blank .py file. In other words, as Martijn has said, I believe it is very important for the community to support meaningful distributions/app servers/higher level frameworks (singular or pural) that show off what Zope (3) is good at and how it's done, that can be customised and (this is where the CA approach really kicks ass) where future upgrades to this means you benefit, not that you need to re-fork it for your own needs. I would be worried if I felt that the Zope 3 community became only about components and left this real world but generic assembly work to someone else when no someone else would be interested or skilled or emotionally invested enough to care. In the Plone world, we have the focus of Plone-the-application that implies we have to make Plone-the-framework better. If things become *too* scattered, where is the focus of Zope3? (note: I'm exaggerating here, I think things are moving in the right direction not the wrong one, I'm just playing devil's advocate and exploring what I've seen from the Plone side of the fence) Note that there is nothing inherently hierarchical about ZODB. Of course, ZODB makes modeling hierarchies (and other graphs) much easier in many ways that working with non-object databases. Of course, I'm a big fan of the ZODB and would use it for all sorts of non-content-centric apps, whatever that means. :) Like I said, I'm quite tainted by Zope2/CMF/Plone. I like to model (many/some) problems as hierarchical data structures with concepts like one-to-many relationships as folders with content. I agree the ZODB isn't necessarily hierarchical, but all the use cases I've ever seen for it have been. :) Well, fortunately, thanks to setuptools and tools like easy_install and zc.buildout, you should only need one trip to the cheese shop (or wherever) and the dependencies should come along automatically. I'm also working on ways to automate packaging and app and all of it's dependencies together. That would be another useful step. I still find it a bit
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Martijn Faassen wrote: My hope is that with Grok we can inject some sensibilities into Zope 3 that focus more on getting things done easily and quickly. I think that the basis built with an attitude of reusable and flexible components is great to build a powerful getting things done easily and quickly system on top. But we really really need such a system, and I hope Grok will be more than just a new technology but will also help drive a shift in focus in the Zope 3 world. And I fully support it; it's even conceivable I could contribute one day, if I find time. This project is really exciting and deserves more traction than it has at the moment. It would be very interesting also if there was a path through which Plone developers and other Five-dependents could start using Grok productivity boosting tools. We have core Zope 3 developers here at this sprint (Philipp, Christian Theune), so I have some hopes we'll succeed. :) ... but it is a fine team :) So, I agree we need what Jim proposes. We just also need what Grok tries to offer. I think that as an open source development community that wants to grow, we need Grok a lot more than we need splitting up Zope 3 into eggs. +1, though perhaps one makes the other easier. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some ZPT insights needed
On Saturday 06 January 2007 07:37, Andreas Jung wrote: because Zope 2.10.2+ will use unicode as internal representation for page templates I am currently checking the options to get rid of UnicodeDecodeErrors for Zope 2.11 by providing some more intelligent conversion of non-unicode content. Basically I want if the content returned by expressions within a page template if unicode or non-unicode. If it is non-unicode it would be converted based on some policy (to be specified) to unicode. This would avoid any kind of UnicodeDecodeError (hopefully). This there a central place in the ZPT code were the evaluated expressions are inserted into the rendered HTML or some internal datastructure used for rending the ZPT? I just need to know where to look at but I have no idea so far :-) Yeah, there is. The engine does all the expression evaluation work. It already handles the I18n stuff, so you should be able to do your unicode conversions there too. The engine uses an expression context. This expression context has all sorts of ``evaluate*()`` methods. Most interesting to you will be the ``evaluateText()`` one. See ``zope.tales.tales``, ``zope.tales.engine``, ``zope.app.pagetemplate.engine``. I hope ... I am sure this is enough to get you started. :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Paul Everitt wrote: Thus, telling the Zope 3 core team to own and distribute the killer app is neither realistic nor fair. Move Zope 3 to its natural turf and collaborate with folks that feel passionate about other turf. Application != the framework. A very good point. Perhaps the future will be: Developer learns Grok. Developer likes Grok. Developer improves Grok. Developer finds that to improve Grok, he should help improve Zope 3. And then maybe s/Grok/Plone/g or s/Grok/something else/g. I'm obviously not in the business or position of telling people what to do (well, ahem, maybe I do, at least in the Plone world, but that's mostly just good intentions). My concern is that we should make the framework accessible and approachable, and that having a focal point and a path through the framework is an important part of that. Grok is encouraging to me in that regard. Plone is quite actively (but not wholesale any time soon) moving in a direction where it becomes a strong consumer of Zope 3. Hopefully, we'll see something else emerge as well that is conceptually a combination of the two: End user-oriented and pure Zope 3. I don't think anyone's argued otherwise, of course, I'm just pointing to existing wisdom I've received and observed. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Some ZPT insights needed
Andreas Jung wrote: Hi, because Zope 2.10.2+ will use unicode as internal representation for page templates I am currently checking the options to get rid of UnicodeDecodeErrors for Zope 2.11 by providing some more intelligent conversion of non-unicode content. Basically I want if the content returned by expressions within a page template if unicode or non-unicode. If it is non-unicode it would be converted based on some policy (to be specified) to unicode. This would avoid any kind of UnicodeDecodeError (hopefully). This there a central place in the ZPT code were the evaluated expressions are inserted into the rendered HTML or some internal datastructure used for rending the ZPT? I just need to know where to look at but I have no idea so far :-) This kind of automagic unicode error defeating logic scares me. With Silva, we have a significant Zope 2 application that already takes care to output unicode to the page template engine. For a while we were using PlacelessTranslationService which has some hacks in place to do automagic conversion from unicode to an encoding. Granted this is the opposite direction than you are proposing, and my intuition is that your direction may be less scary, but I'm still scared. Not having unicode errors can make debugging of pure-unicode applications harder. Bugs sneak in pretty easily and you end up with non-pure content. I'd therefore like it if there were a way, application-root specific, to turn off any auto-conversion behavior. Do you think that would be possible? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some ZPT insights needed
--On 6. Januar 2007 12:15:19 -0500 Stephan Richter [EMAIL PROTECTED] wrote: On Saturday 06 January 2007 12:03, Andreas Jung wrote: returns always unicode for non-strings but keeps standard Python strings as they are. I think we always require to return unicode text within Zope 3, which is a good policy so there should never be a regular string in there. this policy must be enforced? :-) I have some ideas how make resolving UnicodeDecode error configurable but I am not sure if this code should go into the Zope 3 or should remain in the Zope 2 core. Does Zope 3 has to deal with such kind UnicodeDecode errors? I think this is a pure Zope 2 problem at this point, no? We certainly have way of handling UnicodeDecode errors. If you can show that this could potentially be a problem in Zope 3 as well, I would be for adding your UnicodeDecode resolver to the Zope 3 core. It's possibly a major Zope 2 issue. However since we are putting more and more Zope 3 stuff into Zope 2 is becomes also (in some way) a Zope 3 issue. I just wonder if it would be better to move more logic into the related Zope 2 wrapper code (making it more fat) or putting it into the Zope 3 core... I have to brainstorm about it. BTW, weren't you in the room when we had the initial discussions pretty exactely 5 years ago? Yes, you were! :-) http://wiki.zope.org/zope3/Feb2002InternationalizationSprint Oh my god :-) Yet some more years we survived with Zope :-) -aj pgp7USG8D73j1.pgp Description: PGP signature ___ 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.fdrake at gmail.com 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
[Zope3-dev] Error Type: IOError in http://wiki.zope.org/zope3/
I would like edit http://wiki.zope.org/zope3/FAQ/ page but I've this error when I save or preview the page : Error Type: IOError Error Value: [Errno 122] Disk quota exceeded Someone can fix it ? Thanks, Stephane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
