[Zope3-Users] zalchemy integration

[Jeff Shell]

On 8/12/06, David Pratt <fairwinds at eastlink.ca> 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