Piroumian Konstantin wrote:
>
> > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> > Piroumian Konstantin wrote:
> >
> > > Writing JavaScript even for client-side can be very tricky
> > sometimes, but
> > > when you'll start to perform component lookups, EJB calls,
> > etc. in JS then
> > > you'll have much fun trying to understand why your code
> > doesn't work ;)
> >
> > Sorry but I don't get why. We are not talking about client-side
> > javascript that doesn't work as expected because the object
> > model is so
> > different from one browser to the next.
>
> Are you sure that the OM will be the same from one Cocoon version to
> another, or from one Rhino implementation to another? I'm not.
Really? I consider this an insult to this community. Using strong typed
languages or XML syntaxes doesn't make the API/contracts any more solid.
Please, let's stick at reasonable arguments not FUD. The fact that DHTML
is not much portable is *not* a misfeature of Javascript but a problem
with the Object model (the same thing that will happen to C#, BTW).
Also, Java shares the same lack of portability on browsers and years ago
('95) when I told people I was going to use Java, everybody laughted out
loud because of the applet limitations.
I see this happening again.
> > Here, the FOM (flowscript object model) will be one and only
> > one. Also,
> > javascript enforces exception handling, and the FOM contains a direct
> > reference to the cocoon log stream.
>
> That's a good news, but using only logs to debug the flow logic that can be
> very complex (remember the missiles ;) )
FUD again. Did you ever had to use a debugger when you have careful
logging in place?
> would be a like using Notepad for Java programming.
What's wrong with that? I wrote all my software using a simple text
editor. I find it much harder to write XML since there is no XML editor
that is good enough for my needs.
> No problems witht the imagivation. I just wanted to show how I see the
> Presentation - Flow - B-Logic interconnection (and how we are implementing
> it). In my picture the "Screen Flow Logic" is just "screen flow logic" and
> nothing else (neither XML nor script).
>
> To return to the subject, I just don't want the picture to be this:
>
> ---------------------------
> | |
> | COCOON |
> | URI map & Presentation |
> | Screen Flow logic |
> | Business logic |
> | |
> ---------------------------
>
> And allow to keep things separate.
Hmmm, do you seriously think I would propose a technology that forces
you to that and to mix concerns rather than keeping them separate?
Look: there is no way for us to *force* people to do something. Nicola
says: give them avalon. The general usage of Avalon shows this is not so
easy.
If you can write your own pipeline logic inside a map:reader, I can't
stop you. If you want to write your entire business logic into a single
action, I can't stop you. If you want to write your site using a single
huge sitemap and not using wildcards, I can't stop you.
So, if you want to write your business logic in the flowscript, I can't
stop you.
But this doesn't mean that technology is not useful, nor easy to abuse.
> >
> > > For completeness of the example I have to say, that
> > business logic is
> > > implemented partially in EJBs (in pure Java) and partially
> > comes from
> > > external resources (a Workflow System, Rules engine, other
> > subsystems
> > > through Corba, etc.).
> >
> > Then my picture would fit your environment better since the flow logic
> > will call business logic components that will then know where
> > and how to
> > find the appropriate information (IoC here).
>
> I don't see why? Our flow engine calls business components using so called
> "operations" that are written in Java and are much like the Cocoon actions.
> The next step planned here is to implement direct calls to EJBs, like:
>
> <exec operation="ejb:myEJB.getCustomerAccount">
> <result var="customerAccount" />
> </exec>
>
> Maybe BSF will be used to implement this or something else, but the flow
> description itself won't require any programming .
Sure. I tried and I *HATED* the fact that in order to do something as
simple as
if (request.blah < 0)
call("error.html", request.blah);
else
call("result.html", request.blah);
I have to write a 'ComparingSelector' and then use it like this
<map:act type="request">
<map:select type="compare">
<map:when test="{blah} < 0">
<map:call uri="cocoon:error.html">
<map:parameter name="blah" value="{blah}"/>
</map:call>
<map:when>
<map:otherwise>
<map:call uri="cocoon:result.html">
<map:parameter name="blah" value="{blah}"/>
</map:call>
</map:otherwise>
</map:select>
</map:act>
Even without continuations, the flowscript *alone* would make actions
look a preistorical obsession for the XML syntax.
Or you really believe that the above "if (a < 0)" condition is such a
critical business logic that must be incorporated into another java
object?
> >
> > > I must admit that our XML-flow syntax is becoming more and
> > more complex
> >
> > Bingo!
>
> But I hope that "finite" in FSM is also indication that complexity is finite
> ;)
Sure, no problem about finity, but if you have to write/read/maintain 10
times as many lines of code where even the simplest conditional logic
must be contained into an extrernal component, infinity will look much
closer.
> > > but the good news is that you can use a visual tool to edit
> > your flow
> >
> > Hmmm, where did I hear that? Ah, that's the old 'if the language sucks
> > use a better tool' redmond tune. Believe, it doesn't work on open
> > source.
>
> Don't be so sceptic about good visual tools. They make learning time of the
> (maybe sucking) language much shorter. What do you think, if the sitemap had
> a good visual editor then won't it be much simpler to convince people to use
> Cocoon?
Sure, where is it? Are you planning to donate one to us?
I'm not skeptical about visual tools that exist (gosh, I love GUIs!).
I'm skeptical about 'visual tools' that are possible but don't exist,
nor are freely available for us to play with, enhance and control.
> (Disclaimer: I am not a fan of visual XML editing).
I am. I even have a prototype of a visual XML editor somewhere on my
disk, but I don't have time to follow on that so I go for the easy
stuff.
And today, between writing FSM tables using XML trees or writing
procedural flow using a scripting language, I choose the second, each
and every day of my life.
> >
> > > and tie it to business logic
> > > (which is simpler to implement for XML rather than for
> > script-based flow).
> >
> > I don't understand this. May you elaborate more?
>
> This was meant about the editor implementation. It's much easier to
> implement a visual editor for formalized flow language (e.g. Rational Rose -
> State/Activity diagrams) than for a scripting lanuage. Am I wrong?
Granted, but didn't you ever got that feeling of 'I would do it
differently' when you see the auto-generated code of your visual editor?
> >
> > > Here is a snipped from a sitemap where we are using actions...
> >
> > Oh, there is no doubt on the fact that the approaches are
> > similar. Just
> > that I don't think that writing flow logic in XML is a good thing.
>
> We got it ;)
>
> But seems that you agree that for simple cases you won't need scripting
> (from your answer to Andrew), so in this case using a simplified XML flow
> would be quite enough, aren't you?
Yes, but as soon as I see a trace of the infamous <if> or <for-each>
tags, you'll get an immeditate -1 from my side. And I mean it.
> And another big advantage (that you maybe
> concider a disadvantage) of XML flow is that the user can do only those
> things that are allowed by the limited syntax, while in JavaScript you can
> do such unintended things like dynamic pipeline generation
Grrr, you *cannot* do something without having access to the object
model that implements it, damn it! Is it so hard to understand? The
flowscript doesn't (and will never!) have access to the sitemap
component manager, so it cannot do what it's the sitemap's concern to
do.
Do I need to restate it again?
All pipelines are defined and executed by the sitemap. There is nothing
you can write in the flowscript to change this (or it's a bug and we'll
fix it!).
What you can do in the flowscript is to decide what pipeline to call and
how (passing what parameters), but by design you won't be able to do
more than this.
> or business logic implementation.
You guys are concerned about abusing the flowscript ability to describe
procedural logic.
I'm much more concerned about abusing the XML syntax to do exactly that.
And if you say that all logic components will be separate, then my
argument becomes: I don't want to write tons of 1-liner actions and go
thru the mess of write them, compile them, deploy them, test them given
that their reusability tends to zero.
This said, I repeat: I'm not going to propose to deprecate actions so
what it was possible before it's still possible today.
Just don't throw FUD at the flowscript because you are conservative to
your past approaches. I say: let's provide both and see what happens.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
