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 Mon, 19 May 2003 00:39:53 GMT
got lengthy reply again (it's basicly a bad habbit, but in this 
is case, where the subject is not that easy IMHO, we can use 
being explicit in) in short:

- Stefano, you're getting through, so there are loads of 'aha, 
got it' with some rephrasing to kind of check-off/acknowledge
- some new elements though,  so: hoping on new comments
- and I mention Sylvain somewhere down the line, since I 
side-ways pick up on his reply as well



Stefano Mazzocchi wrote:
> on 5/17/03 5:28 PM Marc Portier wrote:
>>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.
> 

afraid, it's not by just using it that this kind of questions pop 
up... there is a large user base that just hopes this was (/will 
be) done 'right' :-)

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

great stuff, thx, bit hard to follow how much of the discussion 
is already inside code-commits (common issue with this kind of 
stuff: he who has missed the dynamics of the time has a though 
job catching up)

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

agree, my name for it is equally biased by how I'm looking at it

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

while:
1. this is great opinionating (is that english?) writing (Belgium 
just had federal elections today, you would've done a good job 
;-)) and

2. I'm quite sure your paper would easily convince me:

however: untill then I rest to be convinced ;-)

please don't be offended, this is said jokingly, I'm maybe just 
too over-exposed to the habit of doing webapps like I did them... 
I don't see myself as not being able to switch, but I do know 
that generally when frameworks are offering me the 
super-advantages I see everyone here assigning to the flow-stuf, 
then there is often a price to pay in terms of 'sacrificed 
control _I_ have'.


In any case, maybe I should try to let you in on how we've 
recently been tackling more and more web-based apps to our 
satisfaction. (It's not that far off from continuations, but 
still different, and it's also not the classical http-session 
trick, although if you abstract enough all of them are basically 
the same of course: generating smart URI's that get hooked back 
by some server side state into some application flowing over to 
the browser-user :-P)

We were reading too much ReST articles and opinions when we 
suddenly had the idea of considering use-cases of web-interaction 
steps as being resources with their own state (in fact some of 
this was expressed (burried?) in our talk on last year's cocoon 
gettogether: 
http://outerthought.net/gettogether/handouts/14%20-%20presentation%20-%20mpo.pdf 
pages 5 and 6 if you want to unburry fast :-))

In short:

1- we have a URI that points to 'initiating' a particular 
use-case (== 'set of interaction steps', but just as flowscripts 
we saw this often map quite directly to the concepts from 
user-interaction and business domains, hence the abuse of the word)
2- hitting this URI results in an instance of this use-case to be 
instantiated, this instance has its own memory (rather then 
abusing the session) of what has happened in that use-case up to 
each moment in time
(truly resty we would recommend the 'hit' to be a POST, and the 
response to be a browser-redirect to the newly created 'temp' 
resource... although this often makes more sense if the 
'user-agent' is not a browser, thinking b2b I mean)
3- inside the URI-pointing to the use-case-instance you can have 
different sub-resources (the instance often also has some 
knowledge of the logical current default sub-resource)


This approach easily offers two interesting modes of operation
1- the session is not limiting the end-user to the typical 
single-instance lock: I can have two windows open for different 
simulations and there is no single session storage which will 
side-influence the 'resource-state' of those separate interactions

2- what we call the 'callcenter-assisted' completion of the 
use-case: the URI's are known and can be communicated, some-one 
else can step in, change 'your' temp-resource, you just do a 
refresh to see the changes... (you might also call this the 
chatroom-experience)

So, basically I'm investigating a sensible way to get using this 
web-app-technique as easy as possible for cocoon users.

You may shoot me now :-)
(but not with the FS argument, right?)

> [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!
> 

yep, got this...
I see how I'm trying to just move up to a higher layer were I see 
more reuse, but I agree that if any particular app coule benefit 
from this, it's probably to be implemented as a further 
modularisation inside his specific controller, so out of the 
scope of cocoon....

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

I see you're saying "blah" is a String variable,
guess my question is can this (or any other) String be passed to 
the flowscript, in fact, in more general terms: can the called 
js-function declare arguments, and can the sitemap pass them over?

(but I get the feeling you're going to answer that I don't want 
to do it :-))

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

yeah, you mean an additional mapping layer offering no extra

(as I expressed earlier with my remark if the controller would 
see a benefit for extra modularisation of it's logic-components 
then such mapping/flexible configuration should be on his 
account, and trying to stuff all of this inside cocoon is FS, right?)

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

sure, I was never aiming at getting rid of it, rather superpose 
one on top

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

got it

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

yes, but I could still have two flow-scripts fs1() and fs2() that 
are delegating to a same dothis(arg1, arg2) that actually does 
the real stuff on the args that are stored and retrieved under 
control of the surounding code in the fs1 and fs2

I was trying to pull that up in Cocoon, I see now how this is not 
helping Cocoon as a framework

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

you did not manage to insult me though :-)
sorry if I sounded defensive and gave you the idea, I was 
actually trying to learn something new (are there smileys for that?)

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

Ok, there was anothere rant on actions, and I basically relate to 
what you are saying... however I'm still in this view (you 
actually confirmed me on that one) that flowscript is 'a' way not 
'the' way...

on my short-list (as I tried to show earlier) of webapps 
techniques to date there is now 3 distinct techniques

1- continuations based
2- temp-resource-interaction-instance-based (sorry for being so 
full of ourselves, looking forward to your comments on it)
3- the 'classic' (you called it FSM)

I would guess there is practically nothing you could do with one 
that couldn't be done with any of the others, and you might 
possibly agree that there are just cases were the obvious choice 
for one will naturally rule out any of the others...

I here you saying that the 'classic' should never be done by 
using actions, although to date it's pretty much the only way 
people get to do it, no?

So I'ld gladly rephrase my call 'to-patch-actions' towards 
formalize the sitemap to 'controller' interface in a way that 
would allow for any of the techniques to fit the bill, preferably 
in a way that all the beautifull pipeline components (jxpath 
transformer et al) would fit the bill.

(but I'm starting to repeat myself, sorry for that)


Blast, I'm just reading up on what Sylvain said in this thread...
Synchronicity?  I mentioned the following on my blog after 
launching this thread:

<quote 
from="http://radio.weblogs.com/0116284/2003/05/16.html#a115" />
Where is the fundamental difference between how sitemaps look at 
subsitemaps, actions and flowscripts? Why the different contracts 
between them? (Why the sometimes strong feelings for or against 
one or the other?)
</quote>

So, Sylvain: your remark about the explanation of the name 
TreeProcessor and the Processor interface... how wild are my 
mind-loops if I'm in fact hearing that the interface between 
sitemap and flow could very well be this already existent 
Processor? just as sitemaps and mounted-sub-sitemaps work?

(of which I have no idea, I just saw this sudden synchronization 
happening, easy explanation on that?)


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

jummy,
more of dynamics I missed out on...
how much of this is still to be done, who's doing what on it, is 
there a roadmap getting us there, work to be taken up?

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

sorry, hope you see by now I'm using 'actions' word as the 
placeholder for proverbial 'classic' stateless web-app design 
technique because they are currently the only cocoon beasts that 
somewhat allow it.

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

thx, read up tomorow on that

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

or just documentation is missing
and euh, not always: I know I'm also way too lazy to read up 
everything, rather just dump into the code and start asking 
questions ;-)

but then you can simply answer with a URL right? (prefering that 
over the RTFM :-))


-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