#104: Moving Flon into plone core
- Proposed by
- whit morriss
- Proposal type
- User interface, Architecture
- Repository branch
- plone2_2-integration
- State
- rejected
Definitions
- apidoc
- pydoc style documentation browser for zope3
Motivation
This would bring the portal interface tool into the modern era, and provide developer a powerful way to allow users to change the ui of their sites.
Since stub interfaces are agnostic to any "type" or klass information, ui and behavior can be reorganized within a site without any need to change filesystem code, reinstallation, or migration. This also provides the fastest way to make part of your site radically diferent than plone, without interferring with the rest of the plone features.
This also would encourage developers to explore the possibilities of component architecture by providing tools to ease entry. Flon exposes a subset of apidoc's inspection ui and allow you to browse what z3 interfaces are available or provided by your context.
Assumptions
This assume that CMFCore will not create it's own implementation of Flon / stub interfaces.
Proposal
Complete integration would be preferable, since Flon patches the catalog and replaces the interface tool. Flon is tested, stable, and deployed in production. Integration would be the straight task of migration it's tests and code into Plone Core.
Implementation
Steps:
- cut flon branch
- merge portal_interface code
- merge portal_catalog code
- move ancillary code & zcml to plone
- migration for portal_interface tool (?)
- create developer documentation
Deliverables
- additional developer documentation (plone.org howto?)
- localization
Risks
- additional dependencies (ProxyIndex, Five(if we are preserving 2.7.5 compat))
Participants
Sidnei da Silva
Whit Morriss
started a thread on CMF mailing list
i agree that this belongs in CMF, not in Plone. i've started a thread on the CMF mailing list referring to this PLIP and asking for thoughts on integrating this into CMF's core.
CMF integration
"This assume that CMFCore will not create it's own implementation of Flon / stub interfaces."
I have not seen any activity on the CMF list about this. Can you please talk to them about how we can cooperate instead of re-invent something or invent something that they later need to re-invent? These features sound like they belong in the CMF core level. They also sound very cool, so let's make sure we get it right and don't end up with incompatible implementations, political entanglement or other nastiness. :)