Rainer Pruy pisze: > Thanks Grzegorz > for illustrating some aspects of the basic concepts. > > From my first post in this thread you can read that I already had the > impression > that on the way from M to A some POST call might be missing in the > interaction. And thus unsuccessfully tried to abuse some mechanisms > of SSP to get the trick done.....
You are right, I forgot about your attempts. > I think, you're right that inverting control will allow for keeping the > necessary control for a e.g. form contained within block A. > I'm still pondering the structural difference between my approach and the > structure and ideas laid out by you. > I'm not yet sure, I'll get convinced to it, but more on this further down.... Don't worry, I expected little opposition from you. :-) > To put the reasoning behind my structure a bit clearer: > > M is the master entry point of a web based application. There reside access > control, (top) navigation logic and basic contract for > presentation (e.g. themes). > > The application consists of a dynamic set of modules (e.g. A) that implement > various aspects of possible interactions and > functionality of the application. Thus, the basic contract and interface of M > is most likely known when e.g. A is implemented. > > However, in the end, I'd like to implement M without knowledge of any of the > (possible) blocks (e.g. A) that the application > installation is composed of at a given time. (So, just add a new block and > there are new menu entries and is new functionality) Yes, it's fair requirement to implement block providing common functionality and resources without thinking about particular cases (blocks). I would like to change name for M block. In my humble opinion it's not *master* but *common* block. It contains resources that are commonly used for pages generation. After changing wording a little I think that real role of M block becomes a little more evident: it's just accessed by other blocks generating specific page. As you see, I suggest to invert role of M block too; from the block accessing (in order to do delegation) all other block to the block accessed by all other blocks requiring common stuff. > Spring does help a lot here (e.g. registering new menu entries with a > "global" manager located with block M). > Nevertheless the whole idea fails miserably, if any menu from a subsidiary > block requires some additional "coding" with M. I don't understand why you would need to modify M when new A block is added. Could you give an example? Anyway, you are touching on another aspect of SSF: dynamic blocks/services discovery[1]. > So, yes, I'am making use of delegation of control here (at least for some > detail aspects of the final page). > But that should just resemble "standard" functional delegation, same as it is > quite natural with "calling" functions in classic > programming languages. Agreed but lets think about it for a while. Isn't it weird that you have one single function that takes numerous parameters that it doesn't care about but only passes to another function and only there all the interesting stuff is happening? Don't you have a feeling that this big procedure is redundant and only adds to stack trace unnecessarily? I have such feeling all the time I think about it... If you invert roles, then A block also uses delegation for generating common layout but this time there is only one procedure taking numerous parameters and the second, responsible for generation of common stuff, takes only a few of them or maybe even none. I see such situation as improvement and less complex code. > Responsibility of interactional behaviour for a certain region of the final > page is delegated to block A (actually one of the forms > implemented there). Probably the use case is closer to portal cases than to > normal "plain" interactions. Yes, this is about a portal case. > I'm looking at the whole structure like I would at an OO object instance. I > do have an instance that has provisions of calling some > methods on local "data" instances (fields). The signature is quite clear. The > actual implementation might cover a wider range of known > or not yet known behaviour. Nevertheless _control_ is delegated to such > methods. Of course you could restructure the whole thing to > always call the instance data method and cause it to use some implementation > parts of the (former) entry class making the former > instances derived classes in the new structure. This is what I did understand > to be the equivalent of the solution you suggested. But > I doubt this will lead to a "natural" structure of responsibilities, > especially if not all methods of the original instance data > classes should be exposed to (arbitrary) callers of M. I also try to think about whole problem in OO terms but apart from plain concepts of OO I try to take into account best practices like isolation. If you are programming in any OO language you probably consider global variables a bad practise as well as passing heavy amounts of data all over around. You strive for design where methods of objects are specialized, don't you? > I totally agree with you that exhibiting the original web request to a > subordinate block is a bad idea. A clean solution must provide > a "new" request providing (some) control over what is contained in it and how > to handle responses (and what information to provide to > the subordinate block. For sure this will not be the most optimally > performing semantics, but it might be a valid internal > optimisation to pass the original request (properly enveloped to guarantee > contracts) in some situations. But never ever should the > specification require the original request to be visible to any block other > than the initial target. > (If I followed previous discussions correctly, current approach involves > serializing and deserializing requests to I at least two weak points: 1. It adds a lot of complexity to SSF thus to applications basing on it as well. 2. You are starting to establish cases: to pass something or not. The second one is the most important because it destroys the whole idea of your M block. You probably wanted to have one nice, universal pipeline delegating generation of some parts of your pages to subordinate blocks. However, if some of them require M block to pass some data of original request it becomes kind of troublesome because you need to dynamically chose if you need to pass data or not. I bet you (or one of your young developers) will end up with passing everything to every block. That would be a complete disaster and contradiction of ideas behind SSF. Imagine you have many, many roads crossing each other in one point. You can easily imagine that no matter how big crossroads you will build with how many fancy spiral ramps you will build it's going to be a major bottleneck in the whole traffic. What I suggest is to build more, smaller crossroads that will distribute the overall hindrance among many different places. > Thus, if the current SSP already is creating some kind of request, what does > prevent it to allow for setting up a POST (or any other > request method besides GET). Ok, there is some need for a syntax to make > clear what kind of request should be performed, while the > regular use case would prefer following the request method that triggered the > subsequent call. This will also provide a clean > transitive semantics for internal resources: some are best exposed using GET, > others require POST, or other methods. And it is up to > any caller can ensure correct usage. There is a subtle problem with this approach. You mentioned servlet service calls in your previous e-mails so you are aware of the fact that internally they use POST requests to pass XML data to be processed. What if someone stumbles upon the idea of creating a service that requires access to the original request. Sure, let's pass the POST data coming from browser, but what the heck are going to do with the XML data that needs to be passed as well? > I have the impression (or some kind of inkling of) that what we are > discussing here is equivalent to (direct) field access in > classical OO and we now are about to recognize that objects (aka blocks here) > might also have methods and our field access semantics > should consistently be extended to such method calls. > > URLs being resolved to pipelines somehow resemble accessing fields in OO > languages. It sounds quite unnatural to just invert > algorithmic control to cleanly get access to some (probably overloaded) > fields when delegating control would be more appropriate? > (Leaving the question unanswered whether my initial use case would serve a > good argument example here). It's more making methods call than accessing to the fields. What if you take argument of redundant parameters (data) passing? [1] http://thread.gmane.org/gmane.text.xml.cocoon.devel/76320/focus=76360 (at the bottom of the message) -- 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]
