Am Dienstag, den 17.05.2005, 23:43 -0500 schrieb Ian Bicking:
> >>
> close together, which I think is appropriate.  Complex logic in ZPT 
> exists, right now; has anyone here not encountered this?  I think my 
> <select> example is pretty normal; the alternative is either to push 
> lots of display logic into the controller, create a third layer between 
> controller and view, render large pieces of content outside of ZPT 

Well. Not really. All you need is a moderate good abstraction of
your data. For example I just use a form controller class to
prepare the data for ZPT. All I need there are path expressions
only. And you decide in the ZPT what you display, the class
provides just the service. You can have a list, a group of radio
buttons or checkboxes or a select.

> entirely, or figure out a way to better mix complex logic and ZPT.  I'm 
> proposing the last of those.  The first is the current status quo. 
> Rending code outside of ZPT is just the thing I mention above, and seems 
> like exactly what you don't want.

Outside really means outside, that is where there are no <tag> s :-)

> A third layer is possible, and I'm open to that, but it's basically the 
> same thing I'm talking about except split into two documents. 
> Personally I think two tightly bound documents (and these would be 
> *very* tightly bound) are just begging to be combined, which is why I 
> prefer putting the block into ZPT.

It would just ease developing a bit. Otoh, just wiring the
[test] tab of a ZPT to an unbound python script somewhere
else could be just enough.

ZPT mailing list

Reply via email to