An HTML FORM element that does not include an action url will be treated as if its action is the url of the page on which it is rendered. We can take advantage of this fact to allow embedded objects to render form elements which, when submitted, update or transform the page on which they are embedded. Examples of this might include:
- Simple polling tools, which update displayed results as each vote is cast
- Database query tools, which render results in-line
- Discussion tools, which update an inlined message list
This is relatively straightforward with BRIDGE, since all HTTP request parameters and attributes are available to each embedded WebView when a page is rendered, via BRIDGE's PropertiesSource mechanism.
Issues include:
- The container object (e.g., the web page in which the form-bearing object is embedded) must be told not to interpret the submission. As of 031209, the only way to do this is to include a hidden form field named "noPageEdit" in the form, with value set to "true". Currently only TextDataServlet looks for this parameter, so other web-editable objects in which other objects can be embedded (e.g., Calendars) can still create problems. This is really just a special case of issue (2):
- If there are multiple editable objects (possibly of the same type), they will each be able to see all of the submitted parameters. So, for example, if no safeguards are in place and a page contains two distinct (hypothetical) embedded discussion objects, a message added to one discussion would be added to both. A solution to this (as well as to Issue [1]) would be to embed a standard hidden field containing the ObjectID, and then to check to emsure that ObjectIDs matched. This has at least two problems:
- It may not be possible to enforce this, except by documentation/convention
- Duplicate updates may still occur if the same object is embedded multiple times on the same page. There is currently no way to distinguish such instances, though it might be possible to introduce a concept of "consuming" parameters, so that the first instance could prevent subsequent instances from re-using the parameters.
- The approach of using an implied action url appears to work with both GET and POST requests. We will need to think about guidelines for when each of these are appropriate:
- For objects that perform non-destructive queries, the GET method may be better because it results in a bookmarkable URL.
- For objects that modify data, or for cases where you do not want distinct URLs exposed, the POST method will be more appropriate.
|