[Zope] - RE: Zope programming idioms

Andreas Kostyrka andreas@ag.or.at
Fri, 18 Dec 1998 23:22:15 +0100 (CET)


On Fri, 18 Dec 1998, Amos Latteier wrote:

> This is a difficult issue. I don't have a good answer right now. Part of my
> motivation for writing 'External Objects' was to try out a possible answer.
> 
> Bobo is much more simple and flexible than Zope. The Zope framework
> provides lot of services, but it also imposes lots of conventions in order
> to play ball.
> 
> It's hard to know how or even if it's possible to marry to "raw power and
> flexibility" of Bobo to the fuller services of Zope. I'm definitely open to
> suggestions.
My solution to this has been a bit radical ;) (Admittingly my Zope allergy
stems more from my BoboPOS reluctance (but Emacs & CVS make for a much
nicer site management.)

I basically wrote my own file based object server with Bobo and DTMLs,
it's basically not that difficult ;)

In fact, after the fact I've noticed that my solution has by default a
completely different object usage:
-) Objects are short lived. That is a disadvantage that you have to write
   activation/deactivation code right into the object, but it has the
   advantage that such code that explicitly loads/saves the object to the
   filestorage object exists, and that the data is available from the
   outside.
-) Actually, there are usually two different classes for an object: One
   Runtime class, and one Management class. This has some disadvantages,
   including the fact that normally the management URL is reached by
   prefixing the path with "edit/" but I (personally) don't consider that
   a major problem: The editing interface IMHO MUST run via https, while
   the Runtime interface in many cases is better served by http.
   (Be it the additional cost and hassle of obtaining an additional domain
    certificate, be it that stupid user will probably enter http:// and
    not https://, etc.)
   It surely on the other hand has the advantage in Intranet/Internet
   solutions where there must be TWO servers: One Intranet one, which is
   edited, and one Internet version, which by design is NOT to be edited.
   This is quite easy to produce with a file tree based server, and the
   Editing functions are all killed by leaving out the /edit/ Entry or
   pointing it to a different class than "DirectoryEdit" :)

> 
> Maybe there could be some way to code in Bobo, but write the UI in Zope...
Even better. Offer the possibility to write the UI via the Web AND via
any normal file editor :)

So basically, the question how much interest there is in such a ``much
nearer to Bobo environement''?

Andreas
-- 
Win95: n., A huge annoying boot virus that causes random spontaneous system
     crashes, usually just before saving a massive project.  Easily cured by
     UNIX.  See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.