Am Dienstag, den 17.05.2005, 14:00 -0500 schrieb Ian Bicking: > Well, ZPT is pretty slow moving these days, but there's a feature that > I'd be interested in. It's inspired by Kid > (http://lesscode.org/projects/kid/), which is very similar to ZPT. In > it, you can have Python code: > > <?python > ... > ?> > > But unlike PHP, ASP, and family, the Python code can't produce output > and must be self-contained. This allows for a nice continuum as code > becomes more complex; you can start out with a normal tal expression, > move to a python: tal expression, and then move things into a header, > and finally move things out into an external script. > > For example, imagine a select box: > > <select name="state"> > <option tal:repeat="state options/states" > tal:attributes="href state/code; > selected python: test(state['code'] == request.get('state', > options.get('state'), 'selected')"> > <span tal:replace="state/code"/> > <span tal:condition="state/long_name">: > <span tal:replace="state/long_name"/></span> > </option> > </select> > > Brutal, eh? But we've probably all been there. With a PI: > > <?python > state_sel = [] > for state in options['states']: > state_data = {} > if state['code'] == request.get('state', options.get('state')): > state_data['selected'] = 'selected' > state_data['description'] = state_data['code'] = state['code'] > if state['long_name']: > state_data['description'] += ': ' + state['long_name'] > state_sel.append(state_data) > ?> > <select name="state"> > <option tal:repeat="state state_sel" > tal:attributes="value state/code selected state/selected | nothing" > tal:content="state/description">state</option> > </select> > > It's not any shorter, but it sure is easier to write, and keeps the > markup fairly clean. > > Of course, in most environments there's ways to move this code elsewhere > -- into an external function or into the code that calls this template. > But that turns what's actually a very localized bit of display-related > code into something else. This doesn't actually *belong* in the > "controller"; the Python code is clearly part of the view. But it's > also horribly ugly when put into the markup. > > I think it's actually really good for ZPT's ideal of being friendly to > people with different roles -- the markup becomes simple enough for > someone who knows only HTML, and for those middling people (of which I > think there are many) who would be comfortable with Python but aren't > necessarily comfortable with adding code to a controller or a Python > script (code which probably has much different duties), it gives them an > easy transitional area. > > Anyway, I think it's a nice idea, and would fit well into ZPT.
-1 for me. I'd even like to remove python: expressions and tal:define because of their constant abuse. +1 would be a solution where you can have one python script attached to the Template to prepare things - to have all display related code in one place. Just like precondition in images/files or as 2nd ZMI tab with pure python code. Tino. _______________________________________________ ZPT mailing list [email protected] http://mail.zope.org/mailman/listinfo/zpt
