[Zope-CMF] xsl/xul and FSPageTemplate
Hi, I have been working on kupu i18n. This implied i18ning xsl files for the drawer. XSL files now carry the i18n namespace and should be imported as FSPageTemplate. However, FSPageTemplate currently removes the extension when building the id. So we cannot simply register .xsl files as FSPageTemplate. For instance, this would not work for kupu which has both Zope and non Zope uses and would need to keep the .xsl extension for xsl files. Actually, as i18n is in its own namespace, the xsl files remain totally functional when served without being interpreted (they just dont translate). Duncan has managed to use the .objects file to register a .xsl file as a FSPageTemplate together with its .metadata that includes the keep_extension property. What would be the right way to avoid this "heavy" mechanism ? I have nothing against .objects declaration which makes things more explicit ala Zope3 but having to include .metadata files in the sake of keeping extension feels really too much. Would it make sense to have a FSPageTemplateWithFullName type (to keep backward compat) or a FSXMLPageTemplate or ... What do you think ? -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ 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] xsl/xul and FSPageTemplate
Julien Anguenot wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Godefroid Chapelle wrote: Hi, I have nothing against .objects declaration which makes things more explicit ala Zope3 but having to include .metadata files in the sake of keeping extension feels really too much. Would it make sense to have a FSPageTemplateWithFullName type (to keep backward compat) or a FSXMLPageTemplate or ... What do you think ? Why don't you create your own FSXSLTemplate object ? It's pretty easy to register this kind of objects within the CMF using the dedicated registry. It might even sub-class FSPageTemplate if it makes sense in your case. Thats what I thought about. I think xsl i18n is generic enough to be in CMF. and I could check the code in if the community agrees on this idea. I would do it like this myself. J. - -- Julien Anguenot | Nuxeo R&D (Paris, France) -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ 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] Migration from CMF 1.3.1
Hi, I have come to a site setup with CMF 1.3.1 I am asked to migrate it to newer code. Are there any special things I need to know about before I upgrade the CMF products ? Thanks -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be ___ 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: Migration from CMF 1.3.1
Jens Vagelpohl wrote: On 30 Dec 2005, at 17:17, Godefroid Chapelle wrote: Hi, I have come to a site setup with CMF 1.3.1 I am asked to migrate it to newer code. Are there any special things I need to know about before I upgrade the CMF products ? No one will have an answer to that one. The only sane solution is to bring up a copy of that environment, put in newer code and see what happens. It's most likely that there will be breakage that you will have to fix. I know this is the way to go... I was just wondering if there could be well known issues like the Catalog fix/migration needed between Zope 2.7 and 2.8. jens Thanks anyway :-) -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be ___ 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] LSM stuff
Tres Seaver wrote: Fixing this LSM stuff is in the hands of a different set of folks, I think. Rob, how did stuff go at Sorrento? > > > Tres. I am just back from holidays that followed the Sorrento sprint. Reading the list did not allow me to understand if we came to a consensus regarding the getToolByName/getUtility question. Tres seems to imply there is one. Can someone make a summary/statement of the current state of thoughts ? Thanks -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be ___ 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] unresolved site manager related issues
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10 Apr 2007, at 10:30, yuppie wrote: Currently non-five.lsm site managers don't work in CMF, see this thread: http://mail.zope.org/pipermail/zope-cmf/2007-March/025817.html Proposed solutions: a) reverting most 'tools as utilities' changes (Kapil) http://mail.zope.org/pipermail/zope-cmf/2007-March/025817.html I'd like to mention this is not just Kapil proposal. Other people at the sprint were involved in the discussion that lead to Kapil's mail. Actually, that mail was written and reviewed by multiple persons. b) supplementing five.lsm (Hanno) http://mail.zope.org/pipermail/zope-cmf/2007-March/025822.html I am not sure if the following has been made clear so I'll try to explain it again. The current implementation of zope.component.registry.Components accesses the internals of the registries instead of using external APIS (I suspect this is for performance reasons). This implies that there are only two ways of implementing automatic acquisition-wrapping of utilities : - patch the Z3 registry itself in order to make all registries acquisition-aware as done currently in Plone 3.0 http://dev.plone.org/plone/browser/plone.app.kss/trunk/plone/app/kss/five_lsm_patch.py - have all local component registries (including five.lsm) derive from a common mixin class that implements 'queryUtility', 'getUtility', 'getUtilitiesFor' and 'getAllUtilitiesRegisteredFor' methods. This is easy to do (I had an implementation in 20 mins). However, in order to use with five.lsm components that are valid in Z3, we would need to "fix" :-S them with conditional imports. The above were facts, lets move to my opinion ;-) Both solutions do not smell very good but it would not be the first time we live with bad smells. However, my main concern regards the strategy used to get rid of tools in content space. I think that we inverse the order of things to do : we try to get rid of getToolByName API before getting rid of dependency on acquisition. Today, we are far away enough from the removal of tools from content space that we need the acquisition magic in five.lsm (correct me if I am wrong) to make most CMF tools work correctly. We first need to fix the most fundamental tools so that they can be used without acquisition (iow as pure utilities). When they are fixed, we can switch their calls from the getToolByName proposed in (a) to the getUtility we all wish. By fixing the implementation/use of those tools, we will have explored most of the consequences of the 'migration'. We can at that moment deprecate the getToolByName API as we will be able to give advices and patterns how to fix, to people that will still be relying on getToolByName acquisition wrapping. c) improving five.lsm (Rocky) AFAICS this is an other attempt to resolve the same issue: http://mail.zope.org/pipermail/zope-cmf/2007-March/025708.html We have to decide which way to go. I prefer c) if it works, b) otherwise. Same here. c) first, then b). Strongly against a). Before the sprint, I have spent more than one day exploring (c) Rocky's proposal and did not get to anything satisfactory. The zope.interface.adapter.AdapterRegistry would need to be acquisition-aware. IOW, we would once again pollute Z3. I explained here above why (b) is not a solution I like and why I support (a). Could you explain why you are strongly against (a) ? jens -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be ___ 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.localsitemanager: proposal
yuppie wrote: Hi! This proposal is now implemented on CMF and five.localsitemanager trunk. Everything *seems* to work, but maybe I'm missing something. This might be a good time to review and test the changes - any feedback is welcome. Thanks ! AFAICS, KSS will no longer need the monkey patch if it sets the LookupClass to FiveVerifyingAdapterLookup. Cheers, Yuppie I tried to test your code this evening... This implied starting to fix Archetypes and Plone to work with all the changes made in CFMCore.interfaces I must say I stopped when I found out IExtensibleMetadata is now a Z3 interface where code in Archetypes still awaits it to be a Z2 interface. I am ready to move on if someone can tell me the pattern to migrate calls like if not IExtensibleMetadata.isImplementedByInstancesOf(klass) interface I currently do not know the dance to move from Z2 to Z3 interfaces. However, I wonder if all the changes needed to run Plone 3 above CMF/trunk won't avoid us to actually test the new code... -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be ___ 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] tools-as-utilities roadmap
yuppie wrote:
Hi!
After some back and forth CMF 2.1 will just mark the first step of the
tools-as-utilities refactoring. We now have a working
five.localsitemanager that adjusts the persistent components registries
to Zope 2, but right now only a few CMF tools can be used as utilities.
Many tool methods depend on self.REQUEST, which is not available in
utilities.
The current state makes things more complex, not easier. So we need to
move on:
Scenario 1:
---
We declare all tool methods that use self.REQUEST instead of an explicit
REQUEST argument as broken. And fix the tools by adding new REQUEST
arguments. I guess one or two dozen methods would need that change in
CMF, many more in third party products.
We can add these arguments as optional arguments in CMF 2.1 and make
them required after a deprecation period. If you use only tools shipped
with CMF or adjusted to the new policy, you can start using getUtility
in CMF 2.1. If not, CMF 2.3 will be the first release that allows to use
getUtility for all tools.
Pros: The changes are simple, in CMF 2.3 we are done.
Cons: A lot of code needs to be modified. Especially third party code.
Scenario 1+2 :
The methods that depend on REQUEST are moved to browser views as below
instead of quickly fixed as in the scenario above. They can then be
deprecated on the tool.
Once a tool has been fixed as utility and views, we should deprecate its
use as tool (this might be implicit in the scenario above).
Pros: migration achieves better separtion of concerns
Cons: longer time to migrate away from tools (which will be long anyway,
as so many 3rd party products have some of those and the understanding
of the patterns will take time to percolate in the community.
Scenario 2:
---
We make dual use of tools. Each tool provides a tool interface (e.g.
IMembershipTool) and an utility interface (e.g. IMembershipUtility). In
most cases the utility interface will be a subset of the tool interface.
In the long run, tool methods that are not valid utility methods need to
be replaced by new utility methods or browser views.
We should add these new utility interfaces for all tools in CMF 2.1 and
use these instead of the tool interfaces for registering utilities. And
'getToolByInterfaceName' should be renamed to 'getUtilityByInterfaceName'.
getUtilityByInterfaceName('IMembershipUtility') would return the same
object as getToolByName(context, 'portal_membership'), but with a
different wrapper and less methods available.
Pros: No deprecation warnings, nobody is forced to switch to utilities.
Cons: This will take much longer, everybody has to work with tools and
utilities side by side for a long time. Might be confusing.
If as a community, we think utilities are the way, we should express it
clearly (even with deprecation warnings) : I think it would be wrong to
have coexisting calls to utilities and tools without deprecation warnings.
Iow, once the effort to fix/migrate a tool has been done, it should be
advertised so that we can learn it and stop asap to use it as a tool.
If, otoh, we are not sure the migration to utilities is the way, we
should not even begin it.
Opinions? Questions? Other scenarios?
Cheers,
Yuppie
PS: Sorry if my english is not accute enough to express all nuances
correctly.
--
Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be
___
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] tools-as-utilities roadmap
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: Hi! Godefroid Chapelle wrote: After some back and forth CMF 2.1 will just mark the first step of the tools-as-utilities refactoring. We now have a working five.localsitemanager that adjusts the persistent components registries to Zope 2, but right now only a few CMF tools can be used as utilities. Many tool methods depend on self.REQUEST, which is not available in utilities. The current state makes things more complex, not easier. So we need to move on: Scenario 1: --- We declare all tool methods that use self.REQUEST instead of an explicit REQUEST argument as broken. And fix the tools by adding new REQUEST arguments. I guess one or two dozen methods would need that change in CMF, many more in third party products. We can add these arguments as optional arguments in CMF 2.1 and make them required after a deprecation period. If you use only tools shipped with CMF or adjusted to the new policy, you can start using getUtility in CMF 2.1. If not, CMF 2.3 will be the first release that allows to use getUtility for all tools. Pros: The changes are simple, in CMF 2.3 we are done. Cons: A lot of code needs to be modified. Especially third party code. Scenario 1+2 : The methods that depend on REQUEST are moved to browser views as below instead of quickly fixed as in the scenario above. They can then be deprecated on the tool. Once a tool has been fixed as utility and views, we should deprecate its use as tool (this might be implicit in the scenario above). There are many tool methods that depend on REQUEST, but most of them take it as argument, not from the acquisition context. Separating all these methods cleanly in utility methods and views will mean replacing the tools by something new, not converting them to utilities. Any method which already takes REQUEST as an argument can be left alone for now. Right I think Godefroid was arguing that methods which expect to be able to acquire 'REQUEST' should be converted to view methods. Good : you clarify my thoughts. Some methods are "indirect" dependents (they call somthing which acquires REQUEST). I think we'd handle those by turning them into view lookups (ideally), or by continuing to call the deprecated API (see below), perhaps suppressing the message. suppressing which message ? the deprecation ? Pros: migration achieves better separtion of concerns Cons: longer time to migrate away from tools (which will be long anyway, as so many 3rd party products have some of those and the understanding of the patterns will take time to percolate in the community. I'm afraid we don't have enough volunteers to implement this scenario. Tools depend on each other and if your tool depends on a non-utility tool you can't make it a utility. The quick fix I propose makes it easy to start the migration - we can split off views later. And the pattern is very simple: Adding REQUEST arguments where REQUEST is used. A bird in the hand is worth two in the bush. I think we have to leave existing REQUEST-acquiring APIs alone, but deprecate them, and then implement them by calling *new* REQUEST-passing APIs. I would rather add methods than add hackery around the default REQUEST argument, as it keeps the deprecation story cleaner. +1 Tres. -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be ___ 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
