Question about widget templates.
Tim Hoffman
I have very little knowledge of mako (slowly getting my head around
it) so bare with me ;-)
I have a question about the widget.html for the Input widget.
(templates/mako/formish/widgets/Input/widget.html)
The code is
<%page args="field" />
<%!
from formish import util
%>
<input id="${field.cssname}" type="text" name="${field.name}" value="$
{field.value[0]}"
% if classes:
${util.classes_from_vars(classes)|n}
% endif
/>
The bit I don't understand the is scope of "classes" in this fragment.
It always appears to be undefined. In which case I don't understand
why the test is present.
I want to be able to apply classes on the widget with css_class, but
they all seem to be wrapped up at field level. And "classes" always
appears to be undefined and classes_from_vars just drops out with no
value.
It seems to me to defeat the purpose of the css_class property on the
widget.
I must be missing something but can't work out what
Thanks
Tim
Matt Goodall
> Hi
>
> I have very little knowledge of mako (slowly getting my head around
> it) so bare with me ;-)
Consider yourself lucky! I've been using Mako for years now and I
still can't decide if I like it ;-).
>
> I have a question about the widget.html for the Input widget.
> (templates/mako/formish/widgets/Input/widget.html)
>
> The code is
>
> <%page args="field" />
> <%!
> from formish import util
> %>
> <input id="${field.cssname}" type="text" name="${field.name}" value="$
> {field.value[0]}"
> % if classes:
> ${util.classes_from_vars(classes)|n}
> % endif
> />
>
> The bit I don't understand the is scope of "classes" in this fragment.
> It always appears to be undefined. In which case I don't understand
> why the test is present.
Yeah, that looks wrong to me. I can't see anything setting up
'classes' for the widget.html template and a quick test I did here
says it's undefined (which I would argue is an error, even if classes
is set somewhere, somehow).
TextArea's widget.html template looks the same.
> I want to be able to apply classes on the widget with css_class, but
> they all seem to be wrapped up at field level. And "classes" always
> appears to be undefined and classes_from_vars just drops out with no
> value.
IIRC it's deliberate to add the widget's css class(es) to the field's
main element. It might seem weird at first but it allows you to
control the style of the entire field based on the type of widget in
use.
My ascii-art-fu is sure to fail me here, but it's quite common to
layout <input /> and <textarea /> fields differently in the same form:
______________________
Input Label |______________________|
Textarea Label
_____________________________________
| |
| |
| |
|_____________________________________|
You can select the field with the <input /> using a
".field.widget-input" CSS selector and the widget itself using
".field.widget-input .inputs". The same is true for a custom css_class
you add, e.g. ".field.my-custom-class .inputs".
>
> It seems to me to defeat the purpose of the css_class property on the
> widget.
>
> I must be missing something but can't work out what
Does the explanation and example CSS selectors help explain things? Is
there anything else you need to know or achieve your goal?
- Matt
Tim Hoffman
On Mar 2, 6:56 pm, Matt Goodall <matt.good...@gmail.com> wrote:
> On 2 March 2010 09:42, Tim Hoffman <zutes...@gmail.com> wrote:
>
> > Hi
>
> > I have very little knowledge of mako (slowly getting my head around
> > it) so bare with me ;-)
>
> Consider yourself lucky! I've been using Mako for years now and I
> still can't decide if I like it ;-).
>
Yeah I am zpt person and all of the non html markup (seems to be most
templating systems ) really hurts to look at ;-)
>
> Yeah, that looks wrong to me. I can't see anything setting up
> 'classes' for the widget.html template and a quick test I did here
> says it's undefined (which I would argue is an error, even if classes
> is set somewhere, somehow).
>
> TextArea's widget.html template looks the same.
>
> > I want to be able to apply classes on the widget with css_class, but
> > they all seem to be wrapped up at field level. And "classes" always
> > appears to be undefined and classes_from_vars just drops out with no
> > value.
ok makes sense (and so I am not stupid when it comes to the actual
widget templates ;-)
I was trying to workout how css_class in the widget was supposed to be
used and the "classes" in the
widget.html was throwing me.
>
> IIRC it's deliberate to add the widget's css class(es) to the field's
> main element. It might seem weird at first but it allows you to
> control the style of the entire field based on the type of widget in
> use.
>
> My ascii-art-fu is sure to fail me here, but it's quite common to
> layout <input /> and <textarea /> fields differently in the same form:
>
> ______________________
> Input Label |______________________|
>
> Textarea Label
> _____________________________________
> | |
> | |
> | |
> |_____________________________________|
>
> You can select the field with the <input /> using a
> ".field.widget-input" CSS selector and the widget itself using
> ".field.widget-input .inputs". The same is true for a custom css_class
> you add, e.g. ".field.my-custom-class .inputs".
>
>
>
> > It seems to me to defeat the purpose of the css_class property on the
> > widget.
>
> > I must be missing something but can't work out what
>
> Does the explanation and example CSS selectors help explain things? Is
> there anything else you need to know or achieve your goal?
>
On the css front I am not the author of the css ;-) and am trying to
match the expected html from the designers mockups.
One of the things being done is attaching validation (via javascript -
jQuery) to the input using css classes
I will get them to modify the css to use the selector anyway.
Rgds
T
> - Matt
Daniel Holth
If you prefer ZPT, you could use the templates from repoze.bfg.formish
pip install -e svn+http://svn.repoze.org/repoze.bfg.formish/trunk#egg=repoze.bfg.formish
import formish
import repoze.bfg.formish
form = formish.Form(schema, renderer=repoze.bfg.formish.get_default_renderer())
Tim Hoffman
Yep, thanks, aware of it. I am running on appengine, and just haven't
had time to put chameleon through its paces for large numbers of
templates
and just a little too far into the project to change.
Just using bobo, repoze.what and formish and zpt (zope.pagetemplates)
for the rest of the site but no repoze.bfg this time ;-)
I found bob subroutes easier to use than the routes in bfg and did not
have a use for anything else in repoze.bfg
T