Re: [Zope-dev] Meaning :-S
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? ;-) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Meaning :-S
On 10/23/2000 11:37 AM, "Chris Withers" [EMAIL PROTECTED] wrote: ...yeah, Zopelet means absolutely nothing, and will just add to confusion :-( The worse confusion is choosing a name that means something and then either o Having to explain that it means different things in different contexts, even within Zope. (This is a bigger problem with the name Method than the whole binding issue. Ditto for script. Instructing a user to write a Python Script will cause a Python programmer to go to the file system). o Having to explain "it's like ... but different..." This was apparently one of the other problems with the name Method, in that PythonMethods (the through-the-web variety) may or may not behave like traditional Methods in programming languages. This is especially bad when the code is Python since Python is also what we develop in. Python can now exist in many places in Zope (web, Extensions/, and Products (disk based)). External Methods were a nice name in that they connoted that it was a chunk of code that was external to Zope (at least the ZODB). The use of 'method' can come back into issue regarding how they got bound (ugh), but the External bit fit. If I was told "write an External method", I knew what that meant. When*ever* I hear someone mention writing a new python method to do something, it has to be qualified with "you mean in a product\class on the file system or a _PythonMethod_?" Function, Script.. They all fall prey to the same thing. Zopelets follows the cute naming of Applet, Servlet, Scriptlet... (IE has Scriptlets). I'm not advocating it entirely, but it follows a nice silly tradition in a way that is explainable - small chunks of Zope code managed through the web. And they happen to be in Python. (or could be predicated by the language of choice). Jeffrey P Shell, [EMAIL PROTECTED] http://www.digicool.com/ | http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Meaning :-S
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
