* Carsten Ziegeler: > While cforms is excellent for developing form based > applications, it has some (minor) problems if Cocoon is used in > a portal environment, being it the Cocoon portal or Cocoon used > as a JSR 168 portlet in a different portal container.
I would say that developing CForms together with Portal does not exhibit *minor* problems, I would rather say it's a major PITA! Why? Because most users develop CForms together with FlowScript's continuations. And this exposes several problems: 1) if you have several forms on your page, when you post a form, all forms believe they are being continued leading to an exception being thrown 2) if you post directly to your FlowScript's pipeline, there's no way to display the portal 3) the FlowScript is not the controller, leading to awkward situations like not being able to issue a redirection (may be a general issue with portals) It's possible to circumvent problem 1) by using CachingURICoplets and by invalidating the cache of the target coplet upon form submission. WDYT? IMO your current work is very valuable because it would allow better integration between portal and forms. However, I'm a bit disappointed because badly mixing and hacking portal and CForms is the only way we had to go for years! I wish this random id feature was there since the beginning. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
