[Kss-devel] Marshalling of form data
Hedley Roos
hedley at upfrontsystems.co.za
Fri Feb 23 11:23:21 CET 2007
> I think we don't need the | convention in the variable name for that.
> Because that is already known from the type of the data to be sent over
> (= the output of currentFormVar). The marshaller can put the record tags
> automatically.
I think you are correct. I'll try to get rid of the redundant and ugly
pipe marshall.
>
> This is actually already used with :list and maybe with :record too. So
> what we actually need to do is
>
> - to make the marshaller marshall the :records types too
My patch does provide this.
>
> - to make the formvar logic smarter so that it can select the composite
> variables that belong to one varname only, from the form.
Example as I understand your statement.
<input name="foo.bar:record" value="a" class="someclass">
<input name="foo.zap:record" value="b" class="someclass">
And in the KSS
input.someclass:click {
evt-click-preventdefault: True;
action-server: kss_MarshallTest;
kss_MarshallTest-value: currentFormVar();
}
Will result in the value {'bar':'a', 'zap':'b'} being available in the
Python script if the user clicks on either of the two inputs.
Is this correct? If so I can see it being difficult but definitely
possible. I handle such a situation by setting 'intelligent' id
attributes on the input tags, and I add "kss_onMetaTypeChange-input_id:
nodeAttr("id")". Then I can manipulate the input_id in the Python script.
>
> I am not saying the final word on this, but changing the syntax in the
> suggested way is something we would like to avoid. So if we can do
> without it...
If I can prevent any syntax changes ot the KSS and provide a limited set
of marshalling would it suffice?
Basically I can try provide for all the cases in marshalltest_form.pt
without changing KSS syntax.
More information about the Kss-devel
mailing list