On 8/12/06, David Pratt <[EMAIL PROTECTED]> wrote:
Hi Jeff. Your approach is very interesting. There is lots room in Zope for differences in the way applications are tackled to deliver on requirements. My feeling is that explicit object metadata and some of the content-management-esque concepts in Zope fit prominently into the future of the web.
I think it may fit with _a_ future, but I don't know if there's _the_ future. Applications with very dynamic web UI's are as much of a piece of that 'future web' as structured semantic content. And I think that those kinds of applications can have slightly or wildly different requirements than CMS style systems. I've played a little bit with 'Seaside', and it's absolutely outstanding how it works and how very little code one has to write to maintain very stateful web apps.
Zope's interfaces and adapters facilitate benefits that can be derived from hybridization with any form of storage. As much as the ZMI may hinder, I believe it plays a role in visualizing incremental development and utilizing what is already there. Unfortunately, time and budgets are also business considerations and this same infrastructure allows for some fairly quick development.
We've been building up our own basic structure that just has less distractions, so we can get started up pretty easily. This web page / 'admin screen' structure is usually copied and pasted into each application. The downside is that it's more work to share the benefits. But the upside is that it's really easy to start tailoring to the requirements and scenarios of a particular application. With the ZMI, I end up asking "is this the UI I want to deliver to my customer?" And the answer is rarely "yes!" I feel like I have to arm wrestle a lot more to turn off and hide features. I still don't really understand how the 'Add' menu works. This isn't a criticism of the ZMI skin. It just hasn't been a fit for any of our customers or applications, which makes it very hard to support. Fortunately, it's fairly easy to do away with. But it also feels very hard to migrate away from if that's where ones initial work is. This is why I'm really looking forward to `zc.buildout`, the egg-ifying of Zope, etc. I look forward to the day when it's much easier to build and re-destribute -- even if it's only internally -- a custom configuration that leaves unwanted bits behind. I regret that I haven't had the time to test and experiment with some of these new developments.
It sounds that the ZMI and browser views hasn't been an impediment but a distraction to what you describe (since you were able to find a path with Zope). This is a demonstration that successful outcomes less tightly bound to more traditional zope development can be achieved also. :-) Many thanks.
Having developed on and for Zope for nearly ten years now, I can say that there is no such thing as "traditional zope development" :). There are a lot of ways to get things done. I think it's a testament to the architectures of both Zope 3 and SQLAlchemy that we've been able to do this latest project in this style - and with the cleanest application/business code we've ever had. But it took a lot of work and time and experience from prior engagements to filter out the parts of Zope 3 that we wanted, the parts that were crucial, and all of the fluff we could leave out. Once we got to that point (and started building up some new libraries and frameworks of our own), our experience with Zope 3 took a turn back towards the positive. -- Jeff Shell _______________________________________________ Zope3-users mailing list Zope3email@example.com http://mail.zope.org/mailman/listinfo/zope3-users