Two comments. One with regards to solving the original problem, one
with regards to links.
SEVERAL TEMPLATES FOR ONE CONTENT TYPE
With the CMF you have another level of typing of objects available:
portal_type (dynamic type). A meta_type can have many corresponding
portal_types, e.g., a generic MyDocument class (implemented in a Python
product) can support many logical types who only varies in their usage
and skin. The CMF lets you set the portal_type at creation time (you're
basically creating a portal_type object, implicitly based on some kind
of meta_type object).
What I'm doing now, and it works quite nicely, is to enable users to
change the portal_type at run-time. In the Metadata edit view for an
object, I scan the available portal_types for the given meta_type and
give the user the option to select one of them as the "current dynamic
type (portal_type). The CMF's portal_skin tool does the rest of
selecting the correct skins to use (based on the portal_type attribute).
LINKS IN THE OODB
I've used Shane's suggestion, and it works most of the time, but if you
ZSync your objects to another server, you'll get two copies instead of
one object and one link... Have a look at the PortalHole product
release recently; it addresses linking.
Another way to do links involves storing the path to the other object
(which is how PortalHole does it), or you can create a portal-wide
unqiue id (someone suggested this) which you can index in the
portal_catalog. Now all you have to do is store the link, and the link
won't break if the objects move with respect to each other (=the path
An improvement on this is to create a Mixin that implements logic to
setup and break these links; this way to you can notify the other object
when you're deleted that it should also remove the link. Otherwise
you'll have broken links when the other object is deleted.
You can also just allow broken links and fix them with regular sweeps
across all content objects checking for and removing broken links
(sort-of like garbage collection).
There should really be a FAQ about how to do this.
We've got this kind of Mixin already, but it comes with a few bugs. Let
me know if you want/need it. :)
> -----Original Message-----
> From: Oliver Bleutgen [mailto:[EMAIL PROTECTED]]
> Posted At: Wednesday, November 14, 2001 03:54
> Posted To: Zope Developer
> Conversation: [Zope-dev] Repost to zope-dev: Best way to do "links"
> Subject: [Zope-dev] Repost to zope-dev: Best way to do "links"
> Hi reposting to zope-dev because the zope-list didn't yield
> any answer (although it should belong there, I think).
> I am unsure how to achieve the following in a product:
> I have a folder with templates which shall be used to render articles.
> This folder will be the central repository of templates for
> all articles
> which find it in their acquisition path.
> Now, I want be able to dynamically assign (and change) templates for a
> given article, and if I edit one template it should reflect in all
> articles which are configured to use that template.
> In http://lists.zope.org/pipermail/zope-dev/2001-May/011187.html Shane
> Hathaway describe hardlinks, which seem to do what I need.
> i.e. I then just do
> t = template_folder.one_template
> self.template = t
> I looked at how ZSQL-methods solve that problem (usage of
> SQLConnections), and as far as I can see ZSQL-methods just
> store the id
> of the ZSQL connection and use that everytime they need to
> access the DB.
> Is that right and if so, why is it done that way?
> Doesn't give that a performance hit?
> And the last one:
> Will the above described method still allow import/export of these
> Zope-Dev maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -