On Mar 11, 2009, at 10:52 AM, David E Jones wrote:


On Mar 11, 2009, at 4:53 AM, Bilgin Ibryam wrote:


On Mar 11, 2009, at 9:43 AM, David E Jones wrote:

So, until then...

To get there with the form widget I think we'll need to introduce a new field type, like a form-backed link that we can use instead of the hyperlink field type that we currently use to pass parameters in the URL.

-David


Hi David,
I think this is good security rule and it would be good to have it in the framework.

Do you have any idea how to cope with "nested forms problem"

This isn't too hard, just takes a little work. You can always put forms with all hidden fields elsewhere in the page and then have a link submit them.

Also, there are links in the screens, which are used to invoke services. Should we replace these links with forms or add a new attribute to link element and render the link as a form with hidden fields containing all the request parameters ?

Yes, screens and other places will need this option too (a way to do mini-forms as an alternative to links for calling services). I'll be playing with these in the near future and figure out a good XML schema for it, probably a "formlink" or something with nested elements for the parameters to pass to it (which will all end up being hidden forms on the parameters).

Some of this is now implemented and in SVN, and used throughout the ProductForms.xml file.

This is implemented as an extension to the existing hyperlink and sub- hyperlink elements. There is now an attribute called "link-type" and if it is set to "hidden-form" then it will create a hidden form and the link generated will just submit that form, causing the parameters to be encrypted in the body of the request instead of in plain text in the URL.

Of course, for them to be put into hidden form fields, they must be setup using the new "parameter" sub-element (under hyperlink or sub- hyperlink). Anything left in the "target" attribute will remain in the form's URL (action), and be submitted unencrypted... so everything should be moved to parameter tags.

I haven't implemented this in the screen widget or in the menu or tree widgets yet either. Actually, after implementing it for the sub- hyperlink element in the form widget I couldn't find any places where a request that calls a service was actually used, so it appears to not be needed there (that I can find yet). In other words, all of those links are for going to different places and not for submitting data to update in the database. Unless we run across other places that do this I'll probably table those for now.

-David


Reply via email to