Re: [Zope-CMF] [CMF 2.1] opaque items calls make performance issue
Am 11.08.2009, 20:06 Uhr, schrieb yuppie y.2...@wcm-solutions.de: I propose to split up CMFCatalogAware in CatalogAware, WorkflowAware and OpaqueItemManager mixins. All the interfaces provided by these base classes should be optional for CMF content. PortalFolderBase e.g. is not catalog or workflow aware, so it should not use those base classes. This is an excellent idea! Finding out that the reason why my folderish objects were not being indexed because PortalFolder switches it off despire being CatalogAware was one of those aha experiences when moving towards a component architecture. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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 2.1] opaque items calls make performance issue
Am 09.08.2009, 04:48 Uhr, schrieb Martin Aspeli optilude+li...@gmail.com: self_base = aq_base(self) for name in self_base.__dict__.keys() obj = getattr(self, name) if ICallableOpaqueItem.providedBy(obj): items.append((obj.getId(), obj)) That's just *nuts*! From my previous answer to this which I forgot to send to the list as well - can we change the list settings so that answers go to it by default? CMF maintains pretty extensive backwards compatability. A similar question came up a couple of years ago and produced this response from Tres: http://mail.zope.org/pipermail/zope-cmf/2007-March/025754.html ie. there is no reason why this should not be deprecated and replaced. Returning to the original questions: But z2ICallableOpaqueItem is a Zope2 interface and I m not used to this kind of object. It seems they are generated on runtime, so for me it's hard to debug. No, it's simply renamed on import in CMFCatalogAware * What are opaqueitems (any example ? I don't have find anything usefull in tests of CMFCore) Interface for callable opaque items. o Opaque items are subelements that are contained using something that is not an ObjectManager. o On add, copy, move and delete operations, a marked opaque items 'manage_afterAdd', 'manage_afterClone' and 'manage_beforeDelete' hooks get called if available. Unavailable hooks do not throw exceptions. DiscussionItems are ICallableOpaqueItems * Is zope2 interface are still used and why ? For anything that uses OpaqueItems. From Tres' post it's pretty unlikely that this is the case. The z2I import as has been removed in CMF trunk. * How could I replace those calls, or improved this code that always return an empty tuple In you own deployments I suggest simply overriding the code to do just that. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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 2.1] opaque items calls make performance issue
Am 07.08.2009, 22:17 Uhr, schrieb toutpt tou...@gmail.com: experimental.opaquespeedup is good but not enough for me. The load tests results are not enough, I want to be more 'aggressive' and experimental. For me this package is backward compatible and do a catalog query instead of parsing all attributes. I want to do nothing except support 'talkback'. I want also to release this package on pypi, and I want your opionons: * makina.opaquespeedup (makina is where I m working) * experimental.aggressiveopaquespeedup * any other idea ? My vote goes to experimental.aggressiveopaquespeedup Is the patch for Plone or CMF? If it's for CMF then you should consider simply submitting a patch or opening a branch. But before you write any package I would like to know a little more about what exactly you want to do. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] [dev] CMF 2.2 dependencies
Am 05.07.2009, 17:38 Uhr, schrieb yuppie y.2...@wcm-solutions.de: 1.) Make Zope = 2.12 required for CMF 2.2 and change all imports. 2.) Make Zope 2.13 required for CMF 2.2. 3.) Add zope.app.component and zope.app.container to CMF dependencies. 4.) Re-add zope.app.component and zope.app.container to Zope 2 trunk dependencies. 5.) Add a lot of try except imports and modify zcml files to make imports from both locations working. Any preferences or better ideas? As previously noted backwards compatability should be desirable but not at too high a price. CMF 2.2 contains a lot of changes not least the eggification and buildout support that stem largely from the changes in Zope trunk so it is reasonable to make 2.12 the new baseline. However, it was also previously stated that Plone 4 might not be able to based on 2.12. Tres seems to indicate that this is no longer going to be the case. So +1 for 1) from me. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] allowedContentTypes improvement
Am 28.06.2009, 09:46 Uhr, schrieb Vincent Fretin vincent.fre...@gmail.com: Hi, I patched Products.CMFCore trunk 2.2 as well. I hope I didn't break anything. Difficult to know as there doesn't seem to be any test for this. I think it would be a good idea to have one Apart from the use of list comprehension, the change seems to be: portal_types.listTypeInfo(self) versus portal_types.listTypeInfo() Where ther is type information which leads to isConstructionAllowed() being called twice. The change shouldn't have any unpleasant side effects and is certainly easier to understand. I would add that the changed code exceeds the recommended maxium line length. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Rename form
Am 18.06.2009, 12:10 Uhr, schrieb Raphael Ritz r.r...@biologie.hu-berlin.de: FWIW: I find it quite natural wanting to rename this specific thing that I'm just looking at so my vote would be for any IContentish object. In the UI sense at least ... I've been thinking along the same lines and it wouldn't be difficult to add another action for renaming individual content objects. Renaming via folders is presumably a continuation of the way things are done in the ZMI which is, of course, how we generally do things in file systems. Nothing wrong with keeping it around even if I think the more content-centric (egid, what a neologism!) approach would be to work with the object itself. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
[Zope-CMF] Help with tests
Hi,
I'm having a little trouble with writing the tests for my formlib
folder contents view replacement. The basic tests (based on yuppie's
doctests) are fine but incomplete. I'm now integrating batching and am
getting caught on view permissions for DummyContent objects.
This is the test:
def _make_batch(self):
from Products.CMFCore.tests.base.dummy import DummyContent
batch_size = 25
for i in range(batch_size + 2):
content_id = Dummy%s % i
content_obj = DummyContent(content_id)
content_obj.portal_type = Dummy Content
obj = self.folder._setObject(content_id, content_obj)
content_obj.manage_setLocalRoles('user_foo', ['Owner'])
def test_check_batching(self):
self._make_batch()
batch_size = 25
view = ContentsView(self.folder, TestRequest())
self.assertEquals(view._getBatchObj().sequence_length,
batch_size)
self.assertEquals(view.navigation_next['title'], NEXT N
ITEMS)
and this is error:
File /Users/charlieclark/cmf-svn/CMF.buildout/trunk/src/Zope2/src/
AccessControl/ZopeGuards.py, line 71, in guarded_getitem
if getSecurityManager().validate(object, object, None, v):
Unauthorized: (item 0): You are not allowed to access 'Dummy0' in this
context
Obviously I don't have the permission to access my newly created
objects. So how do I go about fixing this for my tests? I can't find a
comparable example in the rest of the CMF tests? Is it best to fix the
permissions of the objects so that are viewable be anonymous or
should I assign my view to my user? And while I'm at it, am I creating
my dummy objects in the right way? I remember Tres saying something
about this recently.
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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] Help with tests
Am 07.06.2009 um 15:07 schrieb Tres Seaver:
Do you need to set up a security manager with 'user_foo', grep for
'newSecurityManager' in other CMF tests.
Hi Tres,
I've tried that but am not having much success:
def test_check_batching(self):
user = self.uf.getUserById('user_foo') # should be the owner
of the objects
user = user.__of__(self.uf)
newSecurityManager(None, user)
self._make_batch()
batch_size = 25
view = ContentsView(self.folder, TestRequest())
self.assertEquals(view._getBatchObj().sequence_length,
batch_size)
self.assertEquals(view.navigation_next['title'], PREVIOUS N
ITEMS)
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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] Help with tests
Am 07.06.2009 um 15:26 schrieb Charlie Clark:
Hi Tres,
I've tried that but am not having much success:
Scratch that - invoking an unrestricted user seems to do the trick:
def test_check_batching(self):
newSecurityManager(None,
UnrestrictedUser('user_foo', '', ['Manager'], ''))
self._make_batch()
batch_size = 25
view = ContentsView(self.folder, TestRequest())
self.assertEquals(view._getBatchObj().sequence_length,
batch_size)
self.assertEquals(view.navigation_next['title'], PREVIOUS N
ITEMS)
Is this okay? At least it lets me work on the rest of the tests.
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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
[Zope-CMF] Customised permissions
Hi, this should be a no-brainer but apart from a recent discussion on the death of local permissions I can't much on it - how do I use custom permissions? I've added them in to zcml but they don't crop up in the security interfaces and, surprise, surprise, I get an error when I try and import a role map that uses them. permission id=charlie.can do everything title=Only rulerz can have this permission / Do I need additional Python calls to the security modules to register this? I'm not quite sure if the setDefaultRoles() in CMFCore.permissions does this or not. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Extending FTI.isConstructionAllowed
Am 02.06.2009 um 14:47 schrieb Wichert Akkerman: That assumes the object has already been constructed and you're only testing constraints for adding the instance to the container. Our use case is different: we are testing at a point where construction has not happened yet. I think there are two things to consider here: 1) can I create the object at all? 2) can I add it to a particular container? so yuppies' reference to checkFactory and checkObject are definitely the places to start. Your use case refers not to object creation but containment depths so you're not checking the factory as whether you can create the object but the container as to whether it may contain the object. Surely extending the sample class to count your containment depth will solve the problem: raise the error and rollback the transaction? Charlie PS. written without reference to the scary code but not convinced that extending TypeTool in anyway is a solution to anything. -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Extending FTI.isConstructionAllowed
Am 03.06.2009 um 10:12 schrieb Wichert Akkerman: There are two reasons I want to block creation of the object: performance, and user interface. The last one is more critical: the add-item menus used in Plone (and I suspect CMF as well) look for all object types that can be constructed in the current location. Obviously you do not want to do that by creating all possible objects and testing if you can add them to the container, so we need a way to test if creating an object and adding it to the current container is allowed without creating objects. I agree with you on the UI aspect! In which case, surely you should be looking to set a precondition on checkFactory? class IItemTypePrecondition(zope.interface.Interface): def __call__(container, name, object): Test whether container setitem arguments are valid. Raise zope.interface.Invalid if the object is invalid. def factory(container, name, factory): Test whether objects provided by the factory are acceptable Return a boolean value. It looks to me like the factory method is the place to do the checking. But I guess the problem is integrating this with the TypeInfo.allowed_content_types ? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Customised permissions
Am 03.06.2009 um 13:05 schrieb Wichert Akkerman:
Not if you use collective.autopermission.
In which it states:
# This is borrowed from Products.CMFCore to avoid a dependency.
Where it states
# XXX This ought to be in AccessControl.SecurityInfo.
:-/
It looks like I only need use_mailhost_services which I've hooked up
in like this
security = ModuleSecurityInfo('Products.CMFCore.permissions') -
should this reflect my module?
security.declarePublic('UseMailHostServices')
UseMailHostServices = Permissions.use_mailhost_services
in a dedicated permissions module which I just include in the
configuration. Although I do like the event handling. Wouldn't it be
an idea to put this actually in the CMF?
I also noticed that the CMF permissions are actually declared in Five.
Is there a reason for this? Surely the CMF permission declarations
should be in CMFCore
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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] Customised permissions
Am 03.06.2009 um 15:47 schrieb Martin Aspeli:
That code is, but not the whole functionality. The functionality to
register Zope 2 style permissions when a permission / ZCML statement
is used is new to collectie.autopermission. I merged that back into
Zope
for Zope 2.12, so if you're on 2.12 you're in luck. :)
er, coughs, goes red - still on 2.10 for this project but there is a
chance we might update. Main difference would be the add views which
are all based on yuppie's CMF 2.1+ stuff which has since changed.
It looks like I only need use_mailhost_services which I've hooked up
in like this
security = ModuleSecurityInfo('Products.CMFCore.permissions') -
should this reflect my module?
security.declarePublic('UseMailHostServices')
UseMailHostServices = Permissions.use_mailhost_services
in a dedicated permissions module which I just include in the
configuration. Although I do like the event handling. Wouldn't it be
an idea to put this actually in the CMF?
The point is that Zope 2 permissions spring into existence when you
start using them in a Module/ClassSecurityInfo. If nothing imports a
module that has one of those, your permission doesn't exist. Prior to
Zope 2.12, the permission / directive only used to map Zope 2
permissions to IPermission utilities, but not actually create new
ones.
Thanks for the explanation. So without the event handler I need to
register the permission manually? That would explain what we're
observing.
I also noticed that the CMF permissions are actually declared in
Five.
Is there a reason for this? Surely the CMF permission declarations
should be in CMFCore
Sure. Historical reasons.
Can't argue with them! ;-)
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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] Making it easier to replace MemberData implementation
Am 16.05.2009 um 10:58 schrieb Jens Vagelpohl: I haven't chosen his particular implementation to reach that goal, but one that IMHO fits better with the direction we're going, by using a named factory utility. If no suitable utility is registered, the implementation falls back to the hardcoded MemberData class. +10 ;-) Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Actions growing link target attributes
Am 15.05.2009 um 16:31 schrieb Jens Vagelpohl: The first chunk of code enables the administrator to set the value of the link target for an action, which can then be used to fill the link tag target attribute during rendering. This is an excellent idea. +1 Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Improvements to Discussion Items
Am 22.03.2009 um 10:45 schrieb Martin Aspeli: 1) Fire an IObjectAddedEvent when a Discussion Item is created 2) Fire an IObjectRemovedEvent when a Discussion Item deleted 3) Do not hardcode the review_state of a Discuss Item. This allows discussion items to participate in workflow. 4) Create discussion items based on an IFactory utility rather than hardcoding the class. I've implemented 1-3, along with a simple review workflow and indexers that index the number of comments and the people who've commented on a content item (to make it easier to find items the current user has commented on, and to show the number of comments an item has received in a content listing), in a new Plone product, collective.discussionplus. There's a file of simple monkey patches to CMFDefault here: http://dev.plone.org/collective/browser/collective.discussionplus/trunk/collective/discussionplus/patches.py Would it be useful to push this down into CMF itself? I can't promise I have time to do that (with tests) in the short term, but I'm happy to help anyone who wants to do it. I may find time later, of course. Hiya Martin, thanks very much for this. Seems to make a lot of sense to me. I'll put it on to my to-do list when I've actually done the two things on there already. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Proposal: MemberDataFactory
Am 18.03.2009 um 18:02 schrieb Miles: Sure. Example use cases are fairly simple things like: - I set members to have first_name, last_name, job_title attributes and I want to give them an attribute proper_name that returns '%s %s (%s)' % (first_name, last_name, job_title); - I want to provide a standardised sortable name for ordering rows, e.g. (last_name + ' ' + first_name).lower() - I want to adjust the setProperties method to add a 'modified' attribute that's adjusted on every change of details For sites with integration we use PAS. But for small sites with very simple member requirements, the MemberDataTool generally does most of what's required out of the box. A good explanation. +1 from me. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] IndexableObjectWrapper
Am 18.03.2009 um 13:48 schrieb yuppie: Looks unnecessarily complex to me. But I'm afraid I'm outvoted. I wouldn't say that. From what I've understood of the discussion I tend to favour your position. Unfortunately I don't think I've understood everything well enough to make a really informed decision! I do, however, like the idea of the default adapter. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] IndexableObjectWrapper
Am 10.03.2009 um 09:14 schrieb Raphael Ritz: If there would be a strong preference from the CMF community here I'm sure this would be honored in our discussion. Opinions anyone? (ideally including a reasoning beyond I want ZPL because that's what Zope itself uses) ;-) Actually that is itself a very valid opinion - any company that is interested in software licences prefers as few of them as possible. My preference is always for a no-strings attached licence (ZPL, modifieid BSD, Apache). It's nice to hear that there is some discussion within Plone about licensing. If there is framework code in Plone that might be better placed lower down the stack in CMF then the sooner the better. There is a heap of stuff that could do with refactoring and reengineering along component architecture principles. It is not a little ironic in an open source context that the next release of Plone requires a new release of CMF to which it itself has (hardly?) contributed. This may often be unintentional as Plone developers write libraries for Plone unaware of the problem of backwards licence incompatability - the wrapper for z3c.forms springs to mind - but it is a problem just the same. Concentrating on a content management framework for Zope as the basis for Plone and other approaches is a good thing IMHO. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] IndexableObjectWrapper
Am 10.03.2009 um 10:01 schrieb Wichert Akkerman: The debate is currently focusing on GPL versus BSD license. Any opinions on a choice between those two would be very welcome. Speaking as someone who hasn't written a whole lot of code: BSD. I have a real dislike of the GPL because I think it fails to emphasise the real benefits of open source and it is a real pain if you wish to integrate with other non-GPL stuff whether it's commercial or not. The same discussion came up for Trac a few years ago because of the desire for closer integration with subversion. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] IndexableObjectWrapper
Am 10.03.2009 um 10:49 schrieb Wichert Akkerman: Perhaps in the future the Plone Foundation would be willing to donate code to the Zope Foundation. At this moment that is a bridge too far, and I fear that as soon as I suggest that at this point in time the entire relicensing movement will die in a never-ending debate. Lets save that one for a later day. I suspect you're right on that and that we on this list can all say that, with hindsight, the licence debate should never have happened. Let's hope it can be resolved in the future. I hope this will become easier as development moves to a more library-based approach -- all hail TurPlango! What we cannot (dual-)license for the CMF but think we need for the CMF we will have to reimplement. I have to agree with Jens that saying something was added to Plone rather than the CMF because of the Plone release cycle is disingenuous. As long as I have been following the list the CMF releases have been timed for Plone. It would be good to see this change from now on as I suspect the number of core developers on both projects is limited and both projects would benefit from effectively pooled resources and clear ideas of what goes where. I also have to agree with Jens that the Plone mailing lists are way too noisy. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] [dev] CMF 2.2 plans?
Am 02.03.2009 um 19:27 schrieb yuppie: This is on my todo list, but I still have to write a proposal. Hmm, I don't recall the issue here. There wasn't much discussion about this. Some time ago Dieter asked for grouping support: http://mail.zope.org/pipermail/zope-cmf/2008-September/027776.html I'm still struggling with the abolition of TypeInfo actions so I'd appreciate more discussion or simply explanation of this. Or we could move the forms and other views to a separate package. That way CMFDefault would not depend on zope.formlib nor on z3c.form. I would favor the latter. cmf.forms, maybe? Don't know. I don't think we have the resources to maintain several kinds of full skins for CMFDefault. The browser views should *replace* the old skins and z3c.form is quite useful for writing all the necessary forms. I agree on both those points. In fact I'd rather reorder CMFDefault to use packages for each content type with their own dedicated browser folder and views and the same for the tools. For me the only thing is whether CMFDefault/formlib is in the right place. Tres, is this what you're referring to with by cmf.form(lib)? This itself will depend on whichever library we're using - which I think will be z3c.forms post CMF 2.2 That would mean that CMFDefault-the-example-application will depend on z3c.form. If we are going to split off the forms we need to split off all browser views and the profiles that use these views. Something like 'cmf.app' that includes all the CMFDefault stuff Plone doesn't depend on. I'm not sure if that is a win. Moving to views should, at some point, allow us to deprecate non-view object rendering. But maybe that is a separate point? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] [dev] CMF 2.2 plans?
Am 02.03.2009 um 19:46 schrieb Hanno Schlichting: This can happen in two ways, though. Either move the example- application bits into a different package or move the reusable bits into one. If you are really interested in doing this work, I'd be happy to figure out what parts of CMFDefault Plone is actually using. I think this is essential. While I maintain the CMFDefault is an excellent start for many websites, Plone should not be *directly* dependent upon it - there are just too many conceptional differences and by now also too many stylistic ones as well. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] [dev] CMF 2.2 plans?
Am 28.02.2009 um 13:55 schrieb Hanno Schlichting: Hi. Quoting a mail from Jens from September last year: Is there anything to hold back a CMF 2.2.0 beta at this point? I have one small todo item on my list regarding the changes to content type icons. Things I remember people working on: - Formlib based views Yuppie's already done most of them. Work on my my own folder_contents replacement has been sporadic but is finally coming along and I hope to finish it in March. Then I can work on my table-free replacement of main_template.pt. Beyond that I'll try and work on form(lib) views for some the rest of CMFDefault - the brackets because I think that beyond 2.2 a move to z3c.forms is should be seriously considered. Fortunately the code z3c.forms code is close enough to formlib to make migration fairly straightforward. - Add-views Add to that Jens' CMFActionIcons folding into CMFDefault and presumably Tres' ursa replacement for Globals.py and Yuppie's workflow work. http://www.zope.org/Products/CMF/docs/roadmap/view has a couple of items, I'm not sure about. Is there anything missing, people would like to have in a new version? It should be no surprise, that I'd like to have official support for Zope 2.12 for CMF 2.2 as well ;) Nightly tests are running fine for all I can see. As Zope 2.12 is not likely to be released before Summer, would that be a reasonable timeframe to aim for a CMF 2.2 final release as well? Seems reasonable to me although the Zope 2.12 support is more nice to have than a real requirement. I'm thinking of giving a presentation on CMF 2.2 at Europython which would also fit the timeline and perhaps encourage me to do some of the documentation I've been wanting to work on for the last couple of years. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] [dev] .zexp imports and notifyWorkflowCreated
Am 25.02.2009 um 14:18 schrieb Wichert Akkerman: There are many use cases for both options. One aspect is that it is extremely hard to not get the current behaviour. We had to hire Philipp to write z3c.unconfigure for us just to be able to create a system to prevent CMF from making changes on copies. First of all I'm not sure if that's such a bad thing! ;-) But the solution would probably be making this behaviour configurable somewhere in the workflow tool. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] [dev] .zexp imports and notifyWorkflowCreated
Am 25.02.2009 um 16:10 schrieb Wichert Akkerman: The workflow tool is not a factor at all here. The problem is that CMF registers some event handlers that do things like clear workflow status and local roles when you create a copy. I realise that but surely the handlers can have a default behaviour that can be changed depending on the configuration? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
[Zope-CMF] Getting started with Unittests for BrowserViews
Hi,
I've finally got some time to work on my browser view for folders.
Based on Yuppie's doctest I've started writing a unittest testsuite so
that I can write the tests for the missing functionality and learn
more about unittest as I go along but I'm stumbling at the first
hurdle: what's the best way to call my view? Directly from the view
class or as Multiadapter? If it is the latter what's the correct call
for this as I don't seem to be able to get it right in the zope shell:
folder = site.subfolder
folder
PortalFolder at /CMFDefault/subfolder
getMultiAdapter((folder, request), IBrowserPublisher,
name=ucontents.html)
Traceback (most recent call last):
File stdin, line 1, in ?
File /Users/charlieclark/CMF-Sandbox/cmf-trunk/eggs/
zope.component-3.4.0-py2.4.egg/zope/component/_api.py, line 103, in
getMultiAdapter
raise ComponentLookupError(objects, interface, name)
zope.component.interfaces.ComponentLookupError: ((PortalFolder at /
CMFDefault/subfolder, zope.publisher.browser.TestRequest instance
URL=http://127.0.0.1), InterfaceClass
zope.publisher.interfaces.browser.IBrowserPublisher, u'contents.html')
but
from Products.CMFDefault.browser.new_folder import ContentsView
view = ContentsView(folder, request)
IBrowserPublisher.providedBy(viw)
True
I've noticed that many of the tests use a DummyRequest dictionary but
using an instance of this doesn't work either.
This is the stub of my testsuite:
import unittest
from zope.component import getSiteManager
from zope.component import getMultiAdapter
from zope.publisher.browser import TestRequest
from Products.CMFCore.PortalFolder import PortalFolder
from Products.CMFCore.tests.base.dummy import DummySite
from Products.CMFCore.tests.base.dummy import DummyTool
from Products.CMFCore.interfaces import IPropertiesTool
class FolderBrowserViewTests(unittest.TestCase):
def setUp(self):
Setup a site
# maybe there is a base class for this?
self.site = site = DummySite('site')
self.sm = getSiteManager()
mtool = site._setObject('portal_membership', DummyTool())
ptool = site._setObject('portal_properties', DummyTool())
self.sm.registerUtility(ptool, IPropertiesTool)
ttool = site._setObject('portal_types', DummyTool())
utool = site._setObject('portal_url', DummyTool())
folder = PortalFolder('test')
site._setObject('test', folder)
self.context = folder
def test_view():
request = TestRequest()
view = getMultiAdapter((self.context, request),
'contents.html') # will fail
def test_suite():
suite = unittest.TestSuite)
suite.addTest(unittest.makeSuite(FolderBrowserViewTests))
return suite
I'm very grateful for any suggestions.
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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] [dev] .zexp imports and notifyWorkflowCreated
Am 18.02.2009 um 21:51 schrieb Wichert Akkerman: In my opinion a copy should produce a full copy, including all state and history. Yes, in the technical sense of .copy() but I'm not sure if that is what I as a user expect in a CMS. Do I really want an exact duplicate of everything or perhaps a new object with the content of the old? If the original object has already been published should my new object also be published? If so surely I'm breaking with the workflow principle. In my experience (and I'm not just talking about how I do things) copies are usually made with the original object being archived as a sort of security blanket in case something goes wrong. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] [Checkins] SVN: Products.CMFCalendar/trunk/setup.py - dependency cleanup
Am 16.02.2009 um 13:08 schrieb Jens Vagelpohl: I'm wondering, ist it necessary to declare a dependency where we know that it is a required dependency for another dependency we already declare? Specifically, if CMFDefault is declared as dependency, is it necessary to also declare CMFCore because we know CMFDefault already declares it? hm, do we always *know* that? Unless dealing with known behemoths aka Zope2, I'd go with explicit is better than implicit and expect declarations for any import statement. Then again I'm still not convinced that the CMF itself isn't a mini- behemoth to be eaten tail, toenails and all. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] [dev] five.localsitemanager: dependencies
Am 12.02.2009 um 14:45 schrieb yuppie: install_requires=[ 'setuptools', 'Zope2 = 2.12.dev', ], Is that the right way to resolve that issue? Could it cause any trouble if I would check in that change? Only for someone wishing to use it totally outside of a Zope context. I'm not that familiar with Buildout but I would have thought that any direct import dependencies should be listed - and zope.location doesn't seem to be (neither are zope.event or zope.site for that matter). OTOH the condition = seems to be being incorrectly interpreted. If this is a bug then it should be filed. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] [dev] five.localsitemanager: dependencies
Am 14.02.2009 um 20:33 schrieb Tres Seaver: Given that package's job in life, I strongly doubt that we need to worry about anybody using it outside of a Zope2 app. In fact, I think it might be a good idea just to fold the package back into Zope2 (I don't recall why it ever shipped separately). If it is Zope2 specific then it should be part of Zope2: it's monolithic but we love it anyway. I'm not that familiar with Buildout but I would have thought that any direct import dependencies should be listed - and zope.location doesn't seem to be (neither are zope.event or zope.site for that matter). OTOH the condition = seems to be being incorrectly interpreted. If this is a bug then it should be filed. The transitive dependencies of another dependency don't need to be listed: the problem Yuppie was fixing was a set of over-specific dependencies, now redundant in the new, egg-centric world of Zope 2.12. I think another fix would be to move the Zope2 import to the top of the list, so that its own, more specific dependencies would be installed first: however, I don't see much win over Yuppie's fix. Yuppie's suggestion is fine with me and probably the second solution best solution aside from just making it part of Zope2. But that doesn't stop a bug being a bug. Dieter suggests that the bug is with setuptools which gives it plenty of company. as far as I know. Life used to be so simple with just distutils ;-) Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Accessing skins objects
Am 09.02.2009 um 18:53 schrieb Tres Seaver:
This is talking directly to Zope (no Varnish / Squid in front?)
Please
post the PythonScript, too.
Yep, this is a local wget talking directly to Zope.
The PythonScript is:
request = context.REQUEST
styles = []
styles.append(getattr(context,
'content_global.css').index_html(request, request.RESPONSE))
styles.append(getattr(context, 'default.css').index_html(request,
request.RESPONSE))
#... lots more file
return \n.join(styles)
Now the profile results:
1) View
4499 function calls (4476 primitive calls) in 0.110 CPU seconds
2) PythonScript
12830 function calls (12786 primitive calls) in 0.154 CPU seconds
The 3:1 ratio is probably down to the way index_html works for the
files.
So the PythonScript is more CPU intensive but also delivers faster.
Going on what you suggested yesterday I suspect the difference is down
to how the request is written to. I'll see if I can get something
working with that IFilestreamIterator you suggested.
The FSFile
object *never* stores the bits read from the filesystem, so the more
likely case is that your view is hitting some other bottleneck.
oh, what FS things are affected by the debug-mode flag that forces
them to be reread?, ie. which objects don't reflect underlying file-
system changes?
Other FS objects may have cached information computed from the file
(e.g., the compiled template bytecode for an FSPageTemplate, or
bytecode
for an FSPythonScript). But there is nothing which reads FSFile data
into memory and holds it. both its '__str__' and its 'index_html'
reread the file from dist. However, the object *may* be cached by a
RAMCache or an AcceleratedHTTPCache, if one is configured.
No, very little caching is active at the moment.
If Globals.DevelopmentMode is enabled, then the call to
'_updateFromFS'
in both of those methods ('__str__', 'index_html') removes the object
from the cache on each request.
Yes, I've seen this is how _readFile() works.
BTW, it might be faster to compute the *filenames* in the memo, and
then
return an IFilestreamIterator which chunked the response by reading
the
files one at a time. Running 'cat /path/to/fsidr/*.js' in an
os.system() call might be faster, too ;)
I quite like the iterator idea.
BTW. Can I admit at this stage that I
don't really understand what the memoize method does? 8-)
It caches the result of the method call in the view's instance
dictionary. Be *sure* to use it only for views: using it on a
content
objecct would be disastrous.
I'd read the method and figured that's what it does. But because I'd
never seen the pattern before I wasn't sure. If we do use it, we only
use it views. Having it in browser.utils is a handy hint there. I have
hit problems when combining it with decode - obvious when one thinks
about it - but as all our objects return data in unicode (most are
managed through formlib forms with some stuff stored in an RDBMS with
the driver configured to coerce unicode) decode isn't necessary.
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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] Accessing skins objects
Am 10.02.2009 um 10:16 schrieb Charlie Clark: Now the profile results: 1) View 4499 function calls (4476 primitive calls) in 0.110 CPU seconds 2) PythonScript 12830 function calls (12786 primitive calls) in 0.154 CPU seconds I've added an interator which reduces the number of calls: 2370 function calls (2362 primitive calls) in 0.041 CPU seconds But this reduces data transfer still further to between 10 and 20 MB/s! While I'm convinced that the code is probably better I'm at a loss about the slowdown. This is the code for comments: class FilesIterator(object): size = 0 files = [] def __init__(self, files): for f, size in files: self.files.append(f) self.size += size def next(self): while self.files: f = open(self.files.pop(), rb) data = f.read() f.close() return data class Javascript(ViewBase): Return all Javascript from the skin as a single string folder_name = 'js' content_type = 'application/x-javascript' @memoize def contents(self): skin_tool = getToolByName(self.context, 'portal_skins') layer = skin_tool.getDefaultSkin() skin = skin_tool.getSkinByName(layer) folder = getattr(skin, self.folder_name) obs = [(ob._filepath, ob.get_size()) for ob in folder.objectValues() if ob.meta_type == Filesystem File] fs = FilesIterator(obs) return fs def __call__(self): bundle = self.contents() self.request.response.setHeader(Content-Type, self.content_type) self.request.response.setHeader(Content-Length, bundle.size) data = bundle.next() while data: self.request.response.write(data) data = bundle.next() I did look at the file_iterator in ZPublisher.Iterators but I couldn't see a way to combine that with a list of files. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Accessing skins objects
Am 10.02.2009 um 14:36 schrieb Tres Seaver: You could try changing the view to call 'index_html' instead of '__str__', and see if that helps. If it does, then I think there must be a RAM cache in play somewhere. I actually reckon it's an anomaly down to my rather unscientific testing with wget. Using Apache's ab I get the following results for 100 requests with 10 concurrent: Using a PythonScript: Document Path: /kinopolis/css/styles.css Document Length:381936 bytes Concurrency Level: 10 Time taken for tests: 5.148 seconds Complete requests: 100 Failed requests:0 Write errors: 0 Total transferred: 38234100 bytes HTML transferred: 38193600 bytes Requests per second:19.43 [#/sec] (mean) Time per request: 514.787 [ms] (mean) Time per request: 51.479 [ms] (mean, across all concurrent requests) Transfer rate: 7253.10 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 1.6 0 15 Processing: 138 501 111.9493 813 Waiting: 125 459 106.6453 783 Total:139 501 112.0493 813 Percentage of the requests served within a certain time (ms) 50%493 66%548 75%572 80%600 90%644 95%716 98%724 99%813 100%813 (longest request) Using a BrowserView: Document Path: /kinopolis/kinopolis.css Document Length:238676 bytes Concurrency Level: 10 Time taken for tests: 2.346 seconds Complete requests: 100 Failed requests:99 (Connect: 0, Receive: 0, Length: 99, Exceptions: 0) Write errors: 0 Total transferred: 40933800 bytes HTML transferred: 40914700 bytes Requests per second:42.63 [#/sec] (mean) Time per request: 234.559 [ms] (mean) Time per request: 23.456 [ms] (mean, across all concurrent requests) Transfer rate: 17042.33 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 0.8 0 3 Processing:58 233 68.5229 386 Waiting: 14 39 29.9 32 181 Total: 58 233 68.7229 386 Percentage of the requests served within a certain time (ms) 50%229 66%259 75%281 80%294 90%318 95%363 98%378 99%386 100%386 (longest request) These figures tally in with the Profiler's results although I'm not quite sure where the difference in document length comes from. Thanks very much for the tip. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
[Zope-CMF] Accessing skins objects
Hi, I've written a very simple view for concactenating resources such as CSS or Javascript files to reduce the number of http browser requests: from Products.CMFCore.utils import getToolByName from Products.CMFDefault.browser.utils import memoize, ViewBase class Javascript(ViewBase): Return all Javascript from the skin as a single string folder_name = 'js' content_type = 'application/x-javascript' @memoize def contents(self): skin_tool = getToolByName(self.context, 'portal_skins') layer = skin_tool.getDefaultSkin() skin = skin_tool.getSkinByName(layer) folder = getattr(skin, self.folder_name) obs = [str(ob) for ob in folder.objectValues() if ob.meta_type == Filesystem File] return \n.join(obs) def __call__(self): data = self.contents() self.request.response.setHeader(Content-Type, self.content_type) self.request.response.setHeader(Content-Length, len(data)) self.request.response.write(data) While this works fine, it seems to run considerably slower (about half the speed) than a PythonScript that calls the relevant objects explicitly via getattr(context, id). I'm a bit surprised at this but suspect it may down to whether the file system is actually accessed or whether a persistent object is being called. In my browser view it is impossible to avoid reading in the file again as this happens the __str__ method of the FSFile object. In the hope of enlightenment. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Accessing skins objects
Am 09.02.2009 um 16:10 schrieb Tres Seaver: Try profiling the two requests and see what looks different. I thought someone might say that... ;-) As heavy upstream caching is likely to be used I hope it's not necessary to optimise this too much. The main advantage is reducing the number of individual requests made by the browser when it first sees the site. But I should get more familiar with profiling. Running locally wget gives rates of around about 50 MB/s with the view and around 120 MB/s for a PythonScript. The FSFile object *never* stores the bits read from the filesystem, so the more likely case is that your view is hitting some other bottleneck. oh, what FS things are affected by the debug-mode flag that forces them to be reread?, ie. which objects don't reflect underlying file- system changes? BTW, it might be faster to compute the *filenames* in the memo, and then return an IFilestreamIterator which chunked the response by reading the files one at a time. Running 'cat /path/to/fsidr/*.js' in an os.system() call might be faster, too ;) I quite like the iterator idea. BTW. Can I admit at this stage that I don't really understand what the memoize method does? 8-) Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Weird catalog behaviour
Am 01.02.2009 um 18:14 schrieb Raphael Ritz: You never called 'invokeFactory' in a debug session? ;-) (due to the explicit security check in the process this fails for anonymous) No, don't use invokeFactory in any of our stuff. Thanks to Yuppie, we've gone passed go and moved straight onto using createObject() - we sort of opt-in to bits of the CMF when we understand them! ;-) Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
[Zope-CMF] Weird catalog behaviour
Hi, is there any reason why a portal_catalog.searchResults() returns an empty result set when called on the command line but not from within ZMI? It is the same catalog and I can items to it but I just can't run a search on it. Any ideas? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Weird catalog behaviour
Am 28.01.2009 um 15:44 schrieb Andreas Jung: Command-line (zopectl debug?): you're anonymous ZMI: you're authenticated The catalog adds additional filters under the hood in order to filter out content you are not allowed to see. That could be the explanation - how can I authenticate myself in zopectl debug? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Weird catalog behaviour
Am 28.01.2009 um 15:54 schrieb Andreas Jung: from AccessControl.SecurityManagement import newSecurityManager user = app.acl_users.getUser(user_name_or_id) newSecurityManager(None, user.__of__(app.acl_users)) That does indeed solve the problem! Cheers Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] zc.formlib and content types
Am 26.01.2009 um 15:41 schrieb Miles: Hi, I've been playing with zc.formlib and five to create some simple content types - not exactly ahead of the curve, I know! I want to create a multipage wizard-type form. Each page shares a lot of logic, so at the moment I have one view class, and register different templates against it for the various changes. However, with formlib, I can't see how I'd do this. Is there a more elegant solution than just creating 3 separate forms? Hiya Miles, are you playing with formlib or zc3.form? Formlib lets you override templates pretty easily by redefining the template attribute for each view (please don't rely on the following paths!): class PageOne(CMFDefault.formlib.form.PageForm): class with most of the logic template = templates/first_template.pt class PageTwo(PageOne): logic stays the same but the template has to be different template = templates/second_template.pt class PageThree(PageOne): template = templates/second_template.pt NB. this assumes that your form templates share the same macro for rendering the actual widgets and should be used when you really need different templates. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Charsets
Am 25.01.2009 um 08:35 schrieb Dieter Maurer: Wow. Some magic in formlib deviating from the Zope2 standard behaviour Maybe. But then formlib is not really a standard Zope 2 approach. The one thing I do find weird is that PreferredCharsets() is called for each field in a form. But, if this is true, we do not understand Charlie's observations: When I understood him right, he is using formlib and he is observing problems with the charsets. He found out that this has to do with IE browsers sending an empty Accept-Charsets header which is turned by Zope's preferredCharset into iso-8859-1. But when the same charset is used on both form delivery and on form processing he should not see a problem with mismatched encodings. Actually the problems occur as soon as you use different browsers with non-ASCII text. Of course, iso-8859-1 may not be approriate for form delivery -- and may result in funny special characters in non-western countries. As Daniel noted UTF-8 should be default. I had a quick look at the source of the appropriate module and couldn't see where the broken magic was happening. It's probably a bit beyond me but is the first thing to write a test that we know currently breaks? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Charsets
Am 21.01.2009 um 00:11 schrieb Daniel Nouri: Is this thread by any chance related to this bug: https://bugs.launchpad.net/zope2/+bug/160968 The IUserPreferredCharsets implementation of Zope 3 found in zope.publisher.http.HTTPCharsets has the following condition in it to check if the HTTP_ACCEPT_CHARSET header is available: header_present = 'HTTP_ACCEPT_CHARSET' in self.request However, with Zope 2's request will return '' (the empty string) for any header that starts with 'HTTP_', see ZPublisher.HTTPRequest.HTTPRequest.get. Ultimately, this results in the HTTPCharsets.getPreferredCharsets to return ['iso-8859-1'], where it should really return 'UTF-8'. To understand this problem better, look at Products.Five.browser.decode.processInputs, which uses the negotiator to find out which charset to use to convert form variables. For browsers that do not send the 'HTTP_ACCEPT_CHARSET' header, this will result in wrongly encoded form values. To reproduce this, fill in Chinese characters to any Five formlib form with Internet Explorer 6.0. Since Firefox sends HTTP_ACCEPT_CHARSET, it's not a problem there. Yes Daniel, this is exactly the problem we're facing. So we need to fix Zope = 2.10 and then we shouldn't have to worry about doing anything to the CMF. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Charsets
Am 18.01.2009 um 23:00 schrieb yuppie: Hi Charlie! Hiya Yuppie, Charlie Clark wrote: Am 29.12.2008 um 15:01 schrieb Charlie Clark: CMFDefault.utils def getBrowserCharset(request): Get charset preferred by the browser. envadapter = IUserPreferredCharsets(request) charsets = envadapter.getPreferredCharsets() or ['utf-8'] return charsets[0] This will always be iso-8859-1 for Opera and Firefox because all charsets have the same quality, again even if UTF-8 encoding is specified. getBrowserCharset does almost the same as zope.publisher.http.getCharsetUsingRequest. And it is only used for encoding and decoding 'portal_status_message'. It is not relevant for the issue you noticed. Okay. I haven't been able to track where the decoding of form data occurs for Zope 2 stuff but I can identify the problem in zpublisher.browser.BrowserRequest You mean zope.publisher.browser.BrowserRequest. The Zope 2 version is in Products.Five.browser.decode. Thanks - I thought it must have been in Five but didn't know where to look. AFAICS the fallback to other charsets is usually not required in Zope 3. If the publisher encodes responses using zope.publisher.http.getCharsetUsingRequest, the first charset will be the right one. That seems reasonable. I would suggest that we work towards enforcing UTF-8 in where possible but at the very least add the accept-charset attribute to forms and use the portal's default_charset for this. I'd very much appreciate your comments on this. I can't see a need to implement this in a different way than Zope 3. So I propose to fix the encoding of forms sent to the browser. I agree that there shouldn't be implemented in a different way than for Zope 3. And if we can solve the problems by fixing form encoding I'm happy. Although I'd like to see UTF-8 always the first charset returned if * the quality is the same. One thing that did strike me when working on this is quite how often getPreferredCharsets() is called on single request. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Charsets
Am 19.01.2009 um 11:32 schrieb yuppie: zope.publisher.http.HTTPCharsets explicitly prefers utf-8. Are you sure getPreferredCharsets()[0] is iso-8859-1 with your browser? Or do you override somewhere the Content-Type header set by setPageEncoding()? AFAICS CMFDefault works exactly the way you expect it to. No, I don't override anything. I'll run some tests and post the results. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Charsets
Am 29.12.2008 um 15:01 schrieb Charlie Clark: The site should deliver all pages containing forms (if possible even all pages) with a single charset, let's call it the site charset. Then it uses this same charset to interpret form data. While I understand this, I'm a bit at a loss as to why this is happening. I'm using forms based on CMFDefault's formlib implementation. Charsets are set for the site and zpublisher but something else is probably missing. Delving deeper into this I think I understand things a little better. The accept-charset attribute on a form tag requires the browser to encode any form data in the specific encoding. Ideally this would make additional negotiation unnecessary but this value isn't passed to the server as the HTTP_ACCEPT_CHARSET which is where the fun starts. As has been noted previously, http://mail.zope.org/pipermail/zope3-dev/2004-June/011483.html , browsers don't all behave themselves when setting this header: IE 6 + 7 and Safari set an empty header whereas Opera and Firefox usually set something like iso-8859-1, utf-8, utf-16, *;q=0.1 getPreferredCharsets() will return 'iso-8859-1' where HTTP_ACCEPT_CHARSET is empty. But this will cause problems if the browser is actually using UTF-8. But the way the CMF uses getPreferredCharsets() is right either: CMFDefault.utils def getBrowserCharset(request): Get charset preferred by the browser. envadapter = IUserPreferredCharsets(request) charsets = envadapter.getPreferredCharsets() or ['utf-8'] return charsets[0] This will always be iso-8859-1 for Opera and Firefox because all charsets have the same quality, again even if UTF-8 encoding is specified. I haven't been able to track where the decoding of form data occurs for Zope 2 stuff but I can identify the problem in zpublisher.browser.BrowserRequest def _decode(self, text): Try to decode the text using one of the available charsets. if self.charsets is None: envadapter = IUserPreferredCharsets(self) self.charsets = envadapter.getPreferredCharsets() or ['utf-8'] for charset in self.charsets: try: text = unicode(text, charset) break except UnicodeError: pass return text Here the naive assumption is that we decode from a charset without an error then we have the correct charset. Sometimes this goes unnoticed but with characters like u2013 and u2014 (en-dash and em-dash) it will raise errors as those codepoints are not in the Latin-1 charset but it has it's own equivalents. I would suggest that we work towards enforcing UTF-8 in where possible but at the very least add the accept-charset attribute to forms and use the portal's default_charset for this. I'd very much appreciate your comments on this. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
[Zope-CMF] Running functional tests in a buildout environment
Hi, I've been struggling (and pestering Jens) with running the test on my formlib-based contents view for folders. It seems that CMFDefault/ browser/tests.py is being ignored when called from within the sandbox bin/test -vv -fs ~/CMF-Sandbox/cmf-trunk/src/Products.CMFDefault/ Products/CMFDefault/browser/ tests.py Running tests at level 1 Total: 0 tests, 0 failures, 0 errors in 0.000 seconds. whereas if I in an old-style instance I run bin/zopectl test -vv -fs Products/CMFDefault/browser/ tests.py I get bin/zopectl test -vv -fs Products/CMFDefault/browser /opt/Zope-2.11/lib/python/ZPublisher/Iterators.py:1: DeprecationWarning: The Interface package is deprecated and will be removed in Zope 2.12. Use zope.interface instead. from Interface import Interface Running tests via: /Library/Frameworks/Python.framework/Versions/2.4/ Resources/Python.app/Contents/MacOS/Python /opt/Zope-2.11/bin/test.py - v --config-file /Users/charlieclark/Sites/zurich/etc/zope.conf -vv -fs Products/CMFDefault/browser Parsing /Users/charlieclark/Sites/zurich/etc/zope.conf /opt/Zope-2.11/lib/python/ZPublisher/Iterators.py:1: DeprecationWarning: The Interface package is deprecated and will be removed in Zope 2.12. Use zope.interface instead. from Interface import Interface Running tests at level 1 Running Products.CMFDefault.testing.FunctionalLayer tests: Set up Testing.ZopeTestCase.layer.ZopeLite in 0.531 seconds. Set up Products.CMFCore.testing.FunctionalZCMLLayer in 3.233 seconds. Set up Products.CMFDefault.testing.FunctionalLayer in 1.853 seconds. Running: /Users/charlieclark/Sites/zurich/Products/CMFDefault/browser/ metadata.txt (1.528 s) /Users/charlieclark/Sites/zurich/Products/CMFDefault/browser/ document.txt (0.784 s) /Users/charlieclark/Sites/zurich/Products/CMFDefault/browser/ file.txt (0.610 s) Ran 16 tests with 0 failures and 0 errors in 2.923 seconds. Tearing down left over layers: Tear down Products.CMFDefault.testing.FunctionalLayer in 0.068 seconds. Tear down Products.CMFCore.testing.FunctionalZCMLLayer in 0.003 seconds. Tear down Testing.ZopeTestCase.layer.ZopeLite in 0.000 seconds. What am I doing wrong? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Running functional tests in a buildout environment
Am 12.01.2009 um 22:10 schrieb Jens Vagelpohl: If you are saying that you had both a tests folder and a module test.py in the same place then the answer is probably don't do that. I didn't but that is the current state of play in CMFDefault/browser. I've moved my test into the tests folder. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Cleaning up imports, question about odd feature
Am 29.12.2008 um 19:20 schrieb Tres Seaver: As Jens noted, this change is for FSProperties and FSSQLMethods only. Yep, and these aren't generally objects that need to be changed frequently in the FS. On another and only slightly related note: Tres, in September I seem to remember you saying that the biggest stumbling block for moving to Python 2.5 and beyond was support for RestrictedPython implements, ie. PythonScripts. If this is the case, do we need to add deprecating PythonScripts/untrusted code to the roadmap? I don't have that appetite at the CMF level: I think much of the work has actually been done to ensure that RP works under Python 2.5+ already at the Zope level. It's good to know that they will still work with Python 2.5. My own introduction to Zope was heavily dependent upon combining PythonScripts and PageTemplates and I'm currently seconded to a .NET based CMS which has something remarkably similar: they are a very useful way of encapsulating site-specific behaviour so it would be nice to have them around in one form or other if the associated issues (security, global validity, etc. can be resolved) otherwise some bright spark's bound to reinvent them! You are, of course, right that this wouldn't be a CMF only issue but I think that it's something we should be thinking of once we have a complete set of experimental browser views. looks appropriately guilty/ from AccessControl import ClassSecurityInfo becomes: from AccessControl.SecurityInfo import ClassSecurityInfo +1 I didn't realise this counts as a relative import but I'm all in favour of spelling things out. That one isn't relative: it is just another façade import. Façade imports are where classes and modules are populated through a package's __init__.py or module? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] CMFCatalogAware.dispatchToOpaqueItems madness
Am 19.12.2008 um 10:48 schrieb Matt Hamilton: Of course as soon as you find the problem, you then know how to ask the question... I think that sense of embarassment is an essential part of the solution! ;-) and in looking for opaqueitems, found that Helge has already got there and started waving some performance pixie dust over it: http://pypi.python.org/pypi/experimental.opaquespeedup Still... I don't quite understand why CMF is doing what it is doing in the first place. They are containers which won't be picked up by the normal methods. I agree that the current practice of checking every attribute could be a little expensive if you have lots of child objects stored in attributes. I think the solution is probably to see if the problem that they were introduced to address can't be solved in a different manner. The discussion a couple of weeks ago about CMFCatalogAware suggested that this class does indeed need refactoring for more predictable behaviour. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Charsets
Am 15.12.2008 um 21:01 schrieb Dieter Maurer: It is usually insane to use client preferences to guess the encoding used in form data. Have to agree with you there. Usually, the client will use the charset it has found in the page containing the form. Thus, unless this charset has been determined automatically from the Accept-Charset header, it is merely accidental when the client preferences (Accept-Charset) is able to guess the charset correctly. Right. So I must be doing something wrong if all Zope has to go on for decoding the form is the Accept-Charset? How can I set an encoding for the form? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Charsets
Am 13.12.2008 um 18:40 schrieb Charlie Clark: Hi, I'm struggling with the way formlib forms handle decoding from forms. It looks like this gets set in BrowserView using an IUserPreferredCharsets adapter. The default adapter seems to be in zope.publisher.http and it looks like latin-1 will be set if there is no other charset and I'm having problems with the em-dash and en-dash (u'\u2013' and u'\u2013') characters automatically being converted from latin-1 when they are being entered as cp1252. For content that doesn't through this decoding I have no problems if zpublisher- default- encoding is set to cp1252 and the default_charset is set to cp1252 as well: decoding with CMFDefault.utils.decode() works just fine. I suspect I'm missing something basic in the way charsets are handled but as it's a windows only IE6 environment, is the easiest solution writing an adapter that defaults to cp1252 if there is no HTTP_ACCEPT_CHARSET in the request header? Overriding the adapter works fine. I'm still a bit confused by the original code: # Quoting RFC 2616, $14.2: If no * is present in an Accept- Charset # field, then all character sets not explicitly mentioned get a # quality value of 0, except for ISO-8859-1, which gets a quality # value of 1 if not explicitly mentioned. # And quoting RFC 2616, $14.2: If no Accept-Charset header is # present, the default is that any character set is acceptable. if not sawstar and not sawiso88591 and header_present: charsets.append((1.0, 'iso-8859-1')) So if Accept-Charset is '' then Zope will set the browser charset to Latin-1. This seems a little strange to me as the default is UTF-8 if the header is missing. And if the RFC does say the default is any character set is possible then I would have thought UTF-8 would be okay. Is this a possible bug? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] GenericSetup 1.5
Am 11.12.2008 um 22:57 schrieb Tres Seaver: I certainly plan to review all the docs: ideally, we would have a combination of explanatory, tutorial, and reference docs. I might be able to help here. I am planning to spend some time between Christmas and New Year on my own tasks but would like to help improve documentation as well. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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 browser:page /
Am 12.12.2008 um 13:40 schrieb yuppie: 'browser:addform' and 'browser:editform' automatically generate forms based on a schema. The no longer supported 'browser:addview' directive was much closer to the directive Martin proposes. Since this registers an adapter that provides IBrowserPage, 'cmf:addpage' might be an alternative. I'd be happy with either cmf:addview or cmf:addpage. There's no way around the somewhat counterintuitive fact that the views are registered for the containing object type but as long as this is explained somewhere then anyone working with this should be okay. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
[Zope-CMF] Charsets
Hi, I'm struggling with the way formlib forms handle decoding from forms. It looks like this gets set in BrowserView using an IUserPreferredCharsets adapter. The default adapter seems to be in zope.publisher.http and it looks like latin-1 will be set if there is no other charset and I'm having problems with the em-dash and en-dash (u'\u2013' and u'\u2013') characters automatically being converted from latin-1 when they are being entered as cp1252. For content that doesn't through this decoding I have no problems if zpublisher-default- encoding is set to cp1252 and the default_charset is set to cp1252 as well: decoding with CMFDefault.utils.decode() works just fine. I suspect I'm missing something basic in the way charsets are handled but as it's a windows only IE6 environment, is the easiest solution writing an adapter that defaults to cp1252 if there is no HTTP_ACCEPT_CHARSET in the request header? Thanks for any pointers. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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 browser:page /
Am 09.12.2008 um 14:34 schrieb Martin Aspeli: Meh - of course, I meant: cmf:addview name=my.type for=Products.CMFCore.interfaces.IFolderish fti=..interfaces.IDexterityFTI class=.add.DefaultAddView permission=cmf.AddPortalContent / Hiya, I agree that many people do not understand immediately that Views are Adapters. This is partly conceptual but also related to conventions in ZCML and elsewhere: it's very natural in English to contract view adapters to views and subscriber adapters to subscribers, etc. which is why we get ZCML-directives like subscriber and browser. I think it is correct to encourage developers to move to the ZCML approach for configuring security and as the new add views are CMF specific using a special CMF directive would make this clearer. A separate but related issue might be how we deal with CMFDefault: you seem to refer to it in much the same way I do as the basis for more work as it provides so much useful functionality out of the box but Jens, Tres and others never tire of pointing out that it is actually only a demonstration of what's possible. Should we think of breaking the formlib stuff out of CMFDefault? So that it can be used without CMFDefault? I don't know whether it should move to its own package or CMFCore. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] adding 'context' as an alias for 'object' in action expressions
Am 01.12.2008 um 16:49 schrieb Tres Seaver:
'context' is the canonical name for the object through which a
script or
templated was acquired (its aq_parent, in fact); 'here' is a
long-deprecated alias for 'context'. 'context' is like the 'self'
binding of a normal Python method.
Action expressions aren't scripts / templates, and don't have many of
the stock names ('context', 'container', 'template', 'script',
'traverse_subpath', 'namespace', 'subpath', 'options', 'modules',
'root') which scripts and templates offer; instead, they offer names
which are useful in writing action URLs (e.g., 'object_url',
'folder_url', 'portal', 'user_id', etc.) Their 'self' / 'context'
would
logically be the ActionInformation object, rather than the target
for
which the URL / condition is being computed.
And the proposal was to change the expression context for actions.
What
about CachingPolicyManager and DCWorkflow?
Exactly.
- -1 to the change from me. Writing TALES expressions involves
knowing
what the appropriate set of names are for the given usage.
Tres,
thanks very much for the explanation. I've probably missed it but my
experience has been that Actions and Workflow are the most difficult
parts of the CMF to work with because they don't conform entirely to
the way PythonScripts or PageTemplates behave but I think this is
largely down to a lack of user/developer documentation on what they
are and how to use them. I recently encountered the problem that user
defined action categories will be ignored by ListFilteredActionsFor().
Improving the documentation here would probably be the best solution.
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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] [dev] Should portal_setup be registered as utility?
Am 20.11.2008 um 12:42 schrieb yuppie: Several tool methods have to be replaced by view code before we can register all tools as utilities. It's already on my radar as soon as I get some time to catch my breath (and complete my two other minor tasks first!) In view of this, one can understand that Plone has problems with the setup_tool utility registration. The setup tool is responsible for managing configuration data. I can't see a need to care about the request in that context. Agreed. If third party tools have problems, then they should provide the solutions. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] [dev] Should portal_setup be registered as utility?
Am 16.11.2008 um 16:17 schrieb yuppie: Questions: Is there a good reason why Plone doesn't register portal_setup as utility? Does the same reason apply to CMFDefault? Do we have to support registered and not registered portal_setup tools? Does this relate to the discussions (earlier this year? last year?) on which tools should be moved to utilities? I fully support Jens' justification of the utility approach. Things are a bit weird at the moment with some things still being tools and others utilities but once I got used to the utility approach I found it saner. I don't think that we can support both approaches and if Plone needs a wrapper around the utility with access to the request object then surely that is something for Plone? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] [dev] Should portal_setup be registered as utility?
Am 16.11.2008 um 22:30 schrieb Wichert Akkerman: Imho registering portal_setup as a utility as long as any CMF tool uses self.REQUEST is problematic since it makes it impossible for import/export steps to use such tools. Surely, that's what deprecation messages are for? We do want to move to utilites. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Missing Event Handler for CMFCatalogAware
Am 29.10.2008 um 16:53 schrieb yuppie: I don't think so. OFS.interfaces.IObjectWillBeRemovedEvent is derived from OFS.interfaces.IObjectWillBeMovedEvent. So these lines in handleContentishEvent() should unindex the object: elif IObjectWillBeMovedEvent.providedBy(event): if event.oldParent is not None: ob.unindexObject() You are, of course, right and there is a test which tests just this feature. Digging around I've realised that this is because I have folderish objects which inherit from PortalFolder which explicitly deactivates the ICMFCatalogAware methods. Is there any point in implementing ICMFCatalogAware or IWorkflowAware for Folders? What would we break if we removed the dependency? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Missing Event Handler for CMFCatalogAware
Am 11.11.2008 um 16:52 schrieb yuppie: AFAICT PortalFolder inherits from CMFCatalogAware to make sure it has the same manage_afterAdd, manage_afterClone and manage_beforeDelete methods as other content classes. But these methods are gone, so I guess the dependency is no longer needed. You didn't hear it from me but this is surely abuse of inheritance? Time to call the cops and stand outside our houses in dressing gowns and slippers tutting and looking superior! There might be some code that expects that *all* content classes implement ICatalogAware, IWorkflowAware and IOpaqueItemManager, but if we add deprecation warnings the other code can be cleaned up. +1 It's not as if Folder's behave as content although it is perfectly reasonable in my view for Folderish objects to do so. In the long run I'd like to get rid of CMFCatalogAware completely. Its functionality should be moved to adapters and event subscribers. Indeed. And IWorkflowAware should be implemented separately where required, he added quietly still working his way through Workflow code. I've written an almost generic Transition form for IWorkflowAware objects (the workflow should be pumped through the form). Any interest? Currently dependent upon adding ?form.workflow_action=xyz to the transition action which reminds me of add forms and suggests the whole thing probably needs, ahem, revitalising. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
[Zope-CMF] Missing Event Handler for CMFCatalogAware
Hi, I noticed in an object derived from CMFCatalogAware that it wasn't being removed from the catalogue upon deletion. Looking at the event handlers in CMFCatalogAware it's clear that nothing handles IObjectWillBeRemovedEvent. Is this intentional or mereley an oversight? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] MembershipTool: Using traversal to look up the Members folder?
Am 08.10.2008 um 14:57 schrieb Jens Vagelpohl: Please keep in mind the true nature of CMFDefault: It's a sample application of the framework laid down in CMFCore. True but an eminently usable one. So IMHO _if_ this kind of configurable members folder location feature is added, it should be in CMFCore and thus available to CMFDefault. Very true. As far as the feature itself is concerned, I've never seen a situation where this is useful or needed. So my vote as far as the CMF is concerned is +-0 because it's a YAGNI feature, You Ain't Going to Need It. I'd say the correct place would be a custom membership tool for your specific application that needs to support this use case. +1 for ± 0 ;-) Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Pure CSS for main template
Am 06.10.2008 um 02:00 schrieb Jens Vagelpohl: Please make sure you stick to one functionality/change per branch to make it easier for others to make a diff and understand all the changes. I thought you wanted to use the branch for the folder_contents work only ;-) oops, sorry! It's just I'd been planning to work on this for about a year and yesterday was a good time to start. Should I create a separate branch just for this? The idea is not to do a redesign but to implement the existing one using CSS now that pretty much all of the browsers in use have at least adequate support. Customers will hopefully still want to have a different design but it should be easier to do. CMFDefault represents a simple sample application for the CMF. It doesn't have to be pretty by itself, but any changes should have these goals: - make it easier for people to customize the look-and-feel using CSS only, or... - make it easier to take the current main_template as a guideline for a new main_template by making it as simple and understandable as possible. I hope to achieve both of those. I'm using an em based elastic approach where the layout will grow with the chosen text size. I know that most browsers have now caught up with Opera and offer proper zooming but there are still lots of IE6 installs out there. I'm working on a baseline of 1024 x 768. Does anyone have objections to this? I'd be opposed to any template that uses fixed widths and which does not degrade gracefully with less or more width. hm, the current layout is fixed-width. The new one is not per se fixed- width is driven by the size of the font that a user has. The argument about growing and shrinking gracefully is important but it is also important to maintain usability and particularly readability: having a site expand to fit 100% can mean either extremely long lines or ugly gaps between columns or conversely columns with line-breaks every word. The following article covers the main issues concisely: http://www.htmldog.com/articles/elasticdesign/ What I am to do is to maintain the current design but make it much easier to adapt through CSS, ie. swap between font-size based and percentages. So good documentation of how the layout works is essential. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] portal_fiveactions
Am 04.10.2008 um 16:34 schrieb Jens Vagelpohl: Is anyone actually using the portal_fiveactions tool and the supposed bridging between Z3 menus and CMF actions it is promising? I'm wondering if it's dead wood we're carrying around since it really has not been touched much after the initial import: Not that I'm aware of. Weird doc string in there. Wouldn't mind being able to use Z3 menus but I don't know whether that won't be possible anyway. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] [dev] add view traversal
Am 14.09.2008 um 12:26 schrieb yuppie: This mail has been lying around for a while because I'm not sure it's the right way to start the discussion. But now I'll give it a try. Maybe the sprinters find some time to discuss this: I had to leave yesterday evening... it would have been great if we'd have been able to arrange a CMF sprint in advance even if meant just discussing these kind of things. One result of the Add forms and menus[1] thread was that we'd like to get add views by portal type name. Some custom traversal should look up and return the right view for the specified portal type. I'm currently trying to figure out how to implement that correctly and am struggling with some details: 1.) What should URLs look like? --- Here are same possible URLs for adding a Message to a guest book: http://www.example.org/guestbook/+Message http://www.example.org/guestbook/@@+Message http://www.example.org/guestbook/addMessage.html http://www.example.org/guestbook/+/Message http://www.example.org/guestbook/@@+/Message http://www.example.org/guestbook/+/addMessage.html http://www.example.org/guestbook/+cmf/Message http://www.example.org/guestbook/@@+cmf/Message http://www.example.org/guestbook/+cmf/addMessage.html http://www.example.org/guestbook/add/Message http://www.example.org/guestbook/@@add/Message http://www.example.org/guestbook/add/addMessage.html 2.) Which hook should be used for custom traversal? --- a) for URLs like http://www.example.org/guestbook/+Message In this case we use a special prefix '+' followed by the portal type name. CMF containers don't implement IPublishTraverse, so we can register an IPublishTraverse adapter. If we don't find an add view, we can fall back to DefaultPublishTraverse behavior. Unfortunately the IPublishTraverse hook only works with one adapter. If other packages like plone.app.imaging[2] try to use the same hook, we get a problem. b) for URLs like http://www.example.org/guestbook/+/Message The '+' view already implements IPublishTraverse, so we can't change traversal using an adapter. The only solution I can see is to replace the '+' view by a customized version. c) for URLs like http://www.example.org/guestbook/add/Message If we use our own adding view, we can implement IPublishTraverse inside the view or as adapter. I could live with either b) or c). I guess we need to weigh up the desirability of being as close to Zope 3 style without unwanted side effects. c) would to be the cleanest implementation. Would it be possible to implement b) as a sort of alias for this if desired? 3.) For which context should we register the add views? --- The add views will depend on special portal type handling done by the traverser. So we register the add views for traverser? Or should all views have a default portal type that is used if we access add views directly? In that case we would register the add view for the container. I guess the circle we're trying to square here would be what's the best way to be able to add objects to a particular container. Our particular experience has been to rely on the need to register views for a particular container object but, of course, you still need type information. As the type information (allowed content types for a container object) is always required it probably makes sense to use this rather than an implicit allowability through a registered view. I think this means +1 for registering for the traverser. plone.dexterity[3] uses an @@add-dexterity-content traverser, but I don't think product names like dexterity or cmf should be visible in URLs. Those are implementation details that should be transparent for users. Absolutely. We've found the add forms to be extremely useful but the dependence on knowing the name of the view is a pain even if you can enforce a naming convention. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Formlib based view of folder contents
Am 13.09.2008 um 16:49 schrieb yuppie: I never used it. But one major function of CMFDefault is to showcase CMF features. And I'm not aware of any other code that demonstrates how to use filtering. Good point. If so is it okay to drop the use of the cookie and either use hidden variables as the sorting options do already or possibly dump this information in the session? One of the problems with the current implementation is that the cookie is hard-coded to live until 2020 and will persist from one folder to the next but it's debatable whether the filters you want for one folder you would want for another but not the sort options. Our preference would be to put the filter information in hidden variables. I don't think CMFDefault should rely on sessions. Using hidden variables sounds fine to me. This was our consensus yesterday. I hope it's possible to unpick the folder_filter_form.pt Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] [dev] add view traversal
Am 14.09.2008 um 13:30 schrieb Martin Aspeli: Zope 3 does use IAdding for zope.app.form/zope.formlib based add views; With z3c.form, IAdding support is optional, but the preference is to just use views like @@add-foo.html (note: I hate the .html convention; it is superfluous and looks weird, IMHO). I used to think this but then I thought about the possibility of any non-Zope upstream handling such as caching which might be very grateful for this kind of convention. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
[Zope-CMF] Formlib based view of folder contents
Hi, currently sitting with Tres and Jens in Saarbrücken working on a formlib based view of folder_contents and we're hitting some stuff that's been around for ages but might possibly no longer be required. An example of this is the Contents View Filter. Does anybody actually use this? If so is it okay to drop the use of the cookie and either use hidden variables as the sorting options do already or possibly dump this information in the session? One of the problems with the current implementation is that the cookie is hard-coded to live until 2020 and will persist from one folder to the next but it's debatable whether the filters you want for one folder you would want for another but not the sort options. Our preference would be to put the filter information in hidden variables. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] [dev] more add menu changes
Am 12.09.2008 um 10:56 schrieb yuppie:
I doubt that works: 'context' and expression context are not the same.
It does 'cos it came from my working demo.
I can't think of any other way to do this other than to call this
expression before returning it to the template. But it's more than
possible I've overlooked something.
Why do you want to bypass the actions machinery?
Because I was too stupid to realise I could use it!
Something like that should work in main_template:
tal:define=add_forms python: actions.get('folder/add', {});
Indeed it does. Thank you very much.
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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] [dev] more add menu changes
Am 07.08.2008 um 12:26 schrieb yuppie:
Proposal 2: main_template
-
CMFDefault menus are implemented in main_template. I propose to add
a new section for 'folder/add' actions.
Hi yuppie,
finally had a bit of time to look at this. First of all thank you very
much for your work on this. It's a great pity your not here at the
DZUG conference to discuss.
I have an extremely basic implementation of this for the CMF:
from Products.CMFCore.utils import getToolByName
tt = getToolByName(context, 'portal_types')
ti = tt.getTypeInfo(context)
poss_types = ti.allowed_content_types
add_forms = []
for t in poss_types:
# get type info for child
nti = tt.getTypeInfo(t)
if nti.add_view_expr != '':
url = nti.add_view_expr_object
add_forms.append({'title':nti.title, 'url':url(context)})
return add_forms
I can't think of any other way to do this other than to call this
expression before returning it to the template. But it's more than
possible I've overlooked something.
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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] [dev] more add menu changes
Am 07.08.2008 um 19:21 schrieb Martin Aspeli: Ah In Plone, folder_factories is a list of addable types. You click Add next to each one and it's created with a temporary ID. Then you save it, and it's renamed to a better ID, usually. Add forms are much nicer than that. Objects are only created if the add form is correctly completed. I haven't looked at yuppie's latest implementation but the use of INameChooser for default id's is very usable - in many context management situations auto-generated id's are preferable although Plone's are a bit verbose. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] type infos and 'add' actions - a proposal
Am 21.07.2008 um 12:51 schrieb yuppie: So instead of adding separate 'add' actions we can extend the type info classes, making them implement IAction as well. listActions of the types tool would include type infos if they provide IAction *and* have an url specified. As always, feedback is welcome. +1 an excellent suggestion! Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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: Add forms and menus
Am 17.07.2008 um 12:41 schrieb Laurence Rowe: I'd be interested to hear what you are using this for (other than to redirect to the default view of the newly created object). Not a lot if the truth be told apart from the fact that sometimes you might want to go to the metadata form, other times to an edit form and others straight to a public view. This is the code in CMFDefault.formlib.form def nextURL(self): obj = self._added_obj fti = obj.getTypeInfo() message = translate(self.status, self.context) if isinstance(message, unicode): message = message.encode(self._getBrowserCharset()) return '%s/%s?%s' % (obj.absolute_url(), fti.immediate_view, make_query(portal_status_message=message)) I hope I'm not confusing initial and immediate views! Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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: Add forms and menus
Am 16.07.2008 um 17:24 schrieb Martin Aspeli: I think it's a fairly big shift to assume that the FTI has knowledge of the schema of the type. It's not necessarily a *bad* idea (at least I don't think so, since this is basically how Dexterity works :-), but right now, FTI doesn't have any notion of a schema. With this change, you're effectively dictating (or strongly suggesting) that all CMF types have a schema and that this is the basis for forms, and suggesting that forms aren't registered as independent views but rather inferred from this schema. Indeed. It is reasonable to expect a subclass to provide a set of FormFields but this is not the same as a schema. We have found being able to handle portal_type and schema or fields ie. an instance FormFields() in the super class to avoid repeated use of the somewhat cumbersome FormFields(TextLine(__name__...)) code. we discuss the generic adding approach, we further discuss what has to be considered to be generic. I'm just not sure that generic is so good. If it's easy to make add- and edit- views (probably with convenience classes for CMFish container adding behavior) and obvious how to register them, then do you need more framework? At least not in CMFCore. Explicit is always better than implicit. This stuff really isn't a lot of work but it provides clarity and helps people understand what's going on and I think this is essential for any framework. Less magic is more power. ;-) Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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: Add forms and menus
Am 17.07.2008 um 13:12 schrieb Robert Niederreiter: class Addform(AddformBase) fields = form.Fields(ISchema) and registering it then like: browser:page for=* name=myfactoryname class=.foo.Addform allowed_interface=Procucts.CMFCore.browser.interfaces.ICMFAddForm permission=add.whatever / ..does not give the newbee more clue on whats going on than write it not at all. With respect, I disagree but there are newbies and newbies and YMMV. Our experience on my current project has been that the configuration directives are extremely helpful: our developers have very little Python or Zope experience but they are all programmers. It hasn't removed typo's and copy and paste errors but it has more than once proved invaluable when tracking down errors. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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: Add forms and menus
Am 15.07.2008 um 23:38 schrieb Martin Aspeli: Actually, that's interesting... what purpose does 'initial view' serve in a world with add forms? The same as it ever has - you redirect to the initial view from the add form because the add form is actually registered for the container (IFolderish object) and the initial view is called because the object itself hasn't been used. Should we re-purpose this slightly to make it provide the add form view URL? No, I think it has to be a separate property. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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: Add forms and menus
Am 14.07.2008 um 12:37 schrieb yuppie: Add links are just special 'actions', they should be integrated with CMF's action machinery. Based on the information in the type infos we should be able to create normal IActionInfo objects. (IActionInfo defines the non-persistent wrapper around actions, today we would use adapters to implement this.) If we don't want to use a convention, we need a new property. And if we want to be flexible enough to add the portal type name to the query, a TALES expression for the URL wouldn't be overkill. Works for me - would this be something like the initial view for types? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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: Add forms and menus
Am 14.07.2008 um 12:17 schrieb yuppie: CMF 2.1 was released with some formlib based edit forms. I don't think it was a mistake, because at that time z3c.form wasn't available in the Zope 2 world. It certainly wasn't a mistake in fact I think it was great. To me it seems reasonable at least to try and complete a set of browser views using zope.formlib for CMF 2.2. We're already using zope.formlib in the experimental browser views edit forms. The reference to a sinking ship is totally off- target. My own view is that sometimes it is better to wait for version 2 of a product or library to be released before adoption. Surely Plone has suffered from adopting some stuff too early? *shrug* Do what you please. I'm not particularly wedded to one or the other. But having used both, I'm pretty sure that z3c.form is a better library. In many ways, z3c.form *is* version 2 of formlib. Exactly. z3c.form is a new version of zope.formlib that doesn't care about backwards compatibility. All development is done in z3c.form. Using the picture of a sinking ship: At least the crew has already abandoned the formlib ship. And without crew it will sink sooner or later. I really don't think the ship metaphor is appropriate - software tends to be around for a lot longer than you expect (hasn't MS only just stopped support for Window 3.11?) but that is probably irrelevant. The questions are probably: do we have any problems with zope.formlib that we know will be solved by using z3c.form? what is the overhead of migrating between the two? So far I'm just really a consumer of the formlib integration in the CMF. I had a brief look at the z3c.form stuff last night and it didn't seem to be radically different from formlib so that a migration shouldn't be too much work. But perhaps for precisely the same reason there is less of a need to migrate. It would certainly be advantageous to have both five.formlib and five.form and it's great that we can expect to have a common basis for the CMF and Plone. It was always a goal of CMF to minimize dependencies. But Zope became less monolithic, so we have to define the Zope dependency ourselves. It's no longer just the Zope 2 distribution, we have to use separately shipped packages like five.localsitemanager as well. And z3c.form is *the* current Zope package for creating forms. You've hit on an important point: Zope 2.10 and Zope 2.11 both ship with zope.formlib but things like sitemanager are changing the game and will require more package support so why not bite the bullet? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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: Add forms and menus
Am 13.07.2008 um 14:08 schrieb Martin Aspeli:
Thanks for restarting the discussion and thanks to Yuppie for his
implementation. We've been using it with the changes I outlined the
other week to good effect for the last couple of months.
Bah, I hate these discussions. I'm sure Daniel Nouri would be happy
to relicense. Re-invention for the sake of a license is just too dumb.
I think we all hate such discussions but that's the way it is when
derivative code gets given a different licence.
I'd prefer to keep the name to avoid breaking existing packages,
though.
Another option is to factor out a few things to a five.z3cform and
have plone.z3cform import from it as appropriate.
This is probably necessary anyway. I'm not sure whether it's right to
try and go straight to z3c.form. My understanding is that there isn't
a great deal of difference between the two libraries so hopefully an
implementation could live with both. I don't think that everyone has
moved onto z3c.form - certainly that wasn't my impression at
Europython. It would be nice to have a formlib based CMF 2.2 and I
think I now understand most of this well enough to contribut. We could
possibly onto z3c.form in 2.3 which might have replaced zope.formlib
in Zope by then.
In any case, I'd like to know why you went down the portal_actions
route for rendering the add links. I'm not quite sure I like the
idea of having this be persistent configuration, separate to the
FTI, as the two would need to be kept in sync, and in sync with
the view name registered in ZCML.
CMF makes a distinction between portal types and content types.
Portal types are persistent wrappers around the non-persistent
content types. You can define many different portal types based on
one content type.
Right.
In CMF you add *portal type* instances, so the 'add' links should
be persistent as well. The non-persistent add form has to take the
portal type name as argument to create the correct portal type.
I'm not sure what the right solution is, but I guess extending the
type info classes will be the best approach.
Also, why not try to use the Zope 3 menu concept? There's even a
special add menu directive.
Moving away from persistent actions is not on my todo list. And as
I tried to explain above, the current portal type concept depends
on persistent actions.
Right, I see that. But having things in two places is obviously not
very desirable either.
I'd quite like to find a good approach here that can be used by
both Plone and plain CMF, if possible.
I hope you find one ;)
How about we use a naming convention that's linked to the factory
that's persisted in the FTI, i.e. we look for a view called add-
factory_name and link to that if it's available.
You might as well stick with actions if you're going to do that. I've
been experimenting with the following
portal_type = self.request.form.get('portal_type')
at = getToolByName(self.context, 'portal_actions')
actions = at.listFilteredActionsFor(self.context)
addable = actions.get('add', [])
for a in addable:
if a['id'] == portal_type:
return request.response(%s/%s (%self.context.absolute_url(),
a['url']))
It's workable but so easy to break as it relies on add actions
having the same name as the portal_type. It makes much more sense to
me to have this on the type info: if I ask the type tool for the
factory, surely I can also ask it for the view?
The idea is that the factory name is unique and specific to the
content type. Different portal types that use the same factory would
almost by necessity have the same add view.
We could make this overrideable as well, with another FTI property.
The assumption here is that the add menu is rendered with some
custom code, i.e. it doesn't use the actions machinery or the Zope 3
browser menu concept.
Yes, I think that has to be the case.
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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: Add forms and menus
Am 13.07.2008 um 20:21 schrieb Martin Aspeli:
I doubt that formlib will be replaced by z3c.form. Rather, it just
seems that everyone prefers to work with the latter and so the
former is becoming less relevant.
I wonder who everyone is? When I asked Maartijn Faassen as
Europython he didn't seem to be in a hurry to migrate Grok to using
z3c.form and his work on Formulator was possibly the start of a Zope
forms library of which formlib and z3c.form are the nth and n+1th
generations.
They are definitely different, and don't share any code as far as I
know, but if you know one, moving to the other is pretty trivial.
z3c.form also has good (if a bit too abundant) documentation.
I've only briefly looked at z3c.form but it seems to make abundant
reference to how zope.formlib works.
Thus, if CMF hasn't yet picked a form library in a release, then you
could try to learn from Plone's mistakes and not jump on a sinking
ship. :)
We're already using zope.formlib in the experimental browser views
edit forms. The reference to a sinking ship is totally off-target. My
own view is that sometimes it is better to wait for version 2 of a
product or library to be released before adoption. Surely Plone has
suffered from adopting some stuff too early?
How about we use a naming convention that's linked to the factory
that's persisted in the FTI, i.e. we look for a view called add-
factory_name and link to that if it's available.
You might as well stick with actions if you're going to do that.
I've been experimenting with the following
portal_type = self.request.form.get('portal_type')
at = getToolByName(self.context, 'portal_actions')
actions = at.listFilteredActionsFor(self.context)
addable = actions.get('add', [])
for a in addable:
if a['id'] == portal_type:
return request.response(%s/%s (%self.context.absolute_url(),
a['url']))
It's workable but so easy to break as it relies on add actions
having the same name as the portal_type. It makes much more sense
to me to have this on the type info: if I ask the type tool for
the factory, surely I can also ask it for the view?
You mean we have an action on the FTI object with category 'add' and
name == FTI name/portal_type? That still means having to get that
link right, though (a typo in the FTI name or a rename of the FTI
makes it break), and I question whether you ever need all the other
info that actions provide. We already have ways to control add
permissions and other filters for what's addable where.
Yes, which is why I don't favour this approach: it can work but is
likely to cause problems.
What we all want is to be able to get the add view for a particular
portal_type but we can't do this through QueryMultiAdapter because the
view has to be registered on a container. Actions are unsuitable but
provided Yuppie with a bootstrap to test the whole procedure and
highlight the deficiencies. I'm afraid I don't understand the
internals too well but isn't something like cmf:registerAddView ...
or what we're after until the Zope 3 world comes up with the right
way to do this?
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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] Catalog aware folders
Hi, just noticed something a bit weird: got my own Folderish object that a minimally customised PortalFolder but it's important that it's in the catalog. Although PortalFolderBase already inherits from CMFCatalogAware I've had to explicitly inherit again from CMFCatalogAware in my class. ie. I have the following hierarchy. class PortalFolderBase(DynamicType, CMFCatalogAware, Folder): Base class for portal folder. class PortalFolder(OrderSupport, PortalFolderBase): Implements portal content management, but not UI details. class CatalogFolder(CMFCatalogAware, PortalFolder): Folder that will appear in the catalog I've just checked some of my other sites and folders are not catalogued. Is this a bug? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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: Formlib implementation for folder contents
Am 25.06.2008 um 10:05 schrieb Charlie Clark: Am 25.06.2008 um 04:10 schrieb Dylan Jay: Have you thought about making contents a widget rather than a form? Then it would be easy combine with other forms on folderish items. No, I hadn't. But I will now. Okay, I did some thinking about this and while it will probably work for the folder_contents view doesn't this mean there can only be one field in the widget? This would be fine for a 1:1 implementation of the current view but I thought it would be nice to be able to edit subobjects id's in situ, ie. checkbox plus textfield which I think is a little more complex. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] newstyle content creation
Am 13.05.2008 um 23:39 schrieb yuppie: If a new style factory is specified in the FTI a view of that name is looked up on the adding view of the container. This is from plone.app.contentmenu.menu.FactoriesSubMenuItem: addingview = queryMultiAdapter((addContext, self.request), name='+') if addingview is not None: addview = queryMultiAdapter((addingview, self.request), name=fti.factory) if addview is not None: return '%s/+/%s' % (baseUrl, fti.factory,) That means view name and factory name have to be the same. The portal type is not passed to the view, so it has to be hardcoded inside the view. Not very flexible, but if factory and view are only used for one hardcoded portal type it works. Any more thoughts on this? I agree with you that the hardcoded approach above isn't nice but can't think of a nice way to square the circle where the add forms are registered for the container and not the new object. Is it possible to do something with actions? Either by defining an additional category such as add on the objects themselves? That would be easy enough from the object's perspective but would conflict with the current lookup on the folder category. This shouldn't be too bad as this could be replaced by looking at the allowed_content_types. But I guess this might have the same complexity and performance problems as relying on IAdding. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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: Why do we need types.xml and workflows.xml?
Am 29.06.2008 um 15:04 schrieb yuppie: Some tools are ordered containers, the types tool might become ordered as well. GS always specifies the order of sub-objects in the container's file. I suppose you could bundle all the information into a single types.xml file - like you can with skins but that then makes manual changes a bit trickier - if they are ever required. I find the current system where the file system mirrors the ZMI structure pretty helpful and I'd actually like to see it extended for things like the catalog indices. The biggest problem we have with this is when editing in the ZMI, exporting the XML and putting the XML files in the right folders: you get information from all the profiles in which case it's easy just to work with the individual type and update types.xml manually. Not sure how ordering fits in with this multiple profile setup but it would be pretty fiddly implementing it on a per file basis. Right now we have a relatively easy rule: Adding, moving or removing sub-objects modifies the container, so these changes *always* have to be specified explicitly in the container's file. 'id' and 'meta_type' in the per-item files are not really used. Would it be an improvement to remove that redundant information from the per-item files? I didn't realise they were both redundant! I would only remove them if they are also removed from the ZMI. Worse, it's easy to forget, and no warning that there are orphan files. Adding a warning might be an other solution. This would be a welcome addition to GS in general. I know I'm not the only who's been bitten by the fact that ZCML will complain bitterly about missing stuff which GS is happy to ignore. It doesn't matter that the only thing the two have in common is that they're XML. When developing new content types you add you package in zcml and type definition in GS. It would be nice if a type definition was expected but missing that this was raised. This would work with either approach. I'm pretty sure it's an easy fix to make types.xml and workflows.xml optional (or even deprecated, though of course workflows.xml also has bind information that should remain there). All the information required for adding, moving or removing sub- objects is currently stored in the container's file. Additional code and complexity is necessary to extract that information from per- item files. Avoiding complexity is always a good argument! Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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: Formlib implementation for folder contents
Am 25.06.2008 um 04:10 schrieb Dylan Jay: Have you thought about making contents a widget rather than a form? Then it would be easy combine with other forms on folderish items. No, I hadn't. But I will now. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] newstyle content creation
Am 02.05.2008 um 13:50 schrieb yuppie: Did some more refactoring. If your factory can handle all the input, ContentAddFormBase's 'create' method should be sufficient. If not, you need a 'create' method like the one in FileAddView. Done quite a lot of Add Forms based on your work and we ended up extended the base view to implement form_fields and require the sub classes to provide the portal_type and the schema or list of fields. @property def form_fields(self): fields = form.FormFields( TextLine( __name__='portal_type', default=self.portal_type) ) # allow sub-classes to pass in sequences of schema if isinstance(list, self.schema): for s in self.schema: fields += form.FormFields(s) else: fields += form.FormFields(self.schema) return fields I'm not sure if it's overkill to be able to handle a list of fields but we've found it makes views a lot easier to work with. What do you think? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Formlib implementation for folder contents
Hi, now that I've had a couple of months practice with browser views in general and formlib in particular and also because I've got a particular itch to scratch I've started on a formlib version of folder_contents and I've now got a skeleton version of the form. Well, I've got the form at least! What I've done so far: * a view based on EditForm (haven't quite mastered redirects in PageForm) but not using setUpEditWidgets - I pass the field values in as 'data'. Fields are distinguished from each other using the prefix argument field = form.FormField(f, n, item.id) # using an interface self.form_fields += form.FormFields(field) * turned the buttons into actions - probably the easiest part :-) * generate fields (Boolean for the checkboxes) * use a custom template to iterate through the folder items and call the appropriate widgets. Although this works it's a bit clumsy. This is the rather stripped-down HTML and I'm anticipating renaming on the form. form class=form action=. method=post enctype=multipart/form- data tal:attributes=action request/ACTUAL_URL table tr thSelect/th thName/th thLast Modified/th thPosition/th /tr tr tal:repeat=item context/contentValues td tal:content=structure python: view.widgets['%s.select' %item.id]()Checkbox/td td tal:content=structure python: view.widgets['%s.name' %item.id]()/td td tal:content=item/ModificationDate/td td tal:content=repeat/item/number/td /tr /table div class=buttons tal:loop tal:repeat=action view/actions tal:replace=structure action/render / /div /form While I can probably tidy this up to use a method in the view I'm not convinced it's entirely the right way to do this. But it works! I'll continue working - the actions themselves should be most straightforward on this but would appreciate any comments. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Diff files in portal_skins after a Find
Am 09.06.2008 um 09:42 schrieb Hedley Roos: Hi all I had an itch that I just had to scratch. When doing a Find in portal_skins I often want a diff of the results. Why? Because other people might skin something and then I have to copy the contents into vim and do a diff. This is time consuming if I don't know exactly what I'm looking for. This diff is not the same as the diff available under the History tab for the custom directory. Am I allowed to post a patch as an attachment to this list? It is quite small. You don't need to post diff's to the list. Create a ticket and add it there. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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: Working with Zope 3 skin layers
Am 27.05.2008 um 16:48 schrieb Philipp von Weitershausen: Right. This will look up the 'detail.html' view for (context, request). Now it depends on what layers the request has applied to. Unless you've changed anything in the default skin configuration, it will have Zope's default skin. Since the 'detail.html' view above wasn't registered for the default layer but for soemthing else, it's not found. browser:page for=Products.Charlie.event.interfaces.IEventDetail name=detail.html template=detail.pt class=.detail.DetailEdit permission=cmf.ModifyPortalContent / is fine with /++skin++charlie/@@detail.html Yup, because if you don't specificy a layer explicitly, browser:page / will register a view for IDefaultBrowserLayer. Your charlie skin probably inherits from IDefaultBrowserLayer (either directly or indirectly). That's why this works. Of course, this ties in with what I get from Zope - that the adapter can't be found. I suspect I've misunderstood something fundamental on how views work with layers. My book has a large section devoted to this. :) I know. You're book is probably the most referred to technical book I have! Very lucky that it was released as hard back. I've read the section a couple of times and while I think I understand the underlying mechanism... What I think is still confusing me is: 1) I have created my dedicated skin 2) I have registered a view for that skin I assumed that by registering the view for the skin, the view would automatically use the right layer when called. The effect being much the same as a customised view in a CMF layer: higher up the chain takes precedence. But it seems that this is not the case: unless it is set otherwise Zope will use the default skin. Is it possible to get individual views to use different skins without using ++skin++ in the URL? Regarding CMFDefault - all views are registered explicitly for ICMFDefaultSkin but I think this isn't necessary as this is configured as the default skin. No, it *is* necessary, because the default skin can always change. In fact, nearly every application (in the Zope 3 world) sets the default skin (otherwise you'd need those hideous ++skin++ things in all URLs). Also, by explicitly putting all views on the ICMFDefaultSkin layer, those views are only there if your skin interface inherits from ICMFDefaultSkin. Which means you can easily switch off those CMF views by not including ICMFDefaultSkin. For some people this is an important use case. Wouldn't that raise an error on startup if ICMFDefaultSkin isn't found? Or how do you not include ICMFDefaultSkin? Using overrides? Thanks for the help. Charlie PS: in your book the appendix to ZCML browser:defaultSkin says see browser:skin. This has been deprecated, I think. -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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: Working with Zope 3 skin layers
Am 28.05.2008 um 13:02 schrieb Philipp von Weitershausen: Views don't use layers. You apply a skin layer to the request, and depending on whether the view was registered for this skin layer or any of the layers that are contained in that skin layer, the view will be found. Thanks, that's the explanation I was missing - I hope I'm not the only one who doesn't quite understand what is adapting what when a view is called. 8-) The effect being much the same as a customised view in a CMF layer: higher up the chain takes precedence. Zope 3 layers and skins work exactly like that. But it seems that this is not the case: unless it is set otherwise Zope will use the default skin. Sure, but that's just like in the CMF where you tell the portal_skins tool which skin is the default. Is it possible to get individual views to use different skins without using ++skin++ in the URL? That doesn't make any sense to me and it's not how the CMF works either. In the CMF you may put different views in different skin layers (i.e. folders), but then you always combine them to a skin (in Properties page of the portal_skins tool where you enter a list of folders that make up the skin). For instance, you may have the following skin definition there: Default = custom something_else cmf_default This is very similar to Zope 3, except that we now have interfaces, e.g. ICMFDefaultSkin, ISomethingElse and IMyCustomLayer. You'd now register views for those layer interfaces (probably just for IMyCustomLayer) and then combine those layer interfaces in a skin interface, which is then given a name using the interface / directive and then registered as the default skin: class IMySkin(ICustom, ISomethingElse, ICMFDefaultSkin): pass interface interface=...IMyDefaultSkin type=zope.publisher.interfaces.browser.IBrowserSkinType name=MySkin / browser:defaultSkin name=MySkin / Okay, this is starting to make sense. Layers and skins are confusing especially as they are all just interfaces! :-O When does the skin name get used apart from in ++skin++ urls? Views are still registered to layers, ie. interfaces, aren't they? What I had been expecting to work, but which I think I now understand why it wouldn't, was the ability to add a layer for something like an administration layer which would call a version of standard_macros specific to that layer. I was hoping to be able to change this simply in ZCML rather than in the templates, ie. configure the views I want to use a different skin. Instead, it seems, I need to write and register my own macros and change those templates that need to use them. Not sure whether this is entirely the right way to go about this, as opposed to using a viewlet to do it but as least I've got it to work. Regarding CMFDefault - all views are registered explicitly for ICMFDefaultSkin but I think this isn't necessary as this is configured as the default skin. No, it *is* necessary, because the default skin can always change. In fact, nearly every application (in the Zope 3 world) sets the default skin (otherwise you'd need those hideous ++skin++ things in all URLs). Also, by explicitly putting all views on the ICMFDefaultSkin layer, those views are only there if your skin interface inherits from ICMFDefaultSkin. Which means you can easily switch off those CMF views by not including ICMFDefaultSkin. For some people this is an important use case. Wouldn't that raise an error on startup if ICMFDefaultSkin isn't found? Uh, it's an interface... how can it not be found? I wasn't sure how you meant not including ICMFDefaultSkin and assumed you might mean leave out the configure.zcml from Products.CMFDefault.skin rather than not inheriting from it. Or how do you not include ICMFDefaultSkin? Using overrides? By having your skin interface not inherit from ICMFDefaultSkin, just like in the CMF where you would remove the cmf_default layer from the skin definition if you didn't want to have the views from cmf_default available. PS: in your book the appendix to ZCML browser:defaultSkin says see browser:skin. This has been deprecated, I think. Ah, thank you! You're welcome. For the fourth edition, and I hope there will be one, it might be an idea to add a couple of paragraphs from above to clarify customisation by adding a layer, ie. where world_cookery inherits from Rotterdam and where it differs. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Working with Zope 3 skin layers
Hi, a couple of questions when using these - I was hoping to be able to use one for some special views of a site but I'm getting errors. I've defined and configured a layer and it works when called by ++skin+ + traversal but I have problems if I configured views to work with it explicitly: I get not found errors. ie. browser:page for=Products.Charlie.event.interfaces.IEventDetail layer=Products.Charlie.skin.ICharlieSkin name=detail.html template=detail.pt class=.detail.DetailEdit permission=cmf.ModifyPortalContent / fails for /@@detail.html but browser:page for=Products.Charlie.event.interfaces.IEventDetail name=detail.html template=detail.pt class=.detail.DetailEdit permission=cmf.ModifyPortalContent / is fine with /++skin++charlie/@@detail.html Of course, this ties in with what I get from Zope - that the adapter can't be found. I suspect I've misunderstood something fundamental on how views work with layers. Regarding CMFDefault - all views are registered explicitly for ICMFDefaultSkin but I think this isn't necessary as this is configured as the default skin. I also got a bit a lost with the lookup and would suggest moving the interface definition to the skin folder so that the lookup is more explicit interface interface=Products.CMFDefault.skin.IcamaoCmsSkin type=zope.publisher.interfaces.browser.IBrowserSkinType name=cmf / Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] newstyle content creation
Am 19.05.2008 um 18:51 schrieb Charlie Clark: That's probably the easiest solution at the moment although it would be nice to be able to declare this in the schema. I suppose two different interfaces à la IObject and IMutableObject provide a way. I find fiddling with the form fields too easy to mess up! I think the only thing that's missing from this is a nicer way of getting the portal_type. As this is configurable in the ZMI and perfectly possible to have several types deriving from the same class and, therefore, from the same interface. Although as with browser views this should no longer be possible. I can't see an easy way of doing this but it seems to me much more natural to do this in the interface rather than in the view as it's essentially declarative work. Maybe a dedicated schema field for CMF Types and associated hidden widget? portal_type = CMFDefault.schema.ContentType(title=uportal type) Obviously that won't work but it seems it should be possible to add the portal_type logic to the base form as this should be true for all add forms for CMF objects, shouldn't it? in ContentAddFormBase def setUpWidgets(self, ignore_request=False): super(ContentAddFormBase, self).setUpWidgets(ignore_request=ignore_request) self.widgets['portal_type'].hide = True def form_fields(self): fields = form.FormFields( TextLine( __name__='portal_type', default=self.portal_type) ) return fields add forms now simply need to define their portal_type and extend the fields: portal_type = uTextbody @property def form_fields(self): fields = (super(TextAdd, self).form_fields() + form.FormFields(ITextbody)) return fields I'm not sure if it's good style to do this using properties but it seems to work for and I find it less of a source of copy and paste errors. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Europython
Who's planning to go? I'm not sure if I will yet but if I do I'll probably try and cover the bits of CMF (2.2) that I'm pleased with. Zope and certainly the CMF has been underepresented the last couple of years with Plone having its own conference. This means the RoR clones get all the attention which is a pity as they're not that special. But more importantly there's a whole new generation of Pythonista's out there who don't know enough about Zope. I fondly remember Philipp's presentation of using adapters to turn documents into wikis in Geneva a couple of years ago - this as much as anything convinced me to take a deeper look at the Zope 3 approach. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] newstyle content creation
Am 02.05.2008 um 13:50 schrieb yuppie:
Did some more refactoring. If your factory can handle all the input,
ContentAddFormBase's 'create' method should be sufficient. If not,
you need a 'create' method like the one in FileAddView.
Yes, thank you very much!
You should not use that stuff if you don't need it. Schema
adapters and ProxyFieldProperty are just legacy code for old
content types.
I know. But I didn't know at the time and boy did it make me think
that things were going to be harder than they needed! I had to take
some time out at the time and curse the nameless people who hadn't
written the dummies guide to this! Still, it wasn't a bad idea
making me think more about this stuff.
Sorry. Added a small explanation in the module docstring.
Thanks again. As I said, I don't think it did me any harm to go
through the process of working through adapters. It was just a bit off-
putting when working on my own objects.
Regarding naming: I suppose the easiest thing is to add an id
field to the add form for none file objects.
That's an option if you don't want automatically generated IDs. My
question was how to integrate oldstyle factories that don't have an
add form into an add menu.
ah, now I understand the question! With addForms we get the default
next page but not with oldstyle factories? Is that correct?
It would be nice to have a require once in the schema value for
things like upload fields so that the same schema can be used for
adding and editing.
In my own code I use some modified widgets that support
self.widgets['foo'].required=True to override required=False of the
field.
That's probably the easiest solution at the moment although it would
be nice to be able to declare this in the schema. I suppose two
different interfaces à la IObject and IMutableObject provide a way. I
find fiddling with the form fields too easy to mess up! I think the
only thing that's missing from this is a nicer way of getting the
portal_type. As this is configurable in the ZMI and perfectly possible
to have several types deriving from the same class and, therefore,
from the same interface. Although as with browser views this should no
longer be possible. I can't see an easy way of doing this but it seems
to me much more natural to do this in the interface rather than in the
view as it's essentially declarative work. Maybe a dedicated schema
field for CMF Types and associated hidden widget?
portal_type = CMFDefault.schema.ContentType(title=uportal type)
This does, of course, beg the question: when we've moved everything
to browser_views do we start thinking about moving the default
classes to zope.app based stuff? Or do we still depend too heavily
on the Zope2 security declarations and other stuff?
First priority for existing content classes is backwards
compatibility. I prefer to keep them as they are and to use adapters
to make them work with Zope3 style code.
Okay. Just going from my own experience which was take CMFDefault and
see what you can do with it. - it's actually really nice to be able to
right some very lightweight, effectively Zope 3 classes, and give them
PortalContent. So, whilst supporting legacy classes, it would also be
nice to have a couple of examples of what to do if you write your own
classes from scratch. mm, probably something I could do.
I also understand what you mean about making a menu for this
stuff. It would be nice to have some configuration for this so
that we don't have to rely on actions such as AddFile, AddImage,
etc. Would that be something like listing all views that provide
a specific interface?
No. The view registrations don't provide enough information and
I'd like to keep this configurable TTW.
We can look up the addable types in the types tool as
folder_factories and Plone do. But in that case we need a way to
get the URL of the add view.
The lookup is pretty much what I do at the moment. I can't think of
an easy way of doing this apart from convention which is pretty
much what you suggest with addFile. I suppose the next thing
would be to add support for the '+' syntax and addMenuItem directive?
The IAdding view ('+' syntax) and Zope 3 menus are special code for
the Zope 3 app ZMI. I don't plan to add support for that.
And, as I know from a later post, the IAdding interface isn't
universally popular.
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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] newstyle content creation
Am 25.04.2008 um 19:23 schrieb Charlie Clark: Agreed. The first five lines are generic and should probably be in ContentAddFormBase leaving just the adapter stuff to be implemented by the view itself which is what is was before! _create would be more in keeping with other formlib methods such as handle_success calling _handle_success. I've been successfully able to implement my own add Views for some of my own objects and it definitely makes sense to have let contentAddView do the work. For my objects I don't seem to need anything specific in the view so always implementing a method such has _create or maybe _handle_add doesn't make sense. Maybe a lookup to see if such a method is implemented for adapting any additional adaptation? if hasattr(self, adapt_form_to_object): self.adapt_form_to_object Regarding naming: I suppose the easiest thing is to add an id field to the add form for none file objects. It would be nice to have a require once in the schema value for things like upload fields so that the same schema can be used for adding and editing. Ha, should have looked more closely at the code! You're automatically generating names as required. Maybe the lookup should also cope with forms where an id is supplied just as you've done with filenames? Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Formlib and multiple forms
Hi, I'm not sure if I'm going about this the right way but I'm struggling with using formlib to generate a group of forms / set of repeating elements in what is effectively a grid. I think that either I need to use a collection or a set of forms with different prefixes but I'm still struggling a bit with this. I have a concert object type that takes place in several cities so the repeating element would be the city with the additional information such as date, address and price. Effectively I have two schemas and while I could, I suppose use two different objects (Concert Location), it is important that for the application that the Location information for all venues can be edited at once: effectively a list of dictionaries with each key corresponding to a field. Is it possible to extend a schema like this? Alternatively, and I think this probably makes more sense: how to do I get the form to be extended repeatedly with the same interface but a different prefix? Guidance much appreciated! Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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] Formlib and multiple forms
Am 28.04.2008 um 15:30 schrieb Charlie Clark:
Alternatively, and I think this probably makes more sense: how to do
I get the form to be extended repeatedly with the same interface but
a different prefix?
Ah, it looks like I've got this working:
def setUpWidgets(self, ignore_request=False):
self.widgets = []
for city in [Paris, New York]:
self.adapters = {}
self.widgets += setUpWidgets(
self.form_fields, city, self.context, self.request,
form=self, adapters=self.adapters,
ignore_request=ignore_request)
Is this okay? Or is it a bad thing (TM)?
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
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
