Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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" > > 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]><