Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <20040604035249.40800.qmail@web52204.mail.yahoo.com>
Date: Thu, 3 Jun 2004 20:52:49 -0700 (PDT)
From: Alex Romayev <romayev@yahoo.com>
Subject: [portal] Form-Coplet communication
To: dev@cocoon.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Another form coplet -- another problem ;-)

Problem
-------

Here is what I'm trying to do.  I have a "Search"
coplet, which is a form with lots of search criteria
(about 15 fields).  It has 2 buttons: "Search" and
"Save Search".  

If "Search" button is pressed, 2 things need to
happen:
- "Search Results" coplet (on the same page) needs to
use the criteria to run a query and display the
results.
- "Search" coplet needs to pre-populate itself with
the entered criteria.

If "Save Search" button is pressed, another portal
page ("Save Search") needs to be presented, the name
of the search needs to be entered, the search saved
and the "Search" page displayed with appropriate
results and pre-populated "Search" coplet.

Questions
---------

1. "Using Forms" doc
(http://cocoon.apache.org/2.1/developing/portal/forms.html)
shows how to implement a form using CachingURICoplet. 
This would allow me to use form binding to bind form
to/from SearchCriteria object, which then can be used
to run search or be saved to the database.  However, I
think CachingURICoplet only works when the coplet does
*not* need to communicate with other coplets.  In my
case, SearchCriteria object needs to be passed to
"Search Results" coplet or possibly to "Save Search"
coplet on another portal page.  This is similar to my
previous problem with login coplet, which needed to
communicate outside of its own context.

<snip>
I know, this problem keeps coming up in one form or
another � must be my luck :-(  In general, though, it
seems that coplet to coplet or coplet to portal
communication is allowed via events, however, it would
be great to see it extended to use flow as well. 
Given that flow is now the primary place to put
controller type logic, it seems inconsistent having to
do it in two places: flow and events.  Especially it
becomes tough when the two are not well integrated. 
Ideally, it would be nice to be able to do all of it
in flow with simple sendPage/sendPageAndWait�s, but
I�m not sure how well they would fit into the portal
model.
</snip>

2. Not using CachingURICoplet, in conjunction with
temporary:application-uri attibute, would allow the
"Search" coplet to communicate with other coplets (I
think), however, the fact that request parameters will
not be available to it, means I cannot use Cforms for
binding.  Now, say I could pass all 15 of my search
parameters to my "Search Results" via coplet
attributes (a bit painful, but can be done).  How
would I pass the events to other coplets/pages? 
"Event Handling" doc, has the following paragraph:

"Imagine a form coplet where the user can enter a
city. When this form is processed by the form coplet,
it can generate one (or more) CopletJXPathEvents and
push the entered city information to a weather coplet
and a hotel guide coplet. So, these two coplets
display the information about the selected city."

Sounds like what I need.  How does the form generate
these events and how do these events get passed on to
other coplets?  Is there a way I need to tag input
fields?  Anything I need to add to my submit buttons?

Thanks,
-Alex