cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Ratcliffe" <a...@mrigitech.com>
Subject RE: Conversion of complex form to cforms
Date Mon, 17 Jan 2005 22:52:55 GMT
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


Mime
View raw message