On 6/20/02 1:06 AM, "Nicola Ken Barozzi" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
