On 2/17/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > Incidentally, I find it difficult to make any argument about anything > because I fully appreciate many sides of the issue. :-)
You and me both :) > Gary Poster: > > one could argue that ZODB-based TTW dev got to be so problematic > > *because* it was so successful. There are strengths there. > > > > That said, I'm eager to see what you might think up as an alternative: > > I think both paths might be fruitful. Personally, I like the idea of third party alternatives. I think one of the most extreme and interesting "portlet" style implementations is Seaside's halos. When they're turned on, from what I can tell from the few times I've looked at Seaside and related documentation, you have a lot of customization power. It's not for everybody. But I think it's an implementation that personalizes Zope 2 style Through The Web capability by localizing what you edit to the component that you see. http://blogs.inextenso.com/seaside/blog/learning/0cf6f89c-7824-11d8-81ca-000a27b05150 http://www-128.ibm.com/developerworks/opensource/library/os-lightweight8/ CSS, HTML, and Smalltalk Source for everything is accessible - but it's accessible *in place*, not buried in a completely foreign interface or buried deep within a master template or script... It's still object oriented. Fascinating. But as I said earlier, this is something that Smalltalk's image oriented development supports (where all of the code lives inside a virtual machine/environment, away from any concept of files). The ZODB *can* behave like this, but that only works best if all concept of code-in-the-ZODB-image is separate from any-kind-of-data that might be in it. Anyways, that's an aside. It's not something I nor any of my customers need. But it would be an interesting thing to see someone take up. > The web root is my best idea for an alternative. > > Although I've been talking about addressing the needs of new adopters, > I'm really trying to address *my* needs. I want to build a complex web > site using Zope technologies, but I don't yet know enough about what I'm > building to be able to do any model/view separation. I intend to write > dirty, filthy, unmaintainable code. It's the right thing to do! If it > works, I'll clean it up. If it doesn't, I'll throw it away and try > something else. If I write it with Zope technologies, I know I can > succeed at cleaning it up because Zope has the most powerful tools out > there. If I write it with Apache, I'm certain I'll end up building my > own framework to support whatever flavor of messiness the solution > generates, it'll take twice as long, and it will be impossible to clean > up, so I'll have to start over if I want it to last. Gimme Zope! > > While I'm writing messy code, I also invent messy processes along the > way, and ZODB can't easily support my random new processes. I often > write automated tests for messy code. I often think to myself, "what is > the ugliest possible way I can write this?" Then I really do it and > laugh. That gets me moving when I'm stalled. Sometimes I rewrite > something ten times, relying on version control to get me back. It > turns out that the CMF skins tool is much better at supporting this kind > of work than Zope 3 currently is. > > I want Zope to encourage clean code just like everyone else, but > interesting things rarely start out clean! If Zope wants to be a > platform that people can use to invent crazy new things, it has to allow > for messy code and processes. Where doesn't it allow this? I wrote about this in Griddle Noise earlier this week. I feel more free to mercilessly restructure in Zope 3. I feel free to write things crappy or mediocre initially. Most of our big projects have been done under hard deadlines and technical debt was accrued along the way. But much of that debt was easy to pay back, sometimes with just a day or two of postmortem reconstructive surgery. How is the skins tool better than actual Python classes as view objects? They're still on the file system. They can still be under version control. The page templates are still on the file system. They can still be under version control. I guess I still don't understand how you're using Zope 3, because it sounds like you're using it very differently than I am. I've long since abandoned the ZMI. I never see that list of addable objects (in fact, in my newest applications, I completely bypass IAdding). I basically see the "Zope 3 ZMI" long enough to add one of my sites/applications. At that point, my skins take over, and that's all I see. The rotterdam skin is there as last resort to get out of trouble or to tweak local utility configurations. I guess I've just made some supporting libraries and frameworks to help me. I had this with Zope 2 too, but it's been easier to do with Zope 3. I encourage everyone to do this. -- Jeff Shell _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
