[Zope3-Users] zalchemy integration

[David Pratt]

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 <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.
>