[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 - "A workflow without managed permission can't be exported", [Accepted] http://www.zope.org/Collectors/CMF/397 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 - "WorkflowAction deprecated warning should not printed for WorkflowMethod", [Pending] http://www.zope.org/Collectors/CMF/388 - "workflow notify success should be after reindex", [Pending] http://www.zope.org/Collectors/CMF/389 - "Implicitly acquiring allow_discussion in isDiscussionAllowedFor", [Pending] http://www.zope.org/Collectors/CMF/398 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 ___ 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] i18n Message objects: encoding issues
Hi Chris! Chris Withers wrote: yuppie wrote: 2.) Switch completely to unicode in CMF 2.0: Sounds like a too big change, don't think we should try that. I think we all know this is where we need to be eventually, 2.0 seems the right time to do that, I'd actually prefer this, even though it'll delay the 2.0 release... Might make sense. But I'll not work on this on my own, so unless there are other volunteers this is not really an option. 3.) Use encoded strings and unicode side by side: This requires to know the encoding of the encoded strings. 'default_charset' should provide that information. arrrgg there be dragons... I'm afraid we have to live with the dragons for a while. 3.1.) Encode unicode strings before passing them to page templates: The unicode strings are only returned by newly added parts of the code. So it might be easier to find all the places where a conversion is necessary. On the other hand Message objects are also unicode, so we would have to translate them before passing them to the templates. Yeah, okay, it'll work, but it sucks long term as it's even mroe code that needs to be "undone" when CMF goes fully unicode... Thinking a bit more about it, I doubt this will work. The translations returned by Five's translation service are unicode. And we can't change them without monkey patching. So I still tend to option 3.2.: Decode non-unicode strings before passing them to page templates. 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 doc
Hi Tres! Tres Seaver wrote: Tres Seaver wrote: - The "upgrade" feature you talk about for CPS sounds a bit like what the "version" attribute was originally for on import steps: in the original implementation, the tool knew what versions of import steps had been run in the past, and you could see which steps were "newer" (or had never been run) on the import view. I don't know where that feature went. It seems as though we should either add your update feature, or else resurrect the "version" UI (or maybe both?) I have to admit that I never understood why import steps have a "version" attribute. And I still don't understand that concept: Does that mean each upgrade needs its own import steps? The use case was that, over time, an import step might be updated. If you had installed your site before the update, then your configuration might also need to be updated. I first was confused by these sentences because currently import_steps.xml just registers handlers which might be used by many profiles. So reading "import step" I thought you meant the import handler. But if an "import step" represents a subset of a specific profile this starts to make sense. Some version of the setup tool (maybe never publicly released) tracked the 'version' last installed for each step, and would show you the steps which were out-of-date, or had never been installed, in a way which made them easy to distinguish. I think there was a convenience button which ran only such steps, as well. I don't think I ever saw a version that implemented this. And I'm not sure if GenericSetup should implement this. But at least I understand now why import steps have a "version" attribute. 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: Reference Engine Componentization
hi! Am Tue, 24 Jan 2006 22:32:36 -0600 schrieb whit: > howdy philip! just getting back to this. thanks for your input ;) > > Philipp von Weitershausen wrote: >> whit wrote: >> >>>sorry for the cross post, but I know there are a number of other >>>reference engines out there and I would like to get input as we look >>>at moving the AT ref engine being a component. >>> >>>here is a rough list of steps: >>> >>>1) move current storage of references to use IAnnotations for new >>>content / reference classes. Create a layer of indirection, making >>>reference storage a configurable option. >>> >>>2) refactor UID storage to use IAnnotations >> >> >> I don't think neither references nor UID capabilities have to do with >> annotations. In fact, Zope 3 doesn't use annotations for either one: > > noted...currently, in AT, references are stored in an annotation pattern > (actually as a Folder stored as an attr on the holding object). The > reimplementation requires some sort of persistent storage, and the > reference objects aren't content so storing them as using IAnnotation > seemed logical. > Currently, references are very contentish. some sort of persistence > mechanism will be required, though the behavior on a reference can be > abstracted out through adapters, so what the object is created from > matters less. > > But they have to go somewhere...any suggestions? Well, at the moment archetypes allows real contentish references. In UML this is called also an "Assocation-Class". We're using this heavily in ZUCCARO. However this is implemented, the feature is a must have. > >> - UID capabilities: Zope 3 has the intid utility which allows one to >> assign any object a unique integer id. This should be adopted for Zope >> 2 and I think it would be fairly easy to do wrt persistent objects (as >> the ZODB is the same) > > The AT uid is suppose to be a UUID, thus enabling content migration from > system to system. would it be possible to combine the uuid into a > derivative of the intid utility? I propose to support the different UUID mechanisms described in RFC 4122 "A Universally Unique IDentifier (UUID) URN Namespace" http://www.rfc-editor.org/rfc/rfc4122.txt. I found a nice Python implementation at http://zestyping.livejournal.com/157957.html [...] Jensens -- Jens W. Klein, WEB APPLICATIONS: ZOPE, PLONE - MDA, SOA BlueDynamics Tyrol production: concept, development, design Klein & Partner KEG consulting: analysis, coaching, training http://www.bluedynamics.com management: projects, process, community ___ 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] FS Skins and Last-Modified
Doyon, Jean-Francois wrote at 2006-1-25 15:51 -0500:
> ... FSDTMLMethods ...
>But, for some reason, now it seems bobobase_modification_time comes out
>wrong :(
>
>It's stuck at some date in October, even though the files are far more
>recent.
Note that the "methods" (like "bobobase_modification_time")
inside an "FSDTMLMethod" do not act on the "FSDTMLMethod" but
on its (so called) client.
The model is like this:
The "FSDTMLMethod" is called for an object, its client.
Most methods used inside the "FSDTMLMethod" from the DTML namespace
come in fact from "client" (or are acquired by it).
Therefore, "bobobase_modification_time" give you the
modification time of the ZODB (!) object that happens
to be the "FSDMTMMethod"s client.
When called from ZPublisher (as is apparently your case),
the client is the object located during URL traversal
before the "FSDTMLMethod" ("REQUEST.PARENTS[0]", to be precise).
--
Dieter
___
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 doc
hi all! and great document, florent... thanks! yuppie wrote: Tres Seaver wrote: The use case was that, over time, an import step might be updated. If you had installed your site before the update, then your configuration might also need to be updated. I first was confused by these sentences because currently import_steps.xml just registers handlers which might be used by many profiles. So reading "import step" I thought you meant the import handler. But if an "import step" represents a subset of a specific profile this starts to make sense. i think i understand, but i'm not 100% sure. i'm going to give an example of how i think this would work, hopefully someone will confirm or correct me. say i have a base profile that includes a given toolset.xml file. later, i develop for my product a new custom tool. i would add my tool to the toolset.xml file, and then update the version number of the toolset step in the import_steps.xml. this would (if it were working) indicate to the setup tool that this import step was now out of date in any prior installations, allowing me to trigger this import step (and any others that were out of date) to be re-executed. is this correct? if it is, i definitely like the idea, but think maybe it can be improved upon a bit. i'd rather see the version numbers actually live in the step definition file, for instance... the toolset import step's version number would live in the toolset.xml file, so i don't have to remember to open the import_steps.xml file to keep the versions current. also, version tagging the import step itself may be too broad a stroke at times. in cases where an action has changed on a type info declaration, you'd really want to be able to just update a version number on that particular type's description. this would require the importer itself to be smart enough to check for versions and compare them against a record of the versions at original import time. this type of behaviour could be very useful for content importers, as well. the 'upgradeStep' directive as florent described in his blog entry is also a good idea, i think. i prefer the version number approach for changes that can be cleanly represented in the setup profile, but i'm sure there will be things that need to happen that the setup profile won't be able to capture effectively. -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
