On 11 Sep 2005, at 17:22, yuppie wrote:
Here's some food for thought about a possible code simplification:
I was looking at the (annoying) duplication of configuration data
between CMFSetup type information XML files and
factory_type_information structures stored inside python modules.
It would be cool if the XML files could completely remove the
need to have a factory_type_information, and that seems to be the
case (mostly).
That would be a big win and we are coming closer to the point where
we can do that. Not only for FTI data, but also for other settings
like Actions and workflows.
The Actions thing is another issue that I noticed today. On the
trunk, we seem to have "old style" actions on some tools (I
specifically looked at the Membership and Memberdata tools because
I'm re-doing CMFLDAP) that are not being used at all because they are
now new-style actions in the Actions tool, and indeed those tools are
not even registered as action providers anymore. Any objections to
removing those old-style actions from tools that are no longer set up
as action providers?
I noticed that when I pass an empty tuple as the "fti" argument
to ContentInit everything seems to work as expected. The only
shortcoming I found was the fact that inside the TypesTool, when
you select "Factory Type Information" from the ZMI add list, my
type is not showing up anymore, which makes sense. If you want to
get the type, you can use the portal_setup tool.
Using the setup tool for tasks like that is not easy. You can't
select settings for a specific portal type and use them for your
new type info object.
I hope the pending CMFSetup refactorings will make it easier to
extract specific settings from profiles and to make them selectable
in the add forms for tools, FTIs and workflows. (Just like complete
profiles are selectable in the site add form.)
I'm assuming the "settings" you mean here would be the equivalent of
being able to instantiate CMFSetup-controlled types manually in the
Types tool without going to the Setup tool? Yes, that functionality
is missing. What's the ETA on those refactorings? Sounds interesting.
Would it make sense to remove all those factory_type_information
structures for those types in CMF that have been converted to
CMFSetup? Would there be any bad consequences that I'm not seeing?
1.) I like the feature that allows to create pre-configured FTIs/
STIs and I don't think CMFSetup makes that feature obsolete.
2.) manage_addCMFSite and PortalGenerator are deprecated, but they
still depend on the oldstyle FTI data.
3.) It might be easier to discuss this in the context of Tres'
CMFSetup and roadmap proposals.
So in the end it looks like while we're retaining FTIs in CMF for
backwards compatibility (thus already providing the answer to one
question) it is perfectly safe for me in my products to do away with
them. That was the implied question ;)
jens
_______________________________________________
Zope-CMF maillist - [email protected]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
