Hi Jeff. Good points. I can really add anything more to this other than
I believe there are great possibilities working with Zope 3 in something
that is more tightly bound or not. Zope 3's architecture will be become
as flexible as python itself and it future packaging choices will only
underscore this. I believe it will not be long before we will see newer
skinning approaches taking advantage of the ui frameworks as resources
in Zope3 in a big way.
We are coming into the .3 mark of Zope 3. Typically the stability of the
api's at this point are going to permit all sorts of interesting and
exciting developments - to build on something that has been in fact
solidifying for years now.
Regards,
David
Jeff Shell wrote:
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.
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
