cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: SoC between flow and sitemap
Date Sat, 17 May 2003 22:28:25 GMT
Stefano et all,

Stefano Mazzocchi wrote:
> on 5/16/03 2:52 AM Marc Portier wrote:
> 
> 
>>Please understand: I _do_ like flow (how could we not) there just 
>>seem to be some unclear contracts between flow and sitemap in my 
>>head.... (so excuse me for the maybe rant-y tone of voice here)
> 
> 
> no problem. The more we sort those things out before we release, the better.
> 

I didn't really have a release in mind, but thx for confirming 
that there is something to sort out :-)


Hope you (and others) can spend some more time to this, cause I'm 
getting a bit more persistent in this reply :-/


> 
>>I hope to be fueling some discusion that might lead to clarifying 
>>some of the contracts usefull for general web-app-development 
>>inside cocoon (even for those not using flow maybe).. it could be 
>>that I just overlooked some ready excisting facts of life, please 
>>point those out then
>>
>>
>>[1] flow communicates with pipeline components behind the scenes.
>>(Actually it's not the only component doing so, but that should 
>>not be seen as a justification)
>>
>>sendpageandwait() sets two important objects as attributes to the 
>>request attribute... (the continuation and the so called 
>>bean-dict (hashmap-like 2nd argument to the function)
>>
>>these get picked up by jxpathtransformer (or generator) or any 
>>other pipeline-component that wants to use that information.
>>
>>And there is my fundamental itch with this approach: those 
>>pipeline-components are to be written to deal (exclusively) with 
>>the quite arbitrarily manner in which these 'beans' or usefull 
>>objects are communicated between the deciding logic (flowscipt) 
>>and the consuming publication pipe components
> 
> 
> Yes, this 'weak contract' is a known problem. The way the flow
> communicates with sitemap components is underfined.
> 
> In the past, Carsten expressed the need to avoid adding flow-specific
> hooks into the cocoon object model. Carsten, do you still feel that way
> about it?
> 

Sorry, for missing that previous discussion (pointers to archives?)

Anyway, I would clearly see why Carsten takes this approach 
(although he might have different reasons): Flow to me seems to 
be 'A' not 'THE' way to hook up arbitrary controlling logic?

'That' was probably why the SEPARATIONoC is in my subject... I 
would like to see a contract between sitemap and 
'arbitrary-control-logic' in such a way that not only flow can 
implement it?

> I know you dislike flowscript and would like to be able to deploy your
> stuff without it, but this is forcing such an important internal module
> to be based on such a weak contract and many (myself included) dislike
> this very much.
> 
> Besides, if you don't use flowscript tags into your sitemap, the classes
> are not even loaded by the treeprocessor, so you can deploy your
> machinery without even shipping rhino and things would work anyway.
> 
> I would suggest we add a Flow object to the object model.
> 

would love if it could be called more abstractly a ControlState 
object, and that other components can fit that bill.

More then flowscripts being 'a' way rather then 'the' way, also 
the concept of continuations (however refreshing and thought 
provocing they might be) seems not to be the only sensible way to 
build webapps that require some server side state management.

> 
>>While it's a perfect Model2 approach I would argue that we do NOT 
>>want to keep these arbitrary choices (why the request object? why 
>>the chosen attribute names?) hidden in the java implementation 
>>source codes, yet rather have it under the control of the sitemap 
>>editor.
> 
> 
> Uh?
> 
> 
>><map:match pattern="...">
>>   <map:call function="..">
>>     <!--+
>>         | Can we (euh, do we want to) come up with some
>>         | mapping in here between
>>         |  - logical names of important objects produced
>>         |      inside (by) the flow script: 'continuation',
>>         |      'bean-dict', but also script specific stuff like
>>         |      'user-preferences', 'chat-room',...
>>         |  - and some arbitrary object-addressing-string that
>>         |      allows to formally describe in which space
>>         |      (session, application, request) and under which
>>         |      attributename that 'logical' object is to be
>>         |      stored/retrieved
>>         +-->
>>   </map:call>
>></map:match>
> 
> 
> ah, you want the sitemap to be able to indicate the mapping between the
> flow parameters and the object model?
> 

yes, each 'controller' you would like to have in a webapp is 
typicall capable of producing a number of logical objects...

however, deciding where to store those objects is not an aspect 
that that controller should be concerned about... making sure it 
is outside the logic-component would make sure that it can get 
reused in order to produce a different app.

> I don't like it. I think it would be much more separate to provide a
> Flow object in the object model and let the components take care of it.
> 
> components that interoperate with the flow known about it anyway so that
> can load the right object and play with it with no need to
> flow->object_model translation dictated by the sitemap.
> 

mm, I think you go by at my point here...
my question would be 'how do these components know about how to 
load the _right_ object from the FlowObject' (or ControlState?)

and while answering my point is: if this knowledge is inside 
java-'hard'-code then the reuse of that component is directly 
limited.

> 
>>I would find it logic then that those so called 
>>object-addressing-strings (they should be quite url-like) get 
>>reused to guide the pipeline-components to where they might find 
>>additional information.
> 
> 
> I really don't see the need for this sitemap dictated mapping. Rather
> the opposite: it is complex and doesn't change the picture at all.
> 

getting your point, I just don't (yet) see an alternative to 
letting the controlling component know where he is expected to 
store stuff...

in my head it's more then only processing this request, for that 
we might have 'arbitrary controlling logic' setting up some 
string-values (and maybe even XMLizable arbitrary objects) ready 
behind some attribute-names in this hoped-for ControlState 
object. Pointing to these attributes we know there will be 
references in the publishing pipeline's XML (and not hardcoded in 
the components itself) that will be replaced by the actual values 
as available in the ControlState object...
(this is what you are saying, no? Where ControlState == Flow 
object of course)

next to this request-space however, the same state objects might 
need to be stored at different locations (session, application) 
for reference during subsequent requests...

as I tried to point out earlier in this mail: it limits the 
reusability of the logic-components if they have to be concerned 
with the decisions of those physical storage locations

I'ld like to admit that my proposal tried to catch both flies at 
once... would hate for one of them never to get swat down though

> 
>>[2] flow decides on pipelines outside the sitemap-control.
>>
>>sendPageAndWait()'s first argument points to the cocoon 
>>publication line to use in any given instance.
>>
>>If I would compare this to Actions it would pretty much be the 
>>action that decides on the redirect to use rather then returning 
>>a map that contains enough state-information that allows the 
>>sitemap (with the use of more matchers, selectors and/or smart 
>>resources) to put the correct pipeline to work.
>>
>>Making this comparison
> 
> 
> oh, did I ever mention that my FS-alarms get activated when I smell
> symmetry-driven design?
> 

guess I expressed myself wrong here
[1] what I tried to say
suppose I would have written my arbitrary decision logic not as a 
  flowscipt but as an action, then 'best practices' would 
probably go against using the redirector inside that action... I 
thought the big reason for that would be that you don't want to 
hide that stuff from the sitemap-editor (or even have taken those 
decissions in a way he is forced to adapt his uri design work)


[2] symmetry driven design
never heard of, so I wouldn't know the rule I'm violating...  I 
though good OO (and SoC) came from understanding what is 
(perceived) different and what similar or the same and then 
abstract that out in interfaces? There is nothing more I'm 
seeking for.

> 
>>I'm in fact questioning if we wouldn't 
>>rather put that part of binding the flow-state back to the 
>>uri-request-space under control of the sitemap (the one in charge 
>>of the pipes and their matching URI's in the first place?)
> 
> 
> I don't get it: in the flow, you have the ability to assemble the URI
> you are calling as you like, then in the sitemap, you process it. There
> is no redirection, just invocation.
> 

ok, the URI's in the flow are in fact implicit cocoon:// uri's right?

> And you are passing *both* URI and a map, but the URI goes to the
> sitemap and the map goes to the pipeline, actually separating concerns
> that, in actions, were mixed.
> 
> Following actions as paradigms is going backwards in SoC design as flow
> allows *better* SoC.
> 

Mmm, as soon as we can state it this clearly, again it would be 
nice to now change the way Actions interface with the sitemap?

Why not allow actions also to ONLY use the pipeline-invocation 
rather then the more generic redirection?

In fact, if we would get to define a ControlState object, why not 
let Actions access it as well?

So, I see a big lesson learnt from flow here. And euh, there has 
been this continuous love hate with Actions, no?  Then, why not 
tune them (change the contract with the sitemap) to benefit from 
what we learned along the way?

> [...]
> 
> 
>>So, It's not because the js-script and sitemap.xmap are different 
>>files that they shouldn't be under control of the same person... 
>>(which it nowadays needs to be as I tried to argument)
> 
> 
> I've been working alone on my last two flowscript based cocoon webapps
> and I can tell you that I *enjoyed* having separate files where
> 
>  - one declaratively indicates the the pipelines
>  - the other indicates the transition between them and feeds data to
> them based on some external business logic.
> 

so, I hear it is not only in theory, but very much also in 
practice a logical separation of concerns between the two, right?

Could I go so far as to extend that feeling towards guessing that 
if you weren't not on your own but in a larger team, then quite 
logically one could foresee
- them being edited by different people
- an emerging urge to reuse scripts in other sites and sitemaps?

> The first parameter of sendPage* is *NOT* a URL, a real locator, but a
> *URI* a name of the pipeline you wish to be called. Why? because the URL
> of the browser is *NOT* influenced by the URI that you indicate in that
> call (unlike in client-side redirects!)
> 
> I really see no reasons to change this behavior.
> 

yep, think I got that... only itch remains the reuse in different 
sitemaps maybe, but maybe that's a false promise anyway? (like to 
understand why, and how reuse could be achieved in a better way then)

> 
>>However, in this case I think there is a future for a more 
>>ready-made reuse and even distribution of flowscipts that can be 
>>hookep up in different existing cocoon webapps that each need to 
>>fit it into their own uri-request-space, hopefully without the 
>>need to change the script that is.
> 
> 
> blocks will address this with the use of the block: protocol. Basically
> 
>  sendPageAndWait("block:role://pipeline",{});
> 
> will look up in the block deployment manager what block is associated
> with the given "role" in this particular context and route the request
> to the sitemap that controls that block URI space, which will match the
> /pipeline request it receives.
> 

and you lost me here... pointers on archived block discussions I 
should be checking? (hoping for some example of what it should 
look like and possibly do in some practical setting)

> 
>>regards, and upfront thx for your thoughts, counter-arguments and 
>>possible useful best practices on these
> 
> 
> You are welcome.
> 

thx again,
please do not interpret my (implicit) request for your continued 
attention to this topic as a lack of appreciation for this first 
set of answers ;-)

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message