[REBOL] Re: Zope comments (MU)
From: tim::johnsons-web::com at: 13-Jan-2004 12:06
I'm very interested in zope, because much of my work comes from
web programming and about half of the work that I do, I do in python.
The other half is done with rebol.
I have found rebol much more productive codewise than python. On the
other hand, python has many more external resources, and has internal
(built-in) features that more easily (as I see it) promote scalability.
As a python user, zope has great appeal to me. I don't know enough
about it to know how it integrates with perl-sourced assets, and
that is an issue with me because my partner is exclusively a perl
programmer.
As a rebol user, what I have done thus far is develop a system that I
call 'MU. 'MU exploits Andrew's 'ML and DocKimbel's 'mysql-protocol, as
well as my own CGI resources. The concept is that web content, database
acccess and data posting is controlled in a large part by data
structures. And it provides and lot of validity checking.
Data Drives It
(from the Designer's Tip Sheet).
I'll be (alpha . beta)-testing this over the next couple of months as I
develop another web site and will then release it with all dependencies
to public domain. The next step for me would be to add more zope-like
features, like content and project management.
I would hope that when I do go 'public' with it, that there will
be enough interest to generate constructive criticism, lord knows
I need that. In the meantime, if anyone can offer any ideas on how
I can handle project and content management 'zope-like' and
also how to integrate with perl applications, contact me OTL.
One of the strategies for perl integration would be a
language-independant way to create associative lists from delimited text
files. :-) There's a way to resolve some interoperability issues.
Yeah, zope rocks and imitation is the best form of flattery.
tim
* Jason Cunliffe <[jason--cunliffe--verizon--net]> [040113 10:18]:
> From: "Petr Krenzelok" <[petr--krenzelok--trz--cz]>
> > It is just two weeks one of my friends visited me to help me to install
> > Fedora server. He brought two books with him - Cocoon and Zope. Zope
> > seems to be interesting, he showed me how he used some module for
> > digital photo catalogue. Nice, but really nothing what could not be done
> > in IOS in a MUCH clearer way, at least to me. He admitted, that Zope is
> > nice even for beginners, but once you decide to modify some unsupported
> > functionality, you have to go deep python.
>
> Zope is very easy to use for fast turn-key installation. Amazing what's in
> there.
> Be warned, all the books on Zope are already out of date, though do give
> some helpful overview.
> Zope development moves pretty fast. When we were developing with it four
> years ago we found the simplest was simply to bypass the complex Zope
> framework and develop external python scripts for Zope. Basically just
> single nice readable Python script with a few critical calls into the Zope
> architecture. Worked beautifully, thanks to the fact that Zope invites many
> ways of working. There are many Zope products - plugin extensions, but they
> are almost all individual experiments which people have generously shared.
> Most of the time people just them as-is or adapt in small ways. The result
> can be quite a spaghetti of versions and documentation to sort through. The
> most popular ones are far better documented with plenty examples and people
> who can help.
>
> One of the best kept secrets about Zope is Jerome Alet's "ZShell"
> http://www.librelogiciel.com/software/
> ZShell : Manipulate the Zope Object DataBase with Unix shell like commands
>
> Fascinating , with ZShell, instead of the struggling manually with boring
> gui interface, or the deep syntax of Zope OO namespace, how it suddenly can
> become so simple to program Zope. Jerome developed this very familiar
> concise little tool to sit on top of this enormous framework with nasty
> syntax. In the process effectively changed the paradigm by combingin old and
> new in an obvious way, but which had not been obvious to others :-) Also
> interesting to note that one of Zope's most enticing and clever paradigm --
> 'acquisition' -- has proved to be difficult to work with.
>
> Ironic because it's the innovative Zope features everyone falls in love
> with. But it can be brain-twister in practice. 'Acquisition' provides a
> url-like path syntax where objects inherit methods and properties by
> searching up the tree of their parents till they find the first match. Then
> apply that. Its a brilliant idea. But after years of work, I believe the new
> Zope3 now being written is to fresh code and component-based architecture. I
> am not surprised they changed, but always believed Acquisition was such a
> different paradigm that it really needed a different kind of interface to
> manage it. And that never happened. An interactive map for example. But core
> Zope developers seem to be non-visual creatures.
>
> > Reblets seem to be really
> > better aproach to me. But of course - once you want your "output device"
> > to be web (html), not a View/IOS client, you are in trouble a bit.
>
> Yes the interoperability issue again.
>
> - Jason
>
> --
> To unsubscribe from this list, just send an email to
> [rebol-request--rebol--com] with unsubscribe as the subject.
--
Tim Johnson <[tim--johnsons-web--com]>
http://www.alaska-internet-solutions.com<
