Forgot your password?
New user?
Document Actions
#1: Plone 2.5 support + refactoring
- Contents
- Proposed by
- reinout
- Proposal type
- Architecture
- Assigned to release
- State
- being-discussed
Motivation
Genesis is still some way off and plone 2.5 is just around the corner. We need an interim solution. Archgenxml is widely loved and it is especially important for new plone programmers.
Plone is at a critical point regarding zope 3 stuff and archgenxml can help a lot in guiding people to the zope 3 goodness in plone 2.5 and helping them (and ourselves) to do it the Right Way.
Proposal
- Clean out tagged values and stereotypes. Remove deprecated stuff.
- Fix up the templates to be good plone 2.5/3.0 citizens. Perhaps some old stuff can be removed.
- Add GenericSetup support.
- Look if DIYplonestyle makes some of our skin support obsolete. Probably not, but everything that's not needed can be removed to allow for better maintenance.
- Remove most of the options you can pass in the config file and on the command line. Most of the items should be set as tagged values on the model instead (at least the ones that can be overwritten further down in the model).
Risks
* Modifying the layout of the resulting files, making upgrading from a previous agx project a bit of a pain (unsure if this'll happen).
Participants
Switch to membrane and remember
To my mind the next major release of ArcheGenXML should use membrane and remember instead of stocking to CMFMember since CMFMember does not and will not with PlonePAS.
Remember will replace CMFMember's functionality and be based on membrane. Membrane can and remember will make use of AT based content type so ArcheGenXML would enhance its features of being a great frontend for model driven software development even in case user type defintion.
Good point
Am I pushing my luck in asking for some example templates that we could use as a basis for this?
Additional Ideas
Stereotype for method to add custom css or javascript file. AppConfig.py would be generated and registrations would be added for all stereotyped methods of these types. This may be going overboard (probably is), but we could also add some taged values for these methods so that we could automaticaly include standard code to show items as they are in base_view. Things like the folderlisting_macro, document_actions, document_byline, and any other items that may apply. This could be a single tag that justlisted them in order of how they should be included. Could be pairs to indicate which section they should be in (header, body, footer, folderlisting).
Update the template used for custom view page templates to use the base_view macros rather than a fill_slot_main macro.