[Zope-PTK] Bugreport: When overriding skin in dtml, stylesheetwon'tload

[Kent Polk]

On 13 Feb 2001 12:00:02 -0600, Shane Hathaway wrote:
>> Shane:
>> > It sounds like you want users to have "mini-portals".  Right?  Could you
>> > elaborate on the reason?
>> 
>> Sigve:
>> You are perfectly right! The reason is quite simple. I am developing a
>> site for a "community", which consists of several sub-communities that
>> each want their own look and feel. These sub-communities should be members
>> of other communities.  The scope of news and events should be selectable,
>> so that important news should show up in the posted communitys "parent".
>
>What about the possibility of creating a new portal object for each
>user, then setting the request_varname for each portal_skins object to
>something like "sub_portal_skin"?  That way the user could vary the
>primary skin and the personal skin independently.
>
>Note that a portal object is, in fact, little more than a "skinnable
>portal folder".

You lost me here.
By 'portal object', you don't mean a portal (new) instance, do you?

What I want to do is to have several sub 'portal skins' that are
oriented toward managing different workflows. I'll get back to this
in a minute because I have a preceding question.

Workflow objects...  I have several workflow objects somewhat
developed that currently reside outside of the PTKwhatever, because
I haven't figured out exactly where they fit. We're getting awfully
close to subworkflows here... These objects basically resemble a
tabular document with a lot of metadata and state information in
them. Currently the core tabular data is organized frighteningly
similar to a ZRDB.Results object. However,  I haven't decided how
I'm actually going to store the table data (probably SQL), but it's
convenient for now. most of my subworkflows will be oriented around
one of the tabular-looking objects. 

What I expect to do is to implement these tabular objects using
one of the PTKBase document classes somewhat as a template. AND,
I would like for all of these tabularish workflow thingies to use
the same base view interface where you could view these objects in
a heirarchical fashion (as subworkflows).

Now (back to the original question) should I be looking to implement
this tabularish workflow view as a separate portal or just as a
separate skin for the current portal? I would hope for a separate
skin, because they are all related. Essentially one parent object
that represnets a project, and children which represent all of the
separate workflow tasks for that parent.

Is it time yet to discuss subworkflows? :^)