Grzegorz Kossakowski schrieb:
> 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.
Agreed, that would better reflect it's role in page composition.
However, a small but nevertheless important role is authentication and (global)
authorization.
I have the firm conviction that it is bad design to rely on each subordinate
block (the "A"s) to correctly implement the
authentication and authorization contract of the overall application.
Especially if we allow for such blocks to be contributed by
"third parties". Not involved with putting up the application in the first
place (e.g. customers).
>
> 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?
If there is no inversion of control, and passing (POST) requests resulting from
submitting forms does not work transparently, the
there must be provisions with M to process forms from any subordinate block.
>
> Anyway, you are touching on another aspect of SSF: dynamic blocks/services
> discovery[1].
Having a standardized way of discovering blocks dynamically, would ease
handling the overall structure (e.g. better error messages on
requests to (currently) not available blocks...)
For my current use case, I can come by without, as there is a quite strong
motivation for an implementor of a subordinate block to
follow a local registration policy (otherwise it won't work reasonably).
>
>> 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...
As it adds "single point of authentication/authorization" it is not redundant
in the first place.
When just considering contribution to resulting page, you are right.
>
> 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.
Yes, it will simplify code for M while adding a bit to each subordinate ("A").
>
>> 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.
It will extend to it a bit more, if M would have areas, where more than one
subordinate is to be displayed at a time with the
resulting page. In such case there would be more changes required to both
blocks involved as only one of them can take over control.
(Imagine, both subordinates are going to show forms...)
>
>> 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 can not see where in the current structure we would have something resembling
global variables.
I'm just trying to apply some abstract concepts (from OO world in this case) to
SSP.
We are providing derivation and overriding semantics for "data".
A block currently exposes (some) pipelines to be "called" (used) from other
blocks.
Any such pipeline will get called on the purpose of retrieving the "data"
associated with said pipeline.
A contract will usually include basic semantics and format of such data.
This will suffice for most cases. nevertheless, as long as a pipeline is
allowed to provide aspects of control (flow via map:call
(function or continuation) the actual data just is a side effect (the
activities carried out while retrieving the data result are a
side effect in the first place but as the initial side effect is the main
interest here, view on things and attributions should be
changed).
This is close to the difference on stateless and stateful classes with OO
languages. (and please everyone, do not start a discussion
on whether stateless or stateful designs are superior).
Current use of SSP supports "functional" calls, where result just depends on
parameters. The question effectivly no is, whether SSP
should/will/must support any stateful semantics that cocoon itself has
provisions for.
>
>> 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.
Reading this I now come to a little hesitation:
Should we disregard conceptual consideration, when there (not yet) is an
efficient way of implementing said concepts?
I personally prefer, setting up sound conceptual world and then ponder
implementation alternatives. Then there might be sound reasons
for disabling or trimming down conceptual possibilities at certain points due
to implementation restrictions as such restrictions then
can be easily documented and communicated to users. Having to cope with an
abundant set of concepts that are needed for covering the
overall design space has it's own complexity risk.
>
> 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.
I'm fully aware, that in practice implementors will choose to just pass the
complete request (at least for avoiding to seriously
consider what really would be needed or really should be available with
subordinate blocks). This was reasoning behind my remark for
probably short circuiting such special case to improve performance. But risk of
misuse by programmers might not be sound ground for
rejecting a major concept.
>
> 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.
You're absolutely right, M is a major bottleneck and that is on purpose. M in
my case (the central crossing) is just the big toll
station (to keep the picture)
>
>> 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?
Sorry, here I got lost.
Where does XML data come in here?
For my (probably simplistic perspective) SSP is the method call runtime
implementation for an object based structure based on cocoon
blocks. Calls my result from a "browser" or form other blocks (or probably from
other sources e.g. web services...).
Naively, I assume a block should be provided the very same "calling"
possibilities than a browser would have (and currently does have,
obviously).
Whether performance considerations require special actions for executing some
calls should be a question left to implementation.
>
>> 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?
Can you explain a bit more here on what you have in mind?
>
> [1] http://thread.gmane.org/gmane.text.xml.cocoon.devel/76320/focus=76360 (at
> the bottom of the message)
>
--
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]
