[Zope] Skins folder for python (non-cmf) product

Chad Nantais chad_lists@rednaxel.com
Mon, 31 Mar 2003 16:39:30 -0800


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.