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 changes). 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. :) Regards, -- Bjorn
-----Original Message----- From: Oliver Bleutgen [mailto:myzope@gmx.net] 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 instances?
cheers, oliver
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )