Personal tools
You are here: Home Products Plone Roadmap #104: Moving Flon into plone core
Document Actions

#104: Moving Flon into plone core

Contents
  1. Definitions
  2. Motivation
  3. Assumptions
  4. Proposal
  5. Implementation
  6. Deliverables
  7. Risks
  8. Participants
by Whit Morriss last modified June 11, 2006 - 00:21
Flon extends the portal_interface tool to include the ability to inspect the zope3 interfaces an object may provide. It also allows for the application of stub interfaces to arbitrary objects, thereby allowing the direct application of component behaviors (views, adapters) to object chosen by a user.
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

CMF integration

Posted by Martin Aspeli at August 22, 2005 - 21:46

"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. :)

started a thread on CMF mailing list

Posted by Rob Miller at August 27, 2005 - 00:24

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.


For any issues with the web site functionality, please file a ticket.

Please consult the policy on plone.org content if you want your content published on this site.

Servers and hosting by