cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piroumian Konstantin <KPiroum...@protek.com>
Subject RE: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flow maps)
Date Wed, 26 Jun 2002 09:14:50 GMT
Ok, now I will shut my mouth until I have more time to try the flowscript in
something real, so I won't seem throwing FUD or so.

--
Konstantin Piroumian 

> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org] 
> Sent: Tuesday, June 25, 2002 7:06 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [RT] SpitScript - B-Logic that doesn't suck ( 
> Re: [RT] Flowmaps)
> 
> 
> Piroumian Konstantin wrote:
> > 
> > > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> > > 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} &lt; 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.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
> 
> 
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message