[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Passing State Data between XForms - Architectural Limitations?

• To: xml-dev@l...
• Subject: Passing State Data between XForms - Architectural Limitations?
• From: Chimezie Ogbuji <chimezie@g...>
• Date: Tue, 5 Apr 2005 15:29:31 -0400
• Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=OSxO+GWWmvwwhallidVvxXI9ezeNMGF9mIoqdadHjd5kg1jX+kWmGRQKEowzK6qirijgHCDv+O4KXhinPAkruRo33CXwYNPMfL6noM3yfqWYqwhVlnfLVbu+h1P4sYgDwvvOO4CBcBsLAYZYINNSpOiHAm+FnEQUh1EDtl5bvT4=
• Reply-to: Chimezie Ogbuji <chimezie@g...>

Hello.  While working on a pure XForms based solution, we have come
across what appears to be an architectural shortcoming of XForms as a
*complete* user interface solution.

Perhaps it's mostly because the XForms specification is relatively new
and there haven't been many (if at all) use cases that have pushed
it's envelope as hard as we are.  The original post is here (it's a
yahoo groups list):
http://groups.yahoo.com/group/formsPlayer/message/2203 but the short
of it is that we have a need to essentially replicate what browsers,
cookies, and sessions buy you in a traditional web-application
environment (HTML from Session-enabled Web/Application Server). 
Specifically, we have a need to be able to persist some state
information (mostly for convenience) within an XForm, so when you
navigate between XForms you have a means of knowing your current state
(or some persistent data associated with the state).

In the traditional case, you would create a session and have the
browser automagically maintain (at the very minimum) a unique
identiier to a state which the server understands and associates
persistent data with that indentifier.

That unique identifier is passed about  'under the covers' with
cookies and HTTP headers, etc..   if my undestanding of this is
correct.  However in the scenario where you are writing your UI as an
XForm which works off XML instance data (and is browser agnostic),
there doesn't seem to be an intuitive solution - I can't even imagine
what changes you could suggest to the XForms specification that would
account for something that fundamental.  Perhaps state management is
mutually exclusive from user interface implentation? In which case it
would make sense that you couldn't manage state between user
interfaces with XForms alone, but up until this point, XForms over
SOAP (or any XML-based SOA or RPC) has proven to be quite an elegant
platform to build data-driven applications.

  If your XForm was communicating with a remote service, you *could*
explicitely manage the state information as a service.  For example,
you  could have services to create/delete/manage sessions, but then
without taking advantage of cookies (an artifact of an *older*
architecture) there just doesn't seem to be an elegant way to pass
data in between XForms without doing it explicitely (i.e. ever time I
wish to navigate to a new 'screen', I have to hit the service to
persist my state).

I wonder if people have had a similar need in their XForms and how
they went about it w/out compromising the architecture (i.e., by
taking advantage of the assumption that theXForm was being viewed from
a browser which had the ability to manage state data itself in a way
that had nothing to do with XForms: cookies, javascript, etc..)

thoughts?

Chimezie Ogbuji

• Prev by Date: XML 2005 Call for Participation Now Open - Deadline May 13
• Next by Date: Re: Exposing resources/services vs hiding implementationdetails
• Previous by thread: XML 2005 Call for Participation Now Open - Deadline May 13
• Next by thread: RE: Exposing resources/services vs hiding implementation details
• Index(es):
  • Date
  • Thread