[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