[tw.dynforms] #21: Suggested mods to Cascading Components
Trac from toscawidgets.org
--------------------------------+-------------------------------------------
Reporter: philipcharlesworth | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: dynforms | Version:
Keywords: |
--------------------------------+-------------------------------------------
The onchange event is not necessarily the ideal choice for all types of
field. The modified version of CascadingComponentMixin included in
dynforms_mods.py addresses this by adding an event parameter which
defaults to onchange but can be set to some other meaningful value, for
instance onblur.
The file dynforms_mods.js includes some modified versions of routines from
dynforms.js and some additional routines to provide extra facilities for
ajax calls on form fields which inherit from CascadingComponentMixin.
Briefly, the extra facilities are:
extra and extra2 can be either a single field name or a list of field
names, so there is no limit on how many fields can be specified.
Fields which can potentially provide multiple values, e.g. a
CheckBoxTable, or a MultipleSelectField, will send to the url a string
representation of a list of string values, representing the selected
options, e.g. "['option1','option3']" which can be turned into a proper
Python list by eval. Such fields also send back another value called
'state' which is a single string in which there is a character for each
option value, checked/selected ones being respresented by 'T' and
unchecked/unselected ones by 'F'. I did this specifically because it's the
way I store this type of info in my database but others might also find it
useful. If the field is the one triggering the AJAX event, the data comes
back as value:"[.....]", state:'TFTF'} or, if it's a field from extra or
extra 2 then it would be {fieldname:"[........}", fieldname.state:'TFTF'}
I'm not sure whether the dot between fieldname and state is a good idea or
whether an underscore would be better.
Fields which can only provide single values send back a value
string as normal but, if they are fields with options, such a
RadioList or SingleSelectField, there is also a state value defined in the
same way as for multi-valued fields but with at most one 'T'
character the rest being 'F's.
I started on this originally, partly because I wanted changes in one field
to trigger recalculation of one or more others, but also because, when I
submitted a form with a CheckBoxTable, I only ever got back the name of
the first checked option , the rest being ignored. This problem is solved
by the Cascading Mixin version because if I know which options were
checked when the form was first displayed and AJAX tells me of every
change that occurs up to the point the form is submitted, I don't need to
bother with what submit sends back.
One additional thing added to twd_cascade_apply is the ability to modify
the innerHTML of a SPAN so that things like help text or error text can be
shown as one of the results of an AJAX call.
--
Ticket URL: <http://toscawidgets.org/trac/tw.dynforms/ticket/21>
tw.dynforms </trac/tw.dynforms>
tw.dynforms
Trac from toscawidgets.org
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: dynforms | Version:
---------------------------------+------------------------------------------
Comment(by paj):
Philip - I think these are good ideas and I really appreciate you sending
in some code.
Making extra/extra2 support lists is a simple and useful change that I'll
apply shortly - see ticket #9.
Also, allowing updates of spans seems sensible. I wonder if this could be
made more general, perhaps something to think about later.
As for multivalued controls, I understand the need for this, but I don't
think the implementation is release quality just yet. In particular,
python programs must NEVER use eval on input received from the web -
that's a serious security flaw. So, I'll leave the ticket open and if you
have more ideas, do send them in.
--
Ticket URL: <http://toscawidgets.org/trac/tw.dynforms/ticket/21#comment:1>
tw.dynforms </trac/tw.dynforms>
tw.dynforms
Trac from toscawidgets.org
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: dynforms | Version:
---------------------------------+------------------------------------------
Comment(by paj):
Ok, extra/idextra as lists is done, as is SPANs
--
Ticket URL: <http://toscawidgets.org/trac/tw.dynforms/ticket/21#comment:2>
tw.dynforms </trac/tw.dynforms>
tw.dynforms
Trac from toscawidgets.org
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: dynforms | Version:
---------------------------------+------------------------------------------
Comment(by paj):
Sorry, I'd missed the hooking different events change - applied now!
--
Ticket URL: <http://toscawidgets.org/trac/tw.dynforms/ticket/21#comment:3>
tw.dynforms </trac/tw.dynforms>
tw.dynforms
Trac from toscawidgets.org
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: dynforms | Version:
---------------------------------+------------------------------------------
Comment(by philipcharlesworth):
Paul,
It's great that you have picked up some of my ideas. I will have a
look at your latest release and think some more about it. I accept that
eval is not a good idea; maybe all the data should be explicitly JSON
encoded and decoded. I am intending to get all my callbacks to use
@expose('json').
Enjoy your travels!
Regards,
Phil
--
Ticket URL: <http://toscawidgets.org/trac/tw.dynforms/ticket/21#comment:4>
tw.dynforms </trac/tw.dynforms>
tw.dynforms
Trac from toscawidgets.org
--------------------------------+-------------------------------------------
Reporter: philipcharlesworth | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: dynforms | Version:
Keywords: |
--------------------------------+-------------------------------------------
Comment(by bluepoint):
'''From Philip Charlesworth'''
Paul,
I have finally resolved my problem accessing toscawidgets.org but
only by creating a new identity for myself and using a different email
address.
Some of what I had done in my earlier submission was dictated by the fact
that early alphas of TG2 did not handle repeated parameters in http
requests correctly. Fortunately that has now been fixed, so the problem of
handling ajax data from multi-valued controls has been much simplified.
If CascadingComponentMixin were added to the __all__ list in widgets.py,
it would be possible to use it to define new cascading controls elsewhere.
I attach two files containing suggested modifications to dynforms.js and
here is some explanation:
dynforms_mod1.js
-------------------------
Mods to twd_cascade_req function -- calls a new function twd_get_value()
to get values from controls to add to the request.
Mods to twd_cascade_apply function -- when handling the response, if
'value' appears as a key in data, it is assumed to be a reference to the
control that originated the request. This helps when a single callback is
used to handle requests from a number of different controls as there is no
need for the callback to know which control is involved. I use
'expose('json') on all my callbacks and return dict(key1 = value1,
key2=value2, ...) where one of the keys might be 'value').
New functions twd_get_value and twd_get_select_value:
twd_get_value is called first and deals with either single value controls
or sets of checkboxes, radiobuttons etc. It tries looping over a list of
controls on the assumption that the ids will be decorated with '_0', '_1'
... etc and inserts a value into the request for any checked controls. If
it failed to find any members of a list it uses the undecorated control id
to get the value.
If, however, it finds that a control is a SELECT, it calls
twd_get_select_value to handle it, wwhich just examines the child nodes
and returns the names of any which are selected options.
It's no longer necessary to do anything clever with the values in the
callback routine because TG now packs multiple values into Python lists.
dynforms_mod2.js
-------------------------
An additional thing I needed to do with the response was to change the
attributes of a control, so I have added a further modification to
twd_cascade_apply to handle this. Essentially, I parse the key to see if
the final part is separated by two underscores instead of one underscore
and, if it is, I strip it off and take it to be the name of an attribute
for the control referred to by the rest of the key.
When I come to handle the attribute setting, I normally just do a
setAttribute to the supplied value but if the value is an actual boolean
false (i.e. the callback return specified Python False), I call
removeAttribute. This seemed to be necessary for things like disabled and
readOnly where merely giving them a false value doesn't seem to work.
Regards,
Phil
--
Ticket URL: <http://toscawidgets.org/trac/tw.dynforms/ticket/21#comment:5>
tw.dynforms </trac/tw.dynforms>
tw.dynforms
Trac from toscawidgets.org
--------------------------------+-------------------------------------------
Reporter: philipcharlesworth | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: dynforms | Version:
Keywords: |
--------------------------------+-------------------------------------------
Comment(by paj):
Having produced an initial tw2.dynforms, I've deliberately left out
cascading, so we can define the interface cleanly, to address all these
issues.
http://bitbucket.org/paj/tw2dynforms/overview/
--
Ticket URL: <http://toscawidgets.org/trac/tw.dynforms/ticket/21#comment:6>
tw.dynforms </trac/tw.dynforms>
tw.dynforms