Chris Withers wrote:
> Ken Manheimer wrote:
> > Huh. We're looking for something neutral, to connote code that runs in
> > zope to do some business logic or similar effect. It should distinguish
> > the language used to express the logic - perl vs python vs xslt,
> > etc. I hate "script", but it occurs to me that the "-let" convention may
> > be useful:
> > Python Zopelet
> > Perl Zopelet
> > XSLT Zopelet
> > Zope-specific, runs on the server, shows the implementation language,
> > won't be confused with non-remotely-editable functions, methods, scripts,
> > code in general.
> > This is the first one with which i'm comfortable - but i may well have
> > missed something.
> ...yeah, Zopelet means absolutely nothing, and will just add to
> confusion :-(
> Chris . o O ( what the hell is a Zopelet? ;-)
I have to say that I don't like Zopelet either.
I guess nobody else likes my 'Blocks' nomenclature:
As I mentioned before, I tend to use DTML Methods in two
- as Views on objects (Templates)
- as building blocks for Views
In one context (Views/Templates), the DTML method is meant
to be accessed directly through the web. In the other
context (Block), the DTML method is only ever accessed by a
I would actually like to have a Block object that is not
directly accessible, without having to go through some
Something else to consider for these two Use Cases of
DTML/Python/Perl Methods/Blocks/Scripts, is that typically
only the Block Use-Case is expected to be re-used through
recomposition, as well as acquisition, while Templates/Views
are usually re-used through Acquisition only.
I'm not sure this has any impact on the 'Method Binding'
argument floating around, but I thought I'd mention it again
in that context.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -