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 Mon, 28 Jan 2008 12:04:42 GMT


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: 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