Tabs and application state use case

In response to
* Identifying Application State (TAG)
http://lists.w3.org/Archives/Public/public-forms/2011Dec/0051.html
at
http://lists.w3.org/Archives/Public/public-forms/2012Jan/att-0010/2012-01-11.html#topic4
I was assigned action
ACTION-1855 Leigh Klotz to send out tab use case for #! and 
bidirectional binding.

Consider the tabs example from Kurt Cagle et al:
http://en.wikibooks.org/wiki/XForms/Horizontal_File_Tab_Menu

If you want to allow bookmarking a page with a certain tab selected, you
can use server-side logic to populate an instance with the a value from
the Request URI, for example a query string:

    http://example.com/tabbed-page?tab=tab-1

In XForms 1.1 you then need this:

<instance id="query-string"><data xmlns=""><tab ... server side data 
goes here ...></data></instance>

<action ev:event="xforms-ready">
<toggle><case value="instance('query-string')/tab"></toggle>
</action>

A little more is needed because the Wikibooks example lacks tab
highlighting, and it's done with an instance value kept up-to-date on
toggle.  So we must initialize it.

Consider the page here: http://xformstest.org/2010/07/kurt_cagle/index.xml

We would then add something like this:

<action ev:event="xforms-ready">
<setvalue ref="instance('tabset-instance')/@value"
                 value="instance('query-string')/tab" />
<toggle>
<case value="instance('query-string')/tab" />
</toggle>
</action>

With the XForms 2.0 switch/@ref construct, we can go back to either the
setvalue alone or the toggle alone, assuming we have
<switch ref="instance('tabset-instance')/@value">...</switch>

<action ev:event="xforms-ready">
<toggle>
<case value="instance('tabset-instance')/@value" />
</toggle>
</action>

This lets us write an incoming link to a page with a selected tab, but
doesn't give us a way to bookmark the current state as we click around.

The TAG finding explores ways of keeping track of application state.
One of the more readable discussions referred to by the TAG finding is
the article by Jenni Tennison describing one mechanism, called "hash
URIs", dealing with a common practice involving fragment identifiers.

   http://www.w3.org/QA/2011/05/hash_uris.html

There are trwo advantages of using fragment identifiers
1. they can be read and updated solely on the client
2. semantically they already refer to page parts

Please refer to Jenni's article for more details.

I think we should take a look at the HTML5 history API and the Hashbang
work to see if we can use the events defined there to map to an instance
or function that allows bidirectional binding.  That way, when the user
clicks and the case toggles, and the switch/@ref changes the instance
value, that value propagates back to the location URI automagically.

Received on Wednesday, 18 January 2012 06:39:27 UTC