You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/06/21 00:01:38 UTC
Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Nicola Ken Barozzi wrote:
>
> >>> Andrew C. Oliver wrote:
> >>>
> >>>> Oh god no...businesslogic in javascript.. . no no no. I'm having
> >>>> nightmares
> ...
>
> >> Nicola Ken Barozzi wrote:
> >>
> >>> Maybe, could you just help me come up with a business-logic stuff
> >>> that isn't written in sitemap or flowscript
> ...
>
> > Andrew C. Oliver wrote:
> >
> >> Yes. Lets put our heads together and think it through.
> ...
>
> Per-Olof Norén wrote:
>
> > I *totally* agree on the need for a non-compiling option to execute
> > business logic. Please do think loud on the list and I´ll help
> > thinking... :)
>
> Ok, let's start this really /proactive/ (I love this word, it just fills
> one's mouth ;-) RT about a business logic definition system that has
> these goals:
>
> 1. has a quick write-test-correct cycle, ie not to be compiled
> 2. is easy to write and understand
> 3. is modular
> 4. will make flowscript a solution to a problem, not a problem itself
>
> Definition
> ------------
>
> What the are business components-rules-whatever?
>
> A - definition(s)
> B - use cases
> C - actors involved
>
> ?
Please, stop.
Let's avoid the usual "let's tackle all problems at once" and let's try
to get something hammered down before starting using brain cycles in
some other directions.
There are yet many doubts to cover from the flowscript stuff that start
talking about something else makes less sense ATM, IMHO.
So, please, let's place this back on the stack.
Thank you.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
>>...they are not entirely separate since the business logic might also
>>influence the flow. There should be a good separation (SoC) but I think we
>>need to see the full picture. So I don't think it's totally useless to talk
>>about it right now - but we shouldn't mix it up...
>
>
> I'm wide open to suggestions on how you can *force* somebody to separate
> its flow logic from its business logic.
How can you *force* people to make COP?
Give them Avalon ;-)
Ok, there's more than a way to hang yourself, but let's make it harder.
That's why I'm asking myself what remains to be done after flowscript.
Without is, people were abusing the sitemap, because they needed a solution.
Now they will abuse flowscript, because they need another solution
(business objects).
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by Stefano Mazzocchi <st...@apache.org>.
Torsten Curdt wrote:
>
> <snip/>
>
> > > > There are yet many doubts to cover from the flowscript stuff that start
> > > > talking about something else makes less sense ATM, IMHO.
> > >
> > > This is one of them.
> > > Flowmaps are so powerfull that all the stuff that was innapropriate to
> > > be done in the sitemap (heavy webapps) will automatically slip over to
> > > flowmaps.
> > > And since it's procedural, it's a *big* concern of mine that flowscript
> > > will become the problem-solver catchall.
> >
> > I hear you, but since we all agree that business logic shouldn't be in
> > the flowscript, I don't understand the need to discuss whether or not
> > it's good to have business logic defined in a scripting language.
> >
> > This is an entirely separate concern.
>
> ...they are not entirely separate since the business logic might also
> influence the flow. There should be a good separation (SoC) but I think we
> need to see the full picture. So I don't think it's totally useless to talk
> about it right now - but we shouldn't mix it up...
I'm wide open to suggestions on how you can *force* somebody to separate
its flow logic from its business logic.
Also, I'm wondering how you can make this 'forcing' be effective no
matter what the flow and business logic of somebody is.
My opinion is: let's keep the flowscript and let's keep it limited to
what we need today and be careful in adding more features in the future.
The rest will be done with docos about best practices, flow patterns and
guidelines.
Just like you can write crappy software in Java and great software in
Perl.
In media stat virtus.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by Torsten Curdt <tc...@dff.st>.
<snip/>
> > > There are yet many doubts to cover from the flowscript stuff that start
> > > talking about something else makes less sense ATM, IMHO.
> >
> > This is one of them.
> > Flowmaps are so powerfull that all the stuff that was innapropriate to
> > be done in the sitemap (heavy webapps) will automatically slip over to
> > flowmaps.
> > And since it's procedural, it's a *big* concern of mine that flowscript
> > will become the problem-solver catchall.
>
> I hear you, but since we all agree that business logic shouldn't be in
> the flowscript, I don't understand the need to discuss whether or not
> it's good to have business logic defined in a scripting language.
>
> This is an entirely separate concern.
...they are not entirely separate since the business logic might also
influence the flow. There should be a good separation (SoC) but I think we
need to see the full picture. So I don't think it's totally useless to talk
about it right now - but we shouldn't mix it up...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by Stefano Mazzocchi <st...@apache.org>.
"Andrew C. Oliver" wrote:
>
> >
> >
> >Ok. Here's my vision: a flowscript is the location where you place your
> >flow logic. The flow logic is the collection of instructions that
> >indicate how to make the transition from one page to another.
> >
> >Everything else shouldn't be there.
> >
> >
>
> So why do you need scripting for that? It seems inconsonant with the
> rest of Cocoon and even unnecessary.
It could be, yes.
But I find it extremely handy to be able to describe the transitions
using scripting because it allows me to add programmatic logic to the
transition stages procedurally instead of declaratively.
It's just a matter of taste, I agree, the functionality can be
implemented in many different ways, but just like I like Java more than
Scheme or Lisp, I like to write procedural flows rather than FSM tables
(or Turing Machine tapes, for that matter)
> There is relatively minor difference between what XSLT does (match
> conditions and output a result) and
> what the flowscript does and the sitemap and what the flowscript does.
> The gap is I suppose a mid sitemap
> decision on what the next step should be, therefore, why can the sitemap
> not be extended with minor conditionals
> similar to the ones in XSLT and make flow decisions in XML versus
> Javascript.
Yep, 'dynamic sitemap'. No matter how hard I try to look at it, I don't
see a reasonable way to do it without coming out with something so close
to XSP or XSLT extensions.
Both of which proved to be particularely ill-suited for procedural logic
or SoC in general.
> I regard this flowmap decision as taramount to multiple inheritance. I
> think its a decision that will later come to be
> regretted. I also think I'll be seeing Cocoon applications that are
> virtually implemented exclusively in Javascript instead
> of using the sitemap at all.
This last comment of yours makes me think that you probably missed many
key points in the flowscript discussion: the flowmap doesn't have the
ability to assemble pipelines direction, just to call them via sitemap.
You fear something that is equivalent of stating that actions are bad
because you could write the entire cocoon application using a single big
action and not using the sitemap at all (which has been done, BTW)
It seems to me that it's javascript that scares people away from such a
beautiful and elegant concept and I really don't see why.
> >I hear you, but since we all agree that business logic shouldn't be in
> >the flowscript, I don't understand the need to discuss whether or not
> >it's good to have business logic defined in a scripting language.
> >
> >This is an entirely separate concern.
> >
> >
> Again, we're discussing something taramount to allowing multiple
> inheritance in Java.
Multiple inheritance in Java is allowed for interfaces and not for
classes, just like scripting is allowed to augment the sitemap
capabilities but without mixing them.
> The issue is not whether YOU
> Stefano would code your business logic in the scripting language, its
> whether lots of folks would. And hence creating more
> rediculous and unmaintainable software. Its possible to create bad
> software in any tool, but some tools enable you to create worse
> software. Its why Java succeeded despite being far poorer performing
> over C++. C++ gave you more rope to hang yourself. Its an underlying
> reason you write Cocoon in Java and not PERL. PERL allows almost all of
> the features of Java, but it not only allows but encourages bad form.
> Cocoon has areas that are coded in bad form and without comment, yet
> I'm able to read them moreso than if they were written by the same
> person in PERL for instance. The point being is that this is one of
> those features that enocourages and allows bad form and will probably
> grow into a beast.
It's interesting that you state this, yet you didn't know the
limitations what are 'hardcoded' into the flowscript concept *exactly*
not to give you enough rope to hang yourself with.
> >
> >
> >It's hard to define what a business logic is, but it's easy to know if
> >this has anything to do with describing the transition between pages
> >(flow).
> >
> >
> But a scripting language will allow you to do either.
and actions, dynamic sitemaps or dynamic sitemap extensions.
At least, with flowscript, an abuse can be refactored with little
hassle, unlike abuse of actions which becomes hardcoded into obscure
black art and nobody is able to touch it once it works.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
>
> Andrew C. Oliver wrote:
> > Stefano Mazzocchi wrote:
> > >Ok. Here's my vision: a flowscript is the location where you place your
> > >flow logic. The flow logic is the collection of instructions that
> > >indicate how to make the transition from one page to another.
> > >
> > >Everything else shouldn't be there.
> > >
> > So why do you need scripting for that? It seems inconsonant with the
> > rest of Cocoon and even unnecessary.
>
> Agree, if flowscripts only are supposed to be used for flow logic and not
> for writing complete webapps, the use of JavaScript seem like _massive_ FS
> to me.
Hmmm, I wish I was allowed to send you my 58Kb sitemap used to control
the flow of 4 URI familites (4 mathers)!
Anyway, that sitemap had 12 levels of nesting, matchers with 110 lines
each and I had to write a special transformer and 4 different actions.
Actions that were 10/15 lines each.
With the flowscript, I estimate to be able to refactor the entire thing
in a third of the sitemap code, no actions and a few Kbs of javascript.
And there is no business logic whatsoever there, just page transitions
based on system status (the entire business logic is contained in java
objects).
Now matter what, it will be hard to convince me that using the XML
syntax is a good idea to describe simple procedural logic.
> > There is relatively minor difference between what XSLT does (match
> > conditions and output a result) and
> > what the flowscript does and the sitemap and what the flowscript does.
> > The gap is I suppose a mid sitemap
> > decision on what the next step should be, therefore, why can the sitemap
> > not be extended with minor conditionals
> > similar to the ones in XSLT and make flow decisions in XML versus
> > Javascript.
>
> I described how to add some minimal flow handling mechanisms to the sitemap
> in the last sections of
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101882151416705&w=2.
> The proposal is based on a _very_ light weight kind of continuation passing.
Hmmm, I think I missed this. I'll go over it again.
> As the few commenter seemed to hate the use of xml to describe flow logic
> and the inclusion of flow logic in the sitemap, maybe I should add that one
> of course could describe the same concepts in a different syntax and in a
> separate (flow description) file.
I would not be against this, just I think Javascript is the best
compromise so far because it doesn't force people to learn a new syntax.
> > I regard this flowmap decision as taramount to multiple inheritance. I
> > think its a decision that will later come to be
> > regretted. I also think I'll be seeing Cocoon applications that are
> > virtually implemented exclusively in Javascript instead
> > of using the sitemap at all.
>
> I don't know if it is a good or a bad decision (or even if there have been a
> decision yet ;) ), to adopt flowscripts. I'm quite surprised that there have
> been so little discussion about what they are supposed to be used for. I
> guess most people agree about that flowscripts should describe the flow
> aspect of webapps, but such a general view doesn't help design much. IMO we
> need to be more concrete about the use cases for flowscripts. Without a
> common view on what problem they are supposed to solve, it is hard to know
> if a certain technical solution is good or not.
Good point.
> So what use cases do we have?
>
> * It should definitely be easy to write wizards in a flow description
> language.
> I believe this is the case for flowscripts (see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102052662705449&w=2, for
> details), but on the other hand this could be done in a much smaller and
> more specialized language. Ivelin and Torsten listed some requirements for
> wizards, IIRC.
>
> * Shopping carts? This will be possible when Ovidiu (or someone else) have
> added variables that are accessible across different flowscript invocations.
>
> * Anything more?
what? is your web-app world limited to multi-pages and shoppint carts? I
can believe that. No wonder why you think that the flowscript is FS. For
those things it might well be.
Think granular: you are talking about 'pieces' of web applications. I'm
talking about web applications all together. Think of a on-line banking
system, think of a webmail, a calendar, an administrative intranet, a
revision control system for air-2-air NATO missiles platform spare parts
(yes, I did consulting for that once!)
There is no need to write a flow for something so simple as a data-entry
wizard or a shopping cart. In fact, those are *exactly* those webapp
components where flows can be standardized and reused with little
hassle.
But I'm talking about the webapps: suppose you are hired by a company
that does this revision control system for missiles platforms. It's a
huge military system that connects to spare part databases located
around the planet, thru kick-ass crypto extranets, you have vector parts
transformed into VRML2 and you can know who, when, why and how changed
the spare part 3849484984489 of that missile.
Now, suppose you want to *understand* what's going on: how you move from
page A to page B and why, what can errors are catched, what things can
go wrong, what is called to obtain this data and how.
You *do* *not* care *HOW* the pages are created. First thing you want to
find out is how the system behaves. And 'web app behavior' is the
description of the flow, not the description of the sitemap.
So, your learning process would be something like:
1) use the webapp
[learn cocoon] (optional if you already know this)
2) learn the flowscript
3) learn the sitemap
Believe me: today there is *NO* web technology that allows this simple
course of action to get productive on a system, or to estimate in a
short term the complexity of the system in question.
> <snip/>
> > >No, no, no. With this you are assuming that it's equivalent to use a
> > >scripting language to describe business logic. This is yet to be
> > >discussed, but this is an entirely different concern from this
> > >discussion, thus my call to stop it until we have finished focusing on
> > >the flowscript.
>
> AFAIK Ovidiu have always advertised flowscripts as a language for writing
> webapps in, which is far more general than just describing flow logic. As
> flowscripts can, and most probably, will be used for writing complete
> webapps, I can't see that the business logic and the flow description are
> different concerns.
Hmm, we might be having a terminology impedence mismatch here.
I call 'flow logic' the logic that describes the transition between
states of a web application (sometimes these states map to changes in
pages, sometimes they do not, but the state changes). In this sense, a
flow logic is a white box.
I call 'business logic' the logic that describes how data is created,
handled, managed, kept secure, consistent, persistent. In this sense, a
business logic is a black box.
Example: a webmail is a web application that shows a web view of a mail
server. The business logic is the 'mail server abstraction'. The objects
you call to get access to the underlying data. In case of an IMAP
server, this is a think layer that makes a client IMAP, in case of a POP
server, the layer is bigger because it has to simulate the mail
repository.
The flow layer simply connects the web layer to the underlying business
object layer. It might become quite a complex logic, but the 'juicy'
mail-related logic is contained in the underlying model.
Nobody stops you from writing everything (even the mail business logic)
inside the flowscript, just like nobody forces you to use object
orientation in Java (you can have one single class to do everything!),
but this doesn't mean that OO for Java is FS.
> Keeping the concerns separated at this stage means that
> we decide to just discuss "if", "when", "for", "case" and the like in
> Javascript and don't care about the effects of introducing all the other
> parts of the language.
Hope the above definition of the terminology explains my vision better
because I think that writing a complex business logic using the
flowscript would be such an evident suicide that it would be our fault
if someone does it.
> If we really want to focus on the flow aspect, it is IMO premature to assume
> that flowscripts is the right solution, before we know what problem we want
> to solve.
I know what problems I want to solve: the sitemap poorely describes
procedural flow logic. So far, I've not seen any better solution than
the flowscript.
As far as the 'SpitScript' and this thread: writing business logic (as I
defined it above) in the flowscript is such an evidently terrible idea
that I don't even think it's worth talking about it at this point.
It's like stating that map:readers lead to FS becase you could write an
entire cocoon replacer as a reader.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by Andy Lewis <aj...@ascii27.net>.
I've watched this thred for quite a while. Some people don't like XML, some people don't like
Javascript. It was mentioned on here earlier, and I think it bears repeating:
What is the definition of the problem?
I know, everyone has a general sense of it. But before picking a language, perhaps it would be
worth defining what you need it to do for you. I perosnally find XML far to verbose for many
things, but JavaScript has it's own drawbacks. Frequently things like htis are simply written,
commited, and accepted. This one isn't going that smoothly. So, perhaps a bit of requirements
analysis is in order....
The flow layer must be able to:
- determine a pipeline
(I loved Stefano's propsed syntax for this that included specifying the target for the output)
- access/manipulate application state (object model?)
- access(/manipulate?) business objects (who knows?)
- perform expression evaluation
What else?
Maybe I'm going way to basic here...but I don't see this thread actually reaching any conclusions.
In fact, it appears to be getting increasingly splintered. I'd suggest a clear definition of the
solution attributes first. Then pick a solution to fit.
My $0.2.....
<snip-all/>
--
"The heights of genius are only measurable by the depths of stupidity."
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Luca Morandini wrote:
> Nicola,
>
> you wrote:
>
>>How can you define transitions without logic?
>>Transitions are based on rules.
>>Rules come from algorithms that operate on the model.
>
> I agree with you on principle, but, as of now, this wonderful rules are
> scattered amongst pages, making hard changing the flow. IMHO just
> centralizing that would be a giant step forward.
Obvious. The question is *how* can you define transitions without rules.
Look at Petri nets and Graphcets.
Interesting discussion for PLCs:
http://www.control.com/984669711/index_html
Hmmm...
Should a flowmap-flowscript be some kind od petri net?
> Moreover, you wrote:
>
>
>>And X is for displaying graphics, not running apps.
>>
>>But Cocoon is not as an X server, it does create applications.
>
> I think the example you gave is not well chosen: the web constraints
> developers to execute apps one page at a time, to deal with a lot of
> presentation that has nothing to do with the app, and to rely on tricks to
> make an application out of a bunch of pages.
> Conversely, X, being a mere abstraction layer, doesn't impose constraints on
> apps architecture.
Web pages are our abstraction layer for webapps.
You cannot write apps with an abstraction layer alone.
Webpages also don't impose constraints on apps architecture.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by Luca Morandini <lu...@tin.it>.
Nicola,
you wrote:
> How can you define transitions without logic?
> Transitions are based on rules.
> Rules come from algorithms that operate on the model.
I agree with you on principle, but, as of now, this wonderful rules are
scattered amongst pages, making hard changing the flow. IMHO just
centralizing that would be a giant step forward.
Moreover, you wrote:
> And X is for displaying graphics, not running apps.
>
> But Cocoon is not as an X server, it does create applications.
I think the example you gave is not well chosen: the web constraints
developers to execute apps one page at a time, to deal with a lot of
presentation that has nothing to do with the app, and to rely on tricks to
make an application out of a bunch of pages.
Conversely, X, being a mere abstraction layer, doesn't impose constraints on
apps architecture.
Best regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Monday, June 24, 2002 8:26 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT]
> Flowmaps)
>
>
>
> Luca Morandini wrote:
> > Nicola,
> >
> > for all our abstractions and wondereful paper machines, the
> naked truth is
> > that the web is geared toward presenting documents, not implementing
> > applications.
>
> And X is for displaying graphics, not running apps.
>
> But Cocoon is not as an X server, it does create applications.
>
> > The page structure of HTML has nothing to do with Business Object or
> > Business Rules or other abstractions... but we should deal with it.
> >
> > Therefore, let's just try to centralize transitions amongst
> pages, like the
> > sitemap has done with URI matching and dispatching. Just
> implementing this
> > feature will be a giant step forward.
>
> How can you define transitions without logic?
> Transitions are based on rules.
> Rules come from algorithms that operate on the model.
> Thus, you need
>
> > BTW, I'd like a declarative implementation, rather than using a script
> > language.
>
> If flowmaps are page transitions it could be.
>
> But it's intriguing to think that the javascript flowmaps can be an easy
> way to make webapps... hmmm...
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Luca Morandini wrote:
> Nicola,
>
> for all our abstractions and wondereful paper machines, the naked truth is
> that the web is geared toward presenting documents, not implementing
> applications.
And X is for displaying graphics, not running apps.
But Cocoon is not as an X server, it does create applications.
> The page structure of HTML has nothing to do with Business Object or
> Business Rules or other abstractions... but we should deal with it.
>
> Therefore, let's just try to centralize transitions amongst pages, like the
> sitemap has done with URI matching and dispatching. Just implementing this
> feature will be a giant step forward.
How can you define transitions without logic?
Transitions are based on rules.
Rules come from algorithms that operate on the model.
Thus, you need
> BTW, I'd like a declarative implementation, rather than using a script
> language.
If flowmaps are page transitions it could be.
But it's intriguing to think that the javascript flowmaps can be an easy
way to make webapps... hmmm...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by Luca Morandini <lu...@tin.it>.
Nicola,
for all our abstractions and wondereful paper machines, the naked truth is
that the web is geared toward presenting documents, not implementing
applications.
The page structure of HTML has nothing to do with Business Object or
Business Rules or other abstractions... but we should deal with it.
Therefore, let's just try to centralize transitions amongst pages, like the
sitemap has done with URI matching and dispatching. Just implementing this
feature will be a giant step forward.
BTW, I'd like a declarative implementation, rather than using a script
language.
Best regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Sunday, June 23, 2002 11:21 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT]
> Flowmaps)
>
>
>
> http://research.sun.com/features/ace/
>
>
> This is an example of a business object:
> http://research.sun.com/features/ace/images/ace_graphic1_lg.jpg
>
> And this of a Business Process.
> http://research.sun.com/features/ace/images/ace_graphic2_lg.jpg
>
> Looking at the business process diagram, where does the
> flowmap-flowscript fit?
> How could the rest be done?
>
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
http://research.sun.com/features/ace/
This is an example of a business object:
http://research.sun.com/features/ace/images/ace_graphic1_lg.jpg
And this of a Business Process.
http://research.sun.com/features/ace/images/ace_graphic2_lg.jpg
Looking at the business process diagram, where does the
flowmap-flowscript fit?
How could the rest be done?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Use Cases [was Re: [RT] SpitScript - B-Logic that doesn't suck (
Re: [RT] Flowmaps)]
Posted by Stefano Mazzocchi <st...@apache.org>.
Diana Shannon wrote:
>
> On Sunday, June 23, 2002, at 12:25 PM, Daniel Fagerstrom wrote:
>
> <snip />
>
> > So what use cases do we have?
> >
> > * It should definitely be easy to write wizards in a flow description
> > language.
> > I believe this is the case for flowscripts (see
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102052662705449&w=2,
> > for
> > details), but on the other hand this could be done in a much smaller and
> > more specialized language. Ivelin and Torsten listed some requirements
> > for
> > wizards, IIRC.
> >
> > * Shopping carts? This will be possible when Ovidiu (or someone else)
> > have
> > added variables that are accessible across different flowscript
> > invocations.
> >
> > * Anything more?
>
> I'm trying to imagine what it would be like to use the same sitemap
> (view) and same content (model) with different flowscripts. Here's some
> *very* preliminary thoughts on how I might apply flowscripts to a real
> world need (based on an even more preliminary understanding of what
> might be possible).
>
> Use Case Idea 1
> what: games, simulations, decision support webapps
>
> model: e.g., simulation model of an ecosystem
> - view: sitemap pipelines, presenting useful views of ecosystem (status,
> history, impacts, etc.)
> - controller: flowscripts
> - flowscript variations -> different webapps
> (a) single-user simulation game (users interact with model over a
> period of time)
> (b) multi-user game, similar to (a) but different players (characters
> with different roles) had different flow scripts
> (c) simulation tool (not a game) which shows results of policies over
> time
> (d) decision support tool with feedback about policy decisions
> (flowscripts could be even be granularized based a a field of concern,
> e.g. a farmer may want different advice than a logger)
> ...
>
> Note: I know you're probably thinking, these all could use different
> views (sitemaps) as well. While this may be true, in my experience,
> there is a lot of "view overlap" among these seemingly different
> applications.
>
> Use Case Idea 2:
> what: learning tools
>
> model: learning content
> view: document pages, quiz pages, feedback pages, report pages, etc.
> controller: flowscripts -> same tools, different audiences and users
> with varying learning levels
> (a) basic, intermediate, advanced flowscripts (or grade-level,
> professional concern) for different levels of ability (Some learners
> need reinforcement when they struggle with concepts, other don't.) This
> could be dynamically generated, of course.
> (b) different flowscripts based on context of use (how much time
> available, professional needs, etc.)
> (c) different flowscripts (for future continuations) generated
> dynamically (or by a teacher, e.g.) based on a student's past
> performance.
>
> On the other hand, once you have a great set of flowscripts, you could
> use them with different sitemaps and different models as well. With SoC,
> the possibilities seems almost unlimited for extremely valuable reuse.
>
> Is this overkill for a flowscript?
No Diana, you hit the target! With the introduction of flowscript, it is
possible to have a clear view of the logic that controls the flow your
web application, thus the 'glue' that connects your data (business
logic) with the presentation (pipelines).
You are totally right when you say that there is a lot of overlap in the
flow of very different web applications. For example, both a CMS and an
e-learning system share much of the same logic for audit trails of
content publication. But they have totally different flows from the
user-level.
Anyway, you touched the point describing not simple stuff like
'data-entry wizards', but the flows of the entire application realm.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Use Cases [was Re: [RT] SpitScript - B-Logic that doesn't
suck ( Re: [RT] Flowmaps)]
Posted by Ovidiu Predescu <ov...@apache.org>.
Diana,
On 6/25/02 6:52 AM, "Diana Shannon" <sh...@apache.org> wrote:
>
> On Sunday, June 23, 2002, at 12:25 PM, Daniel Fagerstrom wrote:
>
> <snip />
>
>> So what use cases do we have?
>>
>> * It should definitely be easy to write wizards in a flow description
>> language.
>> I believe this is the case for flowscripts (see
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102052662705449&w=2,
>> for
>> details), but on the other hand this could be done in a much smaller and
>> more specialized language. Ivelin and Torsten listed some requirements
>> for
>> wizards, IIRC.
>>
>> * Shopping carts? This will be possible when Ovidiu (or someone else)
>> have
>> added variables that are accessible across different flowscript
>> invocations.
>>
>> * Anything more?
>
> I'm trying to imagine what it would be like to use the same sitemap
> (view) and same content (model) with different flowscripts. Here's some
> *very* preliminary thoughts on how I might apply flowscripts to a real
> world need (based on an even more preliminary understanding of what
> might be possible).
>
> Use Case Idea 1
> what: games, simulations, decision support webapps
>
> model: e.g., simulation model of an ecosystem
> - view: sitemap pipelines, presenting useful views of ecosystem (status,
> history, impacts, etc.)
> - controller: flowscripts
> - flowscript variations -> different webapps
> (a) single-user simulation game (users interact with model over a
> period of time)
> (b) multi-user game, similar to (a) but different players (characters
> with different roles) had different flow scripts
> (c) simulation tool (not a game) which shows results of policies over
> time
> (d) decision support tool with feedback about policy decisions
> (flowscripts could be even be granularized based a a field of concern,
> e.g. a farmer may want different advice than a logger)
> ...
>
> Note: I know you're probably thinking, these all could use different
> views (sitemaps) as well. While this may be true, in my experience,
> there is a lot of "view overlap" among these seemingly different
> applications.
>
> Use Case Idea 2:
> what: learning tools
>
> model: learning content
> view: document pages, quiz pages, feedback pages, report pages, etc.
> controller: flowscripts -> same tools, different audiences and users
> with varying learning levels
> (a) basic, intermediate, advanced flowscripts (or grade-level,
> professional concern) for different levels of ability (Some learners
> need reinforcement when they struggle with concepts, other don't.) This
> could be dynamically generated, of course.
> (b) different flowscripts based on context of use (how much time
> available, professional needs, etc.)
> (c) different flowscripts (for future continuations) generated
> dynamically (or by a teacher, e.g.) based on a student's past
> performance.
>
> On the other hand, once you have a great set of flowscripts, you could
> use them with different sitemaps and different models as well. With SoC,
> the possibilities seems almost unlimited for extremely valuable reuse.
>
> Is this overkill for a flowscript?
I think these are all great use cases, which can show the potential of flow
scripts! I can definitely see how flowscripts would help the development of
such tools.
I started working on a simple documentation system which allows
documentation to be published, and give user the ability to add notes to
each page. I said this in the past too, I really like the way the PHP
documentation system is setup. For an example check out:
http://www.php.net/manual/en/language.constants.php
I want to implement a similar system using Cocoon, flow scripts and Castor
as a mapping tool between a relational database and Java objects. This is a
non-trivial example which I hope shows how the separation of concerns is
enforced in this design.
Regards,
--
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Use Cases [was Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)]
Posted by Diana Shannon <sh...@apache.org>.
On Sunday, June 23, 2002, at 12:25 PM, Daniel Fagerstrom wrote:
<snip />
> So what use cases do we have?
>
> * It should definitely be easy to write wizards in a flow description
> language.
> I believe this is the case for flowscripts (see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102052662705449&w=2,
> for
> details), but on the other hand this could be done in a much smaller and
> more specialized language. Ivelin and Torsten listed some requirements
> for
> wizards, IIRC.
>
> * Shopping carts? This will be possible when Ovidiu (or someone else)
> have
> added variables that are accessible across different flowscript
> invocations.
>
> * Anything more?
I'm trying to imagine what it would be like to use the same sitemap
(view) and same content (model) with different flowscripts. Here's some
*very* preliminary thoughts on how I might apply flowscripts to a real
world need (based on an even more preliminary understanding of what
might be possible).
Use Case Idea 1
what: games, simulations, decision support webapps
model: e.g., simulation model of an ecosystem
- view: sitemap pipelines, presenting useful views of ecosystem (status,
history, impacts, etc.)
- controller: flowscripts
- flowscript variations -> different webapps
(a) single-user simulation game (users interact with model over a
period of time)
(b) multi-user game, similar to (a) but different players (characters
with different roles) had different flow scripts
(c) simulation tool (not a game) which shows results of policies over
time
(d) decision support tool with feedback about policy decisions
(flowscripts could be even be granularized based a a field of concern,
e.g. a farmer may want different advice than a logger)
...
Note: I know you're probably thinking, these all could use different
views (sitemaps) as well. While this may be true, in my experience,
there is a lot of "view overlap" among these seemingly different
applications.
Use Case Idea 2:
what: learning tools
model: learning content
view: document pages, quiz pages, feedback pages, report pages, etc.
controller: flowscripts -> same tools, different audiences and users
with varying learning levels
(a) basic, intermediate, advanced flowscripts (or grade-level,
professional concern) for different levels of ability (Some learners
need reinforcement when they struggle with concepts, other don't.) This
could be dynamically generated, of course.
(b) different flowscripts based on context of use (how much time
available, professional needs, etc.)
(c) different flowscripts (for future continuations) generated
dynamically (or by a teacher, e.g.) based on a student's past
performance.
On the other hand, once you have a great set of flowscripts, you could
use them with different sitemaps and different models as well. With SoC,
the possibilities seems almost unlimited for extremely valuable reuse.
Is this overkill for a flowscript?
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by Daniel Fagerstrom <da...@swipnet.se>.
Andrew C. Oliver wrote:
> Stefano Mazzocchi wrote:
> >Ok. Here's my vision: a flowscript is the location where you place your
> >flow logic. The flow logic is the collection of instructions that
> >indicate how to make the transition from one page to another.
> >
> >Everything else shouldn't be there.
> >
> So why do you need scripting for that? It seems inconsonant with the
> rest of Cocoon and even unnecessary.
Agree, if flowscripts only are supposed to be used for flow logic and not
for writing complete webapps, the use of JavaScript seem like _massive_ FS
to me.
> There is relatively minor difference between what XSLT does (match
> conditions and output a result) and
> what the flowscript does and the sitemap and what the flowscript does.
> The gap is I suppose a mid sitemap
> decision on what the next step should be, therefore, why can the sitemap
> not be extended with minor conditionals
> similar to the ones in XSLT and make flow decisions in XML versus
> Javascript.
I described how to add some minimal flow handling mechanisms to the sitemap
in the last sections of
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101882151416705&w=2.
The proposal is based on a _very_ light weight kind of continuation passing.
As the few commenter seemed to hate the use of xml to describe flow logic
and the inclusion of flow logic in the sitemap, maybe I should add that one
of course could describe the same concepts in a different syntax and in a
separate (flow description) file.
> I regard this flowmap decision as taramount to multiple inheritance. I
> think its a decision that will later come to be
> regretted. I also think I'll be seeing Cocoon applications that are
> virtually implemented exclusively in Javascript instead
> of using the sitemap at all.
I don't know if it is a good or a bad decision (or even if there have been a
decision yet ;) ), to adopt flowscripts. I'm quite surprised that there have
been so little discussion about what they are supposed to be used for. I
guess most people agree about that flowscripts should describe the flow
aspect of webapps, but such a general view doesn't help design much. IMO we
need to be more concrete about the use cases for flowscripts. Without a
common view on what problem they are supposed to solve, it is hard to know
if a certain technical solution is good or not.
So what use cases do we have?
* It should definitely be easy to write wizards in a flow description
language.
I believe this is the case for flowscripts (see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102052662705449&w=2, for
details), but on the other hand this could be done in a much smaller and
more specialized language. Ivelin and Torsten listed some requirements for
wizards, IIRC.
* Shopping carts? This will be possible when Ovidiu (or someone else) have
added variables that are accessible across different flowscript invocations.
* Anything more?
<snip/>
> >No, no, no. With this you are assuming that it's equivalent to use a
> >scripting language to describe business logic. This is yet to be
> >discussed, but this is an entirely different concern from this
> >discussion, thus my call to stop it until we have finished focusing on
> >the flowscript.
AFAIK Ovidiu have always advertised flowscripts as a language for writing
webapps in, which is far more general than just describing flow logic. As
flowscripts can, and most probably, will be used for writing complete
webapps, I can't see that the business logic and the flow description are
different concerns. Keeping the concerns separated at this stage means that
we decide to just discuss "if", "when", "for", "case" and the like in
Javascript and don't care about the effects of introducing all the other
parts of the language.
If we really want to focus on the flow aspect, it is IMO premature to assume
that flowscripts is the right solution, before we know what problem we want
to solve.
/Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>Ok. Here's my vision: a flowscript is the location where you place your
>flow logic. The flow logic is the collection of instructions that
>indicate how to make the transition from one page to another.
>
>Everything else shouldn't be there.
>
>
So why do you need scripting for that? It seems inconsonant with the
rest of Cocoon and even unnecessary.
There is relatively minor difference between what XSLT does (match
conditions and output a result) and
what the flowscript does and the sitemap and what the flowscript does.
The gap is I suppose a mid sitemap
decision on what the next step should be, therefore, why can the sitemap
not be extended with minor conditionals
similar to the ones in XSLT and make flow decisions in XML versus
Javascript.
I regard this flowmap decision as taramount to multiple inheritance. I
think its a decision that will later come to be
regretted. I also think I'll be seeing Cocoon applications that are
virtually implemented exclusively in Javascript instead
of using the sitemap at all.
>
>
>I hear you, but since we all agree that business logic shouldn't be in
>the flowscript, I don't understand the need to discuss whether or not
>it's good to have business logic defined in a scripting language.
>
>This is an entirely separate concern.
>
>
Again, we're discussing something taramount to allowing multiple
inheritance in Java. The issue is not whether YOU
Stefano would code your business logic in the scripting language, its
whether lots of folks would. And hence creating more
rediculous and unmaintainable software. Its possible to create bad
software in any tool, but some tools enable you to create worse
software. Its why Java succeeded despite being far poorer performing
over C++. C++ gave you more rope to hang yourself. Its an underlying
reason you write Cocoon in Java and not PERL. PERL allows almost all of
the features of Java, but it not only allows but encourages bad form.
Cocoon has areas that are coded in bad form and without comment, yet
I'm able to read them moreso than if they were written by the same
person in PERL for instance. The point being is that this is one of
those features that enocourages and allows bad form and will probably
grow into a beast.
>
>
>It's hard to define what a business logic is, but it's easy to know if
>this has anything to do with describing the transition between pages
>(flow).
>
>
But a scripting language will allow you to do either.
>
>
>>When you made the sitemap you also talked about what it *isn't*, not
>>only what it *is*.
>>Spitscript is what should stay out of the flowmap.
>>
>>
>
>No, no, no. With this you are assuming that it's equivalent to use a
>scripting language to describe business logic. This is yet to be
>discussed, but this is an entirely different concern from this
>discussion, thus my call to stop it until we have finished focusing on
>the flowscript.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: MVC demistified [was Re: [RT] SpitScript - B-Logic that
doesn't suck ]
Posted by Ovidiu Predescu <ov...@apache.org>.
On 6/24/02 8:23 AM, "Stefano Mazzocchi" <st...@apache.org> wrote:
> Nicola Ken Barozzi wrote:
>
>> Let's remember that flowscript is a potential liability in a sense that
>> it can be really abused in doing what you and I know it shouldn't do.
>
> Agreed. In fact, as others already pointed out, it might become a
> gateway to abuse and concern overlap. But I think this could be said of
> actions.
>
>> BTW, just a RT... this means that we would have MVFC: model, view, flow,
>> controller... :-?
>
> Finally, you are scratching the surface and looking into it: there is no
> MVC on the web. MVC assumed a stateful environment. The reason why
> people are so excited about MVC is that is the most ovbious instance of
> the SoC metapattern.
>
> (yes, it's already hard enough to abstract to patterns: abstracting to
> patterns of patterns is *much* harder, even for trained programmers).
>
> So, MVC is just one of the possible ways you can separate concerns and
> (I keep on saying this), it's *NOT* the best way to implement web
> applications, no matter how hard you try.
>
> The reason: http intrinsic statelessness.
I think Web applications are in fact stateful. I don't think the inherent
statelessness of the HTTP protocol changes this fact.
Comparing with a GUI application, you'll find lots of similarities, where
mouse clicks and keyboard clicks are translated into events which are sent
to the application. GUI applications have a run loop, the equivalent of the
HTTP server, which just listens for new events and dispatches them to the
appropriate receivers.
The fact that HTTP is not stateful is by now worked around with cookies or
other techniques which hide this aspect, and make it irrelevant. The end
result is that Web apps are comparable with GUI apps in terms of model.
> So, let's dissect MVC:
>
> 1) view is the concern that everybody identifies easily. It doesn't
> matter what technology you use for this, but template systems (think
> SSI) were invented the day the dynamic web was born.
>
> 2) model is harder. For GUI widgets it's easy: it's the OO abstraction
> of the concept implemented by the MVC pattern (say: a button, a text
> area, etc..) What is the model of your "webmail"? In GUIs, the MVC
> granularity is for the single widget, what is the model granularity for
> web applications?
>
> So, first problem: what is the granularity of MVC? For GUIs is the
> widget (if you disagree, tell me: what is the "model" of photoshop?),
> for webapps what? pages?
>
> No, pages are too small and webapps too big. Then what?
>
> 3) controller is a nightmare: where is it? MVC creates a nice SoC
> because:
>
> - view -> presentation concern
> - model -> data concern
> - controls -> logic concern
>
> but it assumes:
>
> - granularity is coherent
> - state transitions are stateful
>
> I hear you saying: it's up to the implementation to add state to the web
> application transparently. It's easy to do.
>
> Sure, but you are still left with the problem of identifying which is
> the best granularity for those MVC realms. Pages are too small (can you
> have a different controller per page? doesn't make sense), webapps too
> big (can you have a single model for the whole webapp? nah), sessions
> too heavy (can you have a single view for each session? well...).
I think the right granularity is the unit of functionality of a Web page. In
the Jakarta world, the closest encounter to this is the portlet idea, which
embeds the whole functionality of a Web page component in a type of
component, that has View and Controller capabilities, and invokes the Model
from its action methods.
We probably need to think along the same lines of this portlet idea. But
instead of the portlet thingy, we should have many smaller components which
are smaller MVC instances composed of their own flow, subsitemap and
business logic, which is able to represent them. This is very close to the
Cocoon blocks idea, at least the way I see it.
> Result: those who say "let's use an MVC framework" are indeed saying
> "let's use a framework that allows us to separate concerns", the problem
> is that they are biased to perform a specific separation between
> concerns that cannot be applied on the web AS IS!
I don't think this last statement is correct. For example MVC has been
successfully applied to Web application frameworks by Apple WebObject's
since 1996. Check out their latest documentation:
http://developer.apple.com/techpubs/webobjects/DiscoveringWO/index.html
Or a rather outdated documentation for WO 2.0 I think, but more technical
and perhaps easier to grab the concepts from, which is available at:
http://www.crust.net/resources/w3/webobjects.html.d/WebObjectsDoc/
Apple, or NeXT at that time, used to sell this stuff for really big bucks
(I'm talking about $50k/license), and they had large customers like Fedex
and Disney Interactive. Of course, WebObjects was much more than that, they
had, and still have, a very nice, fast and productive DB <-> objects mapping
tool.
> Now you could ask me: what is the best SoC model for the web?
>
> How do I know!?!
>
> I would be *very* egocentric from my side to say: look, you should
> decouple your application like this and this and this. How do I know?
>
> The only think I think I can safely say is: identify your concerns and
> work to separate them.
>
> In some cases, you might even find that MVC is perfect for the job.
> Great, use it. But that's the difference between Cocoon and the rest of
> the world:
>
> 1) Cocoon is about applying SoC on the web
>
> 2) the others webapp frameworks are about applying MVC on the web
>
> Since MVC is a very specific implementation of the SoC metapattern, you
> should be using those MVC-based frameworks only when MVC is good for
> you: unfortunately, not many times since it forces you to follow
> patterns that weren't invented for the web.
>
> So, I think you now understand why
>
>> MVFC: model, view, flow, controller... :-?
>
> is a terrible idea: the concept of flow partially overlaps with the
> concept of controller. But 'flow' is more at the application level: you
> wouldn't be able to state the flow of a GUI widget, but you would be
> able to describe the flow of photoshop operations in terms of different
> widgets.
>
> See my point? MVC works well on small and defined components, but the
> web component (a page) is too small. We need to find something else, for
> example:
>
> - pipelines
> - business logic
> - transitions
>
> but I won't even start to discuss this since I know that each one of us
> will have a different opinion on the subject.
>
> Just one thing: let's stop citing MVC as a good practice for web
> development. It's not, let's fact it once for all and move forward.
As I said above, I do think MVC makes a lot of sense for the Web world. I
think Cocoon has the right ingredients to make it a really nice and powerful
MVC framework for building Web apps. We just need to see what is the right
mix and recipe for all these ingredients to make a good cake ;)
Best regards,
--
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: MVC demistified [was Re: [RT] SpitScript - B-Logic that doesn't
suck ]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:
>
>
>>Let's remember that flowscript is a potential liability in a sense that
>>it can be really abused in doing what you and I know it shouldn't do.
>
> Agreed. In fact, as others already pointed out, it might become a
> gateway to abuse and concern overlap. But I think this could be said of
> actions.
+1
>>BTW, just a RT... this means that we would have MVFC: model, view, flow,
>>controller... :-?
>
> Finally, you are scratching the surface and looking into it: there is no
> MVC on the web. MVC assumed a stateful environment. The reason why
> people are so excited about MVC is that is the most ovbious instance of
> the SoC metapattern.
>
> (yes, it's already hard enough to abstract to patterns: abstracting to
> patterns of patterns is *much* harder, even for trained programmers).
>
> So, MVC is just one of the possible ways you can separate concerns and
> (I keep on saying this), it's *NOT* the best way to implement web
> applications, no matter how hard you try.
>
> The reason: http intrinsic statelessness.
>
> So, let's dissect MVC:
>
> 1) view is the concern that everybody identifies easily. It doesn't
> matter what technology you use for this, but template systems (think
> SSI) were invented the day the dynamic web was born.
>
> 2) model is harder. For GUI widgets it's easy: it's the OO abstraction
> of the concept implemented by the MVC pattern (say: a button, a text
> area, etc..) What is the model of your "webmail"? In GUIs, the MVC
> granularity is for the single widget, what is the model granularity for
> web applications?
>
> So, first problem: what is the granularity of MVC? For GUIs is the
> widget (if you disagree, tell me: what is the "model" of photoshop?),
> for webapps what? pages?
>
> No, pages are too small and webapps too big. Then what?
>
> 3) controller is a nightmare: where is it? MVC creates a nice SoC
> because:
>
> - view -> presentation concern
> - model -> data concern
> - controls -> logic concern
>
> but it assumes:
>
> - granularity is coherent
> - state transitions are stateful
>
> I hear you saying: it's up to the implementation to add state to the web
> application transparently. It's easy to do.
>
> Sure, but you are still left with the problem of identifying which is
> the best granularity for those MVC realms. Pages are too small (can you
> have a different controller per page? doesn't make sense), webapps too
> big (can you have a single model for the whole webapp? nah), sessions
> too heavy (can you have a single view for each session? well...).
>
> Result: those who say "let's use an MVC framework" are indeed saying
> "let's use a framework that allows us to separate concerns", the problem
> is that they are biased to perform a specific separation between
> concerns that cannot be applied on the web AS IS!
>
> Now you could ask me: what is the best SoC model for the web?
>
> How do I know!?!
hahaha :-) S**t, I really hoped for an answer, but a good laugh is
enough for now ;-)
> I would be *very* egocentric from my side to say: look, you should
> decouple your application like this and this and this. How do I know?
Too bad you're not egocentric enough then ;-)
> The only think I think I can safely say is: identify your concerns and
> work to separate them.
>
> In some cases, you might even find that MVC is perfect for the job.
> Great, use it. But that's the difference between Cocoon and the rest of
> the world:
>
> 1) Cocoon is about applying SoC on the web
>
> 2) the others webapp frameworks are about applying MVC on the web
>
> Since MVC is a very specific implementation of the SoC metapattern, you
> should be using those MVC-based frameworks only when MVC is good for
> you: unfortunately, not many times since it forces you to follow
> patterns that weren't invented for the web.
>
> So, I think you now understand why
Yup. The point is that if we want to sell Cocoon, MVC is a cool buzzword...
>>MVFC: model, view, flow, controller... :-?
>
>
> is a terrible idea: the concept of flow partially overlaps with the
> concept of controller. But 'flow' is more at the application level: you
> wouldn't be able to state the flow of a GUI widget, but you would be
> able to describe the flow of photoshop operations in terms of different
> widgets.
>
> See my point? MVC works well on small and defined components, but the
> web component (a page) is too small. We need to find something else, for
> example:
>
> - pipelines
View
> - business logic
Model
> - transitions
Controller
> but I won't even start to discuss this since I know that each one of us
> will have a different opinion on the subject.
>
> Just one thing: let's stop citing MVC as a good practice for web
> development. It's not, let's fact it once for all and move forward.
It's a good buzzword, and easy to understand.
I still use it, since MVC is usually correct, even for webapps:
- view=what you see
- model=the data
- controller=behaviour
Even if it's not the case 100% of the time, pipelines are the view.
The model is somewhere in the javabeans-EJBs, and the controller is the
flowscript.
The sitemap is what ties all together.
So it's a 3+1 model, MVC2 (double level controller).
I know it's kinky, but I'm not joking when I say that *ever* *single*
developer I met aske me if Cocoon is MVC.
And that when showing flowscript, I hear: "Oh, finally Cocoon has a
controller!".
MVC is not the answer to all needs, but referencing it can make things
easier to "market" Cocoon and to make it more understood.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
MVC demistified [was Re: [RT] SpitScript - B-Logic that doesn't suck ]
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
> Let's remember that flowscript is a potential liability in a sense that
> it can be really abused in doing what you and I know it shouldn't do.
Agreed. In fact, as others already pointed out, it might become a
gateway to abuse and concern overlap. But I think this could be said of
actions.
> BTW, just a RT... this means that we would have MVFC: model, view, flow,
> controller... :-?
Finally, you are scratching the surface and looking into it: there is no
MVC on the web. MVC assumed a stateful environment. The reason why
people are so excited about MVC is that is the most ovbious instance of
the SoC metapattern.
(yes, it's already hard enough to abstract to patterns: abstracting to
patterns of patterns is *much* harder, even for trained programmers).
So, MVC is just one of the possible ways you can separate concerns and
(I keep on saying this), it's *NOT* the best way to implement web
applications, no matter how hard you try.
The reason: http intrinsic statelessness.
So, let's dissect MVC:
1) view is the concern that everybody identifies easily. It doesn't
matter what technology you use for this, but template systems (think
SSI) were invented the day the dynamic web was born.
2) model is harder. For GUI widgets it's easy: it's the OO abstraction
of the concept implemented by the MVC pattern (say: a button, a text
area, etc..) What is the model of your "webmail"? In GUIs, the MVC
granularity is for the single widget, what is the model granularity for
web applications?
So, first problem: what is the granularity of MVC? For GUIs is the
widget (if you disagree, tell me: what is the "model" of photoshop?),
for webapps what? pages?
No, pages are too small and webapps too big. Then what?
3) controller is a nightmare: where is it? MVC creates a nice SoC
because:
- view -> presentation concern
- model -> data concern
- controls -> logic concern
but it assumes:
- granularity is coherent
- state transitions are stateful
I hear you saying: it's up to the implementation to add state to the web
application transparently. It's easy to do.
Sure, but you are still left with the problem of identifying which is
the best granularity for those MVC realms. Pages are too small (can you
have a different controller per page? doesn't make sense), webapps too
big (can you have a single model for the whole webapp? nah), sessions
too heavy (can you have a single view for each session? well...).
Result: those who say "let's use an MVC framework" are indeed saying
"let's use a framework that allows us to separate concerns", the problem
is that they are biased to perform a specific separation between
concerns that cannot be applied on the web AS IS!
Now you could ask me: what is the best SoC model for the web?
How do I know!?!
I would be *very* egocentric from my side to say: look, you should
decouple your application like this and this and this. How do I know?
The only think I think I can safely say is: identify your concerns and
work to separate them.
In some cases, you might even find that MVC is perfect for the job.
Great, use it. But that's the difference between Cocoon and the rest of
the world:
1) Cocoon is about applying SoC on the web
2) the others webapp frameworks are about applying MVC on the web
Since MVC is a very specific implementation of the SoC metapattern, you
should be using those MVC-based frameworks only when MVC is good for
you: unfortunately, not many times since it forces you to follow
patterns that weren't invented for the web.
So, I think you now understand why
> MVFC: model, view, flow, controller... :-?
is a terrible idea: the concept of flow partially overlaps with the
concept of controller. But 'flow' is more at the application level: you
wouldn't be able to state the flow of a GUI widget, but you would be
able to describe the flow of photoshop operations in terms of different
widgets.
See my point? MVC works well on small and defined components, but the
web component (a page) is too small. We need to find something else, for
example:
- pipelines
- business logic
- transitions
but I won't even start to discuss this since I know that each one of us
will have a different opinion on the subject.
Just one thing: let's stop citing MVC as a good practice for web
development. It's not, let's fact it once for all and move forward.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:
>
>
>>>Let's avoid the usual "let's tackle all problems at once" and let's try
>>>to get something hammered down before starting using brain cycles in
>>>some other directions.
>>
>>This is actually part of the hammering down.
>>I was talking about definitions (ie what flowscript isn't), not
>>implementations...
>
>
> Ok. Here's my vision: a flowscript is the location where you place your
> flow logic. The flow logic is the collection of instructions that
> indicate how to make the transition from one page to another.
>
> Everything else shouldn't be there.
Ok.
>>>There are yet many doubts to cover from the flowscript stuff that start
>>>talking about something else makes less sense ATM, IMHO.
>>
>>This is one of them.
>>Flowmaps are so powerfull that all the stuff that was innapropriate to
>>be done in the sitemap (heavy webapps) will automatically slip over to
>>flowmaps.
>>And since it's procedural, it's a *big* concern of mine that flowscript
>>will become the problem-solver catchall.
>
>
> I hear you, but since we all agree that business logic shouldn't be in
> the flowscript, I don't understand the need to discuss whether or not
> it's good to have business logic defined in a scripting language.
>
> This is an entirely separate concern.
+1
>>>So, please, let's place this back on the stack.
>>
>>It's already on the stack underneath, this is part of the flowscript
>>definition.
>
>
> It's hard to define what a business logic is, but it's easy to know if
> this has anything to do with describing the transition between pages
> (flow).
+1
>>When you made the sitemap you also talked about what it *isn't*, not
>>only what it *is*.
>>Spitscript is what should stay out of the flowmap.
>
>
> No, no, no. With this you are assuming that it's equivalent to use a
> scripting language to describe business logic. This is yet to be
> discussed, but this is an entirely different concern from this
> discussion, thus my call to stop it until we have finished focusing on
> the flowscript.
Ok, I agree.
Let's remember that flowscript is a potential liability in a sense that
it can be really abused in doing what you and I know it shouldn't do.
BTW, just a RT... this means that we would have MVFC: model, view, flow,
controller... :-?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
> > Let's avoid the usual "let's tackle all problems at once" and let's try
> > to get something hammered down before starting using brain cycles in
> > some other directions.
>
> This is actually part of the hammering down.
> I was talking about definitions (ie what flowscript isn't), not
> implementations...
Ok. Here's my vision: a flowscript is the location where you place your
flow logic. The flow logic is the collection of instructions that
indicate how to make the transition from one page to another.
Everything else shouldn't be there.
> > There are yet many doubts to cover from the flowscript stuff that start
> > talking about something else makes less sense ATM, IMHO.
>
> This is one of them.
> Flowmaps are so powerfull that all the stuff that was innapropriate to
> be done in the sitemap (heavy webapps) will automatically slip over to
> flowmaps.
> And since it's procedural, it's a *big* concern of mine that flowscript
> will become the problem-solver catchall.
I hear you, but since we all agree that business logic shouldn't be in
the flowscript, I don't understand the need to discuss whether or not
it's good to have business logic defined in a scripting language.
This is an entirely separate concern.
> > So, please, let's place this back on the stack.
>
> It's already on the stack underneath, this is part of the flowscript
> definition.
It's hard to define what a business logic is, but it's easy to know if
this has anything to do with describing the transition between pages
(flow).
> When you made the sitemap you also talked about what it *isn't*, not
> only what it *is*.
> Spitscript is what should stay out of the flowmap.
No, no, no. With this you are assuming that it's equivalent to use a
scripting language to describe business logic. This is yet to be
discussed, but this is an entirely different concern from this
discussion, thus my call to stop it until we have finished focusing on
the flowscript.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:
>
>>Ok, let's start this really /proactive/ (I love this word, it just fills
>>one's mouth ;-) RT about a business logic definition system that has
>>these goals:
>>
>>1. has a quick write-test-correct cycle, ie not to be compiled
>>2. is easy to write and understand
>>3. is modular
>>4. will make flowscript a solution to a problem, not a problem itself
>>
>>Definition
>>------------
>>
>>What the are business components-rules-whatever?
>>
>>A - definition(s)
>>B - use cases
>>C - actors involved
>>
>>?
>
>
> Please, stop.
>
> Let's avoid the usual "let's tackle all problems at once" and let's try
> to get something hammered down before starting using brain cycles in
> some other directions.
This is actually part of the hammering down.
I was talking about definitions (ie what flowscript isn't), not
implementations...
> There are yet many doubts to cover from the flowscript stuff that start
> talking about something else makes less sense ATM, IMHO.
This is one of them.
Flowmaps are so powerfull that all the stuff that was innapropriate to
be done in the sitemap (heavy webapps) will automatically slip over to
flowmaps.
And since it's procedural, it's a *big* concern of mine that flowscript
will become the problem-solver catchall.
> So, please, let's place this back on the stack.
It's already on the stack underneath, this is part of the flowscript
definition.
When you made the sitemap you also talked about what it *isn't*, not
only what it *is*.
Spitscript is what should stay out of the flowmap.
Did you really think I would call our business model "spitscript"?
Ok, ok, I know the answer ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org