On Fri, Jun 24, 2011 at 10:02 PM, Chris McDonough <[email protected]> wrote:
> > Not really. As far as I can tell, adding a css_class to the mix only > > puts it into the input tag, not any of the containing markup. So, > > doing something trivial like putting some text-inputs side-by-side is > > not possible. I don't consider this to be advanced layout. > > I don't mean Deform's css_class setting. I mean CSS classes in general; > adding them will require changes to existing templates. > Aha. I get it. Thanks. > So, it seems that one cannot over-ride the highest level field in the > > schema without all the others. Does one have to explicitly set the > > renderer back to the "default" one in all children widgets? What would > > this function be called? > > The first sentence is true if you mean "I want to use a different > renderer in Deform" as opposed to "I want to use a different template > that matches the current renderer in use for this field". > For future searchers and posterity, what I want(ed) is... I want to set my own renderer for the Form() but not for the fields within the form. I'm cool with the stock templates for input elements, just not with the gross <form> itself. This would allow me to have my own custom template for Form() but keep the ones in deform for the rest. Seems like your suggestion of setting the widget.template + copying-over all the deform templates is the answer. > But you can > override the template for a single instance of a widget as necessary > when it's used in a form: > > widget = TextInputWidget() > widget.template = 'mytextinput' > > class SomeSchema(object): > foo = SchemaNode(widget=widget) > > The "widget" above will look for a "mytextinput.pt" template on the > search path instead of the default "textinput.pt" template used by > Deform (if you're using the default Chameleon renderer). > Great. This will work ok for me. > All this said, it really is what it is, and I don't mind if folks don't > use it. I have no concrete theory about how to do something that > reverses any highly general "it's not flexible enough" judgment, so > setting expectations is about the best I can do. > Fair enough. Thanks for the code and for the effort to explain it to me, Chris. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en.
