You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Adam Ratcliffe <ad...@mrigitech.com> on 2005/01/17 00:51:34 UTC
Conversion of complex form to cforms
Hi,
I have a reasonably complex form design that I'd like to convert to cforms.
Being new to cforms I'm not sure how
much work is involved in doing this, can anyone give me an idea as to A)
whether this is possible using cforms;
and B) if using cforms is a good choice for this use case. A description of
the form follows:
The current form design caters for both simple and complex location
searches. In the simple case the user just
enters the location name and town name and submits the form. The form
processing is handled by a flow function
that extracts the request parameters and provides these as input to a
database search.
For complex searches the user may select a checkbox to 'Search by Category',
this executes some client side
javascript that will either send a request to the server to redisplay the
form showing the top level search categories
if the checkbox was previously unchecked, or if the checkbox was previously
checked any displayed categories are
hidden.
Search categories are hierarchical supporting drill-down searching. When
the 'Search by Category' option is 1st
selected the top level categories are retrieved from the database as a List
and this List is used to populate a
selection list. If the user selects a category from the selection list the
client-side onclick handler is fired and
the form is submitted. On the server-side the continuation is resumed, if
the category has sub-categories, the
subcategories are selected from the database and both the top-level
categories and the sub-categories are
displayed as 2 selection lists to the user (these are returned from the db
component as a list of lists).
The initial category selected is shown as 'selected' in the list of
top-level categories.
To search within the selected category at any point the user clicks on the
'Search' button.
Cheers
Adam
Re: Conversion of complex form to cforms
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jan 17, 2005, at 3:49 PM, Adam Ratcliffe wrote:
> I'm using the forms Flow API that comes with 2.1.6, is that v2?
2.1.6 has both.
You probably use load() in the flowscript to pull in the forms API...
if the path has "v2" in it, then it's v2.
see
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108058145901032&w=4
HTH,
-ml-
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Conversion of complex form to cforms
Posted by Adam Ratcliffe <ad...@mrigitech.com>.
> That's pretty much what document.load() does, and you can create a
> document using document.implementation.createDocument... except
> Internet Exploder used to not be able to do this, maybe it does now...
> see http://www.quirksmode.org/dom/importxml.html for how to do it
> differently in IE if necessary.
>
> You can use the XMLHttpRequest object to load synchronously, if that's
> what you need (but you can probably instead use the onload handler of
> your XML-loading document to do whatever needs to be done).
This looks great, I can think of at least one other application I have that
could
benefit from using XMLHttpRequest.
> > One
> > way I can think of
> > doing this would be to load the data into a hidden-frame and get
> > access to
> > it that way - is
> > that what you had in mind?
> > e
>
> Bleah.
> :-)
Agreed !
> Are you using the "v2" forms Flow API? That's how it's done in uh...
> v1, I guess. In v2 you would say
I'm using the forms Flow API that comes with 2.1.6, is that v2?
Cheers
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Conversion of complex form to cforms
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jan 17, 2005, at 2:52 PM, Adam Ratcliffe wrote:
> Hi Mark,
>
> When I put together the original implementation I gave some thought to
> doing
> it all on
> the client-side, I was going to do something like load all of the data
> into
> JS arrays as
> currently the category tree isn't so extensive. A more responsive
> interface
> would certainly
> be good.
>
> With way #2 if the category data was going to be loaded on demand I
> don't
> believe client-side JS
> is able to open a network socket to retrieve XML data from the server.
That's pretty much what document.load() does, and you can create a
document using document.implementation.createDocument... except
Internet Exploder used to not be able to do this, maybe it does now...
see http://www.quirksmode.org/dom/importxml.html for how to do it
differently in IE if necessary.
You can use the XMLHttpRequest object to load synchronously, if that's
what you need (but you can probably instead use the onload handler of
your XML-loading document to do whatever needs to be done).
> One
> way I can think of
> doing this would be to load the data into a hidden-frame and get
> access to
> it that way - is
> that what you had in mind?
> e
Bleah.
:-)
> I'll try way #1 first, the object that you suggested passing to
> showForm(),
> is that possible? I
> tried once before doing something like:
> form.showForm("form-display-pipeline", bizData); and it
> didn't seem to work.
>
Are you using the "v2" forms Flow API? That's how it's done in uh...
v1, I guess. In v2 you would say
var w = form.getWidget();
w.bizData = theBizData;
.
.
.
form.showForm ("form-display-pipeline");
(if memory serves :-)
Have fun,
-ml-
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Conversion of complex form to cforms
Posted by Adam Ratcliffe <ad...@mrigitech.com>.
Hi Mark,
When I put together the original implementation I gave some thought to doing
it all on
the client-side, I was going to do something like load all of the data into
JS arrays as
currently the category tree isn't so extensive. A more responsive interface
would certainly
be good.
With way #2 if the category data was going to be loaded on demand I don't
believe client-side JS
is able to open a network socket to retrieve XML data from the server. One
way I can think of
doing this would be to load the data into a hidden-frame and get access to
it that way - is
that what you had in mind?
I'll try way #1 first, the object that you suggested passing to showForm(),
is that possible? I
tried once before doing something like:
form.showForm("form-display-pipeline", bizData); and it
didn't seem to work.
Cheers
Adam
-----Original Message-----
From: Mark Lundquist [mailto:ml@wrinkledog.com]
Sent: Tuesday, 18 January 2005 10:50 a.m.
To: users@cocoon.apache.org
Subject: Re: Conversion of complex form to cforms
On Jan 16, 2005, at 3:51 PM, Adam Ratcliffe wrote:
> Hi,
>
> I have a reasonably complex form design that I'd like to convert to
> cforms. Being new to cforms I'm not sure how
> much work is involved in doing this, can anyone give me an idea as to
> A) whether this is possible using cforms;
> and B) if using cforms is a good choice for this use case. A
> description of the form follows:
>
> The current form design caters for both simple and complex location
> searches. In the simple case the user just
> enters the location name and town name and submits the form. The form
> processing is handled by a flow function
> that extracts the request parameters and provides these as input to a
> database search.
>
> For complex searches the user may select a checkbox to 'Search by
> Category', this executes some client side
> javascript that will either send a request to the server to redisplay
> the form showing the top level search categories
> if the checkbox was previously unchecked, or if the checkbox was
> previously checked any displayed categories are
> hidden.
>
> Search categories are hierarchical supporting drill-down searching.
> When the 'Search by Category' option is 1st
> selected the top level categories are retrieved from the database as a
> List and this List is used to populate a
> selection list. If the user selects a category from the selection
> list the client-side onclick handler is fired and
> the form is submitted. On the server-side the continuation is
> resumed, if the category has sub-categories, the
> subcategories are selected from the database and both the top-level
> categories and the sub-categories are
> displayed as 2 selection lists to the user (these are returned from
> the db component as a list of lists).
> The initial category selected is shown as 'selected' in the list of
> top-level categories.
>
> To search within the selected category at any point the user clicks on
> the 'Search' button.
>
Hi Adam,
You'd start by declaring all the possible form fields in the form
definition. Then, I can think of 2 ways to do it:
Way #1 would be to declare an <fd:action id="updateForm"/>, and bind
its onClick event to a function that does the lookups and loads the new
form values. Pass an object to the showForm() pipeline that tells the
form template which controls to dispay. Give this button
'style="display: hidden;" (you can do this in the form template using
<fi:styling>. In the client-side JS, figure out what forms.js does to
submit on the updateForm control, and emulate that from the client-side
event handler.
Way #2 to would be to load more smarts into the client-side JS. Have
the event handler hide/unhide controls as necessary, and call some JS
to load XML from the server, parse it and set the values of the form
controls. In this approach, the continuation isn't invoked until the
form is actually submitted. The resources called by the client-side JS
do the lookups and return lightweight XML trees.
Way #2 is more involved but should give you a more responsive user
interface.
Let me know how it goes ;-) I was thinking about this a while back,
because I have a possible project coming up that will require just this
sort of drill-down capability.
HTH,
-ml-
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Conversion of complex form to cforms
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jan 16, 2005, at 3:51 PM, Adam Ratcliffe wrote:
> Hi,
>
> I have a reasonably complex form design that I'd like to convert to
> cforms. Being new to cforms I'm not sure how
> much work is involved in doing this, can anyone give me an idea as to
> A) whether this is possible using cforms;
> and B) if using cforms is a good choice for this use case. A
> description of the form follows:
>
> The current form design caters for both simple and complex location
> searches. In the simple case the user just
> enters the location name and town name and submits the form. The form
> processing is handled by a flow function
> that extracts the request parameters and provides these as input to a
> database search.
>
> For complex searches the user may select a checkbox to 'Search by
> Category', this executes some client side
> javascript that will either send a request to the server to redisplay
> the form showing the top level search categories
> if the checkbox was previously unchecked, or if the checkbox was
> previously checked any displayed categories are
> hidden.
>
> Search categories are hierarchical supporting drill-down searching.
> When the 'Search by Category' option is 1st
> selected the top level categories are retrieved from the database as a
> List and this List is used to populate a
> selection list. If the user selects a category from the selection
> list the client-side onclick handler is fired and
> the form is submitted. On the server-side the continuation is
> resumed, if the category has sub-categories, the
> subcategories are selected from the database and both the top-level
> categories and the sub-categories are
> displayed as 2 selection lists to the user (these are returned from
> the db component as a list of lists).
> The initial category selected is shown as 'selected' in the list of
> top-level categories.
>
> To search within the selected category at any point the user clicks on
> the 'Search' button.
>
Hi Adam,
You'd start by declaring all the possible form fields in the form
definition. Then, I can think of 2 ways to do it:
Way #1 would be to declare an <fd:action id="updateForm"/>, and bind
its onClick event to a function that does the lookups and loads the new
form values. Pass an object to the showForm() pipeline that tells the
form template which controls to dispay. Give this button
'style="display: hidden;" (you can do this in the form template using
<fi:styling>. In the client-side JS, figure out what forms.js does to
submit on the updateForm control, and emulate that from the client-side
event handler.
Way #2 to would be to load more smarts into the client-side JS. Have
the event handler hide/unhide controls as necessary, and call some JS
to load XML from the server, parse it and set the values of the form
controls. In this approach, the continuation isn't invoked until the
form is actually submitted. The resources called by the client-side JS
do the lookups and return lightweight XML trees.
Way #2 is more involved but should give you a more responsive user
interface.
Let me know how it goes ;-) I was thinking about this a while back,
because I have a possible project coming up that will require just this
sort of drill-down capability.
HTH,
-ml-
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org