Closures in Widget template

[Kalium]

I decided to rewrite a widget template and came across a couple of
problems, to which I found solutions. What I'm wondering though, is if
my solutions are 'wrong', in the sense that maybe there is a 'better'
way to do it.

I have a RepeatingForm compound widget which has it's own template
defined. Within this template is some javascript. The javascript in
question is a call to an object constructor, and the parameters of the
constructor are gotten from the widget variables set up in __init__.
So it looks something like this in the template

<script type="text/javascript" language="Javascript">

 new Search('${fields[0].field_id}', '${ value_for(fields[0]) }')

</script>

This worked fine until I decided that the field array may grow in size
by x amount, so I would want to pass in x amount of parameters to the
Search() constructor.
So, in the __init__ of the RepeatingForm, I decided to create an array
of these field objects (which are SingleSelectField widgets) converted
to JSON (well, only the attributes I needed were converted into JSON
and passed).
So it looked something like this in the template

new Search ( [ ${jsonified_array} ] )

That worked fine until I realised that the field_id that had been
jsonified (which as you can see from the first example was one of the
attributes I'm after). Was not what I was expecting. I was expecting
the field_id (of the 'table' select field) to be
'systemsearch_0_table' (systemsearch being the name of the Repeating
form, 0 being the row, and table being the name of the SingleSelect
widget). Instead the field_id was just 'table'.

Obviously the problem was that I was converting them to JSON in the
__init__ and at that point of time it hasn't  had a chance to create
the full field_id within the context of the compound form.

To solve this I turned the jsonified_array into a closure, where the
close does the actual jsonification so it looks something like this.

new Search([ ${jsonified_array(fields)} ])

This now gives me the results I'm after.

Is there something within Turbogears that I could have used to make
this easier for myself so I know for next time? Have I broken any
abstractions along the way?

Cheers

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

[Diez B. Roggisch]

Kalium schrieb:

> I decided to rewrite a widget template and came across a couple of
> problems, to which I found solutions. What I'm wondering though, is if
> my solutions are 'wrong', in the sense that maybe there is a 'better'
> way to do it.
>
> I have a RepeatingForm compound widget which has it's own template
> defined. Within this template is some javascript. The javascript in
> question is a call to an object constructor, and the parameters of the
> constructor are gotten from the widget variables set up in __init__.
> So it looks something like this in the template
>
> <script type="text/javascript" language="Javascript">
>
>  new Search('${fields[0].field_id}', '${ value_for(fields[0]) }')
>
> </script>
>
> This worked fine until I decided that the field array may grow in size
> by x amount, so I would want to pass in x amount of parameters to the
> Search() constructor.
> So, in the __init__ of the RepeatingForm, I decided to create an array
> of these field objects (which are SingleSelectField widgets) converted
> to JSON (well, only the attributes I needed were converted into JSON
> and passed).
> So it looked something like this in the template
>
> new Search ( [ ${jsonified_array} ] )
>
> That worked fine until I realised that the field_id that had been
> jsonified (which as you can see from the first example was one of the
> attributes I'm after). Was not what I was expecting. I was expecting
> the field_id (of the 'table' select field) to be
> 'systemsearch_0_table' (systemsearch being the name of the Repeating
> form, 0 being the row, and table being the name of the SingleSelect
> widget). Instead the field_id was just 'table'.
>
> Obviously the problem was that I was converting them to JSON in the
> __init__ and at that point of time it hasn't  had a chance to create
> the full field_id within the context of the compound form.
>
> To solve this I turned the jsonified_array into a closure, where the
> close does the actual jsonification so it looks something like this.
>
> new Search([ ${jsonified_array(fields)} ])
>
> This now gives me the results I'm after.
>
> Is there something within Turbogears that I could have used to make
> this easier for myself so I know for next time? Have I broken any
> abstractions along the way?

It's not a 100% clear to me what Widget-System you are talking about -
and my TG1.x-widget-knowledge is dwindling every minute.

However, if it's TW, your approach isn't correct I'd say. Instead, use
"update_params" for such computations. Then the ids should be fully
available to you.

Also, if the whole reason for a custom callback is the above script-tag,
you can overcome that with TW as well, as it will inject JS-callbacks
into the page without the need to adapt the template.


Diez

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