[Zope-CMF] Re: trouble applying extension profiles
Hi Rob! Rob Miller wrote: maybe i'm missing something fundamental, but i'm having trouble figuring out how i'm supposed to apply extension profiles to my site. the intended mechanism is clear enough; set the active configuration to be the desired profile and then execute runAllImportSteps on the setup tool. the apparent fuzziness of the boundary between the base profile and the extension profiles seem to be getting in my way, however. my base profile is a default Plone site, which does a bunch of configuration and adds a few pieces of content using the structure folder mechanism that is supported by CMFCore's StructureFolderWalkingAdapter. this works w/o problem. then i specify an extension profile to be the active configuration and again runAllImportSteps. the content is purged by default, which seems odd, and it is not recreated b/c the StructureFolderWalkingAdapter is now looking for a 'structure' folder in the extension profile, which is the wrong place. This is a known issue, as Jens already mentioned. i see three possible ways around this, which i'll list in order from my least to most preferred: - we could have extension profiles not purge any content by default. it seems strange that they do. perhaps this is supposed to be the case already, and either it's just not happening or there's something i've missed within my setup that is causing it to not be the case. That's the current policy. Setup handlers have to make sure they don't purge anything if no related setup files are in the current profile. - allow extension profiles to specify which of the base profile's import steps they depend on, so that only these can be run, instead of the current situation where, AFAICT, you have to either run them all or manually examine the profile and select the steps to run - draw a more clear distinction between the base profile and the extension profiles. instead of having the extension profiles piggy-backing on the base profile, extension profiles would explicitly define all of their own import steps, so that they can be applied cleanly on top of existing sites w/o becoming quite so muddled w/ the default configuration. this would also make it easier to implement an uninstall process that would remove the extension profile from the site. These solutions will create new problems regarding the procedure for exports and re-imports. Cheers, Yuppie ___ 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] 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 jens - CachingPolicyManager: Make Max-Age parameter dynamic, [Accepted] http://www.zope.org/Collectors/CMF/405 mhammond - Windows DevelopmentMode penalty in CMFCore.DirectoryView, [Accepted] http://www.zope.org/Collectors/CMF/366 Pending / Deferred Issues - 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, [Deferred] http://www.zope.org/Collectors/CMF/271 - 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 - workflow notify success should be after reindex, [Pending] http://www.zope.org/Collectors/CMF/389 - Content in Setup gets Cleared (Content Import Handler), [Pending] http://www.zope.org/Collectors/CMF/404 - workflow interface out of date on 1.5 branch, [Pending] http://www.zope.org/Collectors/CMF/407 - 'except ...: pass' in CMFCore/TypesTool.py:_queryFactoryMethod() nullifies VerboseSecurity, [Pending] http://www.zope.org/Collectors/CMF/410 Pending / Deferred Features - Favorite.py: queries and anchors in remote_url, [Pending] http://www.zope.org/Collectors/CMF/26 - DefaultDublinCore should have Creator property, [Pending] http://www.zope.org/Collectors/CMF/61 - 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 - 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 - CMFTopic Does Not Cache, [Deferred] 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, [Deferred] 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 - First Day of Week, [Pending] http://www.zope.org/Collectors/CMF/400 - CachingPolicyManager: Support OFS.Cache.CacheManager, [Pending] http://www.zope.org/Collectors/CMF/408 ___ 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: GenericSetup: purging steps on new base profile
Hi Rob! Rob Miller wrote: i'm picking up a thread from january that sort of petered out... yuppie wrote: Tres Seaver wrote: Florent Guillaume wrote: Because the current base profile id is not stored, there's no way to do detect the change to a different base profile. Should I store that property to allow for that use case? Yes. In fact, I would prefer to be able to introspect both current base profile and applied extension profiles from the tool. I don't want to go down that road. 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. The next step would be to keep track of the applied profiles a snapshot is based on. Things become more and more complicated and we still can't rely on that information: Sites created with older CMF versions don't have that information and manual customizations can make it quite useless. 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 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. What about adding that information to the import logs and creating an import log for the initial site creation as well? Cheers, Yuppie ___ 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: GenericSetup: purging steps on new base profile
Hi Florent! Florent Guillaume wrote: yuppie 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. Major refactoring? I don't think so, at least not for storing the basic information about which profiles are applied, which is a first step toward more powerful features. I guess we just have different expectations what applied profiles means. Of course we can maintain a list of profiles from which we imported all steps. But the fact a profile *was* once applied doesn't necessarily mean it *is* applied. We have no tools to keep track of partial imports and manual configuration changes. And we have no tools to inspect the current configuration and to compare it against a set of profiles. Restoring the configuration from a snapshot makes the list of applied profiles useless, the currently necessary manual uninstall process can't be recorded. 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. It's not state per se, but it's information about what the administrator did to the site. It has the character of history, yes, but needs to be introspected by the tool to provide further features. Just logging the info doesn't cut it. What about adding that information to the import logs and creating an import log for the initial site creation as well? Logs aren't useful to implement better features. Given the limitations of that information: Which features do you think this information should be used for? FWIW, while we're on the topic of GenericSetup, CPS now has a strong need for extension profile dependencies and ordering. Or choice between mandatory alternate extension profiles (like, choose which extension profile will provide the authentication aspects of the portal). At some point we'll have to spec out something and code it. I have some ideas regarding the future of extension profiles. I hope I'll soon find time to outline my thoughts. Cheers, Yuppie ___ 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: Views not found
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29 Mar 2006, at 17:09, yuppie wrote:
- - define my own cmfcalendar skin and layer. Declare it as a
combination of layers cmfcalendar, cmf and default.
- - stick my views directly into layer cmf and don't worry about
defining my own layeer or skin.
I think the second route is the Right Way to do it with Zope 3
style layers. I can't see a need to define an extra layer for
CMFCalendar.
Yes, sounds good to me.
ConfigurationError: ('Invalid value for', 'layer',
ImportError: Couldn't import cmf, No module named cmf)
I guess the problem is the order in which Five loads the
configure.zcml files. But I have no idea what's the recommended way
to make sure CMFDefault's configure.zcml is loaded first.
I'll dig a bit more.
jens
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFEKrnkRAx5nvEhZLIRAoiMAJ4kV4ZGOOw5kqiANtedZGN8mrZHPACcCo03
pIIeSrRLOhsVeO9uNjZXLRo=
=IuZb
-END PGP SIGNATURE-
___
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: trouble applying extension profiles
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29 Mar 2006, at 11:09, Rob Miller wrote: this changes some unit test results, and i need to write another test or two, but it's time for bed. if this seems a reasonable approach i'll finish it up and commit the changes on trunk and 1.6 branch. Do not forget that we have a 2.0 branch as well. right, of course, noted. -r ___ 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] problem in setting local roles for newly created object
Hi
I have a script which creates a new instance of a certain portal_type
by a method constructContent, and then calls manage_setLocalRoles.
And I get an exception:
Module AccessControl.Role, line 362, in manage_setLocalRoles
AttributeError: __hash__
and the lines in question are:
361dict=self.__ac_local_roles__ or {}
362dict[userid]=roles
Needless to say, if do the same things (constructContent and
manage_setLocalRoles) one at a time, it works fine. Does this mean
that I should do something in the meantime, after constructContent, to
complete object construction before calling setLocalRoles? Or is there
other way to set local roles on new object?
Bartek
___
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: Five: question on zcml
Tres, thanks for your answer, the solution was more subtle (or blunt ??). There was an acitons.ActionsToolXMLAdapter defined. However the loading of the module failed due to bad imports. thanks again robert Tres Seaver wrote: The factory for the adapter is identified using a relative lookup when its dotted name starts with a period. You have a module, Products.RedPick.exportimport.actions, but it doesn't have that class. Products.CMFCore.exportimport.actions *does* have it. You need to either: - Point to the one in CMFCore, e.g.: factory=Products.CMFCore.exportimport.acitons.ActionsToolXMLAdapter - Import it or override it in your local actions module. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEKp0W+gerLs4ltQ4RAoRTAKDZ8974r3lqGuWqla5EWukE7zMgqACbBHcz 8QIkWjWQIdUo75CXv32eLKw= =cu9G -END PGP SIGNATURE- ___ 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 begin:vcard fn:robert rottermann n:rottermann;robert email;internet:[EMAIL PROTECTED] tel;work:031 333 10 20 tel;fax:031 333 10 23 tel;home:031 333 36 03 x-mozilla-html:FALSE version:2.1 end:vcard ___ 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
