Content Type Idea - Field Plugins

classic Classic list List threaded Threaded
9 messages Options
David Hietpas David Hietpas
Reply | Threaded
Open this post in threaded view
|

Content Type Idea - Field Plugins

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.

Thanks for your time!

David Hietpas
Library Web Developer
University of Wisconsin Oshkosh
[hidden email] | 920-424-0291

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Nathan Van Gheem Nathan Van Gheem
Reply | Threaded
Open this post in threaded view
|

Re: Content Type Idea - Field Plugins

Is the code on github?

Did you use archetypes.schemaextender to do it? This is kind of what
it's used for, not only extending all, but being able to dynamically
extend content types on the interfaces implemented.

This is especially true for dexterity with behaviors.

Sounds interesting though :)

On Thu, Mar 29, 2012 at 3:41 PM, David Hietpas <[hidden email]> 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.
>
> Thanks for your time!
>
> David Hietpas
> Library Web Developer
> University of Wisconsin Oshkosh
> [hidden email] | 920-424-0291
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Plone-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: Content Type Idea - Field Plugins

In reply to this post by David Hietpas
On 30/03/2012, at 7:42 AM, David Hietpas <[hidden email]> 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 :)


>
> Thanks for your time!
>
> David Hietpas
> Library Web Developer
> University of Wisconsin Oshkosh
> [hidden email] | 920-424-0291
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Plone-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
J-C Brand J-C Brand
Reply | Threaded
Open this post in threaded view
|

Re: Content Type Idea - Field Plugins

On Fri, 2012-03-30 at 09:36 +1100, Dylan Jay wrote:

> On 30/03/2012, at 7:42 AM, David Hietpas <[hidden email]> 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

Cheers
JC




------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: Content Type Idea - Field Plugins

On 15/04/2012, at 6:11 AM, Jan-Carel Brand <[hidden email]> wrote:

> On Fri, 2012-03-30 at 09:36 +1100, Dylan Jay wrote:
>> On 30/03/2012, at 7:42 AM, David Hietpas <[hidden email]> 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.


>
> Cheers
> JC
>
>
>

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: Content Type Idea - Field Plugins

In reply to this post by Nathan Van Gheem
On 30/03/2012, at 7:59 AM, Nathan Van Gheem <[hidden email]> wrote:

> Is the code on github?
>
> Did you use archetypes.schemaextender to do it? This is kind of what
> it's used for, not only extending all, but being able to dynamically
> extend content types on the interfaces implemented.
>
> This is especially true for dexterity with behaviors.
>
> Sounds interesting though :)

It does sound very interesting. If you can add fields through the web
to everything in a section of a site then it sounds like a great
solution to how users can enhance the classification of their content
themselves.

Can you put the code on github?



>
> On Thu, Mar 29, 2012 at 3:41 PM, David Hietpas <[hidden email]> 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.
>>
>> Thanks for your time!
>>
>> David Hietpas
>> Library Web Developer
>> University of Wisconsin Oshkosh
>> [hidden email] | 920-424-0291
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Plone-developers mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/plone-developers
>>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Plone-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
J-C Brand J-C Brand
Reply | Threaded
Open this post in threaded view
|

Re: Content Type Idea - Field Plugins

In reply to this post by Dylan Jay
On Sun, 2012-04-15 at 09:22 +1000, Dylan Jay wrote:

> On 15/04/2012, at 6:11 AM, Jan-Carel Brand <[hidden email]> wrote:
>
> > On Fri, 2012-03-30 at 09:36 +1100, Dylan Jay wrote:
> >> On 30/03/2012, at 7:42 AM, David Hietpas <[hidden email]> 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.






------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Baumann Jonas Baumann Jonas
Reply | Threaded
Open this post in threaded view
|

Re: Content Type Idea - Field Plugins


Am 15.04.2012 um 11:37 schrieb Jan-Carel Brand:

On Sun, 2012-04-15 at 09:22 +1000, Dylan Jay wrote:
On 15/04/2012, at 6:11 AM, Jan-Carel Brand <[hidden email]> wrote:

On Fri, 2012-03-30 at 09:36 +1100, Dylan Jay wrote:
On 30/03/2012, at 7:42 AM, David Hietpas <[hidden email]> wrote:

...

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.


Hey,

I've done something similar recently with archetypes. I needed to have
a request layer interface enabled for a section depending on a "layout",
configurable in the top container (a "Book" in my case, which can be recursively
exported as PDF and based on the "layout" interface different PDF layouts
can be chosen).

I've done it by storing the dotted name of the interface as string and resolving
in the traversable adapter.

My code:

Combining this with schemaextender it is possible to change fields within
the section even without knowing the content types.

Example for additional fields depending on the layout:

Example for extending the schema of every object within the container recursively
without knowing the types
(IWithinBook layer interface is enabled by the traversable adapter too):

This is a rather specific use case - I'm not sure how such an approach could be
generalized into a add-on product.
With dexterity this would be even easier, as mentioned before.

Cheers,
Jonas

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
David Glick (GW) David Glick (GW)
Reply | Threaded
Open this post in threaded view
|

Re: Content Type Idea - Field Plugins

In reply to this post by J-C Brand
On Apr 14, 2012, at 1:11 PM, Jan-Carel Brand wrote:

> On Fri, 2012-03-30 at 09:36 +1100, Dylan Jay wrote:
>> On 30/03/2012, at 7:42 AM, David Hietpas <[hidden email]> 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
>

Note that while this approach would work for behaviors that provide additional fields, it won't work for behaviors that provide marker interfaces, because Dexterity's custom __providedBy__ implementation caches the behavior marker interfaces by portal_type.
David



----------
David Glick
 Web Developer
 [hidden email]
 206.286.1235x32

GiveBIG is coming! Mark your calendar for May 2 and get ready to give big to Groundwire
on this community-wide day of giving.

http://www.seattlefoundation.org/npos/Pages/Groundwire.aspx



------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers