Hi Grzegorz, thanks for your help. Sorry for the confusion about naming the blocks, forget about B, it should have read A, of course.
Before going into the details of my scenario, I have to admit, that there is a "workaround" to overcome the problem and that I am using it already: Of course, one can use the resource components of the form (fd,ft,script), add them in a suitable way to the toplevel sitemap (M in the example case), apply a little tweaking and you are done. Nevertheless this "workaround" is breaking the idea of blocks being units of abstraction (You see, I am a bit contaminated by OO ideas and probably a bit overenthusiastic due to new inheritance concepts available with blocks). Recreating the interaction logic of a form in an outside sitemap forces exhibiting internal resources that one might not be willing to document or make accessible to the outside. I, for my part, do expect, that if an URL I'm calling leads to some form interaction, such form interaction will also be available when the basic form entry url is called from a client block and not only if the interaction is directly with the end user (browser). So my question might end up to be more a fundamental question about abstraction functionality available with the block concept and not about a detail problem in the first place. Besides that fundamental aspect, I'm not sure, whether I can get the scenario small enough to exhibit a problem, as I do not have enough time to check, whether a minimum example still shows the problem. So, let me sketch up a minimum example (untested) and add some words on the complications I added around in my real world example. Now the details of my scenario: A block A has a form interaction. For simplicity assume it to be the sample from cocoon forms block (see http://cocoon.apache.org/2.2/blocks/forms/1.0/478_1_1.html) And assume also, the the block can be accessed with name "reg". Now this block is (re-)used from a new block M. -----M sitemap fragment------------------- <map:pipeline> <map:match pattern="register/**"> <map:generate src="servlet:reg:/{1}" </map:match> <map:serialize type="xhtml"/> </map:pipeline> ------------------------------------------ As you can see, any call with a URL prefix if "register/" is forwarded to block A. This will cause the form to be displayed correctly. But on submit the form is just redisplayed and continued as one would expect. To make the whole a bit more complex. The paradigm as shown above is not used directly, but with aggregation. Block M generates pages as an aggregation from navigation data (some kind of menu entries) and some page content. Block A does something similar. It also aggregates it's own (sub) menu with actual page content (that in some cases is a form) Due to this, usually "calls" to the foreign block usually are from <map:part> and not from <map:generate> (or one would have to add another level of indirection for calling a local pipeline from <map:part> that itself issues the map:generate based reference to the foreign block. I hope you can make some sense out of this quite short sketch and (probably a bit weird) use case. Am I misled in believing forms should be integral kind of resource to be exposed with blocks (and not only files contained there)? Is my approach in "calling" the form completely off? Or, did I just get lost with some details, I still need to get used to? regards Rainer Grzegorz Kossakowski schrieb: > Rainer Pruy pisze: >> Hi, > > Hi Rainer. > >> I just got trapped with the following problem >> and was not yet able to get to a suitable solution. >> >> I do have a form in a block A >> There is a main block M that delegates some calls (GET) via servlet services >> to block A. >> Unfortunately, there also is a form (form block) in block A. >> >> I managed to put up sitemap for M and B to get the form displayed (there are >> still some issues with using xhtml namespace and cforms >> block, but there are some solutions to this..). > > What's B here? How do you delegate calls from M to A block? Can you show > relevant sitemap snippet. > >> However, submitting the filled in form fails. >> If putting a <map:call continuation="..."/> into M sitemap it complains >> about invalid continuations. >> When dispatching continuation calls to A and calling continuation from A >> sitemap it just redisplays the form. >> (Logfile says something about redirecting to "cocoon:/formdisplay" where >> "/formdisplay" is the URL used to call the form template from >> the flowscript) >> >> Then I recognized that form submission is a "POST" operation and tried some >> combinations of servletService generator, transformers and >> servlet-consumer among both sitemaps, and learned a lot about numerous error >> messages and exceptions. > > ServletService generator and friends has completely different purpose. > >> Search for any hints did not reveal anything helpful... > > You are using hottest features of Cocoon 2.2; that at least explains why you > don't get abundant > search results on Servlet Service Framework stuff... > >> Thus, I am back to the basic question: What is the correct approach on using >> forms from blocks in another one? >> >> Any help appreciated.... > > I'm ready to give you a really good advice as soon as I understand your case > thoroughly. I plan to > continue writing documentation[1] of SSF over this weekend and your > real-world experience might be > very helpful. > > [1] > http://cocoon.zones.apache.org/daisy/cdocs-servlet-service-impl/g1/1412.html > -- Rainer Pruy Geschäftsführer Acrys Consult GmbH & Co. KG Untermainkai 29-30, D-60329 Frankfurt Tel: +49-69-244506-0 - Fax: +49-69-244506-50 Web: http://www.acrys.com - Email: [EMAIL PROTECTED] Handelsregister: Frankfurt am Main, HRA 31151 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
