[Zope3-dev] RFC: abolishing python: expressions in ZPT TALES

[Jeff Shell]

Actually, I just found another place where Python expressions are
handy. I have a simple but kindof specialized form - one that is too
simple and too specific to really go through the Zope schema system
without a lot of gnashing of teeth. It may be easier to do with
zope.formlib, but it's still not something I want to find out. With
only two radio buttons and a checklist (in one variation) that can
appear or disappear based on the radio button settings (via
Javascript) or the current configuration. Figuring out how to go
through all the schema stuff and present it in the way I want to
present it is just way too much work for this problem domain. So here
I am with:

            <input type="radio" name="share_with" value="EDITORS"
                tal:attributes="checked python:currentSetting == 'EDITORS'"
                id="cb_everybody">

I suppose I could go through and apply things to the view and set true
or false attributes like 'currentSettingIsEditors'
'currentSettingIsEverybody', but that seems a little ridiculous for
this situation.

This is a rare case as well, usually the zope.app.form or zope.formlib
material provides more than enough. But those are both overkill for
the situation I have here, especially when some simple Javascript
needs to be applied.

For the record - the formlib stuff doesn't really work here because
there's no real Schema of any kind to work with; it's a multiple
choice display with a lot of information displayed for each radio
button choice (how to do this easily with schemas I just don't know.
Vocabularies still make my brain hurt when I try to use them, binding
the right custom widget for some of these collection / choice type
fields is difficult, and this situation really wants a custom widget
to render this text as I want it); and one of the choices may enable
another field to show up when selected. The view behind it does a lot
of computation to figure out the current setting. This is all to
provide a drop-dead-easy security form for certain objects where a
restricted user can opt to share a particular object with an even more
restricted set of users, or keep it public. It seemed easier to use
basic HTML skills to design the UI and dedicate the view's logic to
computing the current setting and applying the user's decision. Not
having Python expressions to do a boolean test to see which radio
button to highlight wouldn't have been the end of the world, but it
would have been severely frustrating. (Figuring out all of the ways
that security and 'anonymous' access can best be granted or denied was
more than enough fun on its own, thank you).

On 12/28/05, Rocky Burt <rocky at serverzen.com> wrote:
> Hi all,
>
> Please don't mistake this as a proposal or anything of the sort but I
> was just curious what the rest of the zope3 community thought on this
> particular topic.  (Please forgive me if this topic has been exhaused to
> death already)
>
> Its my personal opinion that anytime a page template requires logic
> complicated enough to warrant using a 'python:' expression, that logic
> should be re-thought and placed into a view class.  I know that some
> python: expressions are fairly simple, but for an HTML designer, *any*
> python: portions are dangerous to touch (and shouldn't be touched by the
> HTML designer).
>
> What do you all think?
>
> Regards,
> Rocky
>
>
> --
> Rocky Burt
> ServerZen Software -- http://www.serverzen.com
> ServerZen Hosting -- http://www.serverzenhosting.net
> News About The Server -- http://www.serverzen.net
>
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.com
>
>