[OT] XForms

[Andrew Hill <an...@gridnode.com>]

Currently the app Im working on is using an xhtml front end (with struts of
course) but Ive been asked to look at XForms with an eye to migrating to it
in the future (and probably throwing in a migration to JSF while Im there).

Currently the XForms spec is only a candidate release with afaik very little
browser support, though I gather there are a number of plugins that
implement an XForms processor.

I'm in the process of reading through whats on the w3c site about it but am
still pretty clueless as to what it really implies in terms of what we would
do different to now. While I understand what I am reading I dont truly grok
it yet.

Anyone else been looking into this and can share some pointers on what I
need to think about?

Is XForms really going to be the next stage in the evolution of forms on the
browser or is it just some hyped up hot air thats really a wild goose chase?


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

RE: [OT] XForms

[Andrew Hill <an...@gridnode.com>]

Thanks for the reply Simon,

I guess my first question for you isn't so much about using XForms as about
deploying an XForms based solution: what are you using for an XForms
processor on the client side (or on the middle tier)?

Fate has consipired against me in my attempts to evaluate plugins (Im using
IE5 and the IE6 box I can use isn't on SP1 yet and I dont have admin rights
on it, and I couldnt even download the novell plugin etc...) and the two
server side ones Ive had a (very) quick look at (Chiba and IBM XML Forms (an
alphaworks thing)) both seemed very buggy when I tried playing with their
samples.

Only processor implementation Ive seen so far that appears to work is
XSmiles, but I cant see us deploying that on every seat at large customer
sites... :-(

Interesting to note that XForms has moved up to a "Proposed Recommendation"
status now. Hopefully that means the spec is pretty stable now which might
prompt more moves to implement it.

regards
Andrew

-----Original Message-----
From: Simon Kelly [mailto:kelly@ipe.fzk.de]
Sent: Friday, 1 August 2003 16:47
To: Struts Users Mailing List; andrew.david.hill@gridnode.com
Subject: Re: [OT] XForms


I'm just starting to use it myself. And it's a bit of a pain in the RS
really. I think that it will become a standard next year, as for use within
static sites it's an extremely easy thing to use. (The wizard can knock up a
form page in about 2 minutes, and saves a boat load of typing)

However, if like me, your forms are dynamic, it can be a bit of a sh*t to
deal with. You will need to know exactly how to generate the xform xml doc
on the fly, and this means knowing it inside out and back to front. (I'm on
my fifth or sixth read through and it's starting to make my brain hurt)

But I've read enough to know the basics, so any question drop me a line.

Cheers

Simon



----- Original Message -----
From: "Andrew Hill" <an...@gridnode.com>
To: "Struts" <st...@jakarta.apache.org>
Sent: Friday, August 01, 2003 8:02 AM
Subject: [OT] XForms


> Currently the app Im working on is using an xhtml front end (with struts
of
> course) but Ive been asked to look at XForms with an eye to migrating to
it
> in the future (and probably throwing in a migration to JSF while Im
there).
>
> Currently the XForms spec is only a candidate release with afaik very
little
> browser support, though I gather there are a number of plugins that
> implement an XForms processor.
>
> I'm in the process of reading through whats on the w3c site about it but
am
> still pretty clueless as to what it really implies in terms of what we
would
> do different to now. While I understand what I am reading I dont truly
grok
> it yet.
>
> Anyone else been looking into this and can share some pointers on what I
> need to think about?
>
> Is XForms really going to be the next stage in the evolution of forms on
the
> browser or is it just some hyped up hot air thats really a wild goose
chase?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: [OT] XForms

[Simon Kelly <ke...@ipe.fzk.de>]

I'm just starting to use it myself. And it's a bit of a pain in the RS
really. I think that it will become a standard next year, as for use within
static sites it's an extremely easy thing to use. (The wizard can knock up a
form page in about 2 minutes, and saves a boat load of typing)

However, if like me, your forms are dynamic, it can be a bit of a sh*t to
deal with. You will need to know exactly how to generate the xform xml doc
on the fly, and this means knowing it inside out and back to front. (I'm on
my fifth or sixth read through and it's starting to make my brain hurt)

But I've read enough to know the basics, so any question drop me a line.

Cheers

Simon



----- Original Message -----
From: "Andrew Hill" <an...@gridnode.com>
To: "Struts" <st...@jakarta.apache.org>
Sent: Friday, August 01, 2003 8:02 AM
Subject: [OT] XForms


> Currently the app Im working on is using an xhtml front end (with struts
of
> course) but Ive been asked to look at XForms with an eye to migrating to
it
> in the future (and probably throwing in a migration to JSF while Im
there).
>
> Currently the XForms spec is only a candidate release with afaik very
little
> browser support, though I gather there are a number of plugins that
> implement an XForms processor.
>
> I'm in the process of reading through whats on the w3c site about it but
am
> still pretty clueless as to what it really implies in terms of what we
would
> do different to now. While I understand what I am reading I dont truly
grok
> it yet.
>
> Anyone else been looking into this and can share some pointers on what I
> need to think about?
>
> Is XForms really going to be the next stage in the evolution of forms on
the
> browser or is it just some hyped up hot air thats really a wild goose
chase?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

RE: [OT] XForms

[Mike Jasnowski <mj...@bea.com>]

>Is XForms really going to be the next stage in the evolution of forms on
the
>browser or is it just some hyped up hot air thats really a wild goose
chase?

IMHO it's hard to say, XForms has been perculating for along time. I think
if you speak to some vendors (Like Novell) they think so. But in reality,
there are some assumptions being made by these vendors that may make it
difficult for XForms to really proliferate. Such as native support for
XForms. As you mentioned there are few clients that natively support XForms,
and those that do use a plugin. Now you might argue that using a plugin is
good enough, until you have to start managing plugins, plugin verions, etc..
then you have different platforms for the plugin (applets anyone?).  It also
assumes that you (and your app) live in mostly an XML world. Which is not
the case for many, and those that do may not be doing so natively (I.e.
exposing relational data via XML as opposed to an XML database).

And if XForms becomes natively supported, let's hope all vendors choose to
support the same,full spec the same way. (HTML, CSS, CSSP ???).

Frankly I think you can accomplish similar things with existing technologies
and practices.

HTH,
Mike j

-----Original Message-----
From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
Sent: Friday, August 01, 2003 2:03 AM
To: Struts
Subject: [OT] XForms


Currently the app Im working on is using an xhtml front end (with struts of
course) but Ive been asked to look at XForms with an eye to migrating to it
in the future (and probably throwing in a migration to JSF while Im there).

Currently the XForms spec is only a candidate release with afaik very little
browser support, though I gather there are a number of plugins that
implement an XForms processor.

I'm in the process of reading through whats on the w3c site about it but am
still pretty clueless as to what it really implies in terms of what we would
do different to now. While I understand what I am reading I dont truly grok
it yet.

Anyone else been looking into this and can share some pointers on what I
need to think about?

Is XForms really going to be the next stage in the evolution of forms on the
browser or is it just some hyped up hot air thats really a wild goose chase?


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org