[Zope-CMF] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open efge - "CMFSetup: provide non-ascii im- and exports", [Accepted] http://www.zope.org/Collectors/CMF/292 jens - "Discussion replies removal", [Accepted] http://www.zope.org/Collectors/CMF/391 mhammond - "Windows DevelopmentMode penalty in CMFCore.DirectoryView", [Accepted] http://www.zope.org/Collectors/CMF/366 regebro - "fiveactionstool broken (Zope 2.9/3.2)", [Accepted] http://www.zope.org/Collectors/CMF/392 Pending / Deferred Issues - "CMFCalendar weekday locale issue", [Pending] http://www.zope.org/Collectors/CMF/237 - "Wrong cache association for FSObject", [Pending] http://www.zope.org/Collectors/CMF/255 - "CMFSetup: Windows exports contain CR/LF, LF and even CR newlines", [Pending] http://www.zope.org/Collectors/CMF/266 - "FSPropertiesObject.py cannot handle multiline input for lines, text attributes", [Pending] http://www.zope.org/Collectors/CMF/271 - "PortalCatalog.ZopeFindAndApply should probably also search in opaqueItems", [Pending] http://www.zope.org/Collectors/CMF/296 - "Can't invalidate skin items in a RAMCacheManager", [Pending] http://www.zope.org/Collectors/CMF/343 - "CMFSetup: Workflow Tool export fails with workflows which have scripts", [Pending] http://www.zope.org/Collectors/CMF/373 - "CMFCore.Skinnable.SkinnableObjectManager can merge skin data", [Pending] http://www.zope.org/Collectors/CMF/375 - "Proxy Roles does't work for a Script using portal_catalog.searchResults", [Pending] http://www.zope.org/Collectors/CMF/380 - "WorkflowAction deprecated warning should not printed for WorkflowMethod", [Pending] http://www.zope.org/Collectors/CMF/388 - "workflow notify success should be after reindex", [Pending] http://www.zope.org/Collectors/CMF/389 - "came_from and VIRTUAL_URL problem", [Pending] http://www.zope.org/Collectors/CMF/393 - "DCWorkflow - Transition Guards - Documentation Bug", [Pending] http://www.zope.org/Collectors/CMF/394 - "PortalFolder.py _verifyObjectPaste ignores executable security", [Pending] http://www.zope.org/Collectors/CMF/396 Pending / Deferred Features - "Favorite.py: queries and anchors in remote_url", [Pending] http://www.zope.org/Collectors/CMF/26 - "Allow flexible date editing in Event.py (CMFCalendar)", [Pending] http://www.zope.org/Collectors/CMF/40 - "DefaultDublinCore should have Creator property", [Pending] http://www.zope.org/Collectors/CMF/61 - "Make changeFromProperties accept sequences too", [Pending] http://www.zope.org/Collectors/CMF/99 - "path criteria on Topic should honor VHM", [Pending] http://www.zope.org/Collectors/CMF/111 - "Document.py: universal newlines", [Pending] http://www.zope.org/Collectors/CMF/174 - "Permissions in PortalFolder: invokeFactory()", [Pending] http://www.zope.org/Collectors/CMF/175 - "Add condition for transition's action like other action", [Pending] http://www.zope.org/Collectors/CMF/207 - "Major action enhancement", [Pending] http://www.zope.org/Collectors/CMF/232 - "portal_type is undefined in initialization code", [Pending] http://www.zope.org/Collectors/CMF/248 - "Action._listsActions() should be more safe", [Pending] http://www.zope.org/Collectors/CMF/253 - "Expose Document text_format metadata", [Pending] http://www.zope.org/Collectors/CMF/285 - "customization of type of homefolder on creation", [Pending] http://www.zope.org/Collectors/CMF/288 - "Allow contentFilter to use review_state", [Pending] http://www.zope.org/Collectors/CMF/294 - "CMFTopic Does Not Cache", [Pending] http://www.zope.org/Collectors/CMF/295 - "Wishlist: a flag that tags the selected action.", [Pending] http://www.zope.org/Collectors/CMF/301 - "CMFDefault should make use of allowCreate()", [Pending] http://www.zope.org/Collectors/CMF/340 - "Nested Skins", [Pending] http://www.zope.org/Collectors/CMF/377 - "CatalogVariableProvider code + tests", [Pending] http://www.zope.org/Collectors/CMF/378 - "manage_doCustomize() : minor additions", [Pending] http://www.zope.org/Collectors/CMF/382 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] I18NFolder ->
Hi, hope this isn't too plone for this list. I'm rather new to zope/plone and have found myself in charge of moving an existing site from Plone-2.0 to Plone-2.1 and from I18NFolder/Layer to LinguaPlone. I have an existing product, that generates a javascripted dropdown menu. The site uses this menu as its main navigation. Menus are implemented using two archetypes classe 'Menu' and 'MenuItem', Menu is folderish - subclassing I18NFolder, they contain more MenuItems and Menus and show only submenus and menuitems that are in the current language. MenuItems basically just have a referencefield for the object they link to. What folderish type should I subclass for my Menu-class to require the least amount of changes? I'm thinking Folder or BaseFolder. Any caveats you can think of (I'm still not quite comfortable in archetypes). Regards, Thomas Clement Mogensen ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Retaining ease of customisation
Hi all, First of all, a couple of apologies: for the cross-post, but I think this concerns all these groups; for my ignorance: I'm only starting to scratch the surface of Z3, via Five, coming from Plone; and for dragging this out again. However, I think this is important.; and maybe for the length. :) As open source developers, we are dependent on an influx of new talent. That talent starts when people get interested in our products. I got a whiff of Plone for a project, played with it, loved it, learnt about it, and before I knew it, I was a core developer. If ever I have the chance to help out Z3-core, it'll be by way of this path, too, and there are many like me. However, the initial hurdle is quite steep. I really liked the Z2 way when I first learnt about it, and I love the Z3 way even more now that I'm digging into it. But Zope uses obscure technologies that no-one's heard of, no matter how good they are. Hence, anything to lower the burden of entry should be viewed as important, but it's all too easy for those of us who once climbed the hill to be excited by ever-better ways of doing things that we sometimes forget what the learning curve was like. I'm already trying to formulate how we can document to new Plone developers how to take advantage of the Z3 component architecture via Five, and explaining the mind-bend required to think in terms of adapters is actually not so simple. :) But I digress. I think for a lot of people, what drew them to Plone and then Zope-based development was to ease with which one could re-use and override elements of the application, especially the UI. Take a look at http://plone.org/documentation/how-to and see how many of the user-contributed documents are from people who say "I'm not an expert, but I figured out ..." and then go on to talk about portal_skins/custom. Ideally, we'd like to make everything people want to do available with a nice UI, but this is unrealistic. The things people write about in those how-tos are the things real users want to do, and they find low-impedance ways of achieving them with through-the-web customisation. So, when my customer wants a portlet, he discovers that he can copy-and-paste an example he saw on the web into his browser and edit a text box in the ZMI, and suddenly he has his portlet. Okay, that scares me a bit, but it's actually really important. If he had to go to the filesystem, set up a folder with some arbitrary structure, enter some boilerplate python code, remember to name files __init__.py and make a crazy configure.zcml with funny angle brackets, well, frankly, I think he wouldn't bother. More work for me, perhaps, but he could just as easily have been the next optilude, learning, tinkering, testing, exploring and finally contributing something valuable. The arugments against TTW, at least in its CMF 1.x form with portal_skins/custom or, worse still, page templates scattered through a content structure with acquisition magic, are clear. But that doesn't mean the concept isn't valuable. The thing that scares me is that as we move to use more Five/Z3 Views in Plone, those templates stop being customisable through the web. And the more obscure and complicated it becomes for a new user just to change a minor element that can't be fixed with CSS etc. or some setting in the UI, the more likely that user is to give up. I think there needs to be a solution for making quick, preferably TTW customisation of UI templates. As Tres pointed out, this shouldn't add a performance overhead and lead to maintenance woes for those who know what they're doing. Ideally, the site admin should be able to switch this off. Or even, the view creator should have to turn it on (e.g. by using a ZCML directive that makes a template TTW customisable. Or something). I know this strays away from best practice, that people will slap in crazy python: statements in TAL etc. Having a way of dumping this stuff to "real" views would be good, even necessary. But I think ignoring these users because the approach that's most accessible to them doesn't fit with the purity of our framework will seem to them elitist, and it'll probably drive more people to ruby-on-rails, who sell themselves on how easy it is to get started. I don't know how this may work, or whether it should sit in the Z3, CMF2 or Plone 2.x layer of the stack. My hunch is CMF, but I'd like to challenge those more in the know to explain how Z3/CMF/Plone can still accomodate these users, without hurting the more seasoned developers at the same time. Thank you, Martin -- (muted) ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
