Rainer Pruy pisze: > 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.
Yep, you are right to every detail above. It's a basic idea behind block to provide an effective way of making resources and services separated and package them as reusable units. I don't think you can be even more overenthusiastic about Servlet Services features than me. ;) I really believe that SSF has a great potential and to be honest I'm little bit sad that we haven't show all its power up to date. > 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). I wonder about the situation when you just call an external form handling without taking any further actions. Why don't you just delegate entirely the form processing to A block and complete about M completely? > 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. If you just forward I would expect that you just redirect to A block and give it a full responsibility of further request but I guess it's not that simple. :) > 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. Yes, I understand your use case and I even know what's kind of problem you are experiencing. > 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? I think that your use case is valid and you are not making any fundamental mistake by just having such use case but I don't like your design. I agree that your situation is rather edge case that, as it turns out, exhibits some weaknesses of current implementation (read it: lack of necessary features) of SSF. Let me explain where is the exact problem. When form is being submitted by the browser the POST request is being made. The POST request comes to M block; it's matched by "register/**" pattern and generation starts by calling servlet:reg:{1}. We are close to disaster because, using servlet:reg calls means using internal HTTP requests made by M to A block. This internal request is being processed by A block just as it would come from the browser but it doesn't. When internal request is made, it's a GET (at least in our situation) so Form logic in A block thinks it's a first browser request thus serves clean form. The first impression of mine was that we just need to add a feature of passing original request in almost virgin state so if original was POST the internal should be also a POST, etc. After a thinking about it for a while I came to conclusion that something fundamentally wrong is with such approach when two blocks are having access to the whole browser's request. Yes, I meant exactly that: it's fundamentally wrong two forward browser's request. When you think about content of the final page served to browser the way you aggregate data might look proper and logical. You have common snippets like menus, headers and variable content that might be some article or form. It's ok to pull variable content from other blocks (realizing various parts of site) and aggregate it with common layout. It's ok if it's really aggregation of /data/. However, in your case the call to A is not about asking a data. In fact, it's delegation of the _control_ because it depends on A block implementation how sequence of browser-server interactions will look like. In such scenario block M is redundant (as being only dumb proxy) and breaks cleanness of the design. I think that the best practise is always keep control layer in a one block, and it should always be the one handling browser's request directly. I think following such rule guarantees clear, easy to maintain code. What to do exactly in your situation? In short: invert roles. It must be A block the one handling browser's request and pulling data (common layout) from M block. You may be worried that A is closely tied to M block which does not seem to look good. However, you should bear in mind that A must be tied to _interface_ M is implementing. The interface is in this case the set of resources served by block. A block relies only on the interface and you can replace use of M block by any other if you wish without touching A block's code. If you don't know the interface of M block at the time of implementation of A you can chose another way. You can extend raw (read: not being aware of final layout) A block and *override* pipeline from A responsible for rendering form. In overridden pipeline, you can implement easily an aggregation of other resources and even call original pipeline (think of super call) as one part of the aggregation. - o0o - I think that you have touched a really interesting area of Servlet Service Framework's application. Your case brings some problems but at the same time it lets some deeper ideas behind SSF design shines. It's quite exciting because we seem to be at this point in time when we start inventing /design patterns/ similarly as it happened for Object Oriented programming languages. Rainer, I would like you to think about what I have said above and share your comments. It's really crucial to think about it thoroughly because we are the stage of carving in stone various design decisions behind SSF. Best regards, -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
