Alberto Valverde wrote: > > > > > i think i'm going to try and make an abstracted form class though - > > i'm > > really partial to the approach of having a class that calls all the > > widgets (if thats what you want ) or the access the args ( if thats > > what you want ) and can create an appropriate output ( perhaps for tal > > instead of kid ). aside from being able to switch outputs at the user > > level, an approach like that *should* be able to help compensate for > > API changes ( like how the .8x doesn't work with .9x etc ) > > I'm not sure I understand what you mean here so I'll try to guess... > If you want to hack on TG's widgets template engine support (the > easiest way IMO to customize the kind of output widget's produce) > you'd be interested in load_kid_template in meta.py. What would be > ideal is a template engine for widgets, which took strings like > "cheetah:templates.tpl" like expose decorator does and applies the > correct template engine for the output. However, different template > engines for widgets are not a priority right now (you're the first > one AFAIK that has suggested this). >
Mmm I haven't tested it but I think that something like "cheetah:templates.tpl" already works even for widgets templates. Ciao Michele --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
