Re: [Repoze-dev] repoze.plone use with plone versions 3.1?
Hanno Schlichting wrote: On Sun, Jan 17, 2010 at 10:51 AM, Wichert Akkerman wich...@wiggy.net wrote: There is something to consider: I suspect more things are started to require the new publisher events from Zope2, either directly or via one of the backport packages for Zope 2.10. I'm not sure if repoze.zope2 supports those. A fork clearly comes with a cost here. I think neither the publisher events nor the exception view changes of Zope 2.12 have made their way into repoze.zope2. It's not all that hard to do, but without someone driving the project forward, we have diverging code bases and something like Plone 4.0a3 probably doesn't run on repoze.zope2 right now. repoze.zope2, at this point, could be considered one or both of the following: - A proof of concept for Zope 2 WSGI support, waiting to be merged in some fashion. Tres has actually made progress towards doing this on the Zope trunk. - A separate project looking for a maintainer who cares deeply about feature parity with the Zope 2 trunk. Martin has provided some patches that make repoze.zope2 more compatible with the stock Zope 2 publisher over the last year or so, but I'm pretty sure he's not interested in doing that forever. I think everybody is in favor of merging, at least in spirit, to the trunk. And actually, on the Zope 2 trunk, Tres has a notional merge all done except for the cryin': there is a WSGIPublisher IIRC, but it still has some issues. For example, when you visit the ZMI, some ZMI icons are not renderered properly. And there are probably some other lingering issues, which will take a while to shake out. The existence of a WSGIPublisher in the Zope 2 trunk won't help folks who use the Plone defaults for several years, though. I'm not sure what to do in that interregnum. I think about the best we can do is continue to offer r.zope2 up on an as-is basis and hope someone comes along who wants to keep it patched up until the current Zope 2 trunk is Plone's default. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plone use with plone versions 3.1?
Hanno Schlichting wrote: On Sun, Jan 17, 2010 at 10:51 AM, Wichert Akkermanwich...@wiggy.net wrote: There is something to consider: I suspect more things are started to require the new publisher events from Zope2, either directly or via one of the backport packages for Zope 2.10. I'm not sure if repoze.zope2 supports those. A fork clearly comes with a cost here. I think neither the publisher events nor the exception view changes of Zope 2.12 have made their way into repoze.zope2. It's not all that hard to do, but without someone driving the project forward, we have diverging code bases and something like Plone 4.0a3 probably doesn't run on repoze.zope2 right now. Exception view changes did, I think. Publisher events didn't. Anyway, I think the next big thing for Zope 2 is to merge this back into the WSGI publisher, which Tres did some fixing up on recently as well. I'd be willing to help with that, since I have a fair amount of experience with repoze.zope2. I'm hoping to drag Hanno down that particular gutter too. :) My dream would be a Zope 2.13 that would be an unsupported-but-working configuration for Plone 4 (probably via an extended KGS with some additional packages not part of the core 2.13 KGS but required for 2.12 compatibility), with a WSGI publisher by default based on repoze.zope2 + some cleanups. I think this is feasible, especially if we say that we are only going to support a defined API for the publisher, and drop some of the implicit-and-weird stuff that the current ZPublisher does. That means that if you want 100% compatibility, you work with ZPublisher; if you want 80% compatibility and WSGI, you use the new publisher. The advantage is that repoze.zope2 has decent internal documentation and tests and is a lot easier to understand than ZPublisher. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] chameleon.formish and formish i18n
Hi all,
what is the preferred form generation tool for repoze.bfg? I tried
chameleon.formish, which seems a nice solution.
I found the fileupload-widget is broken, attached is a patch to fix it.
This is probably the wrong list to ask about i18n support of formish,
but since chameleon is involved the key is maybe there. I solved the
localization issue of the form labels with the following monkey patch,
but I'm not really happy to use monkey patches in general. does anyone
know of a better solution?
-Tom
from formish.forms import Field
from zope.i18nmessageid.message import Message
from zope.i18n import translate
@property
def title(self):
title = self._orig_title
if isinstance(title, Message):
lang = getattr(self.form, 'target_language', 'en')
return translate(title, target_language=lang)
return title
Field._orig_title = Field.title
Field.title = title
@property
def description(self):
description = self._orig_description
if isinstance(description, Message):
lang = getattr(self.form, 'target_language', 'en')
return translate(description, target_language=lang)
return description
Field._orig_description = Field.description
Field.description = description
Index:
chameleon.formish/chameleon/formish/templates/zpt/formish/widgets/FileUpload/widget.html
===
---
chameleon.formish/chameleon/formish/templates/zpt/formish/widgets/FileUpload/widget.html
(Revision 7981)
+++
chameleon.formish/chameleon/formish/templates/zpt/formish/widgets/FileUpload/widget.html
(Arbeitskopie)
@@ -1,19 +1,17 @@
-div class=preview
- tal:define=star ('*' in field.name);
+tal:var define=star ('*' in field.name);
value_name (not star) and field.value['name'][0] or '';
value_default (not star) and field.value['default'][0] or '';
- mimetype (not star) and field.value['mimetype'][0] or '';
- mimetype mimetype or '';
-
+ mimetype (not star) and field.value['mimetype'][0] or '';
+div class=preview
div tal:condition=field.widget.show_file_preview
class=icon ${mimetype.replace('/','_')}
-img tal:condition=field.widget.show_image_thumbnail and value name != ''
and mimetype.startswith('image')
+img tal:condition=field.widget.show_image_thumbnail and value_name != ''
and mimetype.startswith('image')
src=${field.widget.urlfactory(value_name)}?size=20x20/
-img tal:condition=not (field.widget.show_image_thumbnail and value name
!= '' and mimetype.startswith('image')) and field.widget_thumbnail_default is
not None
- src=${field.widget.image_thumbnail_default/
+ img tal:condition=not (field.widget.show_image_thumbnail and
value_name != '' and mimetype.startswith('image')) and
field.widget.image_thumbnail_default is not None
+src=${field.widget.image_thumbnail_default}/
/div
a tal:condition=field.widget.show_download_link
- href=${field.widget.urlfactory(value_name)download/a
+ href=${field.widget.urlfactory(value_name)}download/a
/div
input id=${field.cssname}-remove type=checkbox
name=${field.name}.remove value=true /
@@ -21,3 +19,4 @@
input id=${field.cssname}-mimetype type=hidden
name=${field.name}.mimetype value=${mimetype} /
input id=${field.cssname}-default type=hidden
name=${field.name}.default value=${value_default} /
input id=${field.cssname} type=file name=${field.name}.file /
+/tal:var
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] chameleon.formish and formish i18n
Hi Tom, On Mon, Jan 18, 2010 at 6:17 AM, Tom Gross itconse...@gmail.com wrote: Hi all, what is the preferred form generation tool for repoze.bfg? I tried chameleon.formish, which seems a nice solution. I found the fileupload-widget is broken, attached is a patch to fix it. This is probably the wrong list to ask about i18n support of formish, but since chameleon is involved the key is maybe there. I solved the localization issue of the form labels with the following monkey patch, but I'm not really happy to use monkey patches in general. does anyone know of a better solution? I wouldn't argue that it's better ... I've been using formencode which has i18n support, formencode.validators is easy to work with, the package has minimal html generation (formencode.htmlfill) which was a design decision. http://formencode.org/i18n.html http://formencode.org/Design.html Best, Darryl -Tom from formish.forms import Field from zope.i18nmessageid.message import Message from zope.i18n import translate @property def title(self): title = self._orig_title if isinstance(title, Message): lang = getattr(self.form, 'target_language', 'en') return translate(title, target_language=lang) return title Field._orig_title = Field.title Field.title = title @property def description(self): description = self._orig_description if isinstance(description, Message): lang = getattr(self.form, 'target_language', 'en') return translate(description, target_language=lang) return description Field._orig_description = Field.description Field.description = description ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
