[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 | |||||||||||||||||