[PSPS08] Dexterity - a through-the-web, model-driven, friendly content type system
|
|
Martin Aspeli-2
|
Hi all,
This is my first follow-up from the Plone Strategic Planning Summit. What are we doing ----------------- The main area I'm championing is "Through-the-Web content types" - the ability to define content types directly from Plone. However, I'd like to expand on that and call it "model-driven content types". Model-driven here means that there's a model that describes the fields and behaviours that a particular type supports. This model should be abstracted from code and be available to various tools. Think ArchGenXML/Genesis as well as a TTW GUI. This system should also be able to support models that are not directly attached to content. That is, standalone forms. I probably won't tackle that first, though, since it should be easy once the content type bits are worked out. There are a few key requirements here: - It should be possible to create new content types TTW - This should require *no* programming or understanding of Python - It must not be a "dead end" - the path from TTW-defined content types to ones managed with code should be clear and simple. - Even if a non-programmer defines a content type, a programmer should be able to extend and use the type. This typically means having the ability to define event handlers or adapters on the code, or introspecting its schema and contents. This will obviously require some code, but should not mean that the non-programmer loses control over the model. - It must be possible to easily and safely transport types created TTW to other instances or make them installable as products I've included a longer description of how we envisage Dexterity working at the end of this email. How do we do it? ---------------- The implementation is tricky. :) I've been talking to a lot of people about how best to do this, and the ideas are starting to form. I'll write about those a bit later when I'm a bit more comfortable with the development model. However, there are a few things that I am quite sure about: - It won't use Archetypes - Archetypes will continue to be supported - We should have some clear migration path from Archetypes to Dexterity for people that want this, but it shouldn't be necessary - The main model will be stored in some XML format to make it easy to use with other tools (think Genesis). - GenericSetup will be part of (but not all of) the XML story - The implementation will be based very much on Zope 3 concepts. Expect to see zope.schema, zope.formlib or z3c.form, userschema, plone.folder, plone.locking and various other packes in the mix - Many parts of this puzzle should be re-usable in other stacks, like Grok I hope and think that this can be done without touching any parts of Plone core. When can we do it? ------------------ This is a *big* undertaking. There's a huge amount of code to be written and a lot of details to be worked out. I am very interested in this, as are others I've spoken to, but don't expect anything very soon. I'd hope to get it into Plone 4 (though I also think it'll eventually work as an add-on). We're looking at 6-9 months, though. What now? --------- Please read the user stories below and tell me what you think! If you're interested in helping out, let me know. Cheers, Martin ========= Dexterity ========= Dexterity is the code name for a new way of creating and managing content types in Plone. It aims to take the power to create content types out of the realm of developers and put it in the hands of site administrators and business analysts. Dexterity is also designed to work well with GUI tools ala Gensis or ArchGenXML. User story - creating content types ------------------------------------- Plone gains a new control panel called "Content types and forms". Through this control panel, a non-developer can choose to create a new type. She will enter basic type properties, such as a title, whether the type is folderish and so on. She also selects any number of behaviours she wants to enable enable, such as locking, versioning, local role security, the ability to assign portlets, or title-to-id renaming. She then enters into a schema editor. Here, she can add any number of fields to build a data model of the new type. Naturally, fields can be edited, deleted or re-ordered as necessary. When the type definition is saved, presuming the type has been enabled, it will show up through the Plone interface, just as a normal content type. User story - packaging up a content type to deploy elsewhere ------------------------------------------------------------- So far, the type has lived in the ZODB only. All the settings made through the web can, however, be exported and re-imported using GenericSetup. User story - adding new behaviour to content types -------------------------------------------------- Some behaviour cannot be managed entirely through-the-web. In this case, we really need a proper Python class and probably an interface for the type. Having a real Python class makes it possible to register adapters, say, for this type or indeed do anything else that's possible with Python code. Thus, a business analyst can defer some advanced tasks to a programmer by having the programmer work on a filesystem package with access to the full power of Python. A programmer can run a 'paster' command to create a new package housing a content type. Before paster generates the skeleton, he is asked for the URL to a web service that describes the type as created through the web (this requires a running site and must be subject to security). The web service gives paster enough information to generate a package that is equivalent to has been managed TTW. The schema and type properties are held in an XML file and loaded dynamically as necessary. If the package is installed in the Plone site where the type was originally defined, the installer will reconcile the two type definitions. If both have changed in incompatible ways, the user will be asked to choose whether to override the TTW version or the filesystem version. Once the two have been connected, they are one and the same Future modifications to the schema TTW will edit the model on the filesystem. When edited TTW, the model will be automatically versioned, using a system such as Mercurial, to allow roll-back to a previous state if necessary. User story - creating content types with alternative tools ---------------------------------------------------------- A visual, standalone tool such as ArchGenXML/Genesis can be used to manage the XML model created paster as above. In this case, the schema did not originate TTW, but the same XML format and API are used. User story - creating views --------------------------- When a new type is defined TTW, it will per default have basic "view" and "edit" tabs. In the GUI, the user can choose to generate a template for the view taking place of the generic one. Rather than being a generic template, this is a flat ZPT that prints all field values in a simple layout. The user can then change this through the web as appropriate. If and when the type is moved to the filesystem, it will be registered as a normal view. As with the schema and type properties in the model, the template of the view will continue to be editable TTW. User story - creating forms --------------------------- The Dexterity system also allows the creation of standalone forms. Forms use the same schema representation and GUI, but do not result in a content type. Forms are added to the Plone content hierarchy with a generic 'Form' content type. When instantiated, this type allows the user to choose from any available forms. When a form is validated and saved, it can be associated with a pre-defined content rule. A set of actions like "send as email" or "save to relational database" are available for rules that can act as form actions. Form packages can be exported or re-created with web services as with content types. The XML representation of a form shares applicable elements with that of a content type. -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
David Glick-2
|
(Ooops, accidentally didn't reply to all. Sorry for the noise Martin.)
Martin, Your description of how model-driven content types would work echoes what I heard at PSPS, and I'm excited about it -- it would make the most common customizations we do quite a bit easier, and allow less technically inclined folks to take on some of that work. I've added some brief comments below, trying to flesh out the user stories. I've been silent on the parts that sound good, which is most of it. :) peace, David Martin Aspeli wrote: > User story - creating content types > ------------------------------------- > > Plone gains a new control panel called "Content types and forms". > Through this control panel, a non-developer can choose to create a new > type. She will enter basic type properties, such as a title, whether > the type is folderish and so on. She also selects any number of > behaviours she wants to enable enable, such as locking, versioning, > local role security, the ability to assign portlets, or title-to-id > renaming. > > She then enters into a schema editor. Here, she can add any number of > fields to build a data model of the new type. Naturally, fields can be > edited, deleted or re-ordered as necessary. > > When the type definition is saved, presuming the type has been > enabled, it will show up through the Plone interface, just as a normal > content type. > > User story - packaging up a content type to deploy elsewhere > ------------------------------------------------------------- > > So far, the type has lived in the ZODB only. All the settings made > through the web can, however, be exported and re-imported using > GenericSetup. > > User story - adding new behaviour to content types > -------------------------------------------------- > > Some behaviour cannot be managed entirely through-the-web. In this > case, we really need a proper Python class and probably an interface > for the type. Having a real Python class makes it possible to register > adapters, say, for this type or indeed do anything else that's > possible with Python code. Thus, a business analyst can defer some > advanced tasks to a programmer by having the programmer work on a > filesystem package with access to the full power of Python. > > A programmer can run a 'paster' command to create a new package > housing a content type. Before paster generates the skeleton, he is > asked for the URL to a web service that describes the type as created > through the web (this requires a running site and must be subject to > security). The web service gives paster enough information to generate > a package that is equivalent to has been managed TTW. The schema and > type properties are held in an XML file and loaded dynamically as > necessary. > > If the package is installed in the Plone site where the type was > originally defined, the installer will reconcile the two type > definitions. If both have changed in incompatible ways, the user will > be asked to choose whether to override the TTW version or the > filesystem version. Once the two have been connected, they are one and > the same > > Future modifications to the schema TTW will edit the model on the > filesystem. When edited TTW, the model will be automatically > versioned, using a system such as Mercurial, to allow roll-back to a > previous state if necessary. > 1. Add on fields to core content types (a la schemaextender, but configured TTW). Or allow migrating content from a core content type to a variation created TTW. The most common customization we need to do is to add a single field or two to a standard content type. Of course, it's important that this sort of customization be localizable to one particular Plone site in a zope instance. 2. Modify TTW a content type that was defined sometime previously, and is actually being used by content. We need to provide smart migration when fields are added, removed, or modified. > User story - creating content types with alternative tools > ---------------------------------------------------------- > > A visual, standalone tool such as ArchGenXML/Genesis can be used to > manage the XML model created paster as above. In this case, the schema > did not originate TTW, but the same XML format and API are used. > > User story - creating views > --------------------------- > > When a new type is defined TTW, it will per default have basic "view" > and "edit" tabs. In the GUI, the user can choose to generate a > template for the view taking place of the generic one. Rather than > being a generic template, this is a flat ZPT that prints all field > values in a simple layout. The user can then change this through the > web as appropriate. > > If and when the type is moved to the filesystem, it will be registered > as a normal view. As with the schema and type properties in the model, > the template of the view will continue to be editable TTW. > a basic view of a content type's fields. In my opinion we should also stop trying to provide a completely generalized template in things like listings, portlets, etc. (which ends up not being generalizable once you add fancy content types like events). Instead we could allow generation of a listing view for each new content type, and use it when building a listing if it's available. But this could be a separate project. > User story - creating forms > --------------------------- > > The Dexterity system also allows the creation of standalone forms. > Forms use the same schema representation and GUI, but do not result in > a content type. > > Forms are added to the Plone content hierarchy with a generic 'Form' > content type. When instantiated, this type allows the user to choose > from any available forms. When a form is validated and saved, it can > be associated with a pre-defined content rule. A set of actions like > "send as email" or "save to relational database" are available for > rules that can act as form actions. > > Form packages can be exported or re-created with web services as with > content types. The XML representation of a form shares applicable > elements with that of a content type. > > > then later decide I'd really like to have the results stored as content in Plone? The distinction between a form and a content type seems to be mainly a question of persistence. (Well, and some other important settings currently stored in FTIs.) Can we aim for making this easily togglable, so that I can easily turn a form into a content type? -- -------------------------- David Glick Project Associate ONE/Northwest New tools and strategies for engaging people in protecting the environment http://www.onenw.org davidglick@... (206) 286-1235 x32 Subscribe to ONEList, our email newsletter! Practical advice for effective online engagement http://www.onenw.org/full_signup ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Florian Schulze-2
|
On Sat, 16 Feb 2008 01:26:06 +0100, David Glick
<davidglick@...> wrote: > I like the idea of automating the generally mindless task of generating > a basic view of a content type's fields. In my opinion we should also > stop trying to provide a completely generalized template in things like > listings, portlets, etc. (which ends up not being generalizable once you > add fancy content types like events). Instead we could allow generation > of a listing view for each new content type, and use it when building a > listing if it's available. But this could be a separate project. I talked with Malthe about this in Naples. We think one good solution would be using views and adapters. The folder listing would use something like IFolderListingTile to get the view for a content type. You could then adapt you content type to this to get a better representation of your type, a default adapter would use only the basic things like title, description and icon. For an event type you could write an adapter which addes the date and location for example. Other views would use different adapters. It may even be possible to do most of this TTW as well, by allowing to register a template and maybe a python script for the view for an interface like IFolderListingTile. Such a thing could easily be exported to the file system as well. Something we haven't figured out yet is what happens if you want to customize this, as you would have to change the adapters for all content types, or register a new custom listing which uses your own interface which again needs to register adapters for each content type. I guess the latter is more easy if you use a default adapter and customize for the content types you really need, as that would amount to roughly the same work as the current way of customizing folder_listing.pt etc. Regards, Florian Schulze ps: I hope this makes sense, as it's late and I'm tired :) pps: This doesn't actually have much to do with Dexterity, so I change the subject ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Martin Aspeli-2
|
In reply to this post by David Glick-2
David Glick wrote:
> 1. Add on fields to core content types (a la schemaextender, but > configured TTW). Or allow migrating content from a core content type to > a variation created TTW. The most common customization we need to do is > to add a single field or two to a standard content type. Of course, > it's important that this sort of customization be localizable to one > particular Plone site in a zope instance. I will consider modification to core types out of scope for now, simply because they are Archetypes-based. Having a standard way of "Dexterising" an AT-based type would be nice, but also quite difficult. It should come later, but we need to get everything else right first. > 2. Modify TTW a content type that was defined sometime previously, and > is actually being used by content. We need to provide smart migration > when fields are added, removed, or modified. Yes, this is part of the plan. > I like the idea of automating the generally mindless task of generating > a basic view of a content type's fields. In my opinion we should also > stop trying to provide a completely generalized template in things like > listings, portlets, etc. (which ends up not being generalizable once you > add fancy content types like events). Instead we could allow generation > of a listing view for each new content type, and use it when building a > listing if it's available. But this could be a separate project. This is important, but also out of scope for this particular piece of work. > What if I create a form and have it generate an e-mail or something, and > then later decide I'd really like to have the results stored as content > in Plone? The distinction between a form and a content type seems to be > mainly a question of persistence. (Well, and some other important > settings currently stored in FTIs.) Can we aim for making this easily > togglable, so that I can easily turn a form into a content type? Interesting. We'll have to think about that. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Matthew Wilkes
|
On Heisei 0020-02-16, at 010651GMT, Martin Aspeli wrote: > I will consider modification to core types out of scope for now, > simply > because they are Archetypes-based. Having a standard way of > "Dexterising" an AT-based type would be nice, but also quite > difficult. > It should come later, but we need to get everything else right first. Are you saying ATCTs are sinister? Seriously though, this is an excellent idea. Personally I'd say that forms are of a lower priority than content types simply because we already have PFG. Writing plone content types TTW is a wonderful idea, if any of you went to Ben Whitnall's talk at Naples you'll know that we (Team Rubber) use plone as part of our client-facing procedure to mock up navigational structure and how content would work. A simple tool to add a new content type would really be a boon, but the idea that we could just use paster to copy the planning done by a sales manager to the developers buildouts is enough to make me start salivating. How about subtyping, would that be in scope? I can imagine a type that has multiple subtle variants (or even just a variant). It would be great if they could be managed through Control Panel. Matt ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Martin Aspeli-2
|
Matthew Wilkes wrote:
> Are you saying ATCTs are sinister? No, ATCTs are great. But Archetypes was never designed for the kind of thing that Dexterity wants to do. And I'm just realising that it's quite hard. ;) > Seriously though, this is an excellent idea. Personally I'd say that > forms are of a lower priority than content types simply because we > already have PFG. That was my thinking. > Writing plone content types TTW is a wonderful > idea, if any of you went to Ben Whitnall's talk at Naples you'll know > that we (Team Rubber) use plone as part of our client-facing procedure > to mock up navigational structure and how content would work. A > simple tool to add a new content type would really be a boon, but the > idea that we could just use paster to copy the planning done by a > sales manager to the developers buildouts is enough to make me start > salivating. That's the plan. :) > How about subtyping, would that be in scope? I can imagine a type > that has multiple subtle variants (or even just a variant). It would > be great if they could be managed through Control Panel. Sub-typing would probably "just work". It would require programming, of course. TTW subtyping support would be a version 2.0 feature, I think. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Raphael Ritz
|
In reply to this post by Martin Aspeli-2
Martin Aspeli wrote:
> Hi all, > Hi Martin, [..] > I've included a longer description of how we envisage Dexterity working > at the end of this email. > somewhat off-topic: which 'Dexterity' inspired the naming http://en.wikipedia.org/wiki/Dexterity_%28disambiguation%29 or what do you want us to associate with it? ;-) Raphael ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Matthew Wilkes
|
> somewhat off-topic: which 'Dexterity' inspired the naming
> > http://en.wikipedia.org/wiki/Dexterity_%28disambiguation%29 I love that wikipedia doesn't have an article on mental dexterity. Probably a good idea to break the habit of looking at wikipedia, dictionaries are much simpler (and much more correct). Hence I'm going to keep with dexterity being the "right" way and ATCTs being sinister. (Latin is fun.) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Lennart Regebro-2
|
In reply to this post by Martin Aspeli-2
Super stuff!
Although I'm not sure why we need to complicate the story by having both ZODB and disk-based models. Isn't ZODB models and import/export via GenericSetup enough? Sure, it means that if you edit the model on disk you need to reimport the model all the time, but is there any other benefit? On Sat, Feb 16, 2008 at 12:53 AM, Martin Aspeli <optilude@...> wrote: > Hi all, > > This is my first follow-up from the Plone Strategic Planning Summit. > > What are we doing > ----------------- > > The main area I'm championing is "Through-the-Web content types" - the > ability to define content types directly from Plone. However, I'd like > to expand on that and call it "model-driven content types". > > Model-driven here means that there's a model that describes the fields > and behaviours that a particular type supports. This model should be > abstracted from code and be available to various tools. Think > ArchGenXML/Genesis as well as a TTW GUI. This system should also be able > to support models that are not directly attached to content. That is, > standalone forms. I probably won't tackle that first, though, since it > should be easy once the content type bits are worked out. > > There are a few key requirements here: > > - It should be possible to create new content types TTW > > - This should require *no* programming or understanding of Python > > - It must not be a "dead end" - the path from TTW-defined content > types to ones managed with code should be clear and simple. > > - Even if a non-programmer defines a content type, a programmer should > be able to extend and use the type. This typically means having the > ability to define event handlers or adapters on the code, or > introspecting its schema and contents. This will obviously require some > code, but should not mean that the non-programmer loses control over the > model. > > - It must be possible to easily and safely transport types created TTW > to other instances or make them installable as products > > I've included a longer description of how we envisage Dexterity working > at the end of this email. > > How do we do it? > ---------------- > > The implementation is tricky. :) I've been talking to a lot of people > about how best to do this, and the ideas are starting to form. I'll > write about those a bit later when I'm a bit more comfortable with the > development model. > > However, there are a few things that I am quite sure about: > > - It won't use Archetypes > > - Archetypes will continue to be supported > > - We should have some clear migration path from Archetypes to > Dexterity for people that want this, but it shouldn't be necessary > > - The main model will be stored in some XML format to make it easy to > use with other tools (think Genesis). > > - GenericSetup will be part of (but not all of) the XML story > > - The implementation will be based very much on Zope 3 concepts. > Expect to see zope.schema, zope.formlib or z3c.form, userschema, > plone.folder, plone.locking and various other packes in the mix > > - Many parts of this puzzle should be re-usable in other stacks, like Grok > > I hope and think that this can be done without touching any parts of > Plone core. > > When can we do it? > ------------------ > > This is a *big* undertaking. There's a huge amount of code to be written > and a lot of details to be worked out. I am very interested in this, as > are others I've spoken to, but don't expect anything very soon. I'd hope > to get it into Plone 4 (though I also think it'll eventually work as an > add-on). We're looking at 6-9 months, though. > > What now? > --------- > > Please read the user stories below and tell me what you think! If you're > interested in helping out, let me know. > > Cheers, > Martin > > ========= > Dexterity > ========= > > Dexterity is the code name for a new way of creating and managing > content types in Plone. It aims to take the power to create content > types out of the realm of developers and put it in the hands of site > administrators and business analysts. Dexterity is also designed to work > well with GUI tools ala Gensis or ArchGenXML. > > User story - creating content types > ------------------------------------- > > Plone gains a new control panel called "Content types and forms". > Through this control panel, a non-developer can choose to create a new > type. She will enter basic type properties, such as a title, whether the > type is folderish and so on. She also selects any number of behaviours > she wants to enable enable, such as locking, versioning, local role > security, the ability to assign portlets, or title-to-id renaming. > > She then enters into a schema editor. Here, she can add any number of > fields to build a data model of the new type. Naturally, fields can be > edited, deleted or re-ordered as necessary. > > When the type definition is saved, presuming the type has been enabled, > it will show up through the Plone interface, just as a normal content type. > > User story - packaging up a content type to deploy elsewhere > ------------------------------------------------------------- > > So far, the type has lived in the ZODB only. All the settings made > through the web can, however, be exported and re-imported using > GenericSetup. > > User story - adding new behaviour to content types > -------------------------------------------------- > > Some behaviour cannot be managed entirely through-the-web. In this case, > we really need a proper Python class and probably an interface for the > type. Having a real Python class makes it possible to register adapters, > say, for this type or indeed do anything else that's possible with > Python code. Thus, a business analyst can defer some advanced tasks to a > programmer by having the programmer work on a filesystem package with > access to the full power of Python. > > A programmer can run a 'paster' command to create a new package housing > a content type. Before paster generates the skeleton, he is asked for > the URL to a web service that describes the type as created through the > web (this requires a running site and must be subject to security). The > web service gives paster enough information to generate a package that > is equivalent to has been managed TTW. The schema and type properties > are held in an XML file and loaded dynamically as necessary. > > If the package is installed in the Plone site where the type was > originally defined, the installer will reconcile the two type > definitions. If both have changed in incompatible ways, the user will be > asked to choose whether to override the TTW version or the filesystem > version. Once the two have been connected, they are one and the same > > Future modifications to the schema TTW will edit the model on the > filesystem. When edited TTW, the model will be automatically versioned, > using a system such as Mercurial, to allow roll-back to a previous state > if necessary. > > User story - creating content types with alternative tools > ---------------------------------------------------------- > > A visual, standalone tool such as ArchGenXML/Genesis can be used to > manage the XML model created paster as above. In this case, the schema > did not originate TTW, but the same XML format and API are used. > > User story - creating views > --------------------------- > > When a new type is defined TTW, it will per default have basic "view" > and "edit" tabs. In the GUI, the user can choose to generate a template > for the view taking place of the generic one. Rather than being a > generic template, this is a flat ZPT that prints all field values in a > simple layout. The user can then change this through the web as appropriate. > > If and when the type is moved to the filesystem, it will be registered > as a normal view. As with the schema and type properties in the model, > the template of the view will continue to be editable TTW. > > User story - creating forms > --------------------------- > > The Dexterity system also allows the creation of standalone forms. Forms > use the same schema representation and GUI, but do not result in a > content type. > > Forms are added to the Plone content hierarchy with a generic 'Form' > content type. When instantiated, this type allows the user to choose > from any available forms. When a form is validated and saved, it can be > associated with a pre-defined content rule. A set of actions like "send > as email" or "save to relational database" are available for rules that > can act as form actions. > > Form packages can be exported or re-created with web services as with > content types. The XML representation of a form shares applicable > elements with that of a content type. > > > -- > Author of `Professional Plone Development`, a book for developers who > want to work with Plone. See http://martinaspeli.net/plone-book > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Plone-developers mailing list > Plone-developers@... > https://lists.sourceforge.net/lists/listinfo/plone-developers > -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Wichert Akkerman
|
In reply to this post by Martin Aspeli-2
Previously Martin Aspeli wrote:
> However, there are a few things that I am quite sure about: > > - It won't use Archetypes I have one remark on this: that means LinguaPlone will no longer be supported. Unless there is an alternative that means an important use case will no longer be possible. Please keep in mind that whatever you end up with has to support both things like LinguaPlone and things like schemaextender. Wichert. -- Wichert Akkerman <wichert@...> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Laurence Rowe
|
In reply to this post by Martin Aspeli-2
Martin Aspeli wrote:
<snip /> > > User story - adding new behaviour to content types > -------------------------------------------------- > > Some behaviour cannot be managed entirely through-the-web. In this case, > we really need a proper Python class and probably an interface for the > type. Having a real Python class makes it possible to register adapters, > say, for this type or indeed do anything else that's possible with > Python code. Thus, a business analyst can defer some advanced tasks to a > programmer by having the programmer work on a filesystem package with > access to the full power of Python. > > A programmer can run a 'paster' command to create a new package housing > a content type. Before paster generates the skeleton, he is asked for > the URL to a web service that describes the type as created through the > web (this requires a running site and must be subject to security). The > web service gives paster enough information to generate a package that > is equivalent to has been managed TTW. The schema and type properties > are held in an XML file and loaded dynamically as necessary. Is this the right way around? Maybe the developer should be programming a `behaviour`, and defining a marker interface for it, which the business analyst then adds to their content type TTW. > If the package is installed in the Plone site where the type was > originally defined, the installer will reconcile the two type > definitions. If both have changed in incompatible ways, the user will be > asked to choose whether to override the TTW version or the filesystem > version. Once the two have been connected, they are one and the same > > Future modifications to the schema TTW will edit the model on the > filesystem. When edited TTW, the model will be automatically versioned, > using a system such as Mercurial, to allow roll-back to a previous state > if necessary. There will necessarily be many changes to the model through the development process. I don't think it need be necessary to import/export all the time. Other things I can imagine doing through the web are defining validators, invariants and dynamic defaults. There should be a final export process that produces a fairly normal python product though, as doing so could have performance benefits. Laurence ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Martin Aspeli-2
|
In reply to this post by Lennart Regebro-2
Lennart Regebro wrote:
> Super stuff! > > Although I'm not sure why we need to complicate the story by having > both ZODB and disk-based models. Isn't ZODB models and import/export > via GenericSetup enough? Sure, it means that if you edit the model on > disk you need to reimport the model all the time, but is there any > other benefit? I suspect performance would be better (no need to look up a persistent schema all the time), and my gut feel was that it'd be easier to work with an XML file on disk that was always "in sync" than a file that'd need to be exported/imported all the time. However, I may be wrong about it. I'm curious what Alec thinks. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Martin Aspeli-2
|
In reply to this post by Wichert Akkerman
Wichert Akkerman wrote:
> Previously Martin Aspeli wrote: >> However, there are a few things that I am quite sure about: >> >> - It won't use Archetypes > > I have one remark on this: that means LinguaPlone will no longer be > supported. Unless there is an alternative that means an important use > case will no longer be possible. I thought plone.app.multilingual would supercede LP and be more general, but maybe that's stagnated? > Please keep in mind that whatever you end up with has to support both > things like LinguaPlone and things like schemaextender. This is completely true. There are a few such things - link integrity, iterate ... basically things that are depending on AT references. I've tried to look at these and it seems that "catching up" would not be impossible, but it's obviously a lot of work. This is also why I don't really think of this as a direct successor to Archetypes. It's more an effort to think about new and better ways to build content types, making this a task that's accessible to administrators and power users, not just programmers. I don't really want to be constrained by the current way AT works, at least not in the initial design/thinking. I think schemaextender like functionality would have to be part of Dexterity anyway. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Max M
|
In reply to this post by Lennart Regebro-2
Lennart Regebro skrev:
> Super stuff! > > Although I'm not sure why we need to complicate the story by having > both ZODB and disk-based models. Isn't ZODB models and import/export > via GenericSetup enough? Sure, it means that if you edit the model on > disk you need to reimport the model all the time, but is there any > other benefit? I believe that the best way to do it, would be to just make a web based content builder. When the system is in development mode, you can design models online, and it will create content types on the file system. A bit like paster, but with a gui and lot more options. The generated content types must be made so that anything done in the filesystem works whether you change something on the filesystem or through the web. Forget xml and do the configuration in Python data structures and it should be possible. A quick thought is a 3 pronged approach: configure.py ------------ contentconfiguration = { 'title' = {'type':'string'}, 'description' = {'type':'text'}, 'adder' = {'type':'method', 'args':['x','y'], 'code':'return x+y'}, } contenttype.py -------------- # ttw generated content type from dexterity import setupFromConfiguration from configure import contentconfiguration from custom import Custom class TheNewContentType(Custom): setupFromConfiguration(contentconfiguration) custom.py --------- class Custom: "Where filesystem based stuff takes place" def mySpecialStuff(self): "ds fas sf" Filesystem based development could then take place in the Custom class without touching anything else. Even better would be if the "TheNewContentType" class could be used as the configuration. But I have no idea how hard it is to introspect classes for that. Having parts of content types in the zodb is not much different than it was with ZClasses. There is a lot of hard lessons in here: http://wiki.zope.org/zope2/ZClassesAreEvil http://mail.zope.org/pipermail/zope/2002-May/115427.html -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Martin Aspeli-2
|
Max M wrote:
> I believe that the best way to do it, would be to just make a web based > content builder. > > When the system is in development mode, you can design models online, > and it will create content types on the file system. > > A bit like paster, but with a gui and lot more options. There are lots of problems with this, such as the fact that you'd need to create, load and install a package into a running Zope instance (which would normally require a restart) and ensure it's in the pythonpath after the next restart (which would normally require a re-buildout). > The generated content types must be made so that anything done in the > filesystem works whether you change something on the filesystem or > through the web. > > Forget xml and do the configuration in Python data structures and it > should be possible. This makes the model much less accessible to external tools or introspection outside Zope. Code generation is very hard and there is a huge amount of scope for things to go wrong as people try to be clever (or try to copy code from somewhere else) and end up confusing the system. Note that the idea is that if you're a programmer, you'll still have all kinds of programming constructs to build your type, including side-stepping any kind of declarative schema configuration if you really want to. The schema as defined through graphical tools, though, is definitely *data*, not code, and data should not be stored in programming language code. > Having parts of content types in the zodb is not much different than it > was with ZClasses. There is a lot of hard lessons in here: > > http://wiki.zope.org/zope2/ZClassesAreEvil > http://mail.zope.org/pipermail/zope/2002-May/115427.html Definitely. I had a chance to speak to Jim Fulton about this a bit as well, which was enlightening. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Martin Aspeli-2
|
In reply to this post by Laurence Rowe
Laurence Rowe wrote:
> Martin Aspeli wrote: > <snip /> >> User story - adding new behaviour to content types >> -------------------------------------------------- >> >> Some behaviour cannot be managed entirely through-the-web. In this case, >> we really need a proper Python class and probably an interface for the >> type. Having a real Python class makes it possible to register adapters, >> say, for this type or indeed do anything else that's possible with >> Python code. Thus, a business analyst can defer some advanced tasks to a >> programmer by having the programmer work on a filesystem package with >> access to the full power of Python. >> >> A programmer can run a 'paster' command to create a new package housing >> a content type. Before paster generates the skeleton, he is asked for >> the URL to a web service that describes the type as created through the >> web (this requires a running site and must be subject to security). The >> web service gives paster enough information to generate a package that >> is equivalent to has been managed TTW. The schema and type properties >> are held in an XML file and loaded dynamically as necessary. > > Is this the right way around? Maybe the developer should be programming > a `behaviour`, and defining a marker interface for it, which the > business analyst then adds to their content type TTW. That's certainly one workflow, and one which I imagine would be quite possible. However, I think that if you transition this to be mainly a programmer task (i.e. you "graduate" from power user to developer, or you hand it over) then this would be quite cumbersome and indirect for deeper modes of integration. Having direct control over the schema in the same place you're defining adapters and event handlers and what not seems more obvious to me. >> If the package is installed in the Plone site where the type was >> originally defined, the installer will reconcile the two type >> definitions. If both have changed in incompatible ways, the user will be >> asked to choose whether to override the TTW version or the filesystem >> version. Once the two have been connected, they are one and the same >> >> Future modifications to the schema TTW will edit the model on the >> filesystem. When edited TTW, the model will be automatically versioned, >> using a system such as Mercurial, to allow roll-back to a previous state >> if necessary. > > There will necessarily be many changes to the model through the > development process. I don't think it need be necessary to import/export > all the time. Right, that was my thinking (although Lennart brought up a good point - is it not easier to store it in the ZODB all the time?). Alec just suggested that we do some kind of implicit versioning when we edit the filesystem XML from the TTW GUI, otherwise accidental changes would be non-recoverable. > Other things I can imagine doing through the web are defining > validators, invariants and dynamic defaults. Mmmm.... Maybe. I was thinking more like picking these from pre-defined lists. Having people type Python into a textbox kind of goes against this. I'd rather then that the filesystem developer made such things available for inclusion in the schema. > There should be a final export process that produces a fairly normal > python product though, as doing so could have performance benefits. I think that if you've made the transition to the filesystem (using paster and the web service) then that *is* a "normal" python product. It may load some schema state from XML rather than from a series of zope.schema calls, but that's not a performance problem after startup. This is very much about having "real" code and packages that can be understood and debugged. There's no point if excessive magic makes it difficult to do anything we hadn't thought of when we designed the framework. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Viðar Svansson
|
In reply to this post by Martin Aspeli-2
Hi
Sorry Martin for the double post. I have been thinking a lot about this lately and had a slightly different idea about the behaviour story that might be worth considering. On Feb 15, 2008 11:53 PM, Martin Aspeli <optilude@...> wrote: [snip] > This is a *big* undertaking. There's a huge amount of code to be written > and a lot of details to be worked out. I am very interested in this, as > are others I've spoken to, but don't expect anything very soon. I'd hope > to get it into Plone 4 (though I also think it'll eventually work as an > add-on). We're looking at 6-9 months, though. Is there anything that makes it hard to aim for this for Plone 3 and above as an add-on? [snip] > User story - adding new behaviour to content types > -------------------------------------------------- > > Some behaviour cannot be managed entirely through-the-web. In this case, > we really need a proper Python class and probably an interface for the > type. Having a real Python class makes it possible to register adapters, > say, for this type or indeed do anything else that's possible with > Python code. Thus, a business analyst can defer some advanced tasks to a > programmer by having the programmer work on a filesystem package with > access to the full power of Python. To solve this, it would be nice if Dexterity would provide an extension API so that adapters could be written for the "live content types". Then the developer could write and install a package that would provide all the extra functionality to the types. For convenience, a view that is registered for all types could be used to inspect the API to hook into the type. Something like @@API should do the trick. There might be some limitation on this approach that I am not aware of (performance was mentioned earlier), but it sounds easier than the web-service story. > > A programmer can run a 'paster' command to create a new package housing > a content type. Before paster generates the skeleton, he is asked for > the URL to a web service that describes the type as created through the > web (this requires a running site and must be subject to security). The > web service gives paster enough information to generate a package that > is equivalent to has been managed TTW. The schema and type properties > are held in an XML file and loaded dynamically as necessary. > > If the package is installed in the Plone site where the type was > originally defined, the installer will reconcile the two type > definitions. If both have changed in incompatible ways, the user will be > asked to choose whether to override the TTW version or the filesystem > version. Once the two have been connected, they are one and the same > > Future modifications to the schema TTW will edit the model on the > filesystem. When edited TTW, the model will be automatically versioned, > using a system such as Mercurial, to allow roll-back to a previous state > if necessary. > This sounds really exciting, but I think we could get without this in the first version. Having an API to hook into types in the ZODB and GS export/import might be enough to have something really useful that we can ship sooner. Viðar ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
Donna Snow (SnowWrite)-2
|
Quick question... is this the TTW content type model Alec introduced at PSPS?
I can't follow all of the discussion.. and I apologize.. but from what I'm gathering this'll allow the integrator to create a content type ttw.. then "push a button" that'll push it out to the filesystem?? Is this the high level concept? Or am I totally off base here? Best Regards, Donna M. Snow, Principal C Squared Enterprises illuminate your web http://www.csquaredtech.com (408)866-1300 On Feb 16, 2008 1:31 PM, Viðar Svansson <vidarsvans@...> wrote: Hi ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Martin Aspeli-2
|
In reply to this post by Viðar Svansson
Hi Vidar,
> I have been thinking a lot about this lately and had a slightly > different idea about the behaviour story that might be worth > considering. Cool. :) >> This is a *big* undertaking. There's a huge amount of code to be written >> and a lot of details to be worked out. I am very interested in this, as >> are others I've spoken to, but don't expect anything very soon. I'd hope >> to get it into Plone 4 (though I also think it'll eventually work as an >> add-on). We're looking at 6-9 months, though. > > Is there anything that makes it hard to aim for this for Plone 3 and > above as an add-on? No, that should be possible (and is in fact the intention). However, timing-wise it looks more like a Plone 4 thing. That may not turn out to be the case, of course. > [snip] > >> User story - adding new behaviour to content types >> -------------------------------------------------- >> >> Some behaviour cannot be managed entirely through-the-web. In this case, >> we really need a proper Python class and probably an interface for the >> type. Having a real Python class makes it possible to register adapters, >> say, for this type or indeed do anything else that's possible with >> Python code. Thus, a business analyst can defer some advanced tasks to a >> programmer by having the programmer work on a filesystem package with >> access to the full power of Python. > > To solve this, it would be nice if Dexterity would provide an > extension API so that adapters could be written for the "live content > types". Then the developer could write and install a package that > would provide all the extra functionality to the types. For > convenience, a view that is registered for all types could be used to > inspect the API to hook into the type. Something like @@API should do > the trick. > There might be some limitation on this approach that I am not aware of > (performance was mentioned earlier), but it sounds easier than the > web-service story. Yes, the "behaviour" registry (features that can be enabled on the type) would probably solve this. That makes sense if you have a non-programmer defining schemata and a programmer who provides generalisable services to plug into those schemata. It would not be ideal if the type and it's schema as well as additional behaviours were all being developed by a single programmer, though - too much indirection. I want to support both modes, where generalisable things become general, selectable behaviours (think "locking" or "link integrity checking"), whilst still making it possible for developers to have full control over a specific type. >> A programmer can run a 'paster' command to create a new package housing >> a content type. Before paster generates the skeleton, he is asked for >> the URL to a web service that describes the type as created through the >> web (this requires a running site and must be subject to security). The >> web service gives paster enough information to generate a package that >> is equivalent to has been managed TTW. The schema and type properties >> are held in an XML file and loaded dynamically as necessary. >> >> If the package is installed in the Plone site where the type was >> originally defined, the installer will reconcile the two type >> definitions. If both have changed in incompatible ways, the user will be >> asked to choose whether to override the TTW version or the filesystem >> version. Once the two have been connected, they are one and the same >> >> Future modifications to the schema TTW will edit the model on the >> filesystem. When edited TTW, the model will be automatically versioned, >> using a system such as Mercurial, to allow roll-back to a previous state >> if necessary. >> > > This sounds really exciting, but I think we could get without this in > the first version. > Having an API to hook into types in the ZODB and GS export/import > might be enough to have something really useful that we can ship > sooner. Maybe. I think it depends on how we approach the implementation. I'm starting to draft a proposal for how to actually implement this, and how to split it up into individually re-usable packages. That will probably inform this a lot more. However, there is one important point here: Most contextual-aware customisation in Zope/Plone depends on being able to adapt the context. To do that, you need a type-specific (marker) interface or class. By its very nature, the generic, TTW-only type cannot have a specific class or interface (you could generate one on the fly, but that wouldn't allow you to register new components for it anyway). There may be ways around this in specific cases - use a named adapter that has the content type id as its name, say - but it doesn't generalise and it becomes quite cumbersome. At the point when people *want* to do this kind of type-specific customisation, they will need to touch filesystem code anyway. Then, it's not too much to ask that they use a web service descriptor to push that information down to the filesystem, where they can be afforded a real class or interface. If there's one thing we've learned from ZCML and (to a certain extent) Archetypes, it's that magically generating things is a bad idea. It makes code difficult to understand and debug and usually means that once you want to step beyond the use case that the original designers had in mind, you're walking off a cliff. I really don't want to have any deep magic here. ;) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Martin Aspeli-2
|
In reply to this post by Donna Snow (SnowWrite)-2
Donna Snow wrote:
> Quick question... is this the TTW content type model Alec introduced at > PSPS? Yes. > I can't follow all of the discussion.. and I apologize.. but from what > I'm gathering this'll allow the integrator to create a content type > ttw.. then "push a button" that'll push it out to the filesystem?? Is > this the high level concept? Or am I totally off base here? Yep. They won't even need to push a button to push it to the filesystem to make it usable. The filesystem aspect should only come into play if you want a developer to be able to do more specific/advanced things with Python. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plone-developers mailing list Plone-developers@... https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
