Re: [Zope-CMF] [dev] failing tests and other unit test issues
> 3.) Zope 2.8 warnings > > 'Zope2' is not available in Zope 2.7 and 'Zope' is deprecated in Zope > 2.8. Same with 'transaction' and 'get_transaction'. > > Has anybody a better idea to resolve it than this way: Well, the deprecation procedures and warning is there to tell you that you are using a way that works no, but will stop working later. The standard pattern when you need to support both the version where they are deprecated, and the version where they are not, is to do nothing... And then when you no longer need to support the older version, you move up to the new non-deprecated API. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] [dev] basic Five support - a small proposal
On 5/24/05, yuppie <[EMAIL PROTECTED]> wrote: > There is already the CMFonFive project, but now that Zope 2.8 ships with > Five I'd like to see basic Five support in CMF itself: Well you have a point. I see some options: 1. Moving CMFonFive to Zope corps CVS and simply shipping it with the next version of CMF. 2. Moving the things that are in CMFonFive into CMFCore. 3. Moving just some parts, and thereby still requireing CMFonFive for any reasonably CMF integration, and hence gaining very little. ;) I prefer 1. Then we too can have a big simple: try: import Five except ImportError: yada yada in the __init__.py > 3.) a base class for Five content: > The PortalContent class does not implement everything required in > CMFDefault. AFAICS at least some DublinCore methods are missing. We > could either add a subset as in PortalFolder or use the complete > DefaultDublinCoreImpl. Well, that's still not a Five issue. But it could be a reasonably thing to have in CMFDefault anyway. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Re: [dev] basic Five support - a small proposal
OK, so, interfaces, and a new base-class (which really isn't a five-class anyway) should go into CMF, then? The typeinfo (if it even is the right way to do this at all) and the menu-action mapping stays in CMFonFive? That makes sense to me. On 5/25/05, yuppie <[EMAIL PROTECTED]> wrote: > Hi! > > > Lennart Regebro wrote: > > On 5/24/05, yuppie <[EMAIL PROTECTED]> wrote: > > > >>There is already the CMFonFive project, but now that Zope 2.8 ships with > >>Five I'd like to see basic Five support in CMF itself: > > > > > > Well you have a point. I see some options: > > > > 1. Moving CMFonFive to Zope corps CVS and simply shipping it with the > > next version of CMF. > > > > 2. Moving the things that are in CMFonFive into CMFCore. > > Moving CMFonFive to the CMF repository might make sense. But I don't > think it is mature enough to be shipped with the CMF distribution or to > be integrated into CMFCore. > > And while CMF interface definitions really don't belong into an add-on > product, there is nothing wrong with shipping additional tools and > TypeInfo classes in separate products. > > > 3. Moving just some parts, and thereby still requireing CMFonFive for > > any reasonably CMF integration, and hence gaining very little. ;) > > Maybe we first have to discuss what we want to gain with Five support. > > My goal is to use Five technology for features CMF doesn't provide or > that could be significantly improved by using Five. I'm sure there are > other areas where CMF could benefit from Five, but these are the things > I've currently on my list: > > - schema based content and forms: > > There are still some issues that have to be resolved in Five, but the > CMF changes I proposed are all I need in CMF. > > - object specific behavior based on marker interfaces: > > Flon does it in a Plone specific way. I think this could become a > generic Five feature, but I still have to figure out why Zope 3.1 has > lost the UI for marker interfaces. > > - events: > > Didn't work on this so far, but it would be really nice if we could use > Five events in CMF. > > >>3.) a base class for Five content: > >>The PortalContent class does not implement everything required in > >>CMFDefault. AFAICS at least some DublinCore methods are missing. We > >>could either add a subset as in PortalFolder or use the complete > >>DefaultDublinCoreImpl. > > > > Well, that's still not a Five issue. But it could be a reasonably > > thing to have in CMFDefault anyway. > > I agree that the class as proposed would be useful for non-Five content > as well. But there might be reasons to make that base class Five > specific at a later point, so I thought it would be a good idea to > announce it as five specific from the beginning. > > > Cheers, > > Yuppie > > -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Problem in TypesTool with CMF1.5.1 and Zope2.8
On 6/13/05, Stefan H. Holek <[EMAIL PROTECTED]> wrote: > I get a whole bunch of Unauthorized errors when running CMF-1_5- > branch tests with Zope 2.8. Interestingly, CMF HEAD does not appear > to suffer from the same... Ouuhh... I just tested with the latest release and HEAD, and HEAD worked. I guess we need to figure out what fixes has been done for 2.8 compatibility and get them into 1_5-branc ___ 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
Re: [Zope-CMF] CMF 1.5.2
On 6/13/05, Jens Vagelpohl <[EMAIL PROTECTED]> wrote: > Question to the group: Any problem with starting the CMF 1.5.2 beta > cycle this week or next week? Well, somebody probably should figure out why 1_5-branch doesn't work with zope 2.8, while HEAD does, so we can fix that first. Does anybody feel guilty for fixing HEAD? :) ___ 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
Re: [Zope-CMF] CMF 1.5.2
On 6/13/05, Lennart Regebro <[EMAIL PROTECTED]> wrote: > Well, somebody probably should figure out why 1_5-branch doesn't work > with zope 2.8, while HEAD does, so we can fix that first. Does anybody > feel guilty for fixing HEAD? :) False alarm. :) No, I see no reason why we can't start the beta cycle now. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: CMF bug day
On 7/5/05, Tres Seaver <[EMAIL PROTECTED]> wrote: > D'oh. Make that:2005/07/07 And here I think you have made a time machine. :-( We'll, I think I can help anyhoo. See ya tomorrow. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] RFC: CMF 2.0 Roadmap
On 7/12/05, Tres Seaver <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I've uploaded a draft of a roadmap for CMF 2.0: > > http://www.zope.org/Products/CMF/docs/requirements/CMF20Roadmap > > Please comment there, or follow up here. Well... I don't really understand the purpose. I know, you write it on the roadmap, it's to make a smooth migration path to Zope3, but how does this help more sepcifically? Currently, you can write Five products and run them under CMF. The difference between Five products and Zope3 products will get smaller and smaller. Very little of this will have anything to do with CMF, although some things will definitely be needed: * Interfaces for everything in CMF is one good thing. * Another is the coming support for local utilities in Five, which needs CMF portals to be a Zope3 site. That could also expand so that the portal_tools of CMF are registered also as local utilities, so that you get the tools via getLocalUtility and not via getToolByName. But all of this are pure add-ons to CMF as of today, and can easily be implemented in CMF 1.6. So I guess I don't really see what a 2.0 could give us. I sure don't mind a rewrite of CMF with Five technologies, but is that really the best way to spend our energy? Convince me. :) ___ 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
Re: [Zope-CMF] [dev] CMFSetup backwards compatibility policy
On 7/14/05, Jens Vagelpohl <[EMAIL PROTECTED]> wrote: > > On 14 Jul 2005, at 17:33, yuppie wrote: > > I don't think we should try to maintain code compatibility on HEAD. > > All we should promise is that imports of old profiles work and that > > we don't break the persistent SetupTool. > > I suppose right now we're all a little bit in the air about what CVS > HEAD is going to become. Will it be CMF 2.0 or CMF 1.6? If we go the > more radical way to 2.0 it would be more permissible to have lesss > backwards compatibility I'd say... I vote for 1.6, at least until it's clear what benefits and roughly what changes 2.0 holds. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: ToolInit deprecation warnings
On 7/23/05, Martin Aspeli <[EMAIL PROTECTED]> wrote: > Note that Plone does this all over the place, and we probably won't change > it for 2.1. 2.1.1 maybe... Well, that's life with deprecation warnings. :-) Also, this is deprecated in 1.5.2 and later only. CMF 1.5.1 still requires it... ___ 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
Re: [Zope-CMF] Re: proposal for cmf:indexable directive
On 9/13/05, yuppie <[EMAIL PROTECTED]> wrote: > Is this in any way CMF-specific? Wouldn't a feature like that be useful > in pure Zope as well? Why do you think the CMF would be the right layer > to implement this? Welll, what is gonna implement it? There is no standard indexing service in Zope, but in CMF there is portal_catalog. Of course, we coule *create* a standard default indexing service in Zope, but what should we then do with portal_catalog? :-D (btw: After a quick read-through of the proposal I didn't have anything to add). ___ 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] Re: proposal for cmf:indexable directive
On 9/13/05, yuppie <[EMAIL PROTECTED]> wrote: > > Welll, what is gonna implement it? There is no standard indexing > > service in Zope, but in CMF there is portal_catalog. > > ??? > > portal_catalog is a thin wrapper around ZCatalog and Zope 3.1 ships with > zope.app.catalog. Yes. And in a CMF site, portal_catalog exists. In Zope site it usually does not. Hence, in a CMF site, there is a standard service, and in a zope site, there is not. > The proposal addresses a general cataloging issue. Can't see why content > used in CMF has to be configured with a special cmf ZCML directive. What namespace to use seems to me to be a minor issue. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Weird IndexableObjectWrapper + TopicIndex + aq_acquired interactions.
OK, lets try on THIS mailing list, then. :)
TopicIndexes can have expressions as filters. Like for example:
"getattr(o, 'portal_type', None) not in ('Section', 'Workspace')"
Where o is the object that are being indexed.
But, this being an expression, it's protected, and therefore, a
getattr becomes a guarded_gettatr.
guarded_getattr does it's security check by doing:
validate = SecurityManagement.getSecurityManager().validate
aq_acquire(inst, name, aq_validate, validate)
Where in this case inst will be the object that is being indexed.
aq_acquire will, if the first parameter is not an AcquisitionWrapper,
and the third parameter is not None, wrap the object.
Now, in most CMF cases, the object is an IndexableObjectWrapper, wrapping an
Acquisition wrapped object. So, aq_acquire will Acquicision wrap the
IndexableObjectWrapper, with the result that the object being used now
has no context!
Then, it passes this to validate, who in turn passes it to allowed,
who check that the object has the users user folder in it's context.
And it hasn't, because it has no context. *blam* You get an
AuthorizedError, and the object does not get indexed.
OK, there are several ways to fix this, one being to not use getattr.
But there is still something missing from my understandning of all
this:
- Not every object has this problem! Why, I have no idea. I had his
problem in two products, and in ONE of them, it disappeared when I
introduced the otherwise useless PropertyManager as a baseclass. The
other product already has propertymanager as a baseclass!
Any insight into this would be appreciated.
//Lennart
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
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] Re: Weird IndexableObjectWrapper + TopicIndex + aq_acquired interactions.
OK, so, for some reason some CMF objects fail when being indexed because they are wrapped in an aq wrapper that wrapped an IndexableObjectWrapper that wraps another aq_wrapper. And sometimes, the same object do not fail in otehrwise very similar situation. *sigh*. So for example, this works fine: container._setObject(id, ob) ob = container._getOb(id) ob.indexObject() All if fine. And this fails: container._setObject(id, ob) ob = container._getOb(id) ob.manage_permission( permission_to_manage='Access contents information', roles=ACCESS_CONTENTS_INFO_ROLES, acquire=0) ob.indexObject() Now, it only fails around every second time. Mhm. Nope, not everytime. It's regukar, a unit test will fail on the same places both times, but *exactly the same call* will still fail about every second time. Hurray. I'm so happy this problem is so easy to track down! Grrr. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: CMFTestCase: Best way to create the CMF site?
On 10/5/05, Chris Withers <[EMAIL PROTECTED]> wrote: > Stefan H. Holek wrote: > > I see two options: > > > > a) Use a different portal name > > > > portal_name = 'mysite' > > CMFTestCase.setupCMFSite(portal_name) > > Can setupCMFSite not do something more clever if it finds the object > already there? > > > b) Use getPortal() to create a new portal per test > > > > def getPortal(self): > > manage_addCMFSite(self.app, portal_name) > > return getattr(self.app, portal_name) > > hahaha, and watch your tests take hours to run ;-) > > Chris Any test including PortalTestCase should really not be seen as a unit test, but a fucntional test. ;) If we could put in some effort of making a minimal dymmy-portal that can be deleted and recreated very quickly, then that would be very interesting. I would assume that that involved a lot of work though... -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] New local site manager branch!
The effort of updating and merging Sidneis old local site manager support is continuing. The new branch is: http://codespeak.net/svn/z3/Five/branch/regebro-sitemanager/ And to prevent it from being outdates and hard to merge (happened even with the branch I made at the castle-sprint) this is going to be merged pretty quickly (that might mean tomorrow, even). So please take a look at it, or if you think you should look at it before merging, scream now! :) I include the CMF list above, because the main idea with this is to make it possible to start converting the portal tools to be local utilities instead, thereby taking another step towards Zope3-ishness. There is already a branch for making CMF portal objects local sites: http://svn.zope.org/CMF/branches/regebro-sitemanager/ It so far contains only added tests: test_localservice.py. These tests that you can add and lookup local utilities after declaring portals to be local sites. Next steps are to include the zcml statement in question in the standards configure.zcml, and change getToolByName to in for utilities before it looks for the portal_something object. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Re: [z3-five] Five and CMFDefault
Not a Five problem, but a CMF problem, switching lists to [EMAIL PROTECTED] On 10/12/05, David Pratt <[EMAIL PROTECTED]> wrote: > One thing I noticed is that there is no class > Products.CMFCore.interfaces.IWorkflowDefinition. It is > Products.CMFCore.interfaces.WorkflowDefinition (no I in front of > WorkflowDefinition). Perhaps this is where it is getting messed up Well, if you try to access Products.CMFCore.interfaces.IWorkflowDefinition and it doesn't exist you would get an error, yes. :) Besides, I have the feeling it should be Products.CMFCore.interfaces.portal_workflow.WorkflowDefinition, unless ther e is some magic going on. And I assume that the missing I is just a typo. > but why then is it not failing for CMFSite product? It probably never arrives at using this? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: CMF and Five views: hooking up "POST"
The standard Zope3-ish way is to have a m,ethod called Update() which you call every time the views template is displayed. This method can prepare all the data to be displayed, as well as handle any form postings. Instead of checking on POST I usually check on the button-presses, but of course if you don't want GET-forms to work, checking for POST is the right thing to do. ___ 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] Re: CMF and Five views: hooking up "POST"
On 10/17/05, yuppie <[EMAIL PROTECTED]> wrote: > I know that pattern, but I don't like it. [...] > The code on the goldegg-folder_contents branch processes the input in > the __call__ method of the view class. The template is only invoked if > needed. It's much cleaner to use the template just for displaying > results, not for triggering controllers. That's purely a matter of taste. From a principal standpoint I don't think there is any difference, really. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Five:traversable and PortalContent
On 11/29/05, Brent Hendricks <[EMAIL PROTECTED]> wrote: > When goldegg was first started, plone had a line like this in configure.zcml: > > class="Products.CMFCore.PortalContent.PortalContent" > /> > > I've noticed that this line causes failures in the CMFCore tests so > I'm taking it out of plone. If it's necessary it should probably go > in CMFCore anyway I think it *is* in the core now. I'm not sure it should be, though. It's there to allow you to make views for objects, and I'm not at all sure it's a good idea to have that feature turned on for everything like that. It has caused me trouble earlier, I know that. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] CMFonFive and CMF 1.6
I'm in the process of making CMFonFive support Zope 2.9/3.2. During the development of CMF, parts of CMFonFive has been sneakily added to CMF, adding significantly to the versioning spaghetti of Zope 2, Zope 3, Five and CMF. The only thing CMFonFive 1.3 (to be released soon) does is the fiveactions tool, which bridges Zope 3s menuItems to CMFs actions. The rest was moved into CMF with CMF 1.5.2. I would like to suggest that CMF 1.6 only supports Zope 2.9 (or only 2.8), and include CMFonFive in it, since figuring out what version to use now is already quite complicated. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Re: [z3-five] Re: CMFonFive and CMF 1.6
On 1/4/06, Rob Miller <[EMAIL PROTECTED]> wrote: > urgh. this isn't ideal for Plone. i'm assuming you've hit some > specific problems w/ getting the current CMFonFive code to support both > 2.8 and 2.9? can you provide a little more detail re: the compatibility > issues? in the meantime, i'll bring this up on plone-devel. The menu implementation in Zope 3.0 and 3.2 are very different. I wouldn't describe this as a problem, it's just not compatible. :-) Zope 2 and Zope 3 now has versions synchronized. I'd like CMF to synchronize the versions as well, as the compatibility matrices grows exponentially. In theory CMFonFive would be able to support Zope 2.7 to 2.9, and CMF 1.4 to 1.6, but supporting any combination of this would require at least four different versions of CMFonFive. It's just a matter of how much work should be put into it. I personally will only make the versions CPS needs in the future, it would be very good if those version where the same as what Plone could use. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: [z3-five] Re: CMFonFive and CMF 1.6
> this makes sense. i'm -1 on the final CMFonFive piece landing in CMF > 1.6 itself, though. the original scope for CMF 1.6 was "CMF 1.5 + > GenericSetup", i don't see a compelling reason to complicate things by > expanding that scope. if CMFonFive stays separate, then you can code it > to support only Zope 2.9 without having to impose this same restriction > on the CMF core. Well, it doesn't make sense, because it continues a complex versioning dance, and leaves many combinations unsupported, but if nobody else wants that fixed, then I won't fix it. :-) And it doesn't really complicate things by expanding any scope, it just moves a bit of code from on product to another. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: [z3-five] Re: CMFonFive and CMF 1.6
On 1/5/06, Jens Vagelpohl <[EMAIL PROTECTED]> wrote: > Sorry I didn't follow this discussion closely, so you want to merge > the last remnants of CMFonFive into CMF 1.6 and 2.0, is that the > suggestion? It's already merged into CMF 2.0 (although it's not actuall *working* yet. ;) ) So it's only 1.6 that is the question yet. The result would be that CMF 1.6 would only support one major version of Zope, which I guess would be 2.9, which doesn't seem to sit well with the Plone community. Anyway, I'll release a CMFonFive 1.3 today, which will work with Zope 2.9, and CMF 1.5.5, and should work with CMF 1.6 (although I haven't tried it yet). -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: [z3-five] Re: CMFonFive and CMF 1.6
On 1/5/06, Rob Miller <[EMAIL PROTECTED]> wrote: > maybe i'm being dense, but i don't see how merging the code into the CMF > core improves this. if i'm understanding this correctly, you wouldn't > be increasing the number of supported combinations at all; No, I'd just get rid of a whole lot of potential version combinations, thereby lessening the support headache that this already is. Although I admittedly can handle that problem by completely ignoring it, which seems to be the preferred option here. And I just realized that Five 1.3 and Five in 1.2 differs much more than I thought too. Glaaah. :-P And CMF 1.6 already has more changes that just GenericSetup, some of which are already causing me other headaches. I guess my main problem is that everything else is currently changing so fast that I don't have time to keep up with the changes, and the more stuff I fix, the more stuff seems to remain to be fixed. CalZope 2.0 (which is needed for the CalPlone implementation) just looks further and further away. :-/ > anyway, it's moot, since you've agreed to keep it a separate product for > now. thank you. Yeah, but that doesn't mean I like it. :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: [z3-five] Re: CMFonFive and CMF 1.6
On 1/5/06, Rob Miller <[EMAIL PROTECTED]> wrote: > Lennart Regebro wrote: > > And CMF 1.6 already has more changes that just GenericSetup, some of > > which are already causing me other headaches. > > which are these? the most significant changes are in the TypesTool, and > this was done in order to achieve more parity btn the 1.6 and 2.0 site > creation code... there's nothing that i know of that's not directly > related to the GenericSetup stuff. Yeah, well that's it. And here I am trying to achieve more parity between 1.6 and 2.0. [ Well, now I'm only teasing you on accord of the wobbly argumentation. ;-) ] -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [z3-five] Re: [Zope-CMF] Re: Re: CMFonFive and CMF 1.6
On 1/5/06, Rob Miller <[EMAIL PROTECTED]> wrote: > i've managed to get Plone working with this rather well, but if you're > having major headaches we could consider changing this. Nah, I solved them now. But it involves having the tests load_site() three times. :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Head-slot in five_template
CMF 1.5 and 1.6 five_template (the one that provides a bridge between zope3 and CMF templates) doesn't have a head-slot. I'm just wondering if that slot is somewhat standard in Zope3 and CMF and not only CPS, becuse it it is I'll add it. So? Is it? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] CMF 2.0 Release Status
Right, the five_actions tool is still completely borked. CMFonFive 1.3 has the correct one, and today I checked in a fix there, so I think it's stabilizing now. I'll copy the CMFonFive 1.3 stuff into CMF 2.0. ___ 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
Re: [Zope-CMF] CMF 2.0 Release Status
On 1/11/06, Lennart Regebro <[EMAIL PROTECTED]> wrote: > Right, the five_actions tool is still completely borked. CMFonFive 1.3 > has the correct one, and today I checked in a fix there, so I think > it's stabilizing now. I'll copy the CMFonFive 1.3 stuff into CMF 2.0. ...this week, I meant to say. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: CMF 2.0 Release Status
On 1/12/06, yuppie <[EMAIL PROTECTED]> wrote: > +1 for dropping Zope 2.8 support On that, it can be mentioned that for the fiveactions tool, having both 2.8 and 2.9 support requires quite some work and code duplication, so I'm +N on dropping 2.8, where N is an arbitrarily large positive number. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: CMF 2.0 Release Status
On 1/12/06, Martin Aspeli <[EMAIL PROTECTED]> wrote: > Do I have to make a package, with new content > type and a pile of ZCML just because I want my Description to be at the > bottom rather than the top of my Document view? One zcml statement is not exactly "a pile". :) > That's a fairly drastic > reduction in functionality and friendliness for the average Joe, don't you > think? No, I don't really. Sure, the current way of "press customize and change" is very easy, *if* you understand HTML, and TAL and CMF. But understanding HTML, TAL and CMF is not what I would call being friendly to the average joe. ;) For the type of functionality you are discussing, I think there are two paths you can take that are truly user friendly. One is CPSSkins, where you in practice has a dedicated WYSIWYG editor for changing the layouts and CSS of a site. It can be argued that CPSSkins is too complex as it is now, and not very user friendly, but it requires zero knowledge of either HTML or TAL. The other way is the expert way, where you use HTML editors, or even just text editors to directly edit the template code. If you are capable of doing that, then surely you are capable of typing in overrides.zcml? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Re: [z3-five] Re: RFC: products-less python packages as zope2 products
On 1/13/06, yuppie <[EMAIL PROTECTED]> wrote: > - CMF 1.6 is not yet released so it might be possible to change it directly. I think we should, but this met some resistance. I want to get rid of CMFonFive completely. Since CMF with version 1.5.2 became Five-aware, CMFonFive has lost it's raison d'etre, and I want to get everything into CMF. > - CMFonFive might be a good place for the patch. The same patch should > work for CMF 1.5 and 1.6. If not, we would end up with four different version of CMFonFive for different combinations of Five, Zope and CMF, and I think three is too many already. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: CMF 2.0 Release Status
On 1/13/06, David Pratt <[EMAIL PROTECTED]> wrote: > Hi Lennart. Isn't CPSSkins GPL? Probably. > I would prefer a generic approach that > compatible with the ZPL. Why? > Would CPSSkins license be changed under this > scenario? I am sure there are others like me that do not develop under > GPL Yeah, I have heard weird rumours to that effect. ;) But you don't need to develop under GPL, CPSSkins is a finished product already, you can just install it. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
On 1/15/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > > 2) work on the latest version of CMFonFive supported on Zope 2.8 > > (CMFonFive 1.2 svn branch) and provide a monkey patch for CMF 1.5 there. > > Why do we need to support CMF 1.5? We probably don't, but: If we want to make the modification on CMFonFive, we either must support CMF 1.5, or make a fourth current CMFonFive version. CMFonFive 1.2.x is for CMF <= 1.5.1 and Five <= 1.2 (And therefore Zope 2.7 and 2.8) CMFonFive 1.3.x is for CMF >= 1.5.2 and Five <= 1.2 (And therefore Zope 2.7 and 2.8) CMFonFive 1.4.x is for CMF >= 1.5.2 and Five >= 1.3 (And therefore Zope 2.9) Now, to support Zope 2.8 and Zope 2.9 with these changes, we need to put it both in 1.3 and 1.4, and we must then support both CMF 1.5 and 1.6. If we only want to support CMF 1.6, we need a CMFonFive 1.5.x that is for CMF >= 1.6.0. > CMFonFive version dance confuses the heck out of me, we should try to > keep things simple. Yes, I agree. So I think all of CMFonFive, including these changes, should be in CMF 1.6. That ends the dance. It was a mistake to move half of CMFonFive into CMF. We should have moved all of it in, and called that 1.6 instead of 1.5.2 (but that's too late now). Doing this however, means that CMF 1.6 will NOT support Zope 2.8. I don't find that to be a problem, the "everything works with everything" seems to be too much work. But others might not agree. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] CMF 2.0 Release Status
On 1/11/06, Lennart Regebro <[EMAIL PROTECTED]> wrote: > On 1/11/06, Lennart Regebro <[EMAIL PROTECTED]> wrote: > > Right, the five_actions tool is still completely borked. CMFonFive 1.3 > > has the correct one, and today I checked in a fix there, so I think > > it's stabilizing now. I'll copy the CMFonFive 1.3 stuff into CMF 2.0. > > ...this week, I meant to say. And because of a nasty cold this weekend, that didn't happen. So, next week it is. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
On 1/16/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: > It's a fundamentally different way of developing and installing > products. Therefore it's good to ask why we would want to expose such a > fundamentally new feature for Zope 2.8. Do we really want to start > explaining to people that "My product is special, you need to install it > like this, unlike what you're used to" when what we're dealing with is > not even the most recent stable release of Zope? You have a good point there. I think we can happily require Zope 2.9 for this functionality. If you are bleeding edge, you can be required to be so on all fronts. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Re: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
I agree that Five development should happen in Five 1.4. This version would then be the basis for Five in Zope 2.10. Increasing Zope 3 compatibility there is good and high priority. Doing so in Five 1.2 is quite low priroty, since that runs on an old version of Zope 3, on which new development seems...not a very high priority. ___ 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
Re: [Zope-CMF] Re: future of getToolByName
On 1/17/06, Raphael Ritz <[EMAIL PROTECTED]> wrote: > It was the promise that 'getToolByName' would always just do > the right thing (TM) so that add-on developers would not have > to worry. So why deprecating that now? Because that promise has been completely revoked, since add-ons developed for old versions of CMF will not work on Zope 3 anyway. ;-) On 1/17/06, Rocky Burt <[EMAIL PROTECTED]> wrote: > Hmm... I'm not sure this is useful unless we map standard utilities to > the equivalently functioning tool (which I don't think is a good idea). Right, any tool that now exists must directly map unto a local utility, and that local utility must also have the same API. If we in CMF 2.0 feel that most tools should be made into utilities, we could register the utilities with a name, and use the old tool name. getToolByName could then both try local acquicistion, and do a query for a generic interface (ICMFTool?) with the name. The other option is to keep the tools, but also register them as utilities. That would probably need some changes in the utility registration, though, from the primitive implementation that is in 1.3. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: Re: RFC: backporting including python-package-product support to support Zope 2.8
On 1/19/06, Martin Aspeli <[EMAIL PROTECTED]> wrote: > On Thu, 19 Jan 2006 00:22:02 -, Philipp von Weitershausen > <[EMAIL PROTECTED]> wrote: > > > I think one year is a pretty big span. Today, for example, you would not > > start a project on Zope 2.8. You would do it with Zope 2.9 which is > > going to get bugfixes until the end of 2006. > > Not if you spend 18 months developing your application :-/ Well, in that case you should be able to at some time during that process, switch to a new Zope version... I do understand that Zope 2.9.0 may not be something you want to depend on, but most likely there will be a 2.9.1 out by May, so maybe you can consider switching then? > I do understand that it's hard to maintain three Zope 2 releases at the > same time (jebus). I'm just worried that this policy, especially if > explicit, would make Zope FUD a bit easier. Zope is in a period of rapid change now, and that is indeed scary. ;) It's hard to avoid that, I think, without putting a huge break on the changing. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Re: [z3-five] [Part 2] RFC: backporting including python-package-product support to support Zope 2.8
On 1/19/06, Rocky Burt <[EMAIL PROTECTED]> wrote: > I would like to include the necessary CMF monkey patches on CMFonFive > trunk (which will either be CMFonFive 1.3.1 or CMFonFive 1.4.0 -- could > someone clarify the state of the trunk for me?) The state of the trunk is 1.3.x. Which version number we use depends entirely on if this works on CMF 1.5 as well as 1.6. We should also move the patch into CMF trunk (which will be 2.0 soon). 1.3.x is for Zope 2.9 and CMF 1.5.2+ support. 1.2.x is for Zope 2.8 and CMF 1.5.2+ support. If 1.5.2+ is not supported, we would need a 1.4 release, which would be for Zope 2.9 and CMF 1.6. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Re: [z3-five] [Part 2] RFC: backporting including python-package-product support to support Zope 2.8
On 1/19/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: > Lennart Regebro wrote: > > On 1/19/06, Rocky Burt <[EMAIL PROTECTED]> wrote: > > > >>I would like to include the necessary CMF monkey patches on CMFonFive > >>trunk (which will either be CMFonFive 1.3.1 or CMFonFive 1.4.0 -- could > >>someone clarify the state of the trunk for me?) > > > > > > The state of the trunk is 1.3.x. > > Hm, I'm confused. Yes. We are talking about CMFonFive, not Five. ;) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] bug on CMFonFive trunk
On 1/23/06, Rocky Burt <[EMAIL PROTECTED]> wrote: > So I'm guessing this problem has to do with the new checking? I doubt it, unless you somehow suceed in having menuItems that have None as title. In any case, it works fine for me. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: bug on CMFonFive trunk
On 1/23/06, Pawel Lewicki <[EMAIL PROTECTED]> wrote: > I reported the same problem on #z3-base on Friday. That checkin makes > action/name unicode string and ZPT has a problem with rendering. No, it makes it a string, to avoid those problems. However, if it is a Message or MessageId object, it will not be a string, but it will continue to be a Message object, so it can be translated. It may be default translation returns an unicode string, which would cause problems (although pobably not the one reported by Rocky). Providing translation for this should work. It does for me, anyway. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] PHPGateway
On 1/25/06, sharif islam <[EMAIL PROTECTED]> wrote: > I can serve php pages using PHPParser fine. However, when I try to use > PHPGateway I get the following error: > "PHPGateway cannot open the destination file. PHPGateway" > PHPGateway: /phptest > File: /www/phptest/manage_interfaces/manage_editProperties > Destination file does not exist." > > My Docroot is /www/phptest which contains several php file. > > I would appreciate some help. Thanks. Well, Zope-cmf is a mailing lst for the use and development of CMF, not PHPGateway. You'll probably get more answers on the zope@zope.org list, or by mailing the product developer directly. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] What's the story for using Z3 content types as first-class citizens in CMF?
On 2/10/06, Martin Aspeli <[EMAIL PROTECTED]> wrote: > Just trying to get an overview - are there any plans or code (CMF 2?) to > make it possible to use Z3 content types as first-class citizens in CMF? Well, depends on what you mean with "Z3 content types" and "First class citizen". :-) > That is, make them available in add menus, make actions/tabs appear on > them, let them use method aliases, make them catalog aware and so on, > without necessarily inheriting from PortalContent. Well... that's a pretty tall order. Especially since the easist solution to all that is to write a wrapper-class that inherits from PortalContent, CMFCatalogWare et al. > Alec Mitchell's plone_schemas product lets you use such types in Plone, > though he derives from CMF's PortalContent (as I recall) and manually > constructs an FTI. I tried to make a ZCML statement that replaced the FTI, since much of the information already exist as other ZCML statements but failed. We need to change things in portal types for that to work I think. > I can see some great advantages to leveraging Z3's content type system, > not at least before they encourage easier re-use. That's not to say that > we can't start to write content types using CMF (or Archetypes as the case > may be in the Plone world) but presenting Z3 interfaces and offering > adapters and get many of the same benefits, but I'd really like to settle > on one content type system in the long run, and I think Z3 schemas are a > nice approach. Well these you can use, now. > Who has experience with this? What holes are there to be plugged before > this stops being a slightly awkward marriage between old and new code? Well, I think the FTI-thingy should be fixed first. It is possible to auto-generate classes out of base-classes with ZCML statements, the browser:page-statetemnt does this, but I honestly think it's to magical and of no particular use. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] What's the story for using Z3 content types as first-class citizens in CMF?
On 2/11/06, Martin Aspeli <[EMAIL PROTECTED]> wrote: > I guess the path I'd see would be to make all the code (yeah, tall indeed) > that uses the methods from these classes work in terms of Z3 interfaces. Oh, that is gonna break a LOT of products I imagine... So I'm not sure it's sucha great idea... > That way, we could write adapters however general or specific that work on > either all/most Z3 content (i.e. objects that provide a Z3 interface with > a schema and thus could have auto-generated add and edit forms etc.) or > that are specific to whatever content type is in question. Sure, but the problem is that every product that uses one of these methods will have to be changed... > > I tried to make a ZCML statement that replaced the FTI, since much of > > the information already exist as other ZCML statements but failed. We > > need to change things in portal types for that to work I think. > > I can see how there may be problems. I think ZCML-extensions that work off > the Z3 directive but extends with whatever CMF may need would be > a nicer way than the in-ZODB portal_types ... Yup. > *Except* there ought to be some way of override that kind of configuration > TTW. It is very important for site admins to be able to e.g. change the > display name of a type or change actions. Ey, you want the cake *and* eat it too. That's pretty difficult. ;-) There are override.zcmls available, and much of what is in there makes little sense to change anyway. The things that should be often changed should probably end up in some sort of GenericSetup profile. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: What's the story for using Z3 content types as first-class citizens in CMF?
On 2/13/06, Tres Seaver <[EMAIL PROTECTED]> wrote: > We might add a new TypeInformation derivative, which knows about the > addable Z3 content. My tests last year indicated that this was not enough, if I remember correctly. The FTI stuff might need a bit if refactoing as well, although I don't remember the details. I should write things like that up.... :-/ -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] [dev] Portal status messages and i18n: a proposal
On 2/23/06, yuppie <[EMAIL PROTECTED]> wrote: > Currently the portal status message is always translated in the i18n > domain of main_template if sent through a redirect. This makes it > impossible to use different domains (and mappings or defaults). > > Add-on products might want to use their own i18n domain. CMFCalendar > demonstrates that use case. "Event changed." is currently not translated > because of that issue. Afaik, using MessageIds solves this. If it doens't, that's a bug. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: [dev] Portal status messages and i18n: a proposal
On 2/23/06, Hanno Schlichting <[EMAIL PROTECTED]> wrote: > Message(ID)s indeed solve this but are complex unicode objects, that are > quite hard to map to a query string safe (per standard pure ascii but > utf-8 might work in recent browser versions) representation. Ah, OK, now I get you. I got really confused by your earlier answer. Right, when you redirect, you need to get the message in there. I would probably just translate it before the redirect, but that does require some extra coding for every case. Automatic solutions would probably be a good idea. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] How to customize forms and pages in the CMF for a CMS
On 2/28/06, Bradly Bernier <[EMAIL PROTECTED]> wrote: > I have been searching the site as well as reading the "Zope Book" and > experimenting with zope and the cmf. What I am trying to do is make some > very simple, easily customizable sites for my client base. So I want the cms > that I create to add new dynamic pages that are interlinked in the site. > These pages will show some basic info and 8-10 pictures. I also want to > implement a easy to use browser base WYSIWYG editor. These things have already been developed, and you can find them as parts of CMSs as CPS and Plone. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: How to customize forms and pages in the CMF for a CMS
On 3/1/06, Bradly Bernier <[EMAIL PROTECTED]> wrote: > Yah Plone seemed to be just as difficult as the CMF when I looked at it. > Plone has way to many options that it scares me which I know would never > work for my very computer illiterate clients. It's easier to disable the things you don't want, than buikd the things you want from scratch. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Classes whose instances appear in ZODB
On 3/8/06, George Lee <[EMAIL PROTECTED]> wrote: > If I want a class to appear in the ZODB, is that just a matter of > subclassing SimpleItem? Define "Appear"? :-) Do you mean that you want it to pop up in the Add menu of the ZMI? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Classes whose instances appear in ZODB
On 3/8/06, George Lee <[EMAIL PROTECTED]> wrote: > Instances show up in the list of objects in a container (which may be > equivalent to the class showing up in the Add menu?) Nope, that's not equivalent. I'm not exactly sure what the requirements are. A getId method, a title attribute and a meta_type probably. Subclassing from SimpleItem is definitely a good idea. Oh, and you need to add the object to the container, of course. ;) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Question About Acquisition.Implicit
On 3/8/06, George Lee <[EMAIL PROTECTED]> wrote: > >From what I can tell from the epydoc documentation of many Zope > classes (e.g. PortalFolder), they do not subclass either Implicit or > Explicit. How is it then that they acquire attributes from their > containers and contexts? They subclass Implicit, via SimpleItem. I have no idea why the epydoc documentation would not show that. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] [dev] five_template slots
On 3/23/06, yuppie <[EMAIL PROTECTED]> wrote: > - mapping 'style_slot' to 'css_slot' is an obvious bug, that change > should be reverted Why is it a bug? That's not obvious to me at all. Both slots are for putting style sheets in... > - the 'header' slot behaves different than in main_template: > main_template provides default content for 'header', the five_template > 'header' is empty by default. OK, syncing that someway seems reasonable. > 1.) Add a new 'body' slot in main_template that wraps around the > 'header' and the 'main' slot. You can either use 'body' *or* 'header' > and 'main'. For 2.0 I'm ok with this, but note that this will mean that everybody must add this slot to their templates when they upgrade to 2.0, or all Five products will break. > 4.) Change the browser view templates to use 'main' instead of 'body' > (that no longer maps to 'main'). Well, they *do* use body so we can't change that. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Re: [dev] five_template slots
On 3/25/06, yuppie <[EMAIL PROTECTED]> wrote: > Because 'css_slot' never existed in CMF, it's even gone in CPS. OK, then it's bug. > Using > nonexistent slots doesn't raise errors so it might not be that obvious, > but the content of 'style_slot' gets lost if it is mapped to 'css_slot'. Strange, works for me here and now. I use style_slot in my templates for CalZope, and they work fine in CPS 3.4. > > Well, they *do* use body so we can't change that. > > I meant the browser view templates in CMFDefault. Oh, I don't know anything about them. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Re: [dev] five_template slots
On 3/26/06, yuppie <[EMAIL PROTECTED]> wrote: > > Strange, works for me here and now. I use style_slot in my templates > > for CalZope, and they work fine in CPS 3.4. > > Yes. That is strange. You were lobbying for replacing the old CMF > five_template by the CMFonFive five_template and after it was added to > CMF 2.0 you removed it from CMFonFive 1.3. Right, because the one that was in CMF had bugs and to few slots. > Now you wonder why CalZope works with CPS 3.4. It's because CPS 3.4 uses > the old CMF five_template from CMF 1.6, not the broken CMFonFive > template that was added to CMF 2.0. The replacement I did was done not only in 20 but also the current branch of CMF which probably was 1.5, then. Otherwise I would not have been able to remove it from CMFonFive, as I use CMFonFive with 1.5 and 1.6, not with 2.0. In fact, I think the idea was to not have any CMFonFive with 2.0 at all. > My question is now: Do we really need the CMF-specific slots in the > five_template? There is no CMF specific slots in five_template, or at least, there were none until yesterday. > Or can we switch back to the old CMF five_template that > seems to work fine for CalZope and CPS 3.4? No, because it didn't work, which is why I replaced it. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Re: [dev] five_template slots
On 3/26/06, yuppie <[EMAIL PROTECTED]> wrote: > This is the latest revision from the CMF 1.6 branch: > http://svn.zope.org/CMF/branches/1.6/CMFDefault/browser/five_template.pt?rev=40122 > > It is shipped with CPS 3.4 and was never changed since the initial > checkin. None of your changes are used in CPS 3.4. Then I do not know what "my changes" are. > > No, because it didn't work, which is why I replaced it. > > Wrong. > > You are using the old CMF five_template in CPS 3.4. I'm getting extremely annoyed by your attitude here, when you are not prepared to explain what the problems are, what changes was made and when, but evidently want to blame them on me, but aren't listening to what I'm saying. I suggest you clearly describe exactly what you think is the problem, and make a suggestion to fix that, without any claims that anything has been broken by anyone, unless you can point out the exact checkin that the breakage happened and explain exactly why it is broken. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Re: [dev] five_template slots
On 3/26/06, yuppie <[EMAIL PROTECTED]> wrote: > I'm listening, but not everything you say makes sense to me. And I don't > want to blame anybody for that change. I just want to understand why the > new five_template is better than the old one. And if it is not better, > revert the change before the final release. I'm not sure what "new" means any more. As I remember, I fixed some problems with it becuase I had fixed them in CMFonFive, and the copy that was in CMF was old. One was that the CMF template inserted an empty line first in the page. Thats one problem I remember clearly. > 1.) Mapping 'style_slot' to 'css_slot' instead of 'style_slot'. You > agreed in http://mail.zope.org/pipermail/zope-cmf/2006-March/024221.html > that this was a bug and I fixed it yesterday. Yup. No breakage going on, it's simply that the CPS "css_slot" (which I wrongly assumed was a CMF slot) has been replaced by the new standard style_slot, and C;FonFive was not updated on this when CPS was updated on it. > 2.) Adding two slots 'base' and 'header'. AFAICS these are CMF specific > slots. If I did get you right you agree that providing CMF specific > slots is not a good idea and CPS 3.4 / CalZope don't use these slots. Right, so we can remove them. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: GenericSetup: purging steps on new base profile
On 3/28/06, Rob Miller <[EMAIL PROTECTED]> wrote: > i, on the other hand, am very interested in being able to see which > profiles have been applied. i don't think it's unreasonable to record > and expose this. of course this can't be treated as the final word on > the current site configuration, but just because someone may have done > further manual configuration doesn't seem to me a good reason to make it > harder to figure out which profiles have been applied in the first place. > > i'm going to cut a branch to experiment a bit w/ implementing this. in > the meantime, this conversation can continue. if the consensus ends up > being against these features, i can put any code from the branch in at > the Plone level. I completely agree that there should be a list of which profiles that have been applied. It's a basic usability and support feature. People say "Eh, we get an error", and we ask them "did you apply this profile" and they go "I don't know". We want them to know. :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: GenericSetup: purging steps on new base profile
On 3/29/06, yuppie <[EMAIL PROTECTED]> wrote: > I have to refine this statement: *For now* I don't want to go down that > road. In the long run I think we have to keep track of applied profiles. > That would help to make the setup tool more powerful and to implement > features like reloading or uninstalling. But AFAICS doing this right > requires a major refactoring and would come to late for CMF 1.6 or 2.0. Those features would require a mjor refactoring yes. But just keeping track in which profiles are installed does not. We only need to keep a list if it, and display it somewhere. > I can see that this information might be useful, but it doesn't > represent a state of the tool or the site. It has more the character of > (sometimes incomplete) history information and I'd prefer to use the > logging machinery for that. Well, whatever, as long as there somewhere is a simple list of which profiles that has been installed displayed. > What about adding that information to the import logs and creating an > import log for the initial site creation as well? It sounds like the information would be hard to extract... -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: trouble applying extension profiles
On 3/31/06, Rob Miller <[EMAIL PROTECTED]> wrote: > i've committed this on the 1.6 branch. this is a pretty significant > change in behaviour. before, a reimport would delete EVERYTHING that > was not explicitly protected by the ".preserve" file of the currently > active profile. now, content will _only_ be deleted if it is in the > "structure" hierarchy so that it will be recreated. this means that > removing something from the structure folder and rerunning the import > step will NOT remove content, you'll have to do so by hand. How about some sort of ".delete" file for that? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: trouble applying extension profiles
On 4/2/06, Jens Vagelpohl <[EMAIL PROTECTED]> wrote: > Thanks Rob! I hope Lennart and Yvo will take a look this weekend or > Monday. I checked out the current 1.6 and ran some of our tests with it and has used it today, and it seems to work fine. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] I gotta ask before I change this, I think.
Would anybody be terribly upset if I changes these snippets of code in GenericSetup: CONVERTER, DEFAULT, KEY = range(3) BASE, EXTENSION = range(1, 3) To CONVERTER, DEFAULT, KEY = 0, 1, 2 BASE, EXTENSION = 1, 2 Which are not only a third as slow (yes, I tested, ;) ) but also a lot less confusing? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Re: I gotta ask before I change this, I think.
On 4/6/06, yuppie <[EMAIL PROTECTED]> wrote: > The whole point was to encourage people to import the names instead of > relying on the values. OK, that is a point. But... > But if you add a warning that the values might > change without further notice I'm fine with the proposed change. I think I like the warning better. > Or do you have a need to use the values? In that case meaningful values > would be better. No, I just stared at the range(1,3) for 30 seconds before I understood it. :) It is possible to obfuscate Python, but you have to work pretty hard. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: SVN: CMF/trunk/CMF - fixed the i18n domain
On 6/2/06, Florent Guillaume <[EMAIL PROTECTED]> wrote: > But -1 for merging 'cmf_default' and 'cmf_calendar'. Why? Because you lose the example of changing the domain? Isn't that what docs are for? Well, CMFCalendar is quite separate from the rest of the CMF in many ways, and if we merge the domains we'll need to merge the po files, and while that makes sense for CMFCore and CMFDefault, which really can't be very separated at all, it doens't make any sense for CMFCalendar. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Re: [dev] RFC: rethinking GenericSetup extension profiles
I don't exactly understand what makes a "customization snapshot" different from an "extension profile", except that you note what profile it is diffed from. Other than that, I think this proposal sounds good. ___ 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] Re: [dev] RFC: rethinking GenericSetup extension profiles
On 7/26/06, yuppie <[EMAIL PROTECTED]> wrote: Even this small difference doesn't exist. The profile it is diffed from is just a normal dependency. OK. I'm trying to come up with errors in this plan, but I fail. The closest i come is that you will need to have different extension profiles for different base profiles, that is one for plain CMF, one for CPS and one for Plone. But the chance that you would actually be able to use the same extension profile for these three systems is so remote anyway, that I can't even claim that to be an actual problem. :) So, I'm +1 on this. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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
Re: [Zope-CMF] Internationlisation question
On 12/4/06, Charlie Clark <[EMAIL PROTECTED]> wrote:
Hi,
I'd to use stftime("%d %B %Y") on my website in different locales
(de_DE and en_GB) on different parts of the website which is not
localised but has some content in German and some different content
in English. Somehow I haven't quite grokked Andy McKay's explanation
of i18n as the following code throws an error
With i18n:name I get an error that i18n:name needs to be within a
translation unit and without it I get a cannot iterate over a non-
sequence.
So, what I am getting wrong?
This part makes no sense to me:
i18n:"data python: DateTime()"
Maybe you meant tal:define="data python: DateTime()" ?
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.nuxeo.org/
___
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
Re: [Zope-CMF] Re: Tools as local utilities
On 2/6/07, Charlie Clark <[EMAIL PROTECTED]> wrote: Am 06.02.2007 um 22:14 schrieb Rocky: > Ultimately the closer we get to structuring our code deployment like > regular python code the easier it will be to take advantage of things > like distutils, eggs, the cheeseshop, etc. I look forward to doing: > easy_install ZopeCMF I hate eggs and easy_install and for me they are not part of "regular python code" but reminiscent of script kiddy magic dust which I *really* don't want in my apps. I know what's driving it and I know it's unfortunately almost unavoidable but I don't have to like it. I've never had a problem with using Products especially since the introduction of "local" Products with Zope 2.7. Except of course that the Products directory contain serious magic, while eggs are part of regular python. ;-) easy_install or not, I wouldn't mind seeing Products giving away to lib/python/Products, but I'm not sure how that would work, considering the magick that surrounds the support for having multiple Products-directories. -- Lennart Regebro: Python, Zope, CPS, Plone consulting. +33 661 58 14 64 ___ 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
Re: [Zope-CMF] Re: Tools as local utilities
On 2/7/07, Charlie Clark <[EMAIL PROTECTED]> wrote: Am 07.02.2007 um 00:36 schrieb Martin Aspeli: > Why? Is it the ability to specify sensible version restrictions? > Have multiple versions of the same package as different > dependencies for different dependents? Automatic downloading of > dependencies where possible/desired? Standardised package metadata? > Standardised location to find and search for add-on libraries? You mean the existing approach didn't support this? Yup, we sure mean that. Ever heard of sys.path? Yeah, which is what eggs use an manage for you. This is guff. Why should Zope add-ons *necessarily* be available as third-party libraries? They shouldn't. The point is that we want third-party libraries to be available as Zope add-ons in much the same way as Zope Products are. But if this is required it's no big deal to put the Zope specific stuff in a Products folder and the library in ../lib/python. Sure, but one of the things, the easy of use you talk about, is that if everything is products you can make an svn-bundle, and just check it out into the products directory. You can't do that if you need it to be in several places. I currently solve this with my own libraries by making Zope products for the libraries as well, that put the libraries into sys.path if they don't already exist there. But that's only possible with libraries that I have control over. Bildout, ploneout and workingenv are there to try to solve these problems. If you don't like *them* I fully understand. They annoy me since they install like, every again, which takes time, and their complicated, and developer packages that ue them often require me to create a new Zope-instance even if I don't want to. But eggs? Eggs are great. Instead of separately downloading, compiling and installing five packages, all you do is "easy_install blah" and it does it for you. I really don't see how anybody can gripe about that. And if you don't want to use it, then don't. Then download, compile and install each paclage separately of you have to. Nobody is FORCING you to use eggs. -- Lennart Regebro: Python, Zope, CPS, Plone consulting. +33 661 58 14 64 ___ 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
Re: [Zope-CMF] Re: state of GenericSetup trunk and branches
On 6/22/07, Rob Miller <[EMAIL PROTECTED]> wrote: > Well. I'd prefer to have *one* obvious and explicit solution. The > failover adds extra code that needs to be maintained and makes it less > obvious where the version number comes from. i agree. i was thinking since my last reply that, since the code is already in there, we could support a special value in the metadata.xml file that explicitly tells GS to use the product version for the profile version, rather than having that be the default behaviour. I think that the profile version number typically should *not* be the same as the version number. Quite often you make a release without changing anything in the profile, and profiles may be just configuration and then not have anything to do with any product version. So I'd prefer if profile versions just aren't product versions at all. But it's not a strong opinion. > If it is pure registration information, why don't we extend the ZCML > directive? But AFAICS data like the version number belongs to the > profile itself and it might be useful to add timestamp based version > numbers to exported profiles. Sounds reasonable to me. All in all, btw, these new feature to GenericSetup look bitchin', and will make truly awseome! :-) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ 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
Re: [Zope-CMF] Re: GenericSetup: How to use upgradeStep?
On 9/25/07, Maurits van Rees <[EMAIL PROTECTED]> wrote: > When you want to remove an index or column you can do that by editing > the profile and adding remove="True" to that index or column. So this > upgrade can be represented as a profile edit. But applying the > profile will empty the remaining indexes that are mentioned in that > profile. So ideally I would want to apply the profile only once when > installing and rely on upgrade steps to handle any further changes > without applying that complete profile again. > > It seems the new upgrade steps do not really solve this particular use > case then. (It can sure be handy for other things, no doubt about > that.) But I had hopes to use them to work around this issue with > catalog.xml. Apparently a workaround is no substitute for really > solving the problem. ;-) > > Is anyone going to the sprints after the Plone conference who wants to > take a shot at this with me? Preferably someone with commit rights. :-) Well, I made a monkey-patch that I haven't merged yet that only did that if the index definition had actually changed, and that was quite trivial. I would appreciate more people looking at this, since this was so easy I get suspiscious. :-) So at the Plone conf seems a good time. > > performing a full upgrade, then, would require reapplying the profile > > configuration and running the upgrade steps. reasonably the quickinstaller > > (or even the GS interface) could do this all as one step. > > Right. Or a warning could be displayed: "This profile has upgrade > steps available; do you want to run them?" CPS listed all upgradeSteps whose version numbers where higher then the numbers of the last upgrades, and had a button to run them. You could also select which to run, and list old steps, and (re-)run them. Since this is a merge of the CPS functionality (and thanks for that Rob, I never understood why Nuxeo branched GenericSetup instead of improving the original one, maybe there was a good reason) I hope there may be something similar here? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ 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
Re: [Zope-CMF] Move CMF collector to Launchpad (redux)
On 10/25/07, Jens Vagelpohl <[EMAIL PROTECTED]> wrote: > Can we have a show of hands, so to speak? +1 Keeping this collector after moving the others succesfully is just weird. :) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ 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
Re: [Zope-CMF] CMF Installation
On Nov 15, 2007 7:26 PM, Xavier Balling <[EMAIL PROTECTED]> wrote: > Next I unzipped the CMF-2.1.0.zip to the C:\Zope\Instance\2.10.5\Products > directory. I completly restarted my machine You only need to restart Zope. > opened Zope, looked in the > Products folder and I do not recognize any CMF objects, nor in the Add menu > are there any CMF objects. What should be here? Yeah, there should be CMF stuff there. > How do I go about troubleshooting this problem and getting CMF installed > properly? First start Zope in debug mode. That way it will complain if it fails to load a product. Secondly, you probably want to look at Plone instead. CMF is a framework for writing content management systems. Plone is a system using CMF. But where CMF is just a framework needs development before it gets useful, Plone is useful out of the box. http://www.plone.org/ -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ 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
Re: [Zope-CMF] CMF Installation
On Nov 15, 2007 8:26 PM, Charlie Clark <[EMAIL PROTECTED]> wrote: > You don't need to do much with it to use it as a CMS Well. I don't agree with that statement. :) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ 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
Re: [Zope-CMF] portal_fiveactions
On Sun, Oct 5, 2008 at 11:32, Hanno Schlichting <[EMAIL PROTECTED]> wrote: > I thought the actions it emits trough the action providers API are > old-style ones and it doesn't register itself in portal_actions as an > action provider... No, you have to do that if you want to use ut. > But no matter what the code does, nobody is using it. I think it's an > artifact from the early "Zope 3 everywhere"-days. Yeah, the idea was to show Zope3 actions in CMF menus. Nobody seems to want that anymore. :) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF add views and
On Tue, Dec 9, 2008 at 14:31, Martin Aspeli wrote: > I'd wager this is a lot closer to what people would expect: > > for="Products.CMFCore.interfaces.IFolderish" > fti="..interfaces.IDexterityFTI" > class=".add.DefaultAddView" > permission="cmf.AddPortalContent" > /> Yes, although I'd probably call it addform. There is a browser:addform in Zope3, right? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
