Re: [portal] Form-Coplet communication

[Alex Romayev]

--- Christian MaMayrhubercmcmayriiicmuturgrazc.at
wrote:
 On Friday 04 June 2004 14:09, Alex RoRomayevrote:
  Hi Chris,
 
  I think this is an option that might work,
 however, a
  couple of questions:
  - Since request parameters are not available to to
  cocopletsI assume it still isn't possible to use
  CFCFormsor binding?
 I did not find a way :-(
 
  - Again, assuming CFCFormsinding cannot be use, I
 have
  about 15 parameters that I need to pass.  Does
 this
  meant I have to create 15 attributes in cocoplet
 configuration,  15 events in bookmarks.xmxmland 15
  entries in sisitemapo pass cocopletttribute to
 the
  cocopletor have you been able to find a better
 way?
 I'm using this feature to pass one value to many
 cocoplets.
 You won't need 15 entries in the sisitemapf you want
 to pass 15 attributes to 
 the cocopletYou can use ururisike

bookmark?cocoplettattvaluecocoplettattvaluecocoplettattvaluecocoplettattvaluecocoplettattvaluecocoplettattvaluecocoplettattvaluecocoplettattvaluecocoplettattvaluecocoplettattvaluecocoplettatt=valuecocoplettatt=valuecocoplettatt=valuecocoplettattvaluecocoplettatt=valuecocoplettatt=valuecocoplettatt=value
 in the sisitemapThe bookmark action will generate a
 {ururiconsisting of all 
 cocopletvents.

Yes, I've been using bookmarks as well.  There are a
bit buggy at the moment, but overall I find that they
are easier to use than events.

 
 The values in the ururlust be ururincoded and I
 don't know how big
 internal cocoon ururl'san grow.

Hasn't been a problem for me.

 
 15 parameters are many, maybe the best thing would
 be to store them as session 
 attributes, using the session-propagator action or
 flflowscript
 The bookmark feature would be useful for layout
 control.
 The session-atattrnput module or flflowscriptould be
 used to retrieve those 
 values stored in the session.

I can't store them in session, since it won't allow
users to have multiple browsers open in order to
perform multiple searches.  However, one workaround I
found was to call an outside of portal ururiuse flow
to extract request parameters, store them in
SeSearchCriteriabject and store the object in request.

However, I find myself wondering why I'm doing what
CFCFormsre designed to do for me.  And this is a
simple case with cocopletsn the same page.  Once I get
into more complex scenarios where I would have to
track the state between the pages/cocopletsI'm going
to start having to figure out how to do all the
wonderful things that flow does for me :-(  

I'm starting to wonder if the old portal-fwfwould work
with flow/cfcformsetter.  Thinking of migrating over
to portal-fwfwhis weekend to see if things get better.
 
 I think this way CaCachingURICoplet'sould still be
 used for cfcform's

I believe CFCFormsind to request only.  So, they can
only be used in CaCachingURICopletshowever with
limitations, which are critical for my site.

 Note: I have not tried this myself. Do
 session-atattr'survive between cocoplets

I think they do, but I haven't tried either.

Thanks very much for your help, Chris.

Cheers,
-Alex

 
 -- 
 lg, Chris
 

Re: [portal] Form-Coplet communication

[Christian Mayrhuber]

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

Re: [portal] Form-Coplet communication

[Alex Romayev]

 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

Hi Chris,

I think this is an option that might work, however, a
couple of questions:
- Since request parameters are not available to to
coplets, I assume it still isn't possible to use
CForms for binding?
- Again, assuming CForms binding cannot be use, I have
about 15 parameters that I need to pass.  Does this
meant I have to create 15 attributes in coplet
configuration,  15 events in bookmarks.xml, and 15
entries in sitemap to pass coplet/attribute to the
coplet, or have you been able to find a better way?

Thanks,
-Alex

Re: [portal] Form-Coplet communication

[Christian Mayrhuber]

On Friday 04 June 2004 14:09, Alex Romayev wrote:
 Hi Chris,

 I think this is an option that might work, however, a
 couple of questions:
 - Since request parameters are not available to to
 coplets, I assume it still isn't possible to use
 CForms for binding?
I did not find a way :-(

 - Again, assuming CForms binding cannot be use, I have
 about 15 parameters that I need to pass.  Does this
 meant I have to create 15 attributes in coplet
 configuration,  15 events in bookmarks.xml, and 15
 entries in sitemap to pass coplet/attribute to the
 coplet, or have you been able to find a better way?
I'm using this feature to pass one value to many coplets...
You won't need 15 entries in the sitemap if you want to pass 15 attributes to 
the coplet. You can use uris like
bookmark?coplet-att1=value#38;coplet-att2=value#38;coplet-att3=value#38;coplet-att3=value#38;coplet-att4=value#38;coplet-att5=value#38;coplet-att6=value#38;coplet-att7=value#38;coplet-att8=value#38;coplet-att9=value#38;coplet-att10=value#38;coplet-att11=value#38;coplet-att12=value#38;coplet-att1=value#38;coplet-att13=value#38;coplet-att14=value#38;coplet-att15=value#38;
in the sitemap. The bookmark action will generate a {uri} consisting of all 
coplet events.

The values in the url must be uri-encoded and I don't know how big
internal cocoon url's can grow.

15 parameters are many, maybe the best thing would be to store them as session 
attributes, using the session-propagator action or flowscript.
The bookmark feature would be useful for layout control.
The session-attr input module or flowscript could be used to retrieve those 
values stored in the session.
I think this way CachingURICoplet's could still be used for cform's.
Note: I have not tried this myself. Do session-attr's survive between coplets?

-- 
lg, Chris

[portal] Form-Coplet communication

[Alex Romayev]

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