On Fri, Jun 24, 2011 at 4:35 PM, Chris McDonough <chr...@plope.com> 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 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.

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?



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


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.

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?

Thanks Chris.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Reply via email to