cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Pruy <Rainer.P...@Acrys.COM>
Subject Re: C2.2: Accessing form via servlet services?
Date Fri, 25 Jan 2008 16:06:06 GMT
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: office@acrys.com
Handelsregister: Frankfurt am Main, HRA 31151

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message