Re: [Zope3-dev] Two visions
On Feb 28, 2006, at 7:39 AM, Martijn Faassen wrote: So, my proposal would be to tone down the vision to what we have already: a co-evolving Zope 3 and Zope 2, with Zope 2 following and Zope 3 leading (or Zope 2 driving Zope 3 forward, however you want to see it). No renaming necessary. No change of course necessary. Zope 2 can stick to Zope 2 features as long as necessary so there's no rush to replicate Zope 2 functionality in Zope 3 any time soon. At the same time, Zope 2 requirements can drive the evolution of Zope 3. I know I sound conservative here, but I'm actually happy with the way things are working now. Let's not fix what isn't broken. We can make incremental steps to making it better, and I'm glad people are starting to understand the ideas behind Five, but I don't see the need for a change of direction. Regards, Martijn +1 Jake http://www.ZopeZone.com "Zoping for the rest of us" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
I think it is a huge mistake to lose Zope branding. After years of building up momentum behind a project, to head off into some strange developer code speak is just going to lose people who are not intimately involved. The world, after many years, gets versions. Stick to it. Works: Mac OS9 -> Mac OSX (10) Here was a mistake: Mosaic -> Netscape -> Netscape Communicator -> Netscape Gold -> Firebird -> Mozilla -> Firefox How about: Zope 2 -> Zope 3 You can change the core technologies, the packaging, the identity, but don't change the name. Jake http://www.ZopeZone.com "Zoping for the rest of us" On Feb 27, 2006, at 10:37 AM, Jim Fulton wrote: I'd like to get feedback on two possible visions for the future of Zope 2 and Zope 3. 1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2 - There will be lots of overlap between the Zope 2 and Zope 3 lifetimes. (Zope 2 might be supported more or less forever.) - Eventually, the gap between Zope 2 and will become very small. requiring a small leap. In this vision, Zope 3 would have to become a lot more like Zope 2, or we would lose features. 2) In an alternate vision, Zope 2 evolves to Zope 5. - Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server. Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree. - Zope 3 will explode. :) For many people, Zope 3 is first a collection of technologies that can be assembled into a variety of different applications. It is second a Zope 2-like application server. I think that these folks aren't really interested in the (Zope 2-like) application server. Zope 3 will continue as a project (or projects) for creating and refining these technologies. (It would probably make sense for this activity to to have some name other than "Zope". On some level, the logical name would be "Z" (pronounced "Zed" :). An argument against "Z" is that it would be hard to google for, but Google handles such queries quite well and I'd expect that we'd move to the top of Google Z search results fairly quickly. However, I'll leave naming decisions to experts. ;) Advantages of this vision: - Zope 2 users don't need to leave Zope 2. - Zope 3 doesn't have to reproduce all Zope 2 features. - There wouldn't be confusion about 2 Zopes. It is important that Zope 5 be backward compatible with both Zope 2 and Zope 3, although not necessarily in the same configuration. Many people are building Zope 3 applications today and they should not be penalized. Thoughts? 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/jake% 40zopezone.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: [Zope-dev] Two visions
That is a good set of ideas. Zope 2 installs into Zope 3. Jake http://www.ZopeZone.com "Zoping for the rest of us" On Feb 27, 2006, at 10:00 PM, Stephan Richter wrote: On Monday 27 February 2006 11:06, Lennart Regebro wrote: I like the vision of Zope2 becoming a set of extra packages you install for Zope3, to get backwards compatibility. Maybe this is the same as what you call Zope 5, maybe not. That would sound good to me!!! 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/jake% 40zopezone.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] Principles
> 1.1 We should have a clear message about where Zope 2 is going. The > message should give existing and prospective Zope 2 users an idea of how > long their code will continue to work on releases in the Zope 2 path and > what kind of upgrade process they will face as the Zope 2 line evolves. Couldn't this clear message be: "One day Plone (CPS, etc.) will run on Zope 3"? Jim Fulton's suggestion, btw, seemed to be that "One day Plone (CPS, etc.) will run on Zope 3 with the aid of an additional Zope 2 package." -- -J. Method ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Movies, audiences, wasted effort, was Re: [Zope3-dev] The vision thing
On Mon, Mar 06, 2006 at 05:13:57PM -0700, Jeff Shell wrote: > On 3/6/06, Paul Winkler <[EMAIL PROTECTED]> wrote: > > A similar app could've been written pretty quickly in Zope 3 by writing > > a schema and using browser:addform, browser:editform, and > > browser:schemadisplay. It would be interesting to see how that would go > > in the movie. I suspect that the movie author (named Sean Kelly i > > think?) would've complained about the xml "sit-ups" and the numerous > > server restarts. > > Those are bad options anyways. They do not have growth potential > either, as you then have to make the conceptual leap from "something > magically generated by this XML declaration" into "how do I customize > what happens on edit?" Actually I agree with you. Dynamic scaffolding has the same problems I was complaining about re. TTW development: it does a bunch of magic that you have to understand and know how to do from scratch the moment you want to go beyond it. In that paragraph I was only trying to fit zope 3 into the kinds of things done in that movie; some of his other examples are pretty magical too. "I write this UML model and presto, I get all this with zero lines of code, wow neat." What I'd really like is something like what you say later on: > This is an area where Rails is particularly strong. I'm normally not a > fan of code generation. But their tool generates just-enough. It's > code you can actually understand and start building from, and a quick > run to the api docs they have online is usually all that's needed to > start understanding the code you're looking at. The code their tool > generates runs basically what you see if you have it dynamically > providing 'scaffolding', so the conceptual difference between the > automatically generated and what it gives you out of the box is pretty > small. OK, so what if we had a code generator that would read some browser:addform/editform/schemadisplay directives and spit out some functionally equivalent code (python, zcml, and zpt) that you could just start using and editing? I think that might be pretty handy. > I really like the concept of through the web tweaking and > manipulation. But I'm sick of templates and scripts. I'm not quite sick of templates yet, but I am sick of "scripts". I still use them in CMF because they give me a convenient place to do what I described: view-related glue that I can tweak without restart. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Movies, audiences, wasted effort, was Re: [Zope3-dev] The vision thing
On 3/6/06, Paul Winkler <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 05, 2006 at 04:04:48PM -0500, Benji York wrote:
> > Geoff Davis wrote:
> > >* What can we learn from Rails / Django / TurboGears?
> >
> > Fun presentation along those lines:
> > http://oodt.jpl.nasa.gov/better-web-app.mov
> >
> > One of the best put together movies I've seen.
>
> Really interesting stuff.
> I was struck by the way he presents zope/plone. He gives it a winning
> "fun factor" score for "hello world"... by doing through-the-web
> development. So he says "Zope [2] rocks" precisely because of features
> that many of us have been largely ignoring and advising against for a
> couple years now. The kind of thing that the built-in zope 2 tutorial
> shows you how to do.
>
> Why is Zope 2 TTW fun?
>
> - No restarts
>
> - No configuration
>
> That's certainly food for thought.
It definitely is. Why is Zope 2 TTW difficult? Ignoring the file
system aspects, one of the big stickers for us at Bottlerocket has
been:
If using Zope 2 TTW to get something done quickly, we need to use
something else for storage. Designing persistent objects AND
'templates and scripts' in the same database in the Zope 2 style never
quite meshed in my brain. The CMF did a good job of separating them
out, but then brought a larger overhead in terms of concepts to figure
out and grasp, and it didn't help the developer in a hurry. A finished
application like Plone does... But then you're working in Plone's UI
and Plone's universe and if that works for you, great. If not, there's
a lot of work.
Starting new projects would be *anguishing* here at Bottlerocket, as
we'd often lose two or three days just thinking of "what is the best
way, what is the fastest way, let's try that real quick, this thing is
too slow, this is too cumbersome, this doesn't look like what we
promised them", and so on.
> A similar app could've been written pretty quickly in Zope 3 by writing
> a schema and using browser:addform, browser:editform, and
> browser:schemadisplay. It would be interesting to see how that would go
> in the movie. I suspect that the movie author (named Sean Kelly i
> think?) would've complained about the xml "sit-ups" and the numerous
> server restarts.
Those are bad options anyways. They do not have growth potential
either, as you then have to make the conceptual leap from "something
magically generated by this XML declaration" into "how do I customize
what happens on edit?"
zope.formlib's forms do better. Although I (personally) find IAdding a
scary thing to work with and roll some of my own add-support
utilities.
I've been thinking about how to start up an application with very
little. I think that you could actually do quite a bit with Zope 3 and
introspection. If you had a folder that implemented 'IPersonContainer'
and it had a containment restraint on 'IPassenger, ICrewMember,
IPassengerGroup', you could (theoretically) have something (a ZCML
directive, a Python function, a base class) that could dynamically
generate a contents table, an add list, edit forms, all from that one
'IPersonContainer' declaration.
>From what I understand of Rails, you can have dynamic scaffolding
pretty easily, and watch your application change as you change the
underlying model (the RDBMS in most cases). But one of the real
strengths, I think, is the generator tool.
The generator tool is pluggable - other generators can be written and
installed. That alone is cool. As you install other plug-ins, they can
add generators to help you start using them. Or other generators can
be made that might stamp out an example web log application.
But the really cool thing about it is that it creates really easy to
use and understand start points. I can see the 'create' and 'edit'
actions it gives me.
def update
@article = Article.find(params[:id])
if @article.update_attributes(params[:article])
flash[:notice] = 'Article was successfully updated.'
redirect_to :action => 'show', :id => @article
else
render :action => 'edit'
end
end
I added a field (through a plug-in) that was too complex to be saved
by the basic 'update_attributes' action, so I had to extract it myself
and call a different method. I don't know if this is the best way to
do it, but this is what I got working this weekend:
def update
@article = Article.find(params[:id])
tags = params[:article][:tag_list]
@article.tag_with(tags) if tags
other = params[:article].reject{|k,v| k == 'tag_list'}
if @article.update_attributes(other)
flash[:notice] = 'Article was successfully updated.'
redirect_to :action => 'show', :id => @article
else
render :action => 'edit'
end
end
This is a really nice balance. Instead of just having something like
taking care of everything for me, or even have code
generated that subclasses from formlib.EditForm but doesn't actually
show the 'handleEdit' action taking care of things, I have something
right here
Re: [Zope3-dev] Re: RFC: Use ConfigParser for High-Level Configuration
Dieter Maurer wrote: > Philipp von Weitershausen wrote at 2006-3-5 18:17 +0100: > >>... >>Looking at your examples (especially the long one), I find the ZConfig >>version much easier to read. > > > While ZConfig allows you the describe related material together > and without indirections, the ConfigParser format forces you > to introduce indirections and to spread related definitions > over a longer area. Yes, this was my concern with it, too. Though the decouple spelling obviously also has advantages as you can configure a server once and then just refer to this server configuration from several instance configuration. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration
Jim Fulton wrote: At: http://dev.zope.org/Zope3/UseConfigParserForHighLevelConfiguration Sorry, working offline, can't check, hope I haven't missed anything crucial :-S Is a proposal for using ConfigParser, rather than ZConfig for high-level configuration. Comments welcome. This smacks of re-invention for the sake of it. I happen to like ZConfig a lot. The way it's used in Zope 2 is a little unpleasant, admittedly, but I think it makes a fine configuration language. The xml required for the schema is pretty trivial if you're coming from zcmhell... I must be missing some big reasons why you'd want to use an inferior config language and rewrite a big chunk of working, battle tested software, but I guess that's in the proposal.. Anyway, a big -1 from me, especially given the backwards compatibility issues prople like myself, with MailingLogger and a number of ZConfig-based, and Dieter, with his NNTP server and doubtless other things, will face. Fred, FWIW, I was really really happy to see that generic section go into the schema, I just haven't had a chance to use it yet... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] "visions"
Isn't there a [EMAIL PROTECTED] list this whole thing could shuffle off onto? *sigh* Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Movies, audiences, wasted effort, was Re: [Zope3-dev] The vision thing
On Sun, Mar 05, 2006 at 04:04:48PM -0500, Benji York wrote: > Geoff Davis wrote: > >* What can we learn from Rails / Django / TurboGears? > > Fun presentation along those lines: > http://oodt.jpl.nasa.gov/better-web-app.mov > > One of the best put together movies I've seen. Really interesting stuff. I was struck by the way he presents zope/plone. He gives it a winning "fun factor" score for "hello world"... by doing through-the-web development. So he says "Zope [2] rocks" precisely because of features that many of us have been largely ignoring and advising against for a couple years now. The kind of thing that the built-in zope 2 tutorial shows you how to do. Why is Zope 2 TTW fun? - No restarts - No configuration That's certainly food for thought. The sample app demos were also interesting... he kinda glosses over what exactly was the full zope/plone stack and how he did it, but since he generated a Plone content-like app from a UML model it's not hard to guess :) Notably it was the kind of app that sits squarely in the single-developer- in-a-hurry space. The "I just want some forms to save some data and I don't want to care how it works" space. The space where, as Jim keeps saying, zope 2 traditionally excelled and Plone lives today. A similar app could've been written pretty quickly in Zope 3 by writing a schema and using browser:addform, browser:editform, and browser:schemadisplay. It would be interesting to see how that would go in the movie. I suspect that the movie author (named Sean Kelly i think?) would've complained about the xml "sit-ups" and the numerous server restarts. (In the middle of the movie he gives a link to his article at http://www.developer.com/xml/article.php/3583081 which includes the line "The fad of applications using XML for their configuration files is dismaying, to say the least...") This is the kind of guy for whom TTW development really is compelling. Watching the "hello world" section reminded me of when I used to really enjoy doing that stuff. But there are some important things left out of that story. Why did I stop enjoying TTW work? Like a lot of Zope 2 developers: * I needed my work to live in CVS. ZODB history and undo isn't good enough as version control. * I needed to write tests that I can run without having a real ZODB and without starting up a server. * I needed a sane way to deploy software from dev to staging and from staging to production. ZSyncer is fine for what it does, but it too is a poor substitute for version control, shell scripts, make, et al. * The unix shell still beats the pants off the ZMI as a complete working environment (even with ExternalEditor, the find tab, etc.) * I got tired of bouncing between restricted and unrestricted code. I want to live in unrestricted code as much as possible. Ultimately the zope 2 restart time started to become less of a problem than dealing with all those problems when working TTW. For CMF development, I settled on a pretty nice compromise: templates and scripts in filesystem directory views, with the scripts doing only view-related glue. This got me files on the filesystem and in CVS, and no restarts when tweaking UI. The scripts are easily testable using CMFTestCase. Pretty nice way to work. I still have to deal with some restricted code, but I'm mostly resigned to that. In Zope 3, we take restarts and filesystem-only development for granted, because it's intended specifically for the audience that I'm a member of... developers who have those concerns. I'm hoping to see a similarly interactive, yet long-term-sane, working style evolve for in zope 3. Maybe we'll get there with Persisent Modules and fssync. If there's a moral to this story, it's this: Scaffolding that gets you up and running with a minimum of fuss is a great thing. Rapid interactive and iterative development is also a great thing. But if you can't easily transition from there to more complex apps that are still maintainable, it sucks. It's irritating to have to throw away some of your knowledge and completely replace it with new ways of thinking; it's better if the new knowledge strictly supplements the old. It's worse than irritating to have to throw away your work and rebuild it from scratch; it's better if your new work can cleanly leverage the old. Put another way, if we consider Jim's first two audiences, how do we teach a single person to move from "i don't want to have to care" to zope zen master / SVN contributor with minimal wasted effort along the way? Today I don't know if there's a clear coherent story to be told there, even for zope 2. If there was... wow, that would be a great. Sorry if I haven't really said anything new. -- Paul Winkler http://www.slinkp.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] RFC: Use ConfigParser for High-Level Configuration
On 3/6/06, Dieter Maurer <[EMAIL PROTECTED]> wrote: > In modern Zope[2] schemas, there is a general purpose abstract type > precisely for this kind of extensions. When Tres and I added this, we planned specifically to see how it was received by the Zope 2 community. If people liked the way this was done, it could be added to Zope 3. That said, I don't think Jim's concerns are limited to the Zope configuration schema, but extend to configurations that do not necessarily involve the Zope application server at all. It may be that a better foundation schema is something to experiment with, especially for non-Zope applications. I don't expect to have any time for this in the near future. -Fred -- Fred L. Drake, Jr. "There is no wealth but life." --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Use ConfigParser for High-Level Configuration
Jim Fulton wrote at 2006-3-5 13:56 -0500: > ... >Why do you think it's better to have to create a monolithic schema for all >applications bits that want to use the configuration file, rather than letting >individual applications define how to read their own data independently? You already can do this now with ZConfig -- no need for a monolithic schema: I recently implemented a ZServer based NNTP server. There was no monolithic schema required. The new "sectiontype" was described in "NNTPServer/component.xml", the configuration file simply imported the package and decribed the NNTP-Server. Formerly, this was possible only for a few abstract types with corresponding multisections (such as servers, storages, ...). In modern Zope[2] schemas, there is a general purpose abstract type precisely for this kind of extensions. -- Dieter ___ 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: RFC: Use ConfigParser for High-Level Configuration
Philipp von Weitershausen wrote at 2006-3-5 18:17 +0100: > ... >Looking at your examples (especially the long one), I find the ZConfig >version much easier to read. While ZConfig allows you the describe related material together and without indirections, the ConfigParser format forces you to introduce indirections and to spread related definitions over a longer area. An example: the logger configuration. In ZConfig: ... ... ... In ConfigParser: [eventlog] handlers = handler1 ... handlern [handler1] ... [handlern] As locality facilitates readability and understanding, ZConfig files tend to be easier to read and understand than ConfigParser ones. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Principles
On Sun, Mar 05, 2006 at 10:09:14AM -0500, Geoff Davis wrote: > One of the things that GTY recommends is to establish a set of agreed upon > principles for evaluating proposals. I think that having such a set of > principles would help us better focus our current discussion. Good idea. > Let's take a step back from the particulars of the various proposals > floating around and see if we can nail down some principles. Here is a > very rough, very incomplete start: > > 1. Zope should have a clear message about where we are going. > > I'm sure we all agree on this, but this is so broad that it is not very > useful. Here's a stab at refining it: > > 1.1 We should have a clear message about where Zope 2 is going. The > message should give existing and prospective Zope 2 users an idea of how > long their code will continue to work on releases in the Zope 2 path and > what kind of upgrade process they will face as the Zope 2 line evolves. +1 > 1.2 Ditto for Zope 3. +1 > 2. Zope should try to expand its developer base. > > Again, I am sure we all agree, but this is too broad to be useful. > > 2.1 Zope should leverage the work of others by moving toward an > architecture that allows one to easily use code from outside Zope. > > This effectively increases the developer base by letting us leverage the > work of others outside the immediate Zope community. I assume that this > (and integration) are the primary motivations driving the CA. > > 2.2 Zope should be useful for developers not using the full application > server stack. > > Again, this serves to increase our developer base by drawing in people > outside our traditional core audience. +1 > We probably need some principles about the Zope brand, and so on, That seems like the most contentious part, and a lot of Jim's suggestions and the ensuing discussion have focused on this. There are several possible principles here, which may pull in different directions because they target different audiences. I started writing some suggested principles but I don't want to start another cycle of repetitious debate on that topic; I'd first rather see some more feedback on the principles you suggested so far. -- Paul Winkler http://www.slinkp.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: The vision thing
On 3/5/06, Max M <[EMAIL PROTECTED]> wrote: > Geoff Davis wrote: > > Jeff Shell has posted some thought-provoking pieces on his blog that are > > relevant to Jim's recent attempt to better articulate a vision for Zope: > > > > http://griddlenoise.blogspot.com/2006/03/zope-crisis-of-faith-coming-this-march.html > > > > http://griddlenoise.blogspot.com/2006/03/crisis-of-faith-messengers-have-been.html > > > Griddle *Noise* and thats exactly what it is... noise. Well, I do love me the noise. [ Check me out at No Fun Fest 2006, Brooklyn! http://www.nofunfest.com/ Mar 17 2006 | http://euc.cx/aodl/ ] I say repeatedly that I'm not a good person. I'm cranky. I don't apologize for it. I see a Zope 3 deliverable in front of me that has half-assed versions of Zope 2 items (the page templates, etc). Zope 2 is far more mature here. I'd love to have a vision that would move these half-assed items out of the Zope 3 application server I have installed here, and fit them into a new vision that does match the maturity of Zope 2. And then, when those things are gone, I'll have a simpler Zope 3 to start from that doesn't have those elements as strange distractions. I'll ultimately have a Zope 3 where a third party developer might write a much better behaving through the web Page Template object and behavior. I'll have a Zope 3 with a simple core and easy-to-install extensions. I'll have a Zope 3 that I will be able to tailor to the needs of me and my customers, who have widely varying needs. I'll have a Zope 3 that I can make lean and mean and fast, with a minimum of configured objects and options threatening to take up memory and resources, which is going to be very important in an upcoming project. > He is probably following the discussions on the lists, and then he is > publishing his view on them on his blog instead of participating in the > dicsussion. It's hard to keep up with all of the discussions, and sometimes it's good to just get big ideas off the chest and open what I have to say up to a larger group of people. > We have probably all seen the Ruby On rails in 15 minutes video, where > they showcase their take on nineties web technology. > > I could probably do one that is a lot more impressive with an UML tool, > Plone, archetypes and ArchgenXML. And it would most likely last 10 > minutes... if I talked very very slowly. And I don't know of any UML tool that didn't have me reaching for the shotgun within 10 minutes. UML is great for sketching. If you want tools to do all your programming, you don't need Python. I think it's ridiculous that they hide the programming language and its usability under so many layers. > But that is not the point. He rants about Rails. But what are the > visions of rails? I don't see that anywhere on their website either. I think it's in pretty big type on the front page. "optimized for programmer happiness and sustainable productivity... write beautiful code by following convention over configuration." One of the best visions I've seen about Rails was saying that J2EE is Slow'n'Clean. It's totally proper. It's totally abstracted. There are lots and lots of XML configurations. Lots and lots of separated objects. And it's a lot of work to do something simple. PHP is the other end of the spectrum: it's quick, but dirty. It's a lot of work to do something 'clean'. Rails tries to provide "Quick'n'Clean". After some quick experiences with it this weekend, it mostly works. I think Zope could be a "mostly quick'n'clean." But right now, it's going back towards a "quick'n'mostly confusing". Ruby's `script/generate scaffold accounts expenses` command is beautiful. It generates an application based on a model. No huge layers like ArchGenXML or ArchgenUML. It uses the model in the database. It then *generates useful and usable starting point code for an application*. The generated interface is simple, and unlike a lot of code generation tools it actually feels like code that you can start modifying and working from. So you have a good starting point for an application, and you can pretty quickly start making it your own. The starting point is really basic, rather bland, but usable. So you know that you can start modifying it from there. It gives the experience of immediate results, as well as immediate "ok, now how do I start making it look/behave like I want?". > He is just another developer who wants Zope to consists of only those > elements that he is insterrested in. I don't mind there being other elements. But I don't want them in the way. I have different visions for me, for my customers, and so on. Some of their needs are VERY VERY VERY different than what a full Zope suite offers. But we still like Zope. As I've said, I've been using it in some form for nearly a decade now. Why can't I have my mid nineties experience again? Why can't I save my death march project in a day by moving to two out of three core pieces? Give Python programmers an excellent tool base built on sim
Re: [Zope3-dev] Zope Eggs
> I think a good goal would be to have something like this: A Zope > instance home aware package/egg loader, so that in an instance home > you could add in packages like this: > > $ bin/package install zc.catalog > $ bin/package install hurry This wouldn't be difficult to implement (at least in a simple way) -- easy_install (provided by setuptools) does downloads from package sources, and we experimented at the sprint with wrapping that functionality in order to bootstrap eggs. > > > On 3/5/06, Nathan R. Yergler <[EMAIL PROTECTED]> wrote: > > During the Zope3 sprint following PyCon, Paul and I, with Jim's > > guidance, began work on exploring how Zope can utilize eggs and be > > packaged using eggs. Since we're still experimenting with how eggs > > will be used, I wrote a script, zpkgegg, which reads the zpkg > > configuration information for a package and generates a "standard" > > setup.py from which an egg and vanilla sdist can be generated. > > > > You can find the script in subversion in the projectsupport project. > > For a brief overview of how the script is used, see README.txt (in > > http://svn.zope.org/projectsupport/trunk/src/zpkgegg/). The eggs > > generated by zpkgegg do not attempt to distinguish between "runtime", > > "testing" or "development" dependencies, so almost all packages will > > want zope.testing. README.txt contains a brief example of how to > > point easy_install at the appropriate folders so that easy_install can > > resolve the dependencies. > > > > Note that at this point we're still experimenting with how we'll use > > eggs, so suggestions, feedback and comments are welcome. > > > > Thanks, > > > > Nathan R. Yergler > > ___ > > Zope3-dev mailing list > > Zope3-dev@zope.org > > Unsub: > > http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.com > > > > > > > -- > Jeff Shell > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope Eggs
Cool effort. One thing that I noticed in Rails when I downloaded it this weekend was how you installed plug-ins. Very easy. There are various 'sources' that can be loaded up which work, I assume, in a similar manner to how you can point easy_install at a web page and tell it 'find links'. To install a plugin into an application instance (similar to a Zope instance home), it's just an effort of: $ script/plugin install acts_as_taggable The plugin is found, and installed in the instance home equivalent. This uses 'gems' under the hood from the looks of it, and adds in the knowledge of a Rails application layout. It was pretty gratifying, being able to start adding in functionality so easily. I think a good goal would be to have something like this: A Zope instance home aware package/egg loader, so that in an instance home you could add in packages like this: $ bin/package install zc.catalog $ bin/package install hurry On 3/5/06, Nathan R. Yergler <[EMAIL PROTECTED]> wrote: > During the Zope3 sprint following PyCon, Paul and I, with Jim's > guidance, began work on exploring how Zope can utilize eggs and be > packaged using eggs. Since we're still experimenting with how eggs > will be used, I wrote a script, zpkgegg, which reads the zpkg > configuration information for a package and generates a "standard" > setup.py from which an egg and vanilla sdist can be generated. > > You can find the script in subversion in the projectsupport project. > For a brief overview of how the script is used, see README.txt (in > http://svn.zope.org/projectsupport/trunk/src/zpkgegg/). The eggs > generated by zpkgegg do not attempt to distinguish between "runtime", > "testing" or "development" dependencies, so almost all packages will > want zope.testing. README.txt contains a brief example of how to > point easy_install at the appropriate folders so that easy_install can > resolve the dependencies. > > Note that at this point we're still experimenting with how we'll use > eggs, so suggestions, feedback and comments are welcome. > > Thanks, > > Nathan R. Yergler > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.com > > -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The vision thing
On Mon, 2006-03-06 at 09:45 +, Stefane Fermigier wrote: > Benji York wrote: > > Geoff Davis wrote: > >> * What can we learn from Rails / Django / TurboGears? > > > > Fun presentation along those lines: > > http://oodt.jpl.nasa.gov/better-web-app.mov I saw that last week from some internal folks at my work. While I despise TTW development, I will admit this presentation changed my opinion some on the audience whom might find it useful. Now if we can just make it so whatever they do TTW can be replicated as a base FS product for easy migration to the *right way* :) Would be a good video to highlight on zope.org (when it's done). Andrew > > > > One of the best put together movies I've seen. > > Yeah, really awesome! Should have won the Oscar! ;) > > Another relevant link: > > http://www.sitepoint.com/blogs/2006/03/04/zend-framework-is-out/ > > i.e. the PHP community trying to imitate us (+ an Eclipse-based ide, for > which there is also an interesting proposa, cf. > http://blogs.nuxeo.com/sections/blogs/fermigier/2006_02_13_about-the-eclipse > - but unfortunately not much traction). > > S. > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: traceback when running tests for zope.app.component
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 j.kartnaller wrote: > Benji York wrote: > >> jürgen Kartnaller wrote: >> >>> Benji York wrote: >>> I emailed the committer Friday about this, but no fix has been forthcoming, so I reverted the offending revisions. Hopefully a revised version can be reapplied soon. >>> >>> >>> Still the same problem after your revert ! >> >> >> The tests pass on my box and on all the buildbot machines (and they >> didn't before). Perhaps you're seeing a different problem. I didn't >> compare the tracebacks to be sure. > > > The traceback only occurs when running the test for zope.app.component : > > python test.py --package=zope.app.component > > A full test runs without problems. A trunk checkout fails for me with the same traceback when run with that command line. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEDFP2+gerLs4ltQ4RAkyOAJ9kIr6yWO7iK9sAkDOA8LxOTmHhdACfV+FU bt9FlEcGL/TCSBWQYzXT3kU= =w0Hz -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: traceback when running tests for zope.app.component
Benji York wrote: jürgen Kartnaller wrote: Benji York wrote: I emailed the committer Friday about this, but no fix has been forthcoming, so I reverted the offending revisions. Hopefully a revised version can be reapplied soon. Still the same problem after your revert ! The tests pass on my box and on all the buildbot machines (and they didn't before). Perhaps you're seeing a different problem. I didn't compare the tracebacks to be sure. The traceback only occurs when running the test for zope.app.component : python test.py --package=zope.app.component A full test runs without problems. Jürgen ___ 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: [Zope-dev] Two visions
Jim Fulton wrote: [snip] I wasn't trying to define app server. I was describing the Zope app server. As long as you realize you do risk confusion even by saying 'Zope app server'. To me, Zope 3 is an app server, so when you say 'the Zope app server' will include its functionalities too. 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] Re: traceback when running tests for zope.app.component
jürgen Kartnaller wrote: Benji York wrote: I emailed the committer Friday about this, but no fix has been forthcoming, so I reverted the offending revisions. Hopefully a revised version can be reapplied soon. Still the same problem after your revert ! The tests pass on my box and on all the buildbot machines (and they didn't before). Perhaps you're seeing a different problem. I didn't compare the tracebacks to be sure. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Z3lab] Zope 3 / Z3ECM April sprint in Paris at Nuxeo
Stefane Fermigier wrote: > Nuxeo, with the kind help of the Zope team of Chalmers > University, plans to organise a Zope 3 sprint on April 3-7 in our > premises in Paris. > I'm afraid we'll have to change the dates, to accomodate for several schedule contraints (including room availability). So the sprint date is now: 17-21 April 2006. S. > The focus of the sprint, like last year's successful sprint, will be ECM > (Enterprise Content Management). > > Last year's Paris sprint was a turning point for the Zope roadmap, when > it was decided to include Five in Zope 2.8, a decision which led to the > current state of the Zope landscape (CMF 2.0 / CPS 3.4 / Plone 2.5 / > Silva 1.5 - all full of Zope 3 components, etc.) > > We hope to make similar significant advances this year. > > Program: > > The current state of Z3ECM is currently best described in these slides: > > http://www.z3lab.org/sections/news/z3ecm-roadmap-september8593/ > > as well as on the www.z3lab.org website itself. > > 4 main themes for the sprint are currently emerging: > > - Repository: there is some unfinished conceptual and preliminary > implementation work to be done regarding document repository design > (including relations between documents, ORM-based storage, etc.) > > Ref: > http://www.nuxeo.com/publications/slides/versioning-and-relation/downloadFile/file/versioning-ep-2005.pdf > http://www.z3lab.org/sections/front-page/design-features/ecm-platform-concept/ > > - CPSSkins v3: Jean-Marc Orliaguet already has a very advanced > implementation, that currently is Zope 3 only. We plan to bridge it with > Zope 2 using Five to make it available on the current CMF-based > platforms (at least CPS 3.4). > > Ref: > http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/archive_view?category=cpsskins > http://svn.z3lab.org/trac/z3lab/browser/cpsskins/branches/jmo-perspectives/ > > - AJAX: we plan to generalize the current approach of CPSSkins v3, which > is to use a JavaScript MVC library that exchanges JSON data structures > with the server, to all the AJAX interactions. > > Ref: > http://blogs.nuxeo.com/sections/blogs/tarek_ziade/archive_view?category=AJAX > http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/archive_view?category=AJAX > > - XForms: we intend to make XML Schemas and XForms the new model for > documents and their representation in Z3ECM. This is specially important > for interoperability with the Apogee project (http://apogee.nuxeo.org/). > > Ref: > http://blogs.nuxeo.com/sections/blogs/eric_barroca/2005_09_05_ajax-does-not-compete/ > > At Nuxeo, we intend to make all these developments available either on > top on CPS 3.4, or for the next iteration of CPS (CPS 3.6). But we'd > also like to share these developments with the rest of the Zope 3 / CMF > / Plone / etc. communities, if they are interested. > > Participation: > > The sprint is open to experimented Zope 3 / CMF / CPS / Plone > developers. We already have booked 4-5 developers from Nuxeo, and > Jean-Marc Orliaguet and Dario Lopez-Kärsten from Chalmers. Please > join the discussion on the z3lab mailing list > (http://lists.nuxeo.com/mailman/listinfo/z3lab) or contact me > ([EMAIL PROTECTED]) if you would like to participate. > > The sprint is free (but you have to pay for your own travel and > accomodation). We (Nuxeo) will modestly provide free pizzas / sandwiches > / diet Coke, etc. > > NB: the dates (3-7 April) have been chosen so that long distance > travelers can go to the Swiss sprint afterwards (8-13 April). If this is > inconvenient for a majority of sprinters, we may change to the week > after the Swiss sprint (17-21 April) but this change has to be decided > quickly. > > I will confirm the date in a later announcement (next week). > > So, once again, let's followup on the z3lab list. > > S. > > -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source! ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The vision thing
Benji York wrote: > Geoff Davis wrote: >> * What can we learn from Rails / Django / TurboGears? > > Fun presentation along those lines: > http://oodt.jpl.nasa.gov/better-web-app.mov > > One of the best put together movies I've seen. Yeah, really awesome! Should have won the Oscar! ;) Another relevant link: http://www.sitepoint.com/blogs/2006/03/04/zend-framework-is-out/ i.e. the PHP community trying to imitate us (+ an Eclipse-based ide, for which there is also an interesting proposa, cf. http://blogs.nuxeo.com/sections/blogs/fermigier/2006_02_13_about-the-eclipse - but unfortunately not much traction). S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source! ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
