Rethinking zopeskel.dexterity

4 views
Skip to first unread message

Steve McMahon

unread,
Apr 15, 2011, 5:33:50 PM4/15/11
to dexterity-...@googlegroups.com, iz...@inigo-tech.com
With Dexterity in increasingly useful shape, I want to raise the question of what the design goals for a zopeskel template for dexterity should be.

Here's my list of goals. It should:

1) Work well in conjunction with the plone.app.dexterity configlet and schema editor. It should be possible to create a content type or types TTW, push an export button, drop the results into the zopeskel-output skeleton's profiles/default directory and have a working package.

2) Support schema-driven development style, but work well in a round-trip development style where a developer adds fields TTW, then exports the new model and adds functionality in the disk product.

3) Encourage grok-style product layout. That would mean skipping creation of "content" and "browser" directories and instead using contenttype_templates directories for templates.

zopeskel.dexterity is going to need some changes if it's to do this. In my mind, it tries a little too hard to be like the archetypes support in zopeskel — down to copying its layout and supporting sub-commands to add content types and fields. I think this means that it only supports schema-driven development, when I think that new Dexterity users are going to start their development TTW, and will be more likely to elaborate with round-trip model.xml files than schema. (I know it's all schema in the end, the question is how it looks to developers.)

Here's what I'd like to see us do:

1) Have the initial zopeskel generation of a package skeleton result in a flatter package without content or browser directories. A new developer would be able to create that skeleton then drop in Dexterity-exported type profiles and *immediately* have a deployable product. (By the way, trunk of plone.app.dexterity now has a button to export type profiles.)

2) There would be a sub-command to create a new content type, and it would offer a choice of a model-centric (an xml model file in a models directory with a plone.directives.form command to pull it into the interface class) or schema-centric styles. Each would create a contenttype_templates directory, possibly with a sample template. (Note that the plone.app.dexterity trunk now also has a model-export button.)

3) We would remove the sub-command to add fields. It is only useful for schema-centric development, and those using that style are the least likely to need or want it. This would also remove several dependencies for zopeskel.dexterity, making it a more robust install.

What do folks think? If there's agreement on the bulk of this, I'm willing to do most of the work to get it into working condition.

Steve

Nathan Van Gheem

unread,
Apr 15, 2011, 5:38:58 PM4/15/11
to dexterity-...@googlegroups.com, Steve McMahon, iz...@inigo-tech.com
zopeskel.dexterity is going to need some changes if it's to do this. In my mind, it tries a little too hard to be like the archetypes support in zopeskel — down to copying its layout and supporting sub-commands to add content types and fields. I think this means that it only supports schema-driven development, when I think that new Dexterity users are going to start their development TTW, and will be more likely to elaborate with round-trip model.xml files than schema. (I know it's all schema in the end, the question is how it looks to developers.)
+1 That makes sense. 

1) Work well in conjunction with the plone.app.dexterity configlet and schema editor. It should be possible to create a content type or types TTW, push an export button, drop the results into the zopeskel-output skeleton's profiles/default directory and have a working package.
FWIW, I did some work with this sort of thing in uwosh.northstar. It'd be really nice to see this moved to dexterity.


--
You received this message because you are subscribed to the Google Groups "Dexterity development" group.
To post to this group, send email to dexterity-...@googlegroups.com.
To unsubscribe from this group, send email to dexterity-develo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dexterity-development?hl=en.

Martin Aspeli

unread,
Apr 15, 2011, 7:09:07 PM4/15/11
to dexterity-...@googlegroups.com, iz...@inigo-tech.com
Hi Steve,

On Friday, 15 April 2011, Steve McMahon <st...@dcn.org> wrote:
> With Dexterity in increasingly useful shape, I want to raise the question of what the design goals for a zopeskel template for dexterity should be.
>
> Here's my list of goals. It should:
>
> 1) Work well in conjunction with the plone.app.dexterity configlet and schema editor. It should be possible to create a content type or types TTW, push an export button, drop the results into the zopeskel-output skeleton's profiles/default directory and have a working package.

This was always a goal of Dexterity. I really hope someone can work on
this. Hint :-)

> 2) Support schema-driven development style, but work well in a round-trip development style where a developer adds fields TTW, then exports the new model and adds functionality in the disk product.

plone.supermodel / plone.directives.form has support for this by
loading a schema from an XML file via a grokker.

> 3) Encourage grok-style product layout. That would mean skipping creation of "content" and "browser" directories and instead using contenttype_templates directories for templates.

+1

> zopeskel.dexterity is going to need some changes if it's to do this. In my mind, it tries a little too hard to be like the archetypes support in zopeskel — down to copying its layout and supporting sub-commands to add content types and fields. I think this means that it only supports schema-driven development, when I think that new Dexterity users are going to start their development TTW, and will be more likely to elaborate with round-trip model.xml files than schema. (I know it's all schema in the end, the question is how it looks to developers.)

Agree. I think this is the hope for the future anyway. Moreover, for
people who start in python there shouldn't be so muchboilerplate that
a template is really necessary.

> Here's what I'd like to see us do:
>
> 1) Have the initial zopeskel generation of a package skeleton result in a flatter package without content or browser directories. A new developer would be able to create that skeleton then drop in Dexterity-exported type profiles and *immediately* have a deployable product. (By the way, trunk of plone.app.dexterity now has a button to export type profiles.)

+1

> 2) There would be a sub-command to create a new content type, and it would offer a choice of a model-centric (an xml model file in a models directory with a plone.directives.form command to pull it into the interface class) or schema-centric styles. Each would create a contenttype_templates directory, possibly with a sample template. (Note that the plone.app.dexterity trunk now also has a model-export button.)

+1

> 3) We would remove the sub-command to add fields. It is only useful for schema-centric development, and those using that style are the least likely to need or want it. This would also remove several dependencies for zopeskel.dexterity, making it a more robust install.

+

> What do folks think? If there's agreement on the bulk of this, I'm willing to do most of the work to get it into working condition.

Yay :-)

Martin

Izhar Firdaus

unread,
Apr 20, 2011, 12:53:38 PM4/20/11
to dexterity-...@googlegroups.com
Hi!

sorry, been a bit busy lately :)

+1

>
> 2) There would be a sub-command to create a new content type, and it would
> offer a choice of a model-centric (an xml model file in a models directory
> with a plone.directives.form command to pull it into the interface class) or
> schema-centric styles. Each would create a contenttype_templates directory,
> possibly with a sample template. (Note that the plone.app.dexterity trunk
> now also has a model-export button.)

+1

>
> 3) We would remove the sub-command to add fields. It is only useful for
> schema-centric development, and those using that style are the least likely
> to need or want it. This would also remove several dependencies for
> zopeskel.dexterity, making it a more robust install.

I dont quite sure who added that subcommands feature .. but to me the
suggestion above sounds good :-)

>
> What do folks think? If there's agreement on the bulk of this, I'm willing
> to do most of the work to get it into working condition.
>

Sounds cool to me :-)

Feel free to implement them. I haven't quite been working on plone
stuff these past few months, so anybody continuing whatever i left
behind is always good news to me :-)

Thanks !!!!

--
Mohd Izhar Firdaus Bin Ismail / KageSenshi
Inigo Consulting (FOSS/Plone Development, Training & Services)
http://www.inigo-tech.com
Fedora Malaysia Contributor & Ambassador
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866  5011 5BD2 584A 8A5D 7331

Steve McMahon

unread,
Apr 20, 2011, 3:45:01 PM4/20/11
to dexterity-...@googlegroups.com
On Wed, Apr 20, 2011 at 9:53 AM, Izhar Firdaus <iz...@inigo-tech.com> wrote:
... 
Feel free to implement them. I haven't quite been working on plone
stuff these past few months, so anybody continuing whatever i left
behind is always good news to me :-)


Thanks! The existing code is very easy to work with, and I don't think these changes will present any problems.

Steve
Reply all
Reply to author
Forward
0 new messages