Hello, which naming conventions are usual for Zope objects? For example: pyThatScript ptPageTemplate OR zptPageTemplate What do you use? What can you recommend? Thanks, Florian
Nothing special.. but I try to stay away from capitalization in any url. If it is all lowercase, it makes it easier to remember. Not really a Zope tip.. :) Jake -- http://www.ZopeZone.com Florian Lindner said:
Hello, which naming conventions are usual for Zope objects? For example: pyThatScript ptPageTemplate OR zptPageTemplate
What do you use? What can you recommend?
Thanks, Florian
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
On Nov 25, 2003, at 9:00 AM, Florian Lindner wrote:
Hello, which naming conventions are usual for Zope objects? For example: pyThatScript ptPageTemplate OR zptPageTemplate
I wouldn't use any naming convention involving resource type for URL-accessible objects. I usually follow the convention that each "screen" has a Python script (with no particular naming convention), and a Page Template that goes with it (by the same name, but with a .pt extension). I've been naming Z SQL methods sql_*, to match the name of the Python Script that uses them (and I use the Z SQL method directly, except through that Python Script) -- and then I put them all in a sql/ folder just for the heck of it. I find it important that objects not share a name, even if they are in different folders -- it can cause lots of confusion when acquisition acts differently than you expect and you get a different object than you wanted (I'd rather get a NotFound). I'm not entirely happy with this application layout, but it's better than a totally ad hoc layout, IMHO. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
Florian Lindner wrote:
which naming conventions are usual for Zope objects? For example: pyThatScript ptPageTemplate OR zptPageTemplate
What do you use? What can you recommend?
Most commonly it's simply a matter of naming things after what it does or is, mostly in a lower-case manner. Related objects should have similar names (like 'something' and 'something_form'.) I don't think a Hungarian-notation concept has much place in an object publishing system. (I also don't care for it in programming, but that's a different area.) --jcc -- "Code generators follow the 80/20 rule. They solve most of the problems, but not all of the problems. There are always features and edge cases that will need hand-coding. Even if code generation could build 100 percent of the application, there will still be an endless supply of boring meetings about feature design." (http://www.devx.com/java/editorial/15511)
On Tue, 25 Nov 2003 15:10:17 -0600 J Cameron Cooper <jccooper@jcameroncooper.com> wrote:
What do you use? What can you recommend?
Unlike most of the other people here, I do use a naming convention, I use_sql, _pt, _py, _dtml as suffixes. Why? Well, I spend most of my time in a text editor, and there are differences in calling convention among the various objects. I like to use explicit parameterization, and find that it helps to get correct parameterization if I know what kind of thing I am calling. Jim Penny
On Nov 25, 2003, at 3:45 PM, Jim Penny wrote:
On Tue, 25 Nov 2003 15:10:17 -0600 J Cameron Cooper <jccooper@jcameroncooper.com> wrote:
What do you use? What can you recommend?
Unlike most of the other people here, I do use a naming convention, I use_sql, _pt, _py, _dtml as suffixes. Why? Well, I spend most of my time in a text editor, and there are differences in calling convention among the various objects. I like to use explicit parameterization, and find that it helps to get correct parameterization if I know what kind of thing I am calling.
This is an issue. The solution I've come to is to wrap all non-Python-Script objects, and outside of the wrappers I call only Python Scripts (or the occasional extension method, SQL brains, etc). This way you get flexible and expressive calling conventions, without being tied to the underlying implementation. Which is to say, it's better to use domain-specific calling conventions (i.e., function signatures) and avoid type-specific conventions. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
On Nov 25, 2003, at 3:45 PM, Jim Penny wrote:
On Tue, 25 Nov 2003 15:10:17 -0600 J Cameron Cooper <jccooper@jcameroncooper.com> wrote:
What do you use? What can you recommend?
Unlike most of the other people here, I do use a naming convention, I use_sql, _pt, _py, _dtml as suffixes. Why? Well, I spend most of my time in a text editor, and there are differences in calling convention among the various objects. I like to use explicit parameterization, and find that it helps to get correct parameterization if I know what kind of thing I am calling.
This is an issue. The solution I've come to is to wrap all non-Python-Script objects, and outside of the wrappers I call only Python Scripts (or the occasional extension method, SQL brains, etc). This way you get flexible and expressive calling conventions, without being tied to the underlying implementation. Which is to say, it's better to use domain-specific calling conventions (i.e., function signatures) and avoid type-specific conventions.
-- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
This sounds interesting, but I'm a newbie and am not clear on what you mean here. How do you wrap all non-Python script objects? Thanks.
On Sat, 2003-11-29 at 12:11, Brad Allen wrote:
This sounds interesting, but I'm a newbie and am not clear on what you mean here. How do you wrap all non-Python script objects?
*How* is easy. If you have an object my_object you want to "wrap" with the Python Script call_my_object, you'd do this: call_my_object: ----- # do other stuff return context.my_object(arguments) ----- As for *why* you might do this, there any many possible reasons. Sometimes it's just cleaner to put scripts in charge of templates than vice versa. It's also a good way to ensure that templates are being passed sane/validated/correctly-typed arguments. It's much easier to do validation work in a script than a template. HTH, Dylan
On Sat, 2003-11-29 at 12:11, Brad Allen wrote:
This sounds interesting, but I'm a newbie and am not clear on what you mean here. How do you wrap all non-Python script objects?
*How* is easy. If you have an object my_object you want to "wrap" with the Python Script call_my_object, you'd do this:
call_my_object: ----- # do other stuff return context.my_object(arguments) -----
As for *why* you might do this, there any many possible reasons. Sometimes it's just cleaner to put scripts in charge of templates than vice versa. It's also a good way to ensure that templates are being passed sane/validated/correctly-typed arguments. It's much easier to do validation work in a script than a template.
HTH,
Dylan
This idea is a big help to me, and I'll probably restructure my current project as a result. I found a similar example of what you're talking about in the Zope book, p247 under "Calling DTML from Scripts". It fleshes out what arguments need to be passed to a dtml object. # grab the method and the REQUEST from the context dtml_method = context.a_dtml_method REQUEST = context.REQUEST # call the dtml method, for parameters see below s = dtml_method(client=context, REQUEST=REQUEST, foo='bar') # s now holds the rendered html return s The Zope book goes on to say that you can add any number of additional "keyword" arguments. In this case, I presume foo is a "keyword" argument. I've been wondering how to pass arguments to dtml documents, since the Zope Management Interface doesn't provide a way to explicitly do it. So, this is how...I don't fully understand all the arguments, but it did work when I tried it. This idea of using scripts to return DTML documents also helps me understand a naming convention I've seen others use: "filename_html" instead of the more traditional "filename.html" for web page files. I guess ".html" would cause a problem for a Python script, wouldn't it? dtml_method = context.a_dtml_method.html The Python script would interpret the "." in ".html" as a object hierarchy separator. So what about naming conventions for graphics file types? Should we still use names like "picture.gif" or "picture.jpg" in the context of Zope? Web page templates can obviously still make use of files with these names, but what if I want to refer to a picture from a Python script? On the other hand, if we start using "picture_jpg" and "picture_gif" will web browsers still "know" what graphics format is in these files and how to process them?
On Sun, 2003-11-30 at 08:08, Brad Allen wrote:
This idea is a big help to me, and I'll probably restructure my current project as a result. I found a similar example of what you're talking about in the Zope book, p247 under "Calling DTML from Scripts". It fleshes out what arguments need to be passed to a dtml object.
# grab the method and the REQUEST from the context dtml_method = context.a_dtml_method REQUEST = context.REQUEST # call the dtml method, for parameters see below s = dtml_method(client=context, REQUEST=REQUEST, foo='bar') # s now holds the rendered html return s
The Zope book goes on to say that you can add any number of additional "keyword" arguments. In this case, I presume foo is a "keyword" argument.
Yes.
I've been wondering how to pass arguments to dtml documents, since the Zope Management Interface doesn't provide a way to explicitly do it.
That's one way. Another way is to modify the REQUEST object: ----- context.REQUEST['some_var'] = 'foo' return context.some_template(context, REQUEST) -----
So, this is how...I don't fully understand all the arguments, but it did work when I tried it.
It's a bit tricky. The first argument provides the template with a namespace, the second with the other with the request-specific information. Your namespace is essentially a stack of names you can "see" from the current context. It provides much of the information that allows Acquisition to work its magic. The REQUEST contains information specific to each client request: marshalled form/querystring variables, cookie values, etc.
This idea of using scripts to return DTML documents also helps me understand a naming convention I've seen others use: "filename_html" instead of the more traditional "filename.html" for web page files. I guess ".html" would cause a problem for a Python script, wouldn't it?
dtml_method = context.a_dtml_method.html
It causes *some* hassle, yes. But it's hardly that big a deal: In Python: ---- dtml_method = getattr(context, 'some_method.html') return dtml_method(context, REQUEST) ---- In DTML: ---- <dtml-var "_['some_method.html']"> ---- That underscore in the dtml tag is your namespace object... it's roughly the same as "context" in a Python script.
The Python script would interpret the "." in ".html" as a object hierarchy separator.
Normally, yes... that also explains why "-" is unacceptable in a name. Either issue can be resolved using the techniques above.
So what about naming conventions for graphics file types?
It's up to you. The same issues and workarounds apply. The only case where it seems to matter is when you're serving documents that require helper apps in IE (PDF, Word Docs, etc.). Apparently, IE has a nasty habit of opening auxiliary apps based on file suffixes rather than MIME types. Grr... Beyond that, you may wish to consider if you'll use Zope for graphics at all. I concluded a while ago that the benefit of having tags rendered on the fly just isn't worth the overhead. When I need to serve a decent number of static files, I prefer to serve them from Apache. HTH, Dylan
At 9:28 AM -0800 11/30/03, Dylan Reinhardt wrote:
The only case where it seems to matter is when you're serving documents that require helper apps in IE (PDF, Word Docs, etc.). Apparently, IE has a nasty habit of opening auxiliary apps based on file suffixes rather than MIME types. Grr...
Beyond that, you may wish to consider if you'll use Zope for graphics at all. I concluded a while ago that the benefit of having tags rendered on the fly just isn't worth the overhead. When I need to serve a decent number of static files, I prefer to serve them from Apache.
Well, in cases where we want to include a few small graphic files within Zope, I guess it will make sense to continue to name them in the traditional way, i.e., "picture.gif", to prevent problems with IE. It sounds like Python scripts can still refer those objects if they need to using gettatr(context,'picture.gif'). Thanks for all the help.
At 30/11/2003 19:59, you wrote:
Well, in cases where we want to include a few small graphic files within Zope, I guess it will make sense to continue to name them in the traditional way, i.e., "picture.gif", to prevent problems with IE. It sounds like Python scripts can still refer those objects if they need to using gettatr(context,'picture.gif').
I prefer to strip file extensions, they are tied to a specific format which is an implementation detail. I need a resource named 'logo' - if it's a jpeg, a gif or svg should be irrelevant, and a *real* webserver should decide which is the best one to return (if there were a choice). Gabriel Genellina Softlab SRL
On Dec 1, 2003, at 1:10 PM, Gabriel Genellina wrote:
I prefer to strip file extensions, they are tied to a specific format which is an implementation detail. I need a resource named 'logo' - if it's a jpeg, a gif or svg should be irrelevant, and a *real* webserver should decide which is the best one to return (if there were a choice).
In reality, though, you'll usually need to have some notion of what kind of object it is. You'll want to know the dimensions, if it's not an image you have to use different tags, etc. Zope can do some of this for you (e.g., creating the IMG tag), but that won't take you very far -- you're likely to need extra access, like CSS, Javascript events, etc., and even if Zope could handle these in a uniform way, it's unlikely that browsers will do the same. The page and its embedded resources are tightly coupled (and I don't think that's really so bad, either). In the end it doesn't matter, because images and other resources aren't generally public URLs. They are specifically referenced and embedded from other pages, and few users view the image URL (and almost no one needs a long-term stable URL for embedded resources like images). -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
Quoting Gabriel Genellina <gagenellina@softlab.com.ar>:
I prefer to strip file extensions, they are tied to a specific format which is an implementation detail. I need a resource named 'logo' - if it's a jpeg, a gif or svg should be irrelevant, and a *real* webserver should decide which is the best one to return (if there were a choice).
All fine and dandy - but how do you tell your log analysis program which requests were for logos so that they can be excluded from your "page" count? -- Cynthia Kiser
At 1/12/2003 13:10, you wrote:
I prefer to strip file extensions, they are tied to a specific format which is an implementation detail. I need a resource named 'logo' - if it's a jpeg, a gif or svg should be irrelevant, and a *real* webserver should decide which is the best one to return (if there were a choice).
All fine and dandy - but how do you tell your log analysis program which requests were for logos so that they can be excluded from your "page" count?
Exclude 'logo' Gabriel Genellina Softlab SRL
Quoting Gabriel Genellina <gagenellina@softlab.com.ar>:
At 1/12/2003 13:10, you wrote:
I prefer to strip file extensions, they are tied to a specific format which is an implementation detail. I need a resource named 'logo' - if it's a jpeg, a gif or svg should be irrelevant, and a *real* webserver should decide which is the best one to return (if there were a choice).
All fine and dandy - but how do you tell your log analysis program which requests were for logos so that they can be excluded from your "page" count?
Exclude 'logo'
Excluding all the image files by name is not a very scalable solution for a site of any reasonable size - even given that one can play cute games with acquisition so that different images are returned depending on context of the page/page fragement. -- Cynthia Kiser
On Mon, 2003-12-01 at 18:10, Cynthia Kiser wrote:
Quoting Gabriel Genellina <gagenellina@softlab.com.ar>:
At 1/12/2003 13:10, you wrote:
I prefer to strip file extensions, they are tied to a specific format which is an implementation detail. I need a resource named 'logo' - if it's a jpeg, a gif or svg should be irrelevant, and a *real* webserver should decide which is the best one to return (if there were a choice).
All fine and dandy - but how do you tell your log analysis program which requests were for logos so that they can be excluded from your "page" count?
Exclude 'logo'
Excluding all the image files by name is not a very scalable solution for a site of any reasonable size - even given that one can play cute games with acquisition so that different images are returned depending on context of the page/page fragement.
If you have a need for images to have special names, one easy (and scalable) solution is to use a special image folder (img, images, etc) for all images. Now images have an easy pattern to exclude. Better yet, serve images from Apache where logging tools are far more mature. If you don't care how many image hits you get, you don't even have to log them in the first place. HTH, Dylan
Case in point for dropping extensions (and naming conventions) - use a blank image called "tracker" (or something less insidious) which is shown once per page, and have that be a python script which tracks pageviews... -jim ----- Original Message ----- From: "Gabriel Genellina" <gagenellina@softlab.com.ar> To: <zope@zope.org> Sent: Monday, December 01, 2003 7:54 PM Subject: Re: [Zope] Naming conventions
At 1/12/2003 13:10, you wrote:
I prefer to strip file extensions, they are tied to a specific format which is an implementation detail. I need a resource named 'logo' - if it's a jpeg, a gif or svg should be irrelevant, and a *real* webserver should decide which is the best one to return (if there were a choice).
All fine and dandy - but how do you tell your log analysis program which requests were for logos so that they can be excluded from your "page" count?
Exclude 'logo'
Gabriel Genellina Softlab SRL
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
participants (10)
-
Brad Allen -
Cynthia Kiser -
Dylan Reinhardt -
Florian Lindner -
Gabriel Genellina -
Ian Bicking -
J Cameron Cooper -
Jake (aka BZ) -
Jim Kutter -
Jim Penny