Re: [Zope] Products vs. ZClasses- Design Question
Hi Jimmie ! Jimmie Houchin wrote: This sounds weird ! Well, every page on the ZDP site has a Maintainer, and that is displayed on the top right. If you click on that link, you get to the member page, where the email exists. I go back again to make sure of what I saw. In the upper right side, all that is there is 'Contributed by maik'. It is not a link. It goes neither to a member page of the maintainer nor provides a mailto: link. This is in Win95 Netscape. When I view the source I didn't anything there but text in a table. This is a bug specific to the Portal, which has a folder called members, and unfortunately, I am using just this name in the DTML script that fetches the information out of the members folder that holds the actual member information. dtml-with members dtml-if "The_Maintainer in objectIds(['Member'])" Maintainer: A HREF="/members/dtml-var The_Maintainer/" dtml-var The_Maintainer/A dtml-else Contributed by dtml-var The_Maintainer /dtml-if /dtml-with I have changed the portal name to zdpmembers, and now it works again. You also have to see that the topics in the ZDP-Portal are normally not related in a way like an article is, so I have not added a navigation, even though I had considered it. I don't think it is a problem for unrelated content or articles. It also doesn't necessarily have to be site wide thing. In this particular instance all three were related to each other and referenced each other via the pros and cons. In this case I will have to make explicit links to the related content, like you propose. It is worth the extra effort. If you think date is not a good indicator of currency, then howabout having Zope versions with which it is accurate for ? The date will play a role when the changes history of documents is implemented. ie: Works with Zope 2.x or Zope 2.2.x, etc. or even a range 2.0-2.1.x. This would allow for changes in Zope which break certain things. For example any information on the security model changes between 2.1.x and 2.2.x. Doing it this way makes it less date dependent. It also allows for people who are using older versions of Zope to understand if it is relevant for them. In my opinion, things like that should be noted in the text, or in the changes history (Something like "adopted to Zope 2.2 security model on 22nd of July 2000). I have noticed that product as well, but didn't find the time to check it out (There is no info on the product page). I haven't either. Just thought it seemed relevant to the topic. It is relevant, and the portal is supposed to spare you the time to check out everything on your own. If someone has checked out this product, please add your knowledge to the Portal. Maybe you can help by adding a draft to the relevant topics, that can replace the description that exists ? Not at this time, sorry. No problem. Thanks for your comments. Best regards, Maik Röder -- Open Source is "about being able to work together with people you've never met, on projects that are in a constant state of flux, on a time schedule that would cause a hummingbird's head to spin." Paul Ferris, http://www.linuxplanet.com/linuxplanet/opinions/1593/1/ ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] Products vs. ZClasses- Design Question
On Fri, 16 Jun 2000, Charlie Derr wrote:
Jeff wrote:
~ As explained above, this advantage is shared by Python Products also. You
~ do *not* want to write application logic with DTML. At a minimum, use
~ Python Methods. Otherwise, use Python.
~
Let me apologize in advance because i think this is going to turn out to be
a really stupid question. I'm never gonna know the answer if i don't ask it
though. :-\
I've seen this mentioned a lot (advice not to write application logic in
DTML). If one wants to use pure python (and not Products and not external
methods) to create complex actions/relationships, then where does one place
this code? Obviously i can litter my DTML with python expressions, but this
seems to be what is being recommended against strongly. Is there a way to
use python "correctly" without writing a product and without encapsulating
it in an external method?
You have two choices:
1) Use PythonMethods, found at:
http://www.zope.org/Members/4am/PythonMethod
These work like DTML Methods, only you write them in Python. They are
relatively safe, also.
2) Create a base class in Python, register it with Zope as a ZClass
Base, and specify it as a parent class to your ZClass.
i.e.:
FILE: TestBase.py
-
class TestBase:
"""My ZClass Base class."""
def __init__(self):
self.foo = 'Foo'
def getFoo(self):
return self.foo
def setFoo(self, value):
self.foo = value
def initialize(context):
context.registerBaseClass(TestBase)
FILE: __init__.py
-
import TestBase
def initialize(context):
TestBase.initialize(context)
Put these two files in your lib/python/Products/TestBase directory.
Then, restart your Zope.
Now, add a new product called Test. Inside it, create a ZClass called
'Test' with a meta-type of 'Test'. Specify TestBase as the base
class.
Inside the Test ZClass, create a DTML Method called index_html. Give
it the following contents:
dtml-var standard_html_header
P
Initial foo: dtml-var getFoo
/P
P
dtml-call expr="setFoo('Hello, world.')
New foo: dtml-var getFoo
/P
dtml-var standard_html_footer
Create an instance of the Test ZClass, and view its index_html.
Voila.
Hope this helps,
tesmia,
~c
--Jeff
---
Jeff K. Hoffman 704.849.0731 x108
Chief Technology Officer mailto:[EMAIL PROTECTED]
Going Virtual, L.L.C. http://www.goingv.com/
___
Zope maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Products vs. ZClasses- Design Question
On Fri, 16 Jun 2000, Garrin Kimmell wrote: Hello, [snip] I've thought of three ways to develop the class: 1. Develop the entire class as a Zope product in Python. The advantage I see here is that developing the application logic is fairly straightforward with Python. I see problems, though, with the user interface, especially if I want to make changes to it after instantiating a few objects. It is my understanding that objects created from a Product are not automatically updated when changes are made to the class methods (as opposed to ZClasses, where they are). Am I correct here? The user interface for a Python Product is generally specified in .dtml files distributed with the Product. If you change one of these .dtml files, all you have to do is restart Zope and you will see the changes. Whether you have created one instance, or one hundred instances, they will all change their interface. What will *not* change (without a little help from you, described below) are the attributes that have been added or removed from the class. In this case, new instances will be configured with the new attributes, while old, previously instantiated instances will retain their old attribute configuration. To migrate your existing instances to the new configuration, you need to write a __setstate__() method in your class, for example (untested): class MyPersistentClass(Persistent): def __setstate__(self): Persistent.__setstate__(self, state) if not hasattr(self, 'newAttr'): self.newAttr = newValue if hasattr(self, 'deprecatedAttr'): del self.deprecatedAttr Each time the object's state is loaded from the ZODB, this method will be invoked. If a previously instantiated instance of your object is loaded, and does not contain an attribute called newAttr, it will be created. Likewise, if it contains an attribute called deprecatedAttr, it will be removed. ZClasses provide no such facility. You cannot upgrade ZClass instance attributes automatically, as far as I know. You'd have to write a script to go through your ZODB and upgrade the old instances manually. Boo. 2. Develop the entire class as a ZClass The principal advantage I see is that changes to the class methods are dynamically updated in all instances of that ZClass. The problem is that DTML is (for me, at least) a pain in the ass to write any complicated application logic with. As explained above, this advantage is shared by Python Products also. You do *not* want to write application logic with DTML. At a minimum, use Python Methods. Otherwise, use Python. 3. Develop the application logic as a Product in Python, then use that class as a mix-in class for a ZClass that implements UI logic with dtml methods. This seems to be the best solution (even if it is the most work). I should get the advantage of having ZClass instances automatically update changes to ZClass methods, while having the programability of Python for application logic in the Product. If I do take this route, are there any quirks I should be aware of when inheriting a ZClass from a product? This is a good way to go, and provides a nice advantage over vanilla Python Products: You do not have to restart Zope to see changes to your UI. However, you cannot reparent a ZClass after it has been created. Well, you can, but no one is very happy with the ways you have to do it. So, if you are a fly by the seat of your pants kind of coder, don't do it. If you do all of your analysis up front, and will know in advance exactly which classes your ZClass will inherit from, go for it. But, should you miss something in your analysis, you will have to reparent your ZClass and endure the pain involved with that process. I am new to Zope and would appreciate any insight into the tradeoffs among these three strategies. In summation, Python Products are, by far, the most flexible solution. You can upgrade them. You can write all of your logic in Python. You write your UI in DTML. You can manage all of this using CVS (or the version control system of your choice). Good stuff. Using ZClasses for your UI can allow you to see updates to your UI in realtime without having to restart Zope. In addition, ZClasses make your UI accessible to people who do not have access to the filesystem of your Zope server. You cannot easily use CVS with ZClasses, since they are stored in the ZODB and not the filesystem. Hope this helps! Thank you, Garrin --Jeff --- Jeff K. Hoffman 704.849.0731 x108 Chief Technology Officer mailto:[EMAIL PROTECTED] Going Virtual, L.L.C. http://www.goingv.com/ ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce
RE: [Zope] Products vs. ZClasses- Design Question
Jeff wrote: ~ As explained above, this advantage is shared by Python Products also. You ~ do *not* want to write application logic with DTML. At a minimum, use ~ Python Methods. Otherwise, use Python. ~ Let me apologize in advance because i think this is going to turn out to be a really stupid question. I'm never gonna know the answer if i don't ask it though. :-\ I've seen this mentioned a lot (advice not to write application logic in DTML). If one wants to use pure python (and not Products and not external methods) to create complex actions/relationships, then where does one place this code? Obviously i can litter my DTML with python expressions, but this seems to be what is being recommended against strongly. Is there a way to use python "correctly" without writing a product and without encapsulating it in an external method? tesmia, ~c ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
