On Sun, 2012-04-15 at 09:22 +1000, Dylan Jay wrote:
> On 15/04/2012, at 6:11 AM, Jan-Carel Brand <lists@...> wrote:
> > On Fri, 2012-03-30 at 09:36 +1100, Dylan Jay wrote:
> >> On 30/03/2012, at 7:42 AM, David Hietpas <hietpasd@...> wrote:
> >>> Hi Everyone,
> >>> I have an idea for content types, I've proven it is possible and I have a basic working prototype. I haven't taken the time to take in Dexterity yet, I've achieved this with AT.
> >>> The idea is to add fields to new or existing content type based off of the placement of the content type on website. So fields could be added to the ATDocument but those fields would only be plugged in if it is within a specific area of the website. Similar to how Placeful workflow can add workflows at different levels of site.
> >>> Use Case (Example):
> >>> I need all the functionality of a Document but I need to add a Selection Field to it. I can extend the type but every Document across the site will have those new fields. I don't want this to be globally added to all ATDocuments, I only need that field for one area of the website.
> >>> I was able to achieve plugging in new fields to content types based off of what Interfaces were provided at that level of the website. This leads to a lot of reusable code and prevents many different content types from being made with minor differences in schema's. Plus saves the developers time.
> >>> Taking this idea one step further. Since we could plug in fields based off of a content types placement in a website, a Content Type Generator could be setup to allow users to make new content types through-the-web. The user would select which fields they need in their new content type, the generator would save their new content type with the plugin interfaces they've chosen. When the type they just created is added on the website, those plugin interfaces would retrieve the correct field classes for the content type and the proper creation/edit page would appear. I am sure a properly designed generic template could handle the basic rendering too.
> >>> Just a idea I would share, I have it working and I plan on running more experiments in this area.
> >> What happens when you move the content to another area?
> >> Does the content type creator get to name it? and can they use this to
> >> find items of this new type in collections?
> >> I think this sounds similar to what was discussed in this very long thread
> >> http://groups.google.com/group/plone-developers/browse_thread/thread/121e6dcec2f539a6/a23651b69a515bfe
> >> Or else it's just dexterity schema editor :)
> > For dexterity this would be very doable via behaviors.
> > Basically you'd just have to override the DexterityBehaviorAssignable
> > adapter in plone.dexterity.behavior (specifically the enumerateBehaviors
> > method) to make sure that behaviors tied to the current parent folder
> > are also retrieved.
> > To store behaviors on a parent folder (which would then be applied to
> > it's children) one could put them in a special annotation.
> > So if an object is copied to another folder and that folder doesn't have
> > the same behaviors, the object will lose the behaviors of the previous
> > parent.
> > The code would be quite similar to the instance behaviors code I wrote
> > about recently:
> > http://opkode.com/media/blog/plone-and-dexterity-enable-behaviors-per-content-type-instance
> I think his requirement was adding fields to a whole section of a site
> which might mean marking every parent is hard. Using a pre traversal
> hook to set an interface on the request which then determines if a
> behavior is turned on for all descendent content.
Ah yes, that's an elegant solution for recursively enabling the behavior
from the parent folder downwards.
But how does the pre-traversal hook know which behaviors to enable? You
don't want to hardcode that. The behaviors that must be enabled in a
certain folder/section must still be stored somewhere, which is where
the annotations come in.
So you still store the behaviors in an annotation on the parent folder.
A pre-traversal hook looks them up and tags them onto the request and
then a custom DexterityAssignable adapter checks the request for
behaviors to apply on the viewed object.