cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Mayrhuber <cm...@iicm.tu-graz.ac.at>
Subject Re: [portal] Form-Coplet communication
Date Fri, 04 Jun 2004 08:22:47 GMT
On Friday 04 June 2004 05:52, Alex Romayev wrote:
> 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

If you want to communicate with the coplets from "outside"
then the best way to accomplish this task is to use the 
bookmark feature of the portal engine.
Have a look at:
http://wiki.cocoondev.org/Wiki.jsp?page=PortalEngineBookmarks

I had similiar problems which were driving me mad, after starting
to use bookmarks, it got a lot easier to control the portal.

-- 
lg, Chris

Mime
View raw message