On Fri, Apr 18, 2008 at 9:24 AM, Ryan Jarvis <[EMAIL PROTECTED]> wrote:
> I have been building templates with Mako and Webhelpers. I have parent
> templates that define the html head and the html body and then include
> child templates (using Mako's include function) which have the exact
> forms defined in them.
Generally inheritence (<%inherit>) works better than include because
you can use self/next/previous to access <%def> methods or the body of
other templates in the inheritence chain: ${next.body()},
${self.foo()}. <%include> is mainly useful when the included section
changes much more frequently than the surrounding template, or if you
have to dynamically choose which file to include at runtime (if that
even works in Mako).
> I want to make a child template that has two
> select boxes in it, one for "type" and one for "subtype". The contents
> of the "subtype" box will be determined dynamically by what the user
> selects in the "type" box via the 'onchange' event handler.
I haven't done this, but conceptually you check the current value of
the 'type' box using Javascript DOM, then collect the options for the
'subtype' box either from a Javascript array you've preinitialized or
by making an AJAX call to the server, then place the options into
'subtype' using Javascript DOM calls.
> -If I create the select box using a webhelper, how do I access the
> currently selected item as a python variable (to pass into the remote
> function I also defined using a webhelper)?
It doesn't work this way, as the other reply said.
> -Since I am in a child template, there is no easy way for me to define
> javascript functions in the html head, correct?
You can do this with a <%def> method in the template containing the
Javascript, and a ${self.head_extra()} method or such in the template
containing the <head>. The latter template will also need an empty
"head_extra" method in case no head_extra is defined elsewhere.
However, putting the Javascript in external files has two major advantages:
1) The browser can cache the (unchanging) Javascript page separately.
2) You don't have to escape '<' and the like or use CDATA sections.
> -I'm not sure of how/where I put logic that can populate the defaults of
> the select boxes when the template is first rendered.
If the options are in a Javascript variable you can populate them
during onload. If they're stored on the server, it makes sense to
preopulate the controls before sending the initial form.
> Do I need to go higher up and import something like ToscaWidgets to
> build my templates?
ToscaWidgets is a more sophistocated kind of webhelpers. It has a
feature to bundle a chunk of HTML with its associated Javascript and
CSS, and then inject all the associated Javascript into the page, But
that's just a convenience for tracking dependencies: it doesn't
produce any better forms or Javascript than you could write yourself.
> Do I need to degrade my templates to explicitly define raw html and
> javascript instead of using webhelpers?
No. Any keyword arguments you add to the helpers will be converted to
HTML attributes. Thus you can add 'onchange' or whatever tags you
need.
It would be worth reading about "unobtrusive Javascript" in a book
like... I don't have the title on hand, Javascript and AJAX something.
There's a rabbit on the cover. :)
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
