cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: SoC between flow and sitemap
Date Sun, 18 May 2003 17:58:15 GMT
on 5/17/03 5:28 PM Marc Portier wrote:

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

oh, yeah, it was something I was already aware and concerned about.
Having more people realizing it makes it even more evident.

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

of course.

[snip]

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

(...looking it up...)

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104766591429125

and following in thread.

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

This is absolutely correct.

> '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 agree, it makes perfect sense.

[snip]

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

I would strongly dislike ControlState. In fact, we are not controlling
state, but controlling transitions between states. Unfortunately, I
don't have a name that really fits my vision.

The sitemap interpreter is called TreeProcessor and it's so general that
it doesn't really mean anything.

Here, we are basically passing a read-only map. Should we call it
ReadOnlyMap? nah.. it sucks. hmmm, any idea?

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

(FS-alert rising) The reason that every computer program can be
described with a turing machine doesn't really make it useful to
consider it as a real solution to take into consideration when
describing a software architectures.

I strongly believe that the FSM-mindset will be whiped out by
continuation-based approaches, as much as if/then/else whiped out the
need for gotos.

In March 1968, Edsger W. Dijkstra wrote the most influential paper on
the history of programming languages "Go To Statement Considered
Harmfull" [http://www.acm.org/classics/oct95/]. There is *NO SINGLE*
programming language today that wasn't influenced by that paper or by
the culture that it created.

History repeating. Today, I'd write "Finite State Machines description
of web applications considered harmful".

[snip]

>>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?)

pfff, it's a *contract* between two separate concern islands!

how you know how to connect to my web page? I give you the URL.

How do you know how to get the information I (controller) pass to you
(view)? by agreeing on where we put it!

How do you remove that contract? you can't!

If you are passing a mapping information from the sitemap to the
flowscript to instruct where to place things, you aren't removing the
contract, you are simply moving it into another place (the sitemap
instead of the flowscript).

But it's *NOT* the sitemap who does the controlling and it's not the
sitemap author which is in charge of describing and managing this contract!

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

It is *NOT* hardcoded into java. It's described in your flowscript!
(even today, for that matter!) when you do

 sentPage("blah", { "whatever", whatever })

you are invoking the pipeline identivied by "blah" by adding the pair:

 "whatever"[string] -> whatever[object]

to the ReadOnlyMap passed by the controller to that pipeline and your
generator calls

 Object value = ObjectModelHelper.getReadOnlyMap().getParameter(name);

where "name" is given by the view (say, a JXtemplate indicating
#{whatever}) as "whatever".

There is no hardcoding whatsoever.

[note: ReadOnlyMap sucks, it's just there to show you my point, it's not
a real suggestion]

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

hopefully the above does.

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

I lost you here

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

ahhhhhhhhh! NOOOOO!! this is controller logic. this is defined in the
controller and managed by it and only by it. the view just *presents*
the information passed to it and the sitemap just maps the resource
requests to the appropriate machinery to generate it.

*this* is clean SoC. having data control instructions partially in the
flow and partially in the sitemap, is, IMHO, reducing SoC clarity by a
great amount.

> 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

that's the point: they should *NOT*! it's the flow that knows where data
is, where data goes, when, why and how. Your logic components can
provide services to the flow (say, bean validation or content
repository) but should *NOT* mess with the rest of the webapp control.

> 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

I hope I managed to show you that:

 1) a contract between the view and the controller is required and it
cannot be eliminated, no matter what.

 2) the controller should be the only one responsible of controlling the
data and therefore the island responsible to manage the data controlling
and storing concern.

 3) the sitemap nor any reusable control components should contain any
information on how to deal with the above data controlling concern

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

the reason why redirection inside actions is bad is *NOT* that the URI
contract should not be used outside the sitemap realm, but it's because
redirection indicates flow logic and that logic is scattered around
several different actions, reducing its overall usability because the
"reuse level" of actions is extremely poor because, in fact, they
represent "fragments of flow control"

by separating redirection from action logic, you are simply improving
the usability of the action itself by avoding the slow
modify/recompile/reinstall/reload cycle that actions impose on you.

it's just a way to improve a weak system.

> [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 was half-joking but forgot to put the smiley. Sorry, didn't mean to
insult you in any way. I apologize for my previous tone.

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

of course!

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

yeah, it would be *very* nice to do so. The way the actions should
interface with the sitemap is: NEVER!

Actions should interface with the flow and only with that.

This will finally remove that stinking <action-set> crap from the
sitemap which is a dead-poor-man try to come up with glue between
granular controlling components that resemble a "flow control".

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

I'm sorry, but Actions are, IMO, doomed. They aren't even worth the
effort to fix them. The flow allows you to glue
general avalon components. And blocks will allow you to add your
components at runtime in a versioned and hot-deployable fashion.

Who needs Actions then? (besides back compatibility, that is)

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

Actions get access to the object model and will automatically have
access to that object as well. No need to do any change there.

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

Because you don't need to! The machinery that will be put in place is
powerful enough to wipe them out entirely, reducing the overall sitemap
sitemap complexity and producing *MUCH* more elegant solutions.

IMO, it's not even worth trying.

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

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?

yes. completely. but this has been already discussed and acconted for:

 1) you can call cocoon.getComponent("form-validator") from inside the
flow, get an avalon component (the truly generic service provider) and
you use it. Period. No need for actions.

[your block deployment descriptor will also know how to map
"form-validator" to its implementing class and instruct the classloader
to what jars to use to look it up (note that this IoC allows for runtime
hot-deployable operation!)]

 2) you do

    <map:flow>
     <map:script src="flow.js"/>
     <map:script src="block:role:/flow.js"/>
    </map:flow>

where the block "role" exposes a pipeline called "flow.js" which could
be read from an internal file or generated by a pipeline (for example,
it could take a workflow description in WFDL and XSLT-transform it to
flowscript code)

Voila'!

You get:

 1) clean SoC
 2) polymorphic behavior
 3) IoC
 4) hot-deploying behavior
 5) transparent versioning

Why would you want to use actions then?

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

Hope I provided enough information for that. if not, ask for more.

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

the block: protocol is described in

http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition

in the section called "Resource dereferencing".

>>>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 ;-)

don't worry. I like these discussions because they show how much is not
understood of what has already been designed and agreed on (which
indicates that agreement might not as vast as I thought)

-- 
Stefano.



Mime
View raw message