Re: Movies, audiences, wasted effort, was Re: [Zope3-dev] The vision thing
Am 07.03.2006 um 14:42 schrieb Martijn Faassen: We need a way to enable the Zope 2 TTW person to be productive without that person creating huge maintenance costs later on. Code created by ZMI developers should look like something that could also be on the filesystem, and can be checked into SVN, and refactored and developed further, i.e. be taken into real maintenance without major hurdles. I would identify these functionalities, to give people something they had in part through TTW. 1. Nearly zero setup: Just edit a function with a context given as parameter. That's actually at the base of an adapter. 2. Easy determination of context or locality: The nice thing with scripts is, that they can be placed somewhere in the content tree. But the meaning for the developer is, that they do not know much about interfaces, he simply sees the spot it should be used. Helping the developer to say "here do this" would be a big benefit. 3. Scripts only get value, if they can interact with a more powerful object api. This actually marks them as parts of something structured, not something to structure with. In Z2 you had your content objects, with rather big APIs, with realworld meaning, like a page or document. They basically build the model. In z3 we try to reduce that. It is no solution to say to the TTW developer here look at all these interfaces and choose the one you need, configure them with zcml and then start to use them in your script. This supports in my view, that scripts are only useful as part of something above core zope3. 4. Editing and testing without restarts. 5. As a question: Are scripts without acquisition useful? Function I would not see are: 1. Editing through a webpage 2. funny parameter definition and context magic With regards, __Janko Hauser ___ 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
Paul Winkler wrote: [snip] 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. This is an issue that's important to me, and to Jim. We had a discussion about all of this in various weblogs a few months ago - I referenced them earlier in some of these threads. I get the impression that Jim wants to drop the promise that Zope 3 is going to gain TTW development features though. It hasn't happened so far, and it's misleading peope. He wants to refocus these efforts to Zope 2's ZMI as far as I understand. I'm not sure whether this is the right wa to go - any presumed new-style TTW development tools would hopefully leverage the Zope 3 components, so even though I'm targeting a Zope 2 audience initially perhaps I'd still like my newly developed system to work with in a pure Zope 3 environment. This means that dropping our promise that we're going to regain functionality in Zope 3 may not be the optimal approach in all this. 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. It's good to say more people say this in different words. I have a very similar experience. On the one hand, Zope 2 TTW development is a great marketing feature to draw people in, and a great way of working for a certain group of people, some of whom will never become a software developer because they don't even want to. On the other hand, this way of working in Zope 2 has produced hard to maintain code, and creating UIs for it all sometimes has been a waste of effort that could've been better spent on making the APIs better, say. We need a way to enable the Zope 2 TTW person to be productive without that person creating huge maintenance costs later on. Code created by ZMI developers should look like something that could also be on the filesystem, and can be checked into SVN, and refactored and developed further, i.e. be taken into real maintenance without major hurdles. 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] The vision thing
On Mar 6, 2006, at 10:44 AM, Andrew Sawyers wrote: 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* :) TTW is very very useful. Not everyone has access to all of the tools all of the time. I have been developing in Zope for at least 5 years and 90% of what I do to build websites is TTW. Options are good, they are called "features". 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: 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
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] 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
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
Re: [Zope3-dev] The vision thing
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. -- 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
Re: [Zope3-dev] The vision thing
On 3/5/06, Jim Fulton <[EMAIL PROTECTED]> wrote: > I think that one of the first steps is to agree on who our > target audiences are and target them individually. Zope has > a number of target audences, including: > > - Non-technical users who just want to crank our a web application >with little muss and fuss. This was the original focus of Zope 2 >and now Plone. > > - People who know what an app server is and know they need one. >People who know they need to reuse applications and need tools >to customise them. People who know they need rich servcies, like >security, transactions, etc. These are the people for whom Zope 3 >was written. > > - People who want straightforward tools for developing small to moderate >complexity sites in Python. I don't think we are servving this audience >well. > > Then there are more fragmented audiences, like people who want a dirt > simple way to create applications based on relational databases. > > My main point is that we need to consider each of these audiences, as > they have separate concerns. We need to be explicit about this and > have messages and technical solutions tailored to each audience. Right you are. Good refocusing post. :-) Zope3 does of course cater to audience #2 very well. Superbly even. It does not cater to audience #1 at all, and notably, don't think it should. Why? Because most of them do not want a set of tools, they want a complete CMS, or at least a framework and a large set of bits which you can stick on easily. The effort to cater to these people should be something written "for" or "on" or "with" Zope3, not a part if Zope3 itself, and includes such things as TTW development products and CMS stuff. We are evidently not serving audience #3 well, because they are complaining. I'm not sure what to do except make Zope3s basic bits easier to use by themselves, which everybody agrees to. So maybe we need THREE visions, and not one? Vision #2 (starting with that one because it's easier): Improving Zope3, refactoring a bit, putting ZCML on a diet and so on. All this seems to me to be straight on track, or? Vision #1: A CMS framework and TTW tools for Zope3. Vision #3: Eggs for the basic technologies. So where is Five and Zope2 in all this? Well, it continues to be an an "upgrade/transition" path for people that are using Zope2 now, but want to slowly move over to the #1 vision. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.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] The vision thing
On Sunday 05 March 2006 10:22, Jim Fulton wrote: > My main point is that we need to consider each of these audiences, as > they have separate concerns. We need to be explicit about this and > have messages and technical solutions tailored to each audience. I agree with that. Our first step is to understand our audiences well and then build a roadmap/vision based on our understanding. I'll note that a roadmap/vision is *not* a promise, but something that we want to work towards. Of course, the roadmap should also take resources and interests into account. 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
Re: [Zope3-dev] The vision thing
Geoff Davis wrote: ... * Can we address Jeff's concerns? If so, how? * What can we learn from Rails / Django / TurboGears? I think that one of the first steps is to agree on who our target audiences are and target them individually. Zope has a number of target audences, including: - Non-technical users who just want to crank our a web application with little muss and fuss. This was the original focus of Zope 2 and now Plone. - People who know what an app server is and know they need one. People who know they need to reuse applications and need tools to customise them. People who know they need rich servcies, like security, transactions, etc. These are the people for whom Zope 3 was written. - People who want straightforward tools for developing small to moderate complexity sites in Python. I don't think we are servving this audience well. Then there are more fragmented audiences, like people who want a dirt simple way to create applications based on relational databases. My main point is that we need to consider each of these audiences, as they have separate concerns. We need to be explicit about this and have messages and technical solutions tailored to each audience. 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] The vision thing
On 3/5/06, Geoff Davis <[EMAIL PROTECTED]> 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 > > I share some of Jeff's concerns. > > One thing that he has been doing that I think is really important for us > is to systematically explore Django / TurboGears / Rails to see what they > are doing that we can learn from. I have already seen several interesting > posts from Jeff on this list and would love to hear more from him on the > topic. > > I have two questions for everyone: > > * Can we address Jeff's concerns? If so, how? > * What can we learn from Rails / Django / TurboGears? To me it seems mostly that one of his concerns are that we are having the vision debate instead of a vision. :-) The other one is the same olf concern: We have no website full of hype. The second one should be easy to fix, but I think out of a general concern for peoples sensibilities, nothing is happening. Too much talk, not enough hockey. The first one I have no solution for, except agreeing on a vision. Which for me seems dead simple, but of course, other don't agree. ;-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] The vision thing
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 I share some of Jeff's concerns. One thing that he has been doing that I think is really important for us is to systematically explore Django / TurboGears / Rails to see what they are doing that we can learn from. I have already seen several interesting posts from Jeff on this list and would love to hear more from him on the topic. I have two questions for everyone: * Can we address Jeff's concerns? If so, how? * What can we learn from Rails / Django / TurboGears? Geoff ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
