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:[EMAIL PROTECTED]] > Sent: Tuesday, June 25, 2002 7:06 PM > To: [EMAIL PROTECTED] > Subject: Re: [RT] SpitScript - B-Logic that doesn't suck ( > Re: [RT] Flowmaps) > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
