On Sun, 2011-06-26 at 17:13 -0500, Matt Feifarek wrote:
> 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.

It costs nothing for us to add a CSS class to an element in the default
widget templates, so if you strategically add some (without changing the
behavior of the widget as a result), and you're keen to have the class
included in the next release of Deform, please fork Deform and add the
classes there then submit a pull request.  I'll be happy to add the
necessary classes, as long as it doesn't break the functional tests.

- C


> 
> 
>  
>         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 pylons-discuss
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.


-- 
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.

Reply via email to