Skins folder for python (non-cmf) product
I am making a product which will act as the 'core' for a site which uses some of my customer products like 'customer' and 'salesperson'. I want any request for a page to be handled by the core product which will provide skins like main_template, customer_search_form, salesperson_add_form. What sort of hack do I need to perform so that when, for example, someone requests customer_search_form while they are in the Customer folder, the search form gets acquired from my core object? I am currently doing this by defining variables in my 'class Core:' for each possible skin. However, I want to get away from defining each skin in the core class. I want each skin in the filesystem directory Core/www to become available to all subobjects. Any hints? Thanks. Chad
On Mon, 2003-03-31 at 13:53, Chad Nantais wrote:
What sort of hack do I need to perform so that when, for example, someone requests customer_search_form while they are in the Customer folder, the search form gets acquired from my core object?
No hack at all. Just make sure that your "core" object is the closest acquirable object that can resolve that name.
I am currently doing this by defining variables in my 'class Core:' for each possible skin. However, I want to get away from defining each skin in the core class. I want each skin in the filesystem directory Core/www to become available to all subobjects.
It sounds like you may not have done this before... so let me give you the quick tour. The standard way of providing product interfaces is to create a file using your favorite templating language. To make that interface a property of your product instances, you need only do: my_interface = DTMLFile('dtml/my_interface', globals()) -or- my_interface = PageTemplateFile('zpt/my_interface', globals()) (After having imported DTMLFile or PageTemplateFile, of course) Really, it's hardly any more work than creating the template file in the first place. If you have too many interfaces to manage, I would guess that you're probably not really using the dynamic features of Zope's templating languages to their full advantage. It's far better, in general, to have an interface that can render 10 different ways than 10 interfaces that are different only in subtle ways. Publishing templates without explicitly defining them as class properties is possible, of course... but it's almost certainly not the answer to the problem you're currently facing. I'm not sure it's the answer to *any* problem. Maybe I'm not getting what you're trying to do. If that seems to be the case, maybe you could expand on your problem? FWIW, Dylan
On Monday, March 31, 2003, at 04:17 PM, Dylan Reinhardt wrote:
On Mon, 2003-03-31 at 13:53, Chad Nantais wrote:
What sort of hack do I need to perform so that when, for example, someone requests customer_search_form while they are in the Customer folder, the search form gets acquired from my core object?
No hack at all. Just make sure that your "core" object is the closest acquirable object that can resolve that name.
I've been doing this.
I am currently doing this by defining variables in my 'class Core:' for each possible skin. However, I want to get away from defining each skin in the core class. I want each skin in the filesystem directory Core/www to become available to all subobjects.
It sounds like you may not have done this before... so let me give you the quick tour.
The standard way of providing product interfaces is to create a file using your favorite templating language. To make that interface a property of your product instances, you need only do:
my_interface = DTMLFile('dtml/my_interface', globals())
-or-
my_interface = PageTemplateFile('zpt/my_interface', globals())
I've been doing this too.
(After having imported DTMLFile or PageTemplateFile, of course)
Really, it's hardly any more work than creating the template file in the first place.
If you have too many interfaces to manage, I would guess that you're probably not really using the dynamic features of Zope's templating languages to their full advantage. It's far better, in general, to have an interface that can render 10 different ways than 10 interfaces that are different only in subtle ways.
Here's where I need to improve my current implementation. I need an interface that can render 10 different ways. Maybe I'll spend more time dissecting CMF to learn how it implements skins.
On Mon, 2003-03-31 at 16:39, Chad Nantais wrote:
I need an interface that can render 10 different ways.
OK. It sounds like what you mean is that a *particular* name associated with your core product needs to render in many different ways depending on some contextual trigger. I'm assuming you've ruled out coding up those differences in the template file itself. It's a good first approach, but too limiting for when you *really* need to switch things around on the fly. It *doesn't* sound like you're talking about CMF-style skins, where objects in the ZMI "override" default interfaces. But if that is what you want, clearly CMF is a great resource for how to do it. Assuming you want to pick from among several defined product interfaces on-the-fly, try something like: --------- # Set up your interfaces: interface1 = DTMLFile('dtml/interface1', globals()) interface2 = DTMLFile('dtml/interface2', globals()) ... def pick_interface(self, REQUEST): # figure out what interface you're using my_interface = some_method(REQUEST[some_field]) # and call your interface on the fly... return self.__dict__[my_interface](self, REQUEST) ---------- That's top-of-head, untested, etc. But probably enough to go on.
Maybe I'll spend more time dissecting CMF to learn how it implements skins.
That's time well-spent in any event. HTH, Dylan
participants (2)
-
Chad Nantais -
Dylan Reinhardt