How to write applications with flowscripts (WAS Re: [RT] Flowmaps)

[Ovidiu Predescu <ov...@apache.org>]

On 6/20/02 1:06 AM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:

> Ovidiu Predescu wrote:
> 
> ...
> 
>> You can also do everything in JavaScript, but beware that you're moving the
>> business logic in JavaScript, where it shouldn't be.
> 
> 
> Where should it be then (not provocative, just a question I cannot
> simply answer myself)?
> 
> I think that if we don't come up with a business-logic framework of some
> sort, we will see programmers do the most wild things.
> 
> IMNSHO, Cocoon should be PnP, and not *require* java programming, ie no
> compilation step.
> 
> <user-perspective>
>  Assuming that I want to make my business rules *without* java, what
> can I use?
>  Where do I put them?
>  How do I organize them?
>  Is there a repository for them?
>  How do I use them in the flow?
>  How do I make transactions?
> </user-perspective>

I think you raise a very good point!

I also believe in rapid prototyping and the use of scripting for building
applications. The problem with scripting in Web apps so far is that code is
often mingled with markup. Just look at how PHP, Perl or any CGI approach
work. In a sense even JSPs are bad, because they allow you to put code in
the markup.

There are two problems in my opinion in such an approach. First the business
logic is mixed with the markup, which makes the business logic very
difficult to reuse if you need to target a different markup, for browsers on
small devices for example. The second problem is that the flow of the pages
in these applications is scattered across multiple pages, which makes
maintenance a nightmare.

The flow control layer attempts to solve these two problems. Imagine for a
second that the only logicsheet available to you in XSP is jpath.xsl. Then
the only way to put dynamic markup in your pages is to create objects
outside the page, and pass them to the XSP in the flow layer, using
sendPage(). In this approach the only way to access a database is to make
use of something like JDO or EJB, that generate Java objects, and pass those
objects to the XSP page, where you can access them using JXPath.  This
prevents a developer to hack code in the page itself.

This is how you separate the View (the XSP/JSP/Velocity/etc. collection of
pages) from the Model (the database code, EJBs, the business logic in
general) through the use of Controller (the flow control layer).

To implement the Model, you can code it in Java, or you can code it in
JavaScript, or any other language you like, as long as Cocoon has support
for it. I don't think we should impose any restrictions.

If the business logic is written in Java, you simply add the jar files
containing it in the WEB-INF/lib/ directory, and start calling it from the
JavaScript flow script, as I described in a message yesterday.

If you don't want to write your business logic in Java, either because you
don't know Java, or because you're starting a new application and want a
rapid prototyping tool, then you have two choices. You can write it in
JavaScript, or you can use a language supported by BSF. For the latter we
still need to integrate it with the flow control layer, but I don't expect
to have big problems.

If you want to implement your business logic in JavaScript, you can
implement the code in a .js file and include it as another file of your flow
script. Technically this works fine, but I think it has the potential to
create a mess later, because the business logic is mixed with the flow
control.

It may actually be better if we have a separate section in the sitemap for
such scripts that implement business logic. This would help in separating
what is business logic and what are flow scripts.

In addition, it could also help in runtime optimizations. For example, the
Rhino JavaScript engine has two modes of execution, an interpreted one and a
compiled one. In the compiled mode, the JavaScript scripts are compiled to
Java bytecodes, so they execute at the same speed as normal Java code. In
the interpreted mode, an internal set of bytecodes are used, whose execution
is evidently slower than the compiled mode. The modified Rhino version with
continuations support works only in interpreted mode (it's actually
impossible to have it work in the compiled mode, but this is a different
story).

So I think it makes sense to have a special section in the sitemap for
including scripts which act as business logic. With JavaScript scripts for
example, we can have these running in compiled mode, while flow scripts,
which are usually smaller, execute in interpreted mode. From a functional
point of view however, these scripts should be visible to the flow scripts.

<map:applications>
 <map:application name="shopping-cart">
  <map:script src="cart.js" language="JavaScript"/>
 </map:application>

 <map:application name="calculator">
  <map:script src="calc.py" language="Python"/>
 </map:application>
</map:application>

We need to figure out how flow scripts are associated with the business
logic scripts, and whether it makes sense to have the same flow script
associated with multiple business logic scripts.

I think this would also make fit nicely with Cocoon blocks, as it makes
things very modular.

Do you think having such support makes sense?

-- 
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: How to write applications with flowscripts (WAS Re: [RT] Flowmaps)

[Nicola Ken Barozzi <ni...@apache.org>]

Ovidiu Predescu wrote:
> On 6/20/02 1:06 AM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:

...

> It may actually be better if we have a separate section in the sitemap for
> such scripts that implement business logic. This would help in separating
> what is business logic and what are flow scripts.
> 
> In addition, it could also help in runtime optimizations. For example, the
> Rhino JavaScript engine has two modes of execution, an interpreted one and a
> compiled one. In the compiled mode, the JavaScript scripts are compiled to
> Java bytecodes, so they execute at the same speed as normal Java code. In
> the interpreted mode, an internal set of bytecodes are used, whose execution
> is evidently slower than the compiled mode. The modified Rhino version with
> continuations support works only in interpreted mode (it's actually
> impossible to have it work in the compiled mode, but this is a different
> story).
> 
> So I think it makes sense to have a special section in the sitemap for
> including scripts which act as business logic. With JavaScript scripts for
> example, we can have these running in compiled mode, while flow scripts,
> which are usually smaller, execute in interpreted mode. From a functional
> point of view however, these scripts should be visible to the flow scripts.
> 
> <map:applications>
>  <map:application name="shopping-cart">
>   <map:script src="cart.js" language="JavaScript"/>
>  </map:application>
> 
>  <map:application name="calculator">
>   <map:script src="calc.py" language="Python"/>
>  </map:application>
> </map:application>

:-)

> We need to figure out how flow scripts are associated with the business
> logic scripts, and whether it makes sense to have the same flow script
> associated with multiple business logic scripts.
> 
> I think this would also make fit nicely with Cocoon blocks, as it makes
> things very modular.
> 
> Do you think having such support makes sense?

I think id does :-)

This would solve these problems at least:

- formalize the MVC pattern which is nice to get one's mouth full but is 
never fully done. MVC is conceptually simple, yet powerfull. This would 
finally stop any phrase like:" I prefer to use Struts because it's MVC". 
*This* is real MVC.

- make use of different optimizations in each MVC domain, ie
*Separation of Concerns*. Till now, the sitemap has been use as a big 
state-type controller, and hacked in many ways. This has mixed concerns 
that should remain separate, ie business logic and flow.

- reduce scope of components making reuse more possible. It's a fact 
that when a component wants to be everything to everyone it sometimes 
gets difficult to reuse it in a non-thought-before approach.
This way we have a more "domained" reuse (M||V||C) that makes sense.

Now the hard parts are making this business part rolling and how to 
control it from the flow...

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