[Zope-dev] Meaning :-S

[Michael Bernstein]

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:

Python Blocks
Perl Blocks
DTML Blocks

As I mentioned before, I tend to use DTML Methods in two
contexts:

- 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
View.

I would actually like to have a Block object that is not
directly accessible, without having to go through some
proxy-role rigamarole.

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.

HTH,

Michael Bernstein.