[Zope-CMF] Checking which version of the CMF is running
Dear all, I noticed recently that Formulator does not work with CMF v2 because FSForm.py imports from CMFCore.CMFPermissions so I thought I'd fix this and thought it might be useful. Easier said than done as there does not seem to be a standard way to find out which version of CMF is installed which is presumably why the Plone installer devotes a few lines to it. I've come up with the following: # Use existing Zope tools to check for the CMFVersion import App.Product import OFS.Application import os.path CMFVERSION = None for priority, product_name, index, product_dir in OFS.Application.get_products(): if product_name == CMFCore: class Dummy(object): Dummy object for a dummy product install def _setObject(self, name, product): pass A = Dummy() A.Control_Panel = Dummy() A.Control_Panel.Products = Dummy() package_dir=os.path.join(product_dir, product_name) OFS.Application.import_product(product_dir, product_name) productObject = App.Product.initializeProduct( None, product_name, package_dir, A) version = productObject.version version = version.split(-) major = int(version[-1][0]) if major = 2: CMFVERSION = 2 I hope this isn't too weird! I think it is flexible enough to be used with other Zope Products if required but does beg the question: shouldn't there be an easier way to do this? Should there be a standard method of getting a Product's version in Zope.app? I assume there are other Products that have similar dependencies, although I am not sure if the problem is in FSForm itself which does some pretty thoughtless importing. 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] retrieve contents of Folder
Am 22.10.2006 um 14:55 schrieb fabio gravina: How I can retrieve all Folder's contents??? folder.get_items() perhaps? Please look at the Zope Book and online help 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: CMF Tests: 12 OK, 1 Failed
Am 24.10.2006 um 15:11 schrieb Jens Vagelpohl: Hash: SHA1 Tres, I am afraid you seem to be the only one able to verify this. IIRC the security fix is yours as - of course - is CMF. ;-) The CMF is not tied to one person. No one has responsibility for all eternity to fix it, even for no-longer-maintained versions. Someone has to take decisions every now and then. I am ready to remove irrelevant combinations, but in this case I have been reluctant up to now because of the possible security implications. CMF 1.4 is unmaintained. This has been known for a long time. Plone, as the largest customer, prescribes specific Zope and CMF versions, which obviously have been tested ad infinitum. I don't see the value for continuing to automatically test combinations that are not used. Agreed, deprecate it and maybe consider introducing a process for deprecation (as well as an easy way to check the version... wink) 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] CMF 2.1 dependencies
Am 01.11.2006 um 14:06 schrieb Jens Vagelpohl: I'd like to make Zope 2.10 required for CMF trunk (2.1). This was discussed before in this thread: http://mail.zope.org/pipermail/zope-cmf/2006-September/024813.html In my sandbox I removed the Zope 2.9 backwards compatibility code and got rid of all deprecation warnings. If there are no objections I'll check in those changes. I am personally +1 on that myself. Right now I believe Plone is the only customer for 2.1, but if anyone else has an objection, please speak up today. I have no problems will deprecating code and also aligning CMF with particular Zope versions. It might, however, be useful to note if any existing applications will be broken by the change. Oh, and it might be nice for someone on the Zope release team to bring out Windows versions of 2.9.5 and 2.10.0 for those who might need to try them in advance. 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: CMF Tests: 3 OK, 2 Failed, 4 Unknown
Am 22.11.2006 um 16:44 schrieb Tres Seaver: These failures are all in the calendar tests, and may have something to do with timezone issues -- anybody got a clue? Did Zope = 2.9 just fiddle with timezone stuff in DateTime? I'm not sure if it's related but this is from this week's releases: Zope 2.9.6 (2006-11-22) Bugs fixed Collector #2191: extended DateTime parser for better support to the ISO8601 specification. -- 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] More questions
Am 22.11.2006 um 16:54 schrieb Doyon, Jean-Francois: You might want to look at METAL macros ... Mydoc: p metal:define-macro=mymacrocontent/p Myotherdoc: p metal:use-macro=here/mydoc/macros/mymacro / See the ZPT reference for more details ... Thanks, I'm quite happy with the METAL and TALES but this is when I wish to include a CMF document within another. It's a bit like the news box but for none news items. 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: Getting started with CMF
Am 21.11.2006 um 17:14 schrieb Jens Vagelpohl: No, you either go into the portal_skins tool, find the main_template and use the Customize functionality to create a copy in the custom skin folder, which you can edit. Or, and this is the more complicated but right way to do it, you create a filesystem product with a filesystem skin folders and maintain your new main_template on the file system. Then you just need to make sure your new skin folder is higher up in the list of skin folders for the skin you use. A good sample product for setting up a new skin folder and integrating it is CMFCalendar, which is part of the CMF. Just so I understand this properly. The second, right, way of doing this is to move pretty much all the code into the file system? Assuming I just wanted to alter the skins is there a skeleton 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
Re: [Zope-CMF] More questions
Am 22.11.2006 um 17:20 schrieb Doyon, Jean-Francois: In that case, simply using something like: div tal:replace=structure here/mydoc / Should do it? That will nest the default view of the document though, which risks giving out a main_template inside a main_template. The trick will revolve around which view you want ... If any, or just the raw data. You could create a ZPT specifically for nesting, and use it for embedding, using macros, or access the data directly via the CookedBody method or something like that? (You'll have to dead the CMFDocument code to get the details though). I'm working with a CMF document so using structure here/mydoc does cause exactly the problems you describe. CookedBody or simpley text also cause problems as the document has non-ascii. I guess I'll have to look at how the news box actually works. 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: More questions
Am 22.11.2006 um 17:44 schrieb Raphael Ritz:
Charlie Clark schrieb:
This is just a quick one: how do I include documents within
another document? ie. say I have local_pt which is going has
different boxed with text from other documents. I assume I have to
call a method on the document to render it correctly but haven't
found the right one yet.
div tal:content=here/MyDocument/text/div nearly works but
obviously isn't quite right. I thought I'd seen a render method
somewhere but that doesn't seem to be it either.
Look for 'CookedBody' aka
div tal:content=structure here/MyDocument/CookedBody/div
might be what you are after.
Not quite. I need the decoded version of CookedBody
so div tal:content=structure python: context.Manifesto.CookedBody
().decode('utf-8') works nicely.
Here I am busy deconstructing all your lovely work! ;-)
Raphael
PS: DocfinderTab is your friend ;-)
Is that Dieter Maurer's Product?
PPS: even when you are not using Plone it might help
to have it up somewhere locally and use Clouseau for
TTW object introspection (you have basically a 'zopectl debug'
session in your browser - really convenient to explore things)
I've got Plone somewhere on this machine but on a different Instance.
Can I run Clouseau simply on the CMF? I can give it a go.
Thanks for the tips.
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: Getting started with CMF
Am 22.11.2006 um 17:37 schrieb Tres Seaver:
The following two commands create the absolute minimum product which
makes filesystem skins availalbe. Run this from your INSTANCE_HOME:
$ mkdir -p Products/myproduct/skins/myproduct
$ cat Products/myproduct/__init__.py EOT
from Products.CMFCore.DirectoryView import registerDirectory
registerDirectory('skins', globals())
EOT
You would then begin putting templates, scripts, etc. into the
'skins/myproduct' directory of the product, e.g.:
$ cat Products/myproduct/skins/myproduct/some_script.py EOT
## Script (Python) some_script
##parameters=
return 'Kilroy was here!'
EOT
Next, register that skin directory in your site's skins tool, by
adding
a Filesystem Directory View using the registered path. Finally, add
the 'myproduct' skins dir to the search path for your skin on the
skins
tool's Properties tab.
That is the business!
One slight addition to make it idiot-proof (or at least Charlie-
proof!) The Filesystem Directory View should be added in the sites
skins folders.
This all begs the question that if, as Jens suggests, file system is
the way to go, surely this process can be automated when creating a
portal?
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: Getting started with CMF
Am 24.11.2006 um 16:00 schrieb Jens Vagelpohl: This all begs the question that if, as Jens suggests, file system is the way to go, surely this process can be automated when creating a portal? Why? Not everyone who creates a portal wants to develop filesystem products. I was extrpolating from your previous post about the correct way to do customisation: Or, and this is the more complicated but right way to do it, you create a filesystem product with a filesystem skin folders and maintain your new main_template on the file system. By the way, *any* code that has unexpected consequences (like creating a portal in the ZODB will create stuff on the file system) is insidious and broken by design. Agreed but if the consequences are explicit and not unexpected? If customisation through file system is indeed the right way then I don't see why this would be unexpected. 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: Getting started with CMF
Am 24.11.2006 um 16:26 schrieb Jens Vagelpohl: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24 Nov 2006, at 16:22, Charlie Clark wrote: I was extrpolating from your previous post about the correct way to do customisation: Or, and this is the more complicated but right way to do it, you create a filesystem product with a filesystem skin folders and maintain your new main_template on the file system. It is true that the better way to store your customizations is in a filesystem skin. However, actions in the ZODB should *not* write back to the sile system. Granted, there are products that are made for that specific purpose (LocalFS etc), but allowing filesystem writes through the ZODB is a big security hole. I'm in total agreement with you regarding those dangers. This is also a presumably just a small part of the CMF work but it's nice to see this movement towards file system development (of code) and Tres' tip make it extremely easy for customisation to be done in the file system. 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] Calendar
Hi, am I right in assuming that the CMF calendar tool does not provide a getNextEvent method? 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] Calendar
Am 27.11.2006 um 13:52 schrieb Jens Vagelpohl: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27 Nov 2006, at 13:34, Charlie Clark wrote: Hi, am I right in assuming that the CMF calendar tool does not provide a getNextEvent method? No. By the way, grep is your friend, and would have told you in a split second :) He isn't my friend - my brain has difficulties with the command line %-) but I asked the question after reading the source. I'm working on my own script to do the work but think it might be a good idea to have it in the tool itself. BTW. it's the first time I've come across getToolByName. How do I add additional event_types? Just patch setup_handlers? There doesn't seem to be any checking for adding valid 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] Calendar
Am 27.11.2006 um 14:14 schrieb Charlie Clark:
He isn't my friend - my brain has difficulties with the command
line %-) but I asked the question after reading the source. I'm
working on my own script to do the work but think it might be a
good idea to have it in the tool itself. BTW. it's the first time
I've come across getToolByName.
This is method I've come up with:
def getNextEvent(self):
Get the next event from the calendar
today = DateTime()
print today
query = self.portal_catalog(
portal_type=self.getCalendarTypes(),
review_state=self.getCalendarStates(),
start={'query': today, 'range': 'max'},
sort_on='start')
def sort_function(x,y): # this should be a utility method
for the class
# as indeed should the check for
uniqueness
z = cmp(x.start,y.start)
if not z:
return cmp(x.end,y.end)
return z
rids = []
results = []
for result in query:
if not result.getRID in rids:
rids.append(result.getRID)
results.append(result)
if results:
results.sort(sort_function)
return results[0]
return None # probably unnecessary
I've also written a simple next_event_view script and
next_event_view_template
I'd write a test for this but I've never written a test so it might
go horribly wrong! ;-)
If you wish I'd be happy to submit this although I think the changes
for unique results and sorting should also be reflected.
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] Calendar
Am 30.11.2006 um 10:29 schrieb Jens Vagelpohl: Hash: SHA1 On 27 Nov 2006, at 17:09, Charlie Clark wrote: If you wish I'd be happy to submit this although I think the changes for unique results and sorting should also be reflected. Feel free to post submissions to the CMF collector where they belong, mailing lists are unsuitable because patches will get lost and forgotten: http://www.zope.org/Collectors/CMF Any code submitted will have a much better chance of being accepted when it comes with unit tests. Okay, I've written the code and a test for the calendar. It seems to work okay. I say seems as it throws the same errors that are already there: http://mail.zope.org/pipermail/cmf-tests/2006-November/003403.html Not really the best environment for a release. I suppose I could always try and fix those errors/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 http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Internationlisation question
Hi, I'd to use stftime(%d %B %Y) on my website in different locales (de_DE and en_GB) on different parts of the website which is not localised but has some content in German and some different content in English. Somehow I haven't quite grokked Andy McKay's explanation of i18n as the following code throws an error span i18n:data python: DateTime() i18n:translate=datefmt i18n:name=date/span With i18n:name I get an error that i18n:name needs to be within a translation unit and without it I get a cannot iterate over a non- sequence. So, what I am getting wrong? 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: [CMF 2.1] FSPageTemplate Unicode
Am 07.01.2007 um 14:26 schrieb Martin Aspeli: However, surely, if we agree that it's premature to do so, commenting out the line that sends a DeprecationWarning won't be much of a change? That's just plain silly! The warning is the best way of informing developers: explicit is better than implicit. I agree with Jens that should go through the archive discussions on this which covered compatability issue. Anyway third party developers should be aware of and checking for the version for their dependencies (I'd like a utility for this for CMF but that's another issue) so that Product X can be categorised as working with CMF versions 1.6 and 2.0 but perhaps not 2.1. +1 to go ahead with Jens' branch. 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] Installing a CMF Content Type from scratch
Hi, I'm working on a new content type for the CMF. I've got it working as a Zope Product and can add instances of it through the ZMI but I need to register for my CMF site. I've been looking at the way Andy McKay does this in his Plone book but this seems to rely on some Plone magic (an install product function in the Plone control panel) which I don't have. I assume I should be able to do everything I need through the portal_types and add a file system directory view for the skins folder. Is this correct? Is anything else required? 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] Internationlisation question
Am 07.12.2006 um 12:54 schrieb Lennart Regebro: span i18n:data python: DateTime() i18n:translate=datefmt i18n:name=date/span With i18n:name I get an error that i18n:name needs to be within a translation unit and without it I get a cannot iterate over a non- sequence. So, what I am getting wrong? This part makes no sense to me: i18n:data python: DateTime() Maybe you meant tal:define=data python: DateTime() ? I don't think so. I've been referring to Andy McKay's book on Plone and he lists i18n:data as an part of the specification but maybe this is specific to Plone? Anyway - what I want to do is have something like 20th January 2007 in some places and 20. Januar 2007 in others on the same site which has no language settings. What is the best way in going about this? Thanks 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: Installing a CMF Content Type from scratch
Am 09.01.2007 um 22:26 schrieb Tres Seaver:
I think this is the bit I'm fuzzy about. Is adding the type
information simply a question of adding a type in portal-types? If so
I'm doing something wrong because it my type is not appearing in the
pull-down list.
You may need to check its globally_addable property (the type
object's) and verify that the container into which you would like
to add
an instance does not have a type-based restriction on adding (e.g.,
the
'filter_contents' and 'allowed_types' settings on the container's type
informatino object).
I realise I'm being somewhat obtuse about this but where do I set the
globally_addable property? I've been basing my stuff on the example
in the Plone book but also on CMFCalendar. My Zope Product gets
installed with no errors. This is my factory_type_information
factory_type_information = {
'id': product_id,
'meta_type': product_name,
'description': ('Extremely flexible type of article.'),
'product': product_name,
'content_icon': 'newsitem.gif',
'immediate_view': 'view',
'actions': (
{'id': 'view',
'name':'View',
'action':'flexible_article_view_form',
'permissions': (view_permission,)},
{'id': 'edit',
'name':'Edit',
'action':'flexible_article_edit_form',
'permissions': (edit_permission,)},
)
}
Does the __init__.py need extending?
Thanks
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: Installing a CMF Content Type from scratch
Am 10.01.2007 um 01:17 schrieb Jens Vagelpohl: I believe Tres is referring to is the global_allow property that you can find in the GenericSetup XML files for content types. To make a long story short: Completely forget the Plone book examples and look at the GenericSetup examples as set by _recent_ CMF versions, described by the XML files inside product/profiles/ default/. factory_type_information dictionaries are obsoleted by GenericSetup profiles. Thanks, I'm using CMF 2.0 from this autumn so I'm using the most recent stable release. I assume CMFCalendar is a good example to follow? Thanks 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: Installing a CMF Content Type from scratch
Am 10.01.2007 um 12:23 schrieb Jens Vagelpohl: What is the additional step using Python code that you're referring to? Is that the setuphandlers stuff called by import_steps? Yep, exactly. Okay, next problem. Getting an error trying to access the context in the edit_form.py or view.py scripts. Unauthorized: Not authorized to access binding: context for statements like options['title'] = context.Title() I've obviously missed some kind of permission but AddPortalContent and ModifyPortalContent and View but this must be something else. 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: Installing a CMF Content Type from scratch
Am 10.01.2007 um 12:52 schrieb Charlie Clark:
Okay, next problem. Getting an error trying to access the context
in the edit_form.py or view.py scripts.
Unauthorized: Not authorized to access binding: context
Silly me! Always pays to look at the full traceback!
2007-01-10 13:49:45 ERROR root Exception while rendering an error
message
Traceback (most recent call last):
File /opt/Zope-2.9/lib/python/OFS/SimpleItem.py, line 223, in
raise_standardErrorMessage
v = s(**kwargs)
File /opt/Zope-2.9/lib/python/Shared/DC/Scripts/Bindings.py,
line 311, in __call__
return self._bindAndExec(args, kw, None)
File /opt/Zope-2.9/lib/python/Shared/DC/Scripts/Bindings.py,
line 348, in _bindAndExec
return self._exec(bound_data, args, kw)
File /Users/charlieclark/eGenix.com/Products/CMFCore/
FSPageTemplate.py, line 196, in _exec
result = self.pt_render(extra_context=bound_names)
File /Users/charlieclark/eGenix.com/Products/CMFCore/
FSPageTemplate.py, line 135, in pt_render
result = FSPageTemplate.inheritedAttribute('pt_render')(
File /opt/Zope-2.9/lib/python/Products/PageTemplates/
PageTemplate.py, line 105, in pt_render
tal=not source, strictinsert=0)()
File /opt/Zope-2.9/lib/python/TAL/TALInterpreter.py, line 238,
in __call__
self.interpret(self.program)
File /opt/Zope-2.9/lib/python/TAL/TALInterpreter.py, line 281,
in interpret
handlers[opcode](self, args)
File /opt/Zope-2.9/lib/python/TAL/TALInterpreter.py, line 735,
in do_useMacro
macro = self.engine.evaluateMacro(macroExpr)
File /opt/Zope-2.9/lib/python/Products/PageTemplates/TALES.py,
line 221, in evaluate
return expression(self)
File /opt/Zope-2.9/lib/python/Products/PageTemplates/
Expressions.py, line 185, in __call__
return self._eval(econtext)
File /opt/Zope-2.9/lib/python/Products/PageTemplates/
Expressions.py, line 173, in _eval
ob = self._subexprs[-1](econtext)
File /opt/Zope-2.9/lib/python/Products/PageTemplates/
Expressions.py, line 127, in _eval
ob = restrictedTraverse(ob, path, getSecurityManager())
File /opt/Zope-2.9/lib/python/Products/PageTemplates/
Expressions.py, line 284, in restrictedTraverse
t=get(object, '__bobo_traverse__', N)
File /opt/Zope-2.9/lib/python/Shared/DC/Scripts/Bindings.py,
line 180, in __getattr__
self.__you_lose()
File /opt/Zope-2.9/lib/python/Shared/DC/Scripts/Bindings.py,
line 187, in __you_lose
raise Unauthorized('Not authorized to access binding: %s' % name)
Unauthorized: Not authorized to access binding: context
So, it is actually the Templates that are being blocked from
accessing the context! Unfortunately I do not understand why this
should 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: Installing a CMF Content Type from scratch
Am 10.01.2007 um 13:52 schrieb Charlie Clark: So, it is actually the Templates that are being blocked from accessing the context! Unfortunately I do not understand why this should be the case. aaagh! Simple error: the skin was not in the list of skins to be viewed. Do all content-types have to have a description? ie. is this a necessary part of the DublinCoreSpe? 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] Portal users and some other stuff
Hi,
my shiny new content type is now working pretty much as expected.
Thanks to Tres and Jens for pointing me in the right direction and
giving me encouraging nudges.
For the necessary forms, at least based on the CMF Event code, it
seems to me that code like
options['title'] = form.get('title', context.Title())
options['text'] = form.get('text', context.text)
options['text_format'] = form.get('text_format', context.text_format)
options['headline'] = form.get('headline', context.headline)
options['teaser'] = form.get('teaser', context.teaser)
options['category'] = form.get('category', context.category)
options['keywords'] = form.get('keywords', context.keywords)
options['resources'] = form.get('resources', context.resources)
could be optimised in the context could be treated as a dictionary
object, ie. supported get.
ie.
attrs = ['headline', 'teaser', 'category']
optins = {}
# assign attributes that do not require additional processing
for attr in attrs:
options[attr] = form.get(attr, context.get(attr))
# attributes that need special treatment...
I was initially confused that the context was the same as the
instance of my content-type and didn't support this as I use this
idiom quite frequently to reduce my typos. Is this too much of an
edge case to warrant the extension in general (but I'm free to do it
myself) or perhaps an outdated methodology?
If I need to add attributes to portal users such as their full name,
is it best to customise the member object for my site or to use a
plugin?
--
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] Portal users and some other stuff
Am 12.01.2007 um 10:13 schrieb Jens Vagelpohl:
That's a matter of taste. I like explicit, so I prefer the existing
method.
Explicit is better than implicit but I don't see what's wrong with
having an explicit list of fields through which to loop, as long as
the call is the same as this reduces typos and makes things easier to
manage. Of course, exposing all attributes by allowing __get__ to be
the same as getattr can cause problems for objects that are not
simply based on dictionaries.
I was initially confused that the context was the same as the
instance of my content-type and didn't support this as I use this
idiom quite frequently to reduce my typos. Is this too much of an
edge case to warrant the extension in general (but I'm free to do
it myself) or perhaps an outdated methodology?
I'm not sure what this paragraph means.
It was quite late...
In PythonScripts I quite often use
context.get('objectname') rather than context.objectname for anything
programmatic. It seems to me that there is a case for making certain
attributes of content-types available via get so that dispatching can
be used where appropriate.
If I need to add attributes to portal users such as their full
name, is it best to customise the member object for my site or to
use a plugin?
All you need to do is to add the desired property to the list of
properties in the member data tool, and then extend the preferences
form and its handlers with your new property (untested off the top
of my head).
Thanks. Works as expected.
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: Portal users and some other stuff
Am 12.01.2007 um 14:35 schrieb Jens Vagelpohl: Here is the new implementation for event_edit_form and event_view: http://svn.zope.org/CMF/trunk/CMFCalendar/browser/event.py? rev=71045view=markup There you go, even better ;) Indeed, nice to see all those horrible decorators have gone! Now that my content-type is sort of working I can afford to give this a go. Does this have dependencies on the current svn trunk or will it work with CMF 2.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 http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Portal users and some other stuff
Am 12.01.2007 um 10:13 schrieb Jens Vagelpohl:
All you need to do is to add the desired property to the list of
properties in the member data tool, and then extend the preferences
form and its handlers with your new property (untested off the top
of my head).
FWIW
while that is really straightforward, getting at the property
elsewhere (such as content byline) proved a bit of a challenge as the
creators are returned as a list of strings rather than membership
objects so
creator/fullname is not possible instead
tal:content=python: mtool.getMemberById(creator).getProperty
('fullname')
is required. Posting to the list for reference purposes.
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] Portal users and some other stuff
Am 15.01.2007 um 14:55 schrieb Charlie Clark:
tal:content=python: mtool.getMemberById(creator).getProperty
('fullname')
aagh - this only works if you have permission for getMemberById but I
want to globally replace creator, ie. acl_user with fullname in
contentByLine. Do I need to create an action for this in
portal_memberdata?
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: Tools as local utilities
Am 06.02.2007 um 22:14 schrieb Rocky: Ultimately the closer we get to structuring our code deployment like regular python code the easier it will be to take advantage of things like distutils, eggs, the cheeseshop, etc. I look forward to doing: easy_install ZopeCMF I hate eggs and easy_install and for me they are not part of regular python code but reminiscent of script kiddy magic dust which I *really* don't want in my apps. I know what's driving it and I know it's unfortunately almost unavoidable but I don't have to like it. I've never had a problem with using Products especially since the introduction of local Products with Zope 2.7. 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: Tools as local utilities
Am 07.02.2007 um 00:36 schrieb Martin Aspeli: Why? Is it the ability to specify sensible version restrictions? Have multiple versions of the same package as different dependencies for different dependents? Automatic downloading of dependencies where possible/desired? Standardised package metadata? Standardised location to find and search for add-on libraries? You mean the existing approach didn't support this? Ever heard of sys.path? Sorry, I don't want to waste bandwidth on the CMF list on a flame war. Eggs are there and I will have to learn to live with them but I don't have to like them. I know what's driving it and I know it's unfortunately almost unavoidable but I don't have to like it. I've never had a problem with using Products especially since the introduction of local Products with Zope 2.7. Meanwhile, the rest of the Python world came up with something better and more widely accepted. Until Zope 2.10 and Plone 3, the whole Plone and CMF stack depended on no library that was re-usable outside of Zope (apart from PIL, and unless you count parts of Zope 3 shipped with Zope 2.8+). Eggs make your life easier, especially if you want to use tools like workingenv.py or zc.buildout. This is guff. Why should Zope add-ons *necessarily* be available as third-party libraries? But if this is required it's no big deal to put the Zope specific stuff in a Products folder and the library in ../lib/python. Works fine for mxODBC 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: Five's local sitemanager, CMF, etc
Am 23.02.2007 um 12:52 schrieb Tres Seaver: Hmm, I won't quibble about migration code. +1. +1 me neither For registering the tools as utilities you still need to run the componentregistry import step. I would not use on-the-fly magic for that part, I think people should do that explicitly. If the code which *used* to work using 'getToolByName' now breaks beofre that step is done, then we have a problem. If there is a clear, simple step to perform after upgrade, then we should be OK. I thought Jens had written it so nothing breaks? E.g., we might tell folks to do something like: $ cd $INSTANCE_HOME $ ./bin/zopectl run Products/CMFCore/scripts/updateSites foo bar/baz To upgrade the 'foo', and 'bar/baz' site objects. I see no benefit to trying to do any migration from within the ZMI here. Me neither. I guess that CMF users can be expected to work in the file system. It is probably just me on this list but I would appreciate a list of the changes in the architecture with particular reference to what is likely to break or will need changing. So far I've picked up on yuppie's stuff to support views and Jens' work on utilities. Off hand I wouldn't expect those changes to break existing sites. I'm planning to do some work on the CMF next week, even using the svn version, which as Jens noted, is not what many people are likely to do. And now that I've got Phil's book I'll start working in a more Zope 3 kind of way. 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: Derived Content Types WebDAV
Am 28.03.2007 um 18:45 schrieb Tres Seaver: I would be quite surprised if these methods had much to do with WebDAV editing. Instead, I would look for PROPPATCH (and how it is implemented). The methods Charlie lays out are used to crack metadata from the body of a content object (Document, NewsItem, Event) during a PUT. PROPPATCH would indeed be the way to modify the values without re-uploading the body. I'm a bit confused! (Not for the first time!) The changes I've implemented are working for us: we're editing documents in the WebDAV file system using text/HTML editors. As it's not just the meta-data that may be changed I assume that we have to upload everything on saving. I am however, worried about the fact about possible encoding issues similar to what happens if you edit attributes such as description in the ZMI rather than in the CMF and use non-ascii get problems is this likely to happen here 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 http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Sanitised HTML
Hi, I noted that documents with the HTML content get sanitised when edited in the web (presumably this is to prevent possibly dangerous elements like javascript and forms being entered) but how is this controlled? I can't find anything in the source that looks responsible for this. Is there a CMF setting for this or which method do I need to overwrite? 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: Sanitised HTML
Am 21.04.2007 um 19:41 schrieb Tres Seaver: The skin method 'validateHTML' calls 'CMFDefault.utils.scrubHTML' to do the cleaning. My answer to this went straight to Tres and not the list! Thanks very much Tres - what would we do without you? I know that most of the discussion on the list is dealing with things for the new release but would it possibly make sense to document the horde of methods in CMF-Default skins? Or am I simply not looking in the right places for information? 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: Making TypesTool faster
Am 03.05.2007 um 00:50 schrieb Alexander Limi: At present, Archetypes-based content types cannot be used with a factory (I tried hard, but there are some acquisition-related/factory related reasons); I'd like to refactor this, but we can't for Plone 3.0 at least. Right. Obviously, we'd like to do this the proper way, but we can't do that for a while yet. I'm sorry but it's -1 from me. The change is unnecessary and the problem seems to be with Archetypes and not the CMF. In my view it is incorrect to change the infrastucture to compensate for the deficiencies of a component. If you need it in Plone you can add it as a patch. 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: Making TypesTool faster
Am 04.05.2007 um 14:00 schrieb Martin Aspeli: I'm not entirely convinced the problem is in AT, and I think we are conflating two different issues here. One is an observation of Tres' that AT has a function that could perform more cacheing. That's a good point, and may mitigate some of the performance issues by cacheing at a higher level, but it doesn't mean there aren't further opportunities for improvements to the underlying code. Indeed it doesn't but the argument is that there is a performance problem in Plone rather than CMF. Tres' most telling argument for me is: The cache is actually based only on the container (which could be a path) and the user ID. It would be a perfect use of a RAM Cache Manager (assuming that we cached mappings rather than persistent references). Using a volatile here (which is what I assume you mean) would dilute the locality of the cache by the number of database connections in use. The other issue is some code in TypesTool which is making a lot of calls to a procedure in Zope which is unlikely (impossible?) to ever return a different result until Zope is restarted and new products are detected. No, the issue is how often the TypesTool is being called (from within Plone). Surely the cache should be higher upstream in this case? Or maybe no, see below. If the two are orthogonal, and we already have a sane patch, then why not (at least if we can get some tests in place) fix the one at the CMF level and deal with the other Archetypes issue separately. The Archetypes issue should indeed be dealt with separately. I am, however, not convinced that this patch is sane. If the calls to Zope are indeed the issue as you suggest then I would suggest looking at their mechanism and whether Zope rather than the CMF can be improved in this respect - going on what Alec is quoted as saying it still makes sense to me to put the cache in the Zope making it available to all components. I've only had a brief look at the Product registration, etc. in Zope but from what I saw it looked like it could indeed be improved. 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] Problem with STX rendering
Just a quick question - it appears that STX has a problem with non- ascii texts so if I have a Document set as structured text some formatting operations will fail on non-ascii. Example: **some bold text with äüß** will be rendered as **some bold text with äüß**and not strongsome bold text with äüß/strong as expected. This is Zope 2.9 + CMF 2.0 I notice there is a similar bug: http://www.zope.org/Collectors/Zope/2285 Although I would expect this to be independent of locale (it's an encoding issue) and I've got the problem with Zope 2.9. Anyway before I submit a follow-up to the bug is there any CMF setting I can use to avoid this problem? Thanks 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] Re: Problem with STX rendering
Am 11.05.2007 um 01:09 schrieb Alexander Limi: On Thu, 10 May 2007 07:28:49 -0700, Charlie Clark [EMAIL PROTECTED] wrote: Anyway before I submit a follow-up to the bug is there any CMF setting I can use to avoid this problem? It's a known issue with STX. Thanks, does that mean anything's being done about it? I would have thought Plone users would be suffering the most with it. I spent some time looking at the underlying code yesterday and can see what's causing the problem. If I take my own medicine the STX code should be fixed. STLetters simply makes use of string.letters and string.digits which are then thrown into various re's expr = re.compile(r'\*\*([%s%s%s\s]+?)\*\*' % (letters, digits, strongem_punc)) This will work with non-ascii only if the encoding for string.letters and the text to be compared is the same which, certainly on my machine is not the case, but can be easily fixed. letters = string.letters.decode(locale.getlocale()[1].encode (WHATEVERCMFISPUSHING) I thought that the default_zpublisher_encoding would do but that's wrong. Assuming it's possible to get the value from Zope surely this would be a relatively painless fix? It might be an idea would be to hook into the ReST encoding directives that are mysteriously included in /etc/zope.conf An alternative would be to coerce the use of unicode and simply compare against that: re.compile(r'\*\*([\s\w]+?)\*\*', re.U) #extended as necessary for punctuation The advantage of this is that it would be entirely independent of locale but this would take more work on STX which seems to choke if fed unicode. Going back briefly to ReST: if Zope seems ready to support this out of the box, wouldn't it useful to support ReST in CMFDefault.Document? Or is the dependency on docutils too precarious? It could be added gracefully to the edit form if import reStructuredText succeeded. Or is this yet another case of me being behind the loop again? 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: Problem with STX rendering
Am 11.05.2007 um 18:31 schrieb Raphael Ritz: Just want to through this in here: Hanno is going to spend his GSoC project this year on reworking the transformation story for Plone http://code.google.com/soc/plone/appinfo.html?csaid=37C0499E14F646DC Maybe we give Hanno some pointers on what to consider as applications here ;-) Sorry, but I can't see any relation: my post is solely related to content in the ZODB. Anyway doesn't Silva do this (work extremely well with external files) 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 http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Kupu CMF
I guess this is one for Philip but maybe someone else can help me out. I'm trying to get kupu to work with a CMF site. I've installed the kupu package into Products and restarted Zope (2.9) but I can't access the macros even though I've added the common folder to my portal skins. 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 http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Kupu CMF
Am 30.05.2007 um 16:13 schrieb Tres Seaver: What am I doing wrong? Have you added the folder to the search path (on the Properties tab of the skins tool)? Just haveing the FSDirectoryView isn't enough. Yes I did and I can see the objects in the skin. Is there any way to check for the existence of a template in a PythonScript? Or check the search path? 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] Compound documents
Hi, for a new site I need a content type that combines a Document with an Image - it's essentially an Employee type and I was wondering the best way to implement this. Because I want there is a strict 1:1 relationship between text and image I am currently thinking about extending CMFDefault.Image to handle the additional attributes but I wonder if there is a way to create a meta-type that would magically bring the two different content types together? Thoughts and tips appreciated as ever. 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] Adding support for ReST to Document.py
Hi, further to the discussion last month I'm about to provide a patch which will support ReST for Document.py plus a revised document_edit_template.pt I don't know how to support the Zope3 stuff - the patch and test were done using CMF 2.0. I'm currently trying to set up a CMF 2.1 environment but I'm running into problems 2007-06-11 17:34:01 INFO ZServer HTTP server started at Mon Jun 11 17:34:01 2007 Hostname: 0.0.0.0 Port: 9080 2007-06-11 17:34:02 ERROR Application Could not import Products.CMFActionIcons Traceback (most recent call last): File /opt/Zope-2.10/lib/python/OFS/Application.py, line 703, in import_product product=__import__(pname, global_dict, global_dict, silly) File /Users/charlieclark/Sites/cmf/Products/CMFActionIcons/ __init__.py, line 20, in ? from Products.CMFCore.utils import ToolInit File /Users/charlieclark/Sites/cmf/Products/CMFCore/__init__.py, line 34, in ? import FSPageTemplate File /Users/charlieclark/Sites/cmf/Products/CMFCore/ FSPageTemplate.py, line 39, in ? from Products.PageTemplates.utils import encodingFromXMLPreamble, charsetFromMetaEquiv ImportError: No module named utils Traceback (most recent call last): File /opt/Zope-2.10/lib/python/Zope2/Startup/run.py, line 56, in ? run() File /opt/Zope-2.10/lib/python/Zope2/Startup/run.py, line 21, in run starter.prepare() File /opt/Zope-2.10/lib/python/Zope2/Startup/__init__.py, line 102, in prepare self.startZope() File /opt/Zope-2.10/lib/python/Zope2/Startup/__init__.py, line 278, in startZope Zope2.startup() File /opt/Zope-2.10/lib/python/Zope2/__init__.py, line 47, in startup _startup() File /opt/Zope-2.10/lib/python/Zope2/App/startup.py, line 45, in startup OFS.Application.import_products() File /opt/Zope-2.10/lib/python/OFS/Application.py, line 680, in import_products import_product(product_dir, product_name, raise_exc=debug_mode) File /opt/Zope-2.10/lib/python/OFS/Application.py, line 703, in import_product product=__import__(pname, global_dict, global_dict, silly) File /Users/charlieclark/Sites/cmf/Products/CMFActionIcons/ __init__.py, line 20, in ? from Products.CMFCore.utils import ToolInit File /Users/charlieclark/Sites/cmf/Products/CMFCore/__init__.py, line 34, in ? import FSPageTemplate File /Users/charlieclark/Sites/cmf/Products/CMFCore/ FSPageTemplate.py, line 39, in ? from Products.PageTemplates.utils import encodingFromXMLPreamble, charsetFromMetaEquiv ImportError: No module named utils 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] Adding support for ReST to Document.py
Am 11.06.2007 um 17:37 schrieb Charlie Clark: File /Users/charlieclark/Sites/cmf/Products/CMFCore/ FSPageTemplate.py, line 39, in ? from Products.PageTemplates.utils import encodingFromXMLPreamble, charsetFromMetaEquiv ImportError: No module named utils Okay, mea culpa - my version of Zope 2.10 was defect. 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] Adding support for ReST to Document.py
Am 11.06.2007 um 17:46 schrieb Charlie Clark: Am 11.06.2007 um 17:37 schrieb Charlie Clark: File /Users/charlieclark/Sites/cmf/Products/CMFCore/ FSPageTemplate.py, line 39, in ? from Products.PageTemplates.utils import encodingFromXMLPreamble, charsetFromMetaEquiv ImportError: No module named utils Okay, mea culpa - my version of Zope 2.10 was defect. Back to my original problem: it's easy enough to edit Document.py and document_edit_template. However, I note that the browser/document.py does some kind of lookup for supported text formats. Is this what Tres was referring to? How do I register restructured for use for anything using formlib? BTW - should we keep NewsItem as a separate Python module? The difference between a NewsItem and a Document is minimal and essentially one of presentation and this should surely be handled by the registration. 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] Adding support for ReST to Document.py
Am 11.06.2007 um 21:28 schrieb Jens Vagelpohl: See the very top of CMFDefault/browser/document.py, there's a simple hardcoded structure. Thanks! Now how do I go about testing these views? Do I make the views the default profile? 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] Adding support for ReST to Document.py
Am 12.06.2007 um 10:18 schrieb Jens Vagelpohl: Thanks! Now how do I go about testing these views? Do I make the views the default profile? Just look at how it's done in the tests under browser/tests Duh! ;-) But how do I go about using this in a site rather than skins? 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] Adding support for ReST to Document.py
Am 12.06.2007 um 10:29 schrieb Jens Vagelpohl: Have you actually looked at those tests? You will find examples that manually create a view with a fake request and a fake context (e.g. folder.txt), and examples that use the testbrowser (e.g. metadata.txt). Yes, I have looked at them. Guess it's time to familiarise myself with Zope 3-style testing... 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] Adding support for ReST to Document.py
Am 12.06.2007 um 10:22 schrieb Charlie Clark: But how do I go about using this in a site rather than skins? To answer my own question: it's easy as adding /@@view.html, etc. to the URL. 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] Adding support for ReST to Document.py
Am 12.06.2007 um 10:29 schrieb Jens Vagelpohl: Have you actually looked at those tests? You will find examples that manually create a view with a fake request and a fake context (e.g. folder.txt), and examples that use the testbrowser (e.g. metadata.txt). There are no explicit tests for the formatting and no errors when tests are run. @@edit.html works as it should if ReST is available. 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] Fixing STX for non-ascii
Hi,
since my patch to support ReST for Documents ( Newsitems - thanks to
Jens for this), I've gone back to looking at what was my original
problem: STX choking with non-ascii text. From my tests this
afternoon this looks surprisingly easy to fix. This is a sample
method from zope.structuredtext.document.py (which is used for Zope
2.10 and up but looks little more than a simple reimplementation of
the StructuredText package)
def doc_strong(self,
s,
expr = re.compile('\*\*([\w%s\s]+?)\*\*' %
(strongem_punc), re.UNICODE).search # works with non-ASCII
# expr = re.compile(r'\*\*([%s%s%s\s]+?)\*\*' %
(letters, digits, strongem_punc)).search # fails with non-ASCII
#expr = re.compile(r'\s*\*\*([ \n\r%s0-9.:/;,
\'\\?\-\_\/\=\-\\\(\)]+)\*\*(?!\*|-)' % letters).search, # old
expr, inconsistent punc, failed to cross newlines.
):
r=expr(s)
if r:
start, end = r.span(1)
return (stng.StructuredTextStrong(s[start:end]),
start-2, end+2)
It seems simply adding the re.UNICODE flag and using \w rather than
string.letters + string.digits is sufficient. However, given my
relative inexperience with regexes this could simply be naïvety on my
part.
If this does indeed work does a patch need submitting for both Zope
2.1x and Zope 3?
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] Fixing STX for non-ascii
Am 13.06.2007 um 16:44 schrieb Jens Vagelpohl: The zope.structuredtext package is a Zope 3 package, so without looking closely I would assume no patches would be needed for Zope 2.x, since it just uses the Zope 3 package. Okay, I'll make a submission to the Zope 3 collector and see what comes of it. 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] Fixing STX for non-ascii
Am 13.06.2007 um 17:45 schrieb Jens Vagelpohl: If your goal is to attach a patch to the issue you're about to file, please do *not* mix up changes that affect the problem at hand with unrelated cosmetic cleanups. That will just serve to confuse the reader. Do the cleanup separately, if you have to. Thanks for the tip. I'll do the cleanup separately. I think it's worth it in case anyone wants to look at this code which is pretty cryptic at times and also inconsistent. Can I actually test this module in Zope 2? bin/zopectl test -s zope.structuredtext doesn't run any 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 http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Fixing STX for non-ascii
Am 13.06.2007 um 18:47 schrieb Jens Vagelpohl: If I need to run tests for packages that are not part of my instance home I go to the root of my software home and use test.py manually: $ /usr/local/bin/python2.4 test.py -szope.structuredtext Thanks. Again. For some reason Tres method doesn't work, I get an empty module method. throws up errors for everything so I guess I've got some investigating as to why this is happening. 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] Fixing STX for non-ascii
Am 13.06.2007 um 22:25 schrieb Charlie Clark: Thanks. Again. For some reason Tres method doesn't work, I get an empty module method. throws up errors for everything so I guess I've got some investigating as to why this is happening. So fixed my errors, written run tests including some additional ones for headers, ordered lists and bullets and submitted a separate cosmetic patch. https://bugs.launchpad.net/zope3/+bug/120376 if anyone's interested 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] Minor problem with local_pt and non-ascii portal properties
Hi, it is not possible to do anything with a local_pt in the ZMI if any of the Portal properties are non-ascii. I have a site called Düsseldorf with a local_pt containing some customisations for the homepage. With CMF 2.0 and Zope 2.9 this is not a problem but CMF 2.1 and Zope 2.10 will cause an error presumably due to the switch to Zope 3 PageTemplates. The tracaback is below. The first question is: am I doing something wrong using local_pt like this? If not the second question is: what's the best way around this? Charlie Traceback (innermost last): Module ZPublisher.Publish, line 119, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 42, in call_object Module Shared.DC.Scripts.Bindings, line 313, in __call__ Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec Module Products.PageTemplates.PageTemplateFile, line 129, in _exec Module Products.PageTemplates.PageTemplate, line 89, in pt_render Module zope.pagetemplate.pagetemplate, line 117, in pt_render Module zope.tal.talinterpreter, line 271, in __call__ Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 534, in do_optTag_tal Module zope.tal.talinterpreter, line 516, in no_tag Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 754, in do_insertStructure_tal UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 207: ordinal not in range(128) -- 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] New factory stuff
Hi, I've managed to do successfully migrate a couple of my sites to CMF 2.1, ie. I've experienced no errors and made some adjustments such as using the configure.zcml to register content-types. One thing I haven't quite sussed: my products are still registered using ContentType.addContentType function but I notice that the CMF Default types make use of zope.component.factory and seem to register factories somewhere, ie. cmf.document I haven't been able to recreate this behaviour myself despite invoking a factory. Do I need to create my own namespace to register content types or can I insert them in the cmf one? 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] ICS support for CMF Calendar
I'm working on a ics(vcs) view for CMF Calendar as it's something I use quite a lot myself. A couple of things: * the vCal format isn't really suitable for a PageTemplate although it is possible. Are there any other options? * I usually generate a unique hash using md5. CMFUid doesn't seem to support generating a hash for an object so it's probably not the right tool. Should I extend Event.py for the UID or just use a string? The UID in a vCal doesn't seem to have much relevance outside of a subscribed service, ie. you can have lots of events with essentially the same UID in calendar. At least neither Outlook nor iCal seem to mind and will continue to create new events. * is there anywhere I can extract the timezone from apart from the system? * should events come with default alarms? Comments, as always, welcome. 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] ICS support for CMF Calendar
Am 22.06.2007 um 10:34 schrieb Dan Fairs: You might try Chris Withers' Twiddler: http://www.simplistix.co.uk/software/python/twiddler Might be a piledriver for your nail though! Hi Dan, I don't want to introduce a dependency on twiddler or genshi into CMFCalendar and it's not necessary for this as the template requires little or no logic: formatting or string.Template are more than adequate but I would like to have the template outside of the calling script. You can in fact use ZPT quite well for non *ML if you use the pseudo-tags tal:content tal:content=options/start_date / is only a little bit more verbose than %(start_date)s or $start_date but it would be nice to have a handler for string.Template templates. Is it possible to work with .txt? ie. template = context.event_ics_template() template = template % options # or template.substitute(options) The bigger problem seems that there is no easy way to get the timezone needed to get appointments to work properly. vCal requires timezone id's like Europe/Amsterdam. Looks like the only thing is to coerce the time to what the server thinks is UTC and hope the client will do the conversion. 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: New factory stuff
Am 22.06.2007 um 12:04 schrieb yuppie: Did you register your factory as utility? Did you make sure 'product' is empty in your type info? I did register it as a utility but product wasn't empty! Seems to be working now Does this mean that product initialisation in __init__.py can be reduced to simple imports? ie. import Employee with no more calls to utils.ToolInit and utils.ContentInit? Do I need to create my own namespace to register content types or can I insert them in the cmf one? The only reason a namespace is used is to make sure identifiers are unique. If you use your own namespace, you don't have to care about utility names used by other products. That does indeed make sense. 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 http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Minor problem with local_pt and non-ascii portal properties
Am 22.06.2007 um 12:13 schrieb yuppie: Please try to use a script and Products.CMFDefault.utils.decode. In CMF 2.1 *all* strings passed to a template have to be unicode. Maybe 'portal_title' defined in getMainGlobals works for you, at least it shows how to use 'decode'. Displaying the local_pt works fine. I just can't edit it without changing the portal_title first which is strange because I can't understand why the portal_title is called in the ZMI when the manage_workspace is called. I thought the whole idea of local_pt was to be able to write template snippets that don't fit an existing template but this becomes impossible if you can't edit 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 http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Effective Date inconsistencies
Am 23.06.2007 um 11:18 schrieb Alexander Limi: Not so: - EffectiveDate returns a *string* 'None' when it has no value (wtf?) What would you rather have? An attribute error? This is the implementation from CMFDefault.DublinCore def EffectiveDate( self, zone=None ): Dublin Core Date element - date resource becomes effective. if zone is None: zone = _zone ed = getattr( self, 'effective_date', None ) return ed and ed.toZone(zone).ISO() or 'None' def ModificationDate( self, zone=None ): Dublin Core Date element - date resource last modified. if zone is None: zone = _zone return self.modified().toZone(zone).ISO() If you wish to overwrite this in your content types then fine but I think returning 'None' as a string is a correct because ModificationDate also returns a string. If you wish to compare the values you need to access context.effective and context_modified tal:test tal:condition=python: context.effective() context.modified() / Not that I don't think some of this stuff couldn't be cleaned up: you have to convert any of these dates back into objects to internationalise them in 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 http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Re: Effective Date inconsistencies
Am 23.06.2007 um 19:30 schrieb Alexander Limi: Wonderful, then my template code depends on some variable defined in the code as the floor date as a private variable, meaning I shouldn't introspect it. Very robust. ;) It was just an example. As I am not sure what you want do it was supposed to be illustrative. It's easy enough to move the code into a content-type for your special case with a has_effective method which will give you your boolean. ModificationDate() and EffectiveDate() should both return strings for presentation; there's another method that returns the string unknown if there is no value modified() and effective() should both return dates for comparison If additional information is required then derived types should implement the necessary additional methods. As Tres says, it might make sense to make __FLOOR_DATE, etc. less of an unknown quantity and it might make sense to make them portal or content type properties that can be set. However, before any changes are made it would be nice to have a more detailed explanation as to why you need these things. 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] ICS support for CMF Calendar
Am 22.06.2007 um 11:01 schrieb Charlie Clark: ie. template = context.event_ics_template() template = template % options # or template.substitute(options) Currently using a ZPT. Seems to be working fine. Classic skins have been finished now I need to work on browser view stuff and I haven't much of a scooby about this. I assume I need to write an adapter in Zope 3 stylee?, ie. similar to what Philip does with a PDF in his book. Grateful for another pointers. The bigger problem seems that there is no easy way to get the timezone needed to get appointments to work properly. vCal requires timezone id's like Europe/Amsterdam. Looks like the only thing is to coerce the time to what the server thinks is UTC and hope the client will do the conversion. Currently coercing to UTC which works with Apple's iCal and Outlook 2003. Kontakt seems to ignoring TZID completely but seeing as it's part of the specification, there's not a lot that can be done when it's not implemented. Sunbird is choking on something but I can't really imagine anyone is actually using this technology study. On positive side: alarms are accepted by iCal, Outlook and Kontakt so I think it makes sense to add them to events. 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
Re: [Zope-CMF] Re: [dev] five.localsitemanager: proposal
Am 23.06.2007 um 14:53 schrieb yuppie: This proposal is now implemented on CMF and five.localsitemanager trunk. Everything *seems* to work, but maybe I'm missing something. This might be a good time to review and test the changes - any feedback is welcome. Done: - There are 10 tools in CMF that are not ready for being used as utilities, they have to be used the old way until they are fixed: content_type_registry cookie_authentication portal_actions portal_calendar portal_catalog portal_skins portal_types portal_uidhandler portal_url portal_workflow Taking you up on the *any* feedback thing. I have a skin script that uses the portal_catalog traditionally via getToolByName. I don't know how to use getUtility from within a script but getToolByComponentName raises Error Type: ComponentLookupError Error Value: ICatalogTool As I don't like getting deprecation errors I've changed tack and have moved to context.portal_catalog... I've just been through most of the e-mails on this subject and I didn't end up feeling much the wiser except that the idea to move to utilities doesn't seem to be as smooth as initially envisioned. 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] five.localsitemanager: proposal
Am 26.06.2007 um 08:42 schrieb yuppie: Please don't do that. For the tools in the list quoted above getToolByName is your best choice, at least for now. I just removed the misleading deprecation warning from the trunk. (This was already done on the 2.1 branch, but never forward ported.) Thanks for the clarification. 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] Error in CMF-Core
2007-06-27 16:47:10 ERROR Application Couldn't install CMFCore Traceback (most recent call last): File /opt/Zope-2.10/lib/python/OFS/Application.py, line 780, in install_product initmethod(context) File /Users/charlieclark/Sites/cmf/Products/CMFCore/__init__.py, line 153, in initialize import Globals File /opt/Zope-2.10/lib/python/App/ProductContext.py, line 360, in registerHelp ht=APIHelpTopic.APIHelpTopic(file, '', os.path.join(path, file)) File /opt/Zope-2.10/lib/python/HelpSys/APIHelpTopic.py, line 79, in __init__ self.title=self.apis[0].name IndexError: list index out of range Traceback (most recent call last): File /opt/Zope-2.10/lib/python/Zope2/Startup/run.py, line 56, in ? run() File /opt/Zope-2.10/lib/python/Zope2/Startup/run.py, line 21, in run starter.prepare() File /opt/Zope-2.10/lib/python/Zope2/Startup/__init__.py, line 102, in prepare self.startZope() File /opt/Zope-2.10/lib/python/Zope2/Startup/__init__.py, line 278, in startZope Zope2.startup() File /opt/Zope-2.10/lib/python/Zope2/__init__.py, line 47, in startup _startup() File /opt/Zope-2.10/lib/python/Zope2/App/startup.py, line 102, in startup OFS.Application.initialize(application) File /opt/Zope-2.10/lib/python/OFS/Application.py, line 309, in initialize initializer.initialize() File /opt/Zope-2.10/lib/python/OFS/Application.py, line 338, in initialize self.install_products() File /opt/Zope-2.10/lib/python/OFS/Application.py, line 603, in install_products return install_products(app) File /opt/Zope-2.10/lib/python/OFS/Application.py, line 634, in install_products folder_permissions, raise_exc=debug_mode) File /opt/Zope-2.10/lib/python/OFS/Application.py, line 780, in install_product initmethod(context) File /opt/Zope-2.10/lib/python/Zope2/Startup/__init__.py, line 153, in initialize import Globals File /opt/Zope-2.10/lib/python/App/ProductContext.py, line 360, in registerHelp ht=APIHelpTopic.APIHelpTopic(file, '', os.path.join(path, file)) File /opt/Zope-2.10/lib/python/HelpSys/APIHelpTopic.py, line 79, in __init__ self.title=self.apis[0].name I'm in the process of updating one of my sites to CMF trunk but I'm getting the above error when starting the server or migrating. Just want to check here before filing 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] Where is getProperty?
Am 29.06.2007 um 10:07 schrieb Charlie Clark: I can't see getProperty defined anywhere. No tests are failing. Hm, I guess I should pay more attention to some e-mails: this is probably related to yuppie's posting that trunk is broken. 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: Where is getProperty?
Am 29.06.2007 um 10:37 schrieb yuppie: Looks like your utility isn't acquisition wrapped - getProperty is usually acquired from the site root. 1.) Your site seems to broken, there is currently no migration code that updates the lookup class if you have an old site manager instance. 2.) getProperty should become part of the IPropertiesTool interface and implementation. It should not rely on acquisition. It's coming from the index_html.py script: return context.index_html_template(**decode(options, script)) How should I be wrapping 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 http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Where is getProperty?
Am 29.06.2007 um 11:04 schrieb yuppie: You shouldn't, getUtility should. Can you please test the attached patch? It should fix your site manager instance on the fly. Seems to do the trick! Thanks 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] tools-as-utilities roadmap
Am 06.07.2007 um 17:22 schrieb yuppie: I can live with that approach, but would like to see CMF 2.1 adjusted: 'getToolByInterfaceName' is a completely misleading method name if tools will not become utilities. This method has no 'context' (or 'REQUEST') argument, so it can't return tools. It returns utilities. 'getUtilityByInterfaceName' would be a much better name for a 'getUtility' replacement used in untrusted code. This makes a lot of sense to me. Did it get included in the last beta or is it roadmap stuff? 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] Moving to browser views
Hi,
I making my first stab at browser views for my iCal support having
finally come up with some templates that seem to produce files that
work with most calendar programs.
I have a couple of questions:
1) should I implement them as BrowserViews calling templates or
should I use an adapter? The templates are TAL and the only
difference to an HTML page is the different response header.
2) how do I pass in values derived specifically for these views? ie.
going from
options = {}
options['name'] = charlie
...
return context.mytemplate(**options)
to the appropriate call inside a browser view. I haven't been able to
work this out based on the examples or the Zope 3 book.
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] Moving to browser views
Am 18.07.2007 um 21:51 schrieb Charlie Clark:
2) how do I pass in values derived specifically for these views?
ie. going from
options = {}
options['name'] = charlie
...
return context.mytemplate(**options)
Looks like I've solved that:
return ViewPageTemplateFile('templates/test.pt')(self, **options)
However, seeing as all the examples such as document.py and event.py
are different this probably isn't the correct way to proceed...
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: Moving to browser views
Am 18.07.2007 um 22:07 schrieb Rob Miller: while it may be appropriate in some cases to pass values directly into the template like this, usually the template pulls the values from the view class. you can make name an attribute (or a property) of the view class, and then use the view/name TALES expression within the template. Okay, thanks! I'm nearly there. I think. %-? ;-) Because I'm only creating essentially a slightly different view of an event I've taken the ZCML for the standard view as a lead: browser:page for=Products.CMFCalendar.interfaces.IEvent layer=Products.CMFDefault.interfaces.ICMFDefaultSkin name=event_iCal_view class=.event.EventiCalView permission=zope2.View / is event_iCal_view my view class? So, let's say I need to turn my creation date into 20030127T09Z I can call this in my view class via self.startdate = self.context.CreationDate() and call this in my template via view/startdate? 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: Moving to browser views
Am 18.07.2007 um 23:03 schrieb Philipp von Weitershausen: shameless-plug You know, I wrote a whole book for learning how to use this Zope 3 stuffm (and that includes explanations of how to use it in Zope 2 via Five). /shameless-plug No need to be shameless, Mr. Gallagher! I've got the book and am working my way through it. It's very good but it didn't cover this in quite the detail I need. 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: Moving to browser views
Am 18.07.2007 um 23:10 schrieb Maurits van Rees: No, that is the name. That means you can do tal:define=view context/@@event_iCal_view in a template that has an IEvent provider as context. The class is the EventiCalView class in event.py. Yes, thanks. So, let's say I need to turn my creation date into 20030127T09Z I can call this in my view class via self.startdate = self.context.CreationDate() and call this in my template via view/startdate? Yes. You need to do the tal:define above first though, unless there is some other magic (well, code) that hooks up this view to that specific template. Actually I don't define the view explicitly in the template as my class calls it directly. I think that is done when you specify template=mytemplate in the zcml snippet. Well, I've now got two classes (EventvCalView has to set different headers so I can't see an easy way round this in ZCML) and two different templates. Everything is working fine apart from the content-type is remaining steadfastly text/html! Content-Disposition is being set correctly. How do I fix this? ;-) Tomorrow I'll try and write the tests for this so that I can submit the patch. And I'll also have something to talk about at the Rheinland ZUG meeting on Friday! ;-) 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: Moving to browser views
Am 18.07.2007 um 23:32 schrieb Charlie Clark: Well, I've now got two classes (EventvCalView has to set different headers so I can't see an easy way round this in ZCML) and two different templates. Everything is working fine apart from the content-type is remaining steadfastly text/html! Content- Disposition is being set correctly. How do I fix this? ;-) mm, calling the template gets the response header reset... 1) call the template 2) set the headers 3) write the response 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: Plone needs a release this week
Am 31.07.2007 um 15:51 schrieb yuppie: AFAICS the premature GenericSetup 1.3 release has the biggest issues: I'm behind the loop on GenericSetup having only encountered it when writing a content type for a single site. I would appreciate an explanation of the difference between declarative and imperative as linguistically they are almost identical. I have never done imports exports so would appreciate knowing where to go to read up on them so that I can contribute to the debate or at least understand it fully. ... I still consider the VERSION.txt support a mis-feature. VERSION.txt is really nasty anyway but if it is still around you are right: the profile version is not necessarily the same as the product version and so nothing should assume this. five.localsitemanager still has no UI for inspecting and editing component registrations. I added the 'components_xmlconfig.html' view to GenericSetup as an alternative way to do this, but a normal UI would still be useful. CMF seems to be in good shape, but the migration code and documentation could need some cleanup: - The 2.1 migration should use the new 'upgradeStep' feature, the on-the-fly migration code in PortalObjectBase.getSiteManager should be replaced by an 'upgradeStep' - It might be useful to review the docstrings in CMFCore.utils and interfaces._tools. There are misleading comments like BBB: for use in 'getToolByName'; in the future, prefer 'zapi.getUtility (IActionsTool)'. Seems not all docs reflect the latest tools-as- utilities changes. Yes, please! I recently really struggled writing a browser view because of the lack of doc strings. I can only assume that BBB has something to do with something bad. I think the most important issues can be resolved before the weekend *if* some people are willing to help. Having recently given a presentation (in German) on CMF 2.1 I hope at least to be contributing to the documentation. However, as noted above there are significant areas with which I have little or no experience. 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: Plone needs a release this week
Am 31.07.2007 um 17:17 schrieb Tres Seaver: 'imperative' indicates that the profile executes arbitrary Python code; 'declarative' indecates that the profile applies external configuration data, read from one or more data files in the profile. Running two imperative profiles, A and B, may create different effects based on the order in which they are run, or whether they are run more than once. With declarative profiles, OTOH, the state is all captured in the data file(s), which means there are no ordering depencencies, and it is always safe (idempotent) to reapply the step. Thanks for the explanation, Tres. I still find the term distinction somewhat confusing and would suggest runtime or ad hoc for the second one but if it is an established term in software development then who am I to rewrite the book! While I have a fairly intense dislike of XML I am fully in favour on configuration being kept external to an application although I don't see how conflicts: two products wishing to configure the same object differently can be resolved this way. However, it seems I am not the only one who been confused by the discussion. Would it make sense to move it to a wiki where we have use cases, problems, etc? What I am personally missing are examples of current gotchas and how they can be resolved. Does http://zope.org/Products/CMF/docs/requirements/proposals/ GenericSetup_architectureflect the current status? 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] script to update permissions
Am 02.08.2007 um 23:17 schrieb David Chelimsky: I want to write a script that will traverse a directory tree and update the View permission on any Folder that meets certain criteria. Suggestions? This might sound trite but walking a folder hierarchy shouldn't be difficult and assuming you give the Script a manager proxy role it shouldn't have any trouble adjusting permissions. However, this might not be what you want. Assuming the folders aquire the permissions of the parent, might it not be simpler to adjust the permissions of the highest level folder? This would certainly be the most manageable. 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: CMF collector on Launchpad?
Am 13.08.2007 um 10:49 schrieb Hanno Schlichting: I'm +0.5 on moving away from anything on zope.org. I find the collector UI and speed suboptimal to work with. Launchpad provides a reasonable good bug tracker from my experience (I mostly reported bugs against the launchpad translation system itself in the past ;)). Personally I find trac a lot more efficient to work with, though. But it's UI is definitely geared towards developers (which is in the end the prime target group for CMF). Trac certainly *looks* good and has done to highlight usability deficiences of other bug trackers such as Bugzilla and Collector. I'll dare to speak out the unthinkable and as an alternative option suggest to move the CMF bug tracker to a trac instance hosted on plone.org. Andrew Milton has at least done a wrapper so you can run Trac on a Zope site. But having spent some time on Trac I would be against using it in its current form for a product as complex as the CMF. It has an appalling data model which is simply not suited to any form of dependency. A common user database between the Plone and CMF bug trackers is a bigger benefit than the common user base between CMF and Zope I think. But maybe our two communities still don't overlap enough for that idea to work out ;) I think there's merit in having some form of connection Zope - CMF - Plone for reporting bugs in which case I would be in favour of either modifying Collector or Launchpad for our needs. I've not posted or dealt with a great many bugs but have not found the form of the Collector to be a big problem. It's certainly easier to use than Bugzilla. What is often a greater issue is actually tackling bugs that do get submitted. 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] Design approach questions: unique content-ish items?
Am 17.09.2007 um 21:10 schrieb Doyon, Jean-Francois: Let's use the simplest example I can think of: The site search interface. 1) There's the portal_catalog tool, which does many things, but doesn't do the UI. 2) Presume that a given site only has one site search 3) Presume that you might host many sites, and you might want to provide some configurable content and/or configuration within the content of the search UI (DC Metadata and other things?) 4) You need your own code to wrap portal_catalog, put a look/ templates to it, customize some search logic, etc ... 5) The location of the search object might be anywhere in the folder structure of a given site (root or otherwise). At least I do not want to presume as to where a client might want to put it (beause navigation is usually affected by content structure for better or worst. As are breadcrumbs). I can't see what's wrong with the standard approach to this. You seem to be able to define your basic functionality very well and also which aspects of the UI and functionality you wish to make optional or customisable for site administrators essentially through skinning. Write a Class to give your McGuffin everything it needs, even if this is largely inheriting from portal functionality and write the necessary components such as controllers and templates which can be customised as required. This would make the object globally accessible via URL traversal, eg. /mcguffin. You would have only one instance of it but this instance would look and behave differently if customised lower in the hierarchy. I am not sure how well this would work with different CMF instances as opposed to subsites but I am also not so sure from your description whether that is what you want. I think your attempt to add utility methods to such an object is confusing and, therefore, probably 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 http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Design approach questions: unique content-ish items?
Am 14.09.2007 um 21:21 schrieb Doyon, Jean-Francois: The simple example is the search stuff. I have a search form, search results, etc ... build around a content-ish type that in turn uses portal_catalog. This type should exist only once in the site. It is in many ways a tool, though it has a user oriented web interface. It also needs things like DC Metadata support (Corporate policy, ALL our web pages must have this), and maybe I want to let a site owner configure other properties of their instance of the search engine. Of course, I can just try it, but I'm curious as to high level thoughts on this type of object, how it can or should be handled, if anyone has faced this before and how they approach it, etc ... Of course, I can't see any way around utilities needing to be in the root :( I suppose I can fake paths and breadcrumbs or some such thing if needed ... It's an intriguing post but I think you need to provide more information on the objects methods you want available for your sites. It sounds a bit like you have something (call it a McGuffin for any film buffs out there) that is installed in the root so that it should be available for any lower level item but it should also be customisable in some way. Why is this different to default instance of the McGuffin installed at root level with local, customised McGuffins installed lower down the hierarchy? This is standard way to do things in Zope, ie. you can overwrite the document_view method of any particular document. 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] Eggification redux
Am 25.09.2007 um 02:05 schrieb Tres Seaver: I'd like to break the remaining CMF packages out (moving from '/ CMF' to 'Products.CMFCore', 'Products.CMFDefault', etc.) and push the 2.1.0 eggs out, as well as equivalent changes for PluggableAuthService and PluginRegistry. Any objections, or other thoughts? While I am very sceptical about the move to eggs (I know it's inevitable) and I hope we can avoid some of the problems that seem to be affecting Grok as a result. Regarding the naming change: this would be consistent with other Zope 3 style changes. 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] Known working sets II [was: Eggification redux]
Am 25.09.2007 um 14:06 schrieb Philipp von Weitershausen: * A versions.cfg that's loaded via HTTP. zc.buildout actually supports this now which makes it quite appealing. Also, far as I know, all major deployers of Zope3 that use zc.buildout for deployment use this form of pinning egg versions right now, which means it's actually being used out there. This sounds essentially similar to what Tres is proposing: an online resource with explicit configuration details. * Adding version conflict resolution to zc.buildout and/or setuptools. That way you could create meta eggs (e.g. the 'Zope' egg) with '==' version specificers (for Grok, the 'grok' egg would function as the meta egg as well). If this would cause version conflicts (and they often occur in buildout due to the lack of a full dependency tree before download), it should be possible to say which egg's versions are authoritative. This sounds like an accident waiting to happen in terms of maintenance. I guess the underlying problem is the move towards the more library- based approach to Zope which makes mixing packages a bit more challenging. I haven't spent a lot of time with the various Linux package managers because most of my unix experience has been with FreeBSD where make install just works, except if you want to install unixODBC and iODBC at the same time ;-) but I have been bitten by different libraries going in different places and incompatabilities between libraries. I've also had some experience with CPAN which always does make test before installing and given the chance of incompatibilities I would hope that any installer would run tests on a temporary install before actually installing anything for real. I don't think any installer should be able to break existing components with default settings. My experiences suggest that I will be installing from source for a while yet. 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] Controlling permissions for actions
Hi, how do I control access to a PythonScript that should only be available as an action? I've setup the action for the site and given it a permission but this seems only to affect it's visibility for users. ie. I have a script manage_wombats and configured action for it with the Permission Manage portal. It is listed as an action only for managers but is globally available as a URL. 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] Controlling permissions for actions
Am 27.09.2007 um 12:40 schrieb Jens Vagelpohl: If you have a script somewhere in the skins or in your site it will *always* be available for people who call it up directly by URL. There is no builtin mechanism in Zope or the CMF to control that. You could do some manual checking inside the script to make sure the calling user has the right permissions or the script is not called by direct URL traversal. Thanks, I thought as much. It's not difficult to check the user for the correct role and return an index page otherwise but I guess I need to start explicitly attaching such scripts to objects and their methods but I'm still on that learning curve, which is probably not helped by the fact I nearly always store data in an RDBMS and I don't use O/R mappers. 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] Controlling permissions for actions
Am 27.09.2007 um 13:09 schrieb Wichert Akkerman: You can use a browser view instead of a python script and protect that with a permission. That's good to hear! This is probably going to be my last skins- based project and I will try and move it to a browser view approach. It's been my first real attempt to implement application logic in the CMF and has been an interesting experience coming from a more classical TTW Zope 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] Controlling permissions for actions
Am 27.09.2007 um 21:26 schrieb Dieter Maurer: You can, of course, restrict its View permission -- via its Security tab, if it is in the ZODB, or with a *.metadata files for an FSObject. I'm used to restrictions in the ZODB: I usually put these kind of things in a folder with I then restrict. Can you tell me more about metadata? 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] Move CMF collector to Launchpad (redux)
Am 25.10.2007 um 12:37 schrieb Jens Vagelpohl: Can we have a show of hands, so to speak? Given my minimal contribution so far I will abstain. However, before any vote is taken I think it is important to discuss the issues. OTOH imagine how elections would work if we were required to provide justifications for our votes! 0) Jens - get yerself a better browser! ;-) FFS Omniweb :-D OTOH I also complain bitterly when one thing does not work with my favourite tool. Eventually I grew up and swapped NetPositive fer Opera ! :-P hm, the footer doesn't work proply with Opera 9.5!!! 1) I like the Canonical team: Steve Alexander is top and Gustavo Niemeyer has come up with a very reasonable ORM for Launchpad. 2) Data protection: hosting on launchpad.net might raise data protection issues for existing zope.org users. 3) I'm not particularly attached to the Zope collector but the UI for Launchpad isn't brilliant either. Trac's UI is lovely but its data model is totally borked. I'm planning to take a look at Roundup but the argument for consolidating Zope + CMF bugs on a single system is extremely persuasive. 4) It's great when someone else does the work for you and this should be underestimated. 5) E-mail integration: this has to work properly and should include reply by e-mail and reflect user preferences for whole or incremental history. In conclusion: I'm still abstaining because, although the arguments for the automated migration are strong, we are under no time pressure and might like to see some features added before any migration. 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] Move CMF collector to Launchpad (redux)
Am 27.10.2007 um 01:52 schrieb Jens Vagelpohl: OW is a well-supported browser that has been around longer than OS X itself, and it uses the very same WebKit underpinnings Safari uses, just different versions. Its ad filtering is superior to any other browser on my system, and it has a lot of features other browsers either don't have at all or are slow to deliver. However, that's completely off-topic here. No my browser is bigger than yours, please. It was a tongue-in-cheek remark: while whether a particular browser is supported or not sounds like a surprising criterium for the choice of bug tracker but given how much we work with our browsers a completely reasonable one. 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] Accessing the context
Dear all, a simple question with hopefully a simple answer! How do I access objects from an object's context or hierarchy? Specifically I'd like to be able to access a ZopeDA connection for a site. Is it correct that I have to register this somewhere to be able to access it from a portal object? 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] Accessing the context
Am 30.10.2007 um 16:19 schrieb robert rottermann:
da = getattr('my_da_or_what_ever', context, None)
Doesn't that only work within a PythonScript? I need access from
within a content type, ie. real Python code?
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] Accessing the context
Am 30.10.2007 um 16:53 schrieb Wichert Akkerman: getattr(context, 'my_da_or_what_ever', None) works a bit better. Doesn't that only work within a PythonScript? I need access from within a content type, ie. real Python code? It's called acquisition and it works everywhere. Try it. Yes, but the context isn't available everywhere. How do I get hold of 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 http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Accessing the context
Am 30.10.2007 um 17:04 schrieb Andrew Sawyers: If it's in a content type's class, why not: id = getattr(self, 'da_id', None) Just using self as the context should be fine. -- that of course presumes that the type is wrapped properly when you call that within your method. mm, currently getting None back so I guess I'm not wrapping things properly. This is a skeleton bit of code: class ContentType(PortalContent): A content type with access to an external database def __init__(self, id): self.id = id DA = getattr(self, 'MyDA', None) #self.conn = DA() # not working at the moment because DA is None Is it wrong to try and do this in my __init__ ? Regarding your other suggestion: yes, I probably will factor this out into a utility once I've worked out how to access the DA!!! 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] Accessing the context
Am 30.10.2007 um 17:40 schrieb Wichert Akkerman:
__init__ is indeed the wrong place: when the instance is created it is
not placed in an acquisition context yet.
That would indeed explain things!!! Is it okay to call a method which
does this from __init__ ?
def __init__(self, id):
self.id = id
self.set_connection()
security.declarePublic('set_connection')
def set_connection(self):
DA = (self, 'myDA', None)
This is also not working. :-/
Thanks very much for your help.
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] Accessing the context
Am 30.10.2007 um 18:13 schrieb robert rottermann: there are two places where you can put your code, in both cases acquisition is fully functional. Thanks very much! Now hit an error that my database connection object can't be pickled but at least I can access it! :-D 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] First steps with tools
Hi,
thanks again to everyone who helped me yesterday. I feel understand
things a lot better now. However, there are still a lot of things I
need to learn.
As suggested I'm trying to factor out a function from a content type
into utility so that it can be used for any content type. My utility
is simple: I want to be able to publish documents to my subscribers.
The following code is based on bits of the RegistrationTool and
elsewhere but with a little more understanding than my usual copy
paste:
class PublishTool(BaseTool)
def publishByEmail(self, document=):
text = getattr(aq_base(document), EditableBody)
subject = getattr(aq_base(document), Title)
lang = getattr(aq_base(document), lang)
ptool = getUtility(IPropertiesTool)
headers = {}
headers['Subject'] = subject
headers['From'] = ptool.email_from_address
host = getUtility(IMailHost)
subscibers = self.getSubscribersByLanguage(lang)
for s in subscribers:
headers['To'] = s.email
email = makeEmail(decode(text, script), script, headers)
try:
host.send(email)
except:
# don't stop just because you can't send a single e-mail
Now, apart from obvious problems that this is not the way to handle
with large subscriptions - MailDrop or a dedicated mailing list are
better for that, I know and I suspect makeEmail might not work in
this context - what is the best way to make this available as an
action for my documents? Looking at CMFDefault it seems that
currently I would actually do much of this work in a PythonScript
with attendant template very similar to how discussions work. Is this
correct? Or is there another way to provide this action to documents
and make it available only when the user has the correct permissions?
While I've been working on this I've noticed is that there are no
browser views for the various utilities such as logging in, signing
up or having a discussion. Is this because they haven't been done yet
or am I looking in the wrong place?
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
