On Fri, 2011-06-24 at 21:03 -0500, Matt Feifarek wrote: > On Fri, Jun 24, 2011 at 4:35 PM, Chris McDonough <[email protected]> > wrote: > I mean, you sort of already have that capability, or at least > it's > possible to add classes to do this. > > > 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. > I just tried to make a mako template for Form() and use it to render, > stepping through the children and rendering each of them (my next step > would have been to get fancier with the form.mako for a specific > layout). BUT, even though I did NOT set the default renderer, and set > only the renderer for the Form() object, the mako_renderer() I made is > trying to render all of the children also. There's only one template renderer in play at a time. > 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". > cant easily get, is to be able to style an individual form > element using > its HTML id, which really sort of just isn't compatible with > Deform's > goal of allowing for the rendering of multiple copies of the > same form > > > I don't care if it's id; I just want to be able to get to it. id is > the most obvious solution, but if it's hard-wired into something else, > it's busy, I get it. If this is true, you could add CSS classes where you want them in overridden templates. It doesn't even need to be dynamic... this really has nothing to do with knowing Chameleon as you can just jam in class attributes as necessary statically in the template code. Creating an alternate Mako rendering is sort of a red herring in that circumstance (or at least for this particular reason only), because there'd be nothing dynamic about those attributes. > Overriding templates is relatively easy. > > http://docs.pylonsproject.org/projects/deform/dev/templates.html#adjusting-the-chameleon-template-path > . Once you have your own path set up, you just basically copy the structure > of the existing templates directory over as necessary to override bits of it. > > > This would require a complete path with a complete set of templates > for every form in an application: if you have "edit_user" and > "edit_project" and "change_password" they might all be different html > markups, and doing anything any kind of "custom" like 2-columns would > mean that each would have to either choose that entire set or another > entire set. Ugh. 2-column layout vs. arbitrary layout #2 where field X is high on the page and field Y is low on the page vs. arbitrary layout #3, etc, is what I mean by "retail" and "arbitrary". If you need to change HTML structure to get the layout you want for a particular form rendering in a way that doesn't make sense for all form renderings, then, yes, you need to create one or more different templates for elements of that form and use those templates when you render that form. > Why not just send into the Field instance or even to the render() call > a template filename, ala pyramids view_config()? Fall-back to the > stock form.pt or whatever, of course. Is this possible with current > deform, or would it be possible in theory? This is more or less what happens now, except the rendering system requires a non-path-qualified name for the template. 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). 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. - C -- 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.
