i want to thank DC (jim, shane, and paul) for inviting me to come to the new
DC offices. i had a great time and learned a bunch... and met
i gave a quick overview of the smartobjects design/framework and jim and
shane presented some ideas for an or mapping for the zodb.
to be honest it seemed both extremely elegant and slightly disturbing at the
sametime. I've grown accustomed to treating the ZODB as a magic black box,
that just works. integrating an or layer at this low level disturbs me as it
meant that application developers would need to tinker at the lowest level of
the zope framework, plus the dangers that to properly support application
development the zodb would need to be bloated with accessory apis. at the
same time it offers a really elegant way to make the or mapping available to
python programmers on a pure python level (which is something i'm also
for both approaches there are some similiar problems that must be tackled,
namely definition of the or mapping, generation of stub python classes,
integration with zope notions (permission, etc). so hopefully discussion here
will flesh out, to the point of making a choice clear.
i'm primarily focused on doing the or mapping definition in xml, as its
language neutral and allows me to leverage other tools (like torque
java.apache.org/turbine/torque.html) to assist in application
i've thought about it for a few days, and while i'm not convinced completely
that a zodb approach is the best method, i'm going to start work on the some
of the support classes nesc. for moving forward, namely some of the xml
model/generators outlined in my design (embryonic)
most of my concerns echo the issues that philip has brought up re the
need of application developers. i do feel some if not most of these issues
can be solved, i'm just wondering if for zope this is the best solution. for
pure python development it seems alright. for zope, i wonder if a higher
level application framework is more suitable.
to clarify some existing points in this thread to date.
- (IMO) zpatterns is about two things, delegation and data abstraction at
the application level. the zpatterns framework doesn't assist in automating
this and its up to the integrator/developer to manually wire together all the
app/business objects. the smartobjects framework is about automating
development and presenting easier development interfaces for both
developers and designers. this isn't to say that such automation and
interfaces couldn't be built on top of zpatterns, just to say that there are
some different design goals.
- one of the primary goals of smartobjects is easy integration with zope in a
manner that is natural for zope developers. this does not mandate a new db
access api, its about facilitating automation of this api so that the objects
can be treated as normaly zope objects. both approaches (smartobjects and or
zodb) must still tackle similiar fundamental issues to integrate with zope.
on the zodb level this seems complicated to me (which betrays my incomplete
understanding of the zodb internals), plus it requires some additions to the
zodb interface to allow effective application usage (namely a generic query
mechanism, and probably interogation of a class information).
- one of my main objectives in developing an or mapping is to use the
acs4 (www.arsdigita.com) applications natively (or as close as possible)
- my smartobjects design (www.zope.org/Members/k_vertigo/smartobjects) is
mine, in that smartobjects is primarily a iuveno project this does not mean
it is smartobjects. stephen richter (of iuveno) liked parts of the design and
will likely use it parts of it in a iuveno implementation but what comes out
of iuveno is not limited or beholden in anyway by my proposal. the key focus
of the proposal is a metamodel (schema) based approach.
- i think any integration of or layer should be complementary to the zope
framework. shane's existing examples and discussion of an or layer seem to be
more geared towards replacing the zodb, than complementing. is the idea to
use some sort of zodb product as a mounted storage?, or is this a replacement
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -