Discussions

News: Simplifying Web Development: Jython, Spring and Velocity

  1. There has been a lot of discussion around the points: "Web development is unnecessarily verbose with Java throughout", and "Scripting languages are more applicable for some of this development". Thomas Risberg shows us his experiment with Jython, Spring, and Velocity.

    Excerpt
    Simplify Web development with Jython, Spring and Velocity Anthony Eden has recently been blogging about simplifying web application development. He is suggesting using a scripting language for your controller in The Way You Develop Web Applications May Be Wrong. I think he has some good points and it just happens that I have been experimenting with some similar ideas.

    I was trying to use Jython as the scripting language for the controller, but I was not happy about giving up on using Spring for configuring my web application. So I figured out how to load a WebApplicationContext using a Jython servlet. Then I added Velocity to handle the view part. This combination makes for pretty easy coding for the controller and this would be extremely helpful for applications that are not terribly complex. The nice thing with using Spring for the data access layer is that there is no need to manage any database connections in your scripts. Makes the code much more compact and readable.
    Read Simplify Web development with Jython, Spring and Velocity

    Threaded Messages (30)

  2. http://nanocontainer.codehaus.org
  3. Anthony Eden:
    "The Way You Develop Web Applications May Be Wrong.
    The current means of developing web applications utilizing complex object models and ORM is wrong".


    Carlos E. Perez
    "An extremely accurate observation"

    James Turner:
    "Java developers seem to be in love with unneeded and confusing layers of complexity
    ..being destroyed by Rampaging Computer Science"

    http://www.linuxworld.com/story/44251.htm

    What can I say? What have I been saying for a while?

    Spring, Velocity and scripting. What more can you possible need?

    And now, my favorite!
    "I told you so."

    Regards
    Rolf Tollerud
  4. Why just the controller? Why not also the view part? Velocity-like templating frameworks actually invent a small non-standard scripting language and embed in the markup. IMHO Jython (or other good scripting languages) + XMLC can provide better code/markup separation than JSP.

    MVC (coming from Smalltalk) is the first step towards maintainable code. Even with the help of scripting, it's still quite difficult to develop web application.

    I've been noticing the "modal web application" style lately from the (Scheme) Lisp and (Squeak) Smalltalk community - google "modal web server" or "Squeak Seaside" for detail. Instead of passively responding to requests, this style of web development builds an abstraction layer on top and turns the whole thing inside-out, writing web application is more like writing desktop applications. That would tremendously simplifying web development. Unfortunately, JVM does not support "continuation" natively, which is needed for this new style. It's a pity since Guy Steel the Lisp guy is involved with the java architecture. The closest we can get is probably SISC (http://sisc.sourceforge.net).

    Anyway, new ideas come from language other than Java.
  5. Unfortunately, JVM does not support "continuation" natively, which is needed for this new style.

    Have a look at the ATCT library from Velare. Very clever stuff. It provides a class (ACTCThread) which is a byte-code interpreter with support for suspension/continuation, but which allows you to defer to the JVM as well if you want. The ATCTThread class is serialisable.

    Regards
    Kit
  6. ... I've been noticing the "modal web application" style lately from the (Scheme) Lisp and (Squeak) Smalltalk community - google "modal web server" or "Squeak Seaside" for detail. Instead of passively responding to requests, this style of web development builds an abstraction layer on top and turns the whole thing inside-out, writing web application is more like writing desktop applications. That would tremendously simplifying web development. Unfortunately, JVM does not support "continuation" natively, which is needed for this new style. It's a pity since Guy Steel the Lisp guy is involved with the java architecture. The closest we can get is probably SISC (http://sisc.sourceforge.net)...
    The Cocoon guys have something similar in v2.1. Have a look at http://cocoon.apache.org/2.1/userdocs/flow/continuations.html.
  7. modal web server and Spring[ Go to top ]

    Dave Johnson has seperated Cocoons continuation based control flow engine from Cocoon and is getting it working standalone.

    Control Flow is free
    JSP Control Flow engine

    Ready to be be tacked onto Spring.

    Regards
    Rolf Tollerud
  8. modal web development[ Go to top ]

    Come to think of it href=goto is it not?
  9. Simplifying development is obviously a good thing, and it is especially good thing if you do not have to sacrifice the good sides of your old method.

    It is notable that the MVC approach was not trashed in this approach. It was dealing with scripted controllers/actions instead of Java. This might be a good solution if it indeed simplifies database interaction and other things for your typical web application.

    Apart from the scripting simplicity, the approach in whole is not really that much simpler than your typical Java web app. I think it is wrong to assume that everyone is fiddling with layers of model objects and complexities like EJBs. You just don't have to.
  10. I don't really understand all the hype about spripting. Some months ago I was looking at the code of open for business: while it's architecture is pretty clean, it was a mess of freemarker + JSP + jpublish mvc + pages bound to page classes with an xml file per page + beanshell actions + 2 different xml scripting "micro"-languages (average length of line: 120 chars) which "speed up development of business logic" + services configured in xml files + java for the core + ofbiz entity engine for persistence + XPDL-defined workflows + business rules with their own language.

    So, basically, the need to "speed up development" with the magical wand of scripting - which incredibly allows being able to reload actions at runtime - and "simplify the architecture" with jpublish resulted in a system that needs a university diploma only to understand what languages were used in order to build the whole thing.

    I ask: are the features for modern java development that one can find in IDEs such as idea and eclipse so useless to people programming with beanshell or an xml micro-language? My feeling is that the need to reload an action at runtime (without resorting to class reloading or hot deploy, of course) must be especially compelling when using one of those same scripting languages: writing code with them must be extraordinary error-prone, and I imagine one normally has to pass through a frequent code/reload code/retest-in-container cycle, since there is no compile-safety, no IDE assistance, and so on.

    People seem to believe that having to press "alt-enter" when IDEA suggests to create a new class given its name used in code is too much work, and they rather go happily to jedit or ultraedit, click "file - new" and open a new wonderful beanshell class, where they do not have to type the horrible "public class" (which is nevertheless automatically written by IDEA, of course...). Not to mention all the myriads of refactoring features they lose.

    I don't know what all of you scripting fans are smoking, but these days I spend a minority of my time writing java code, because IDEA it's simply perfect at helping me with that, and most of my time is spent with that shit that JSP + JSP EL (a scripting feature, of course, no checks, no code completion, no popup documentation) + Html + javascript (another shitty scripting language, you will guess) is, and when I'm in the "script-free" world I live happy, and as soon as I have to resort to online html documentation to know what properties I can call on a DOM object, I suddenly start thinking that I should have chosen a different job, such as doing the farmer or writing poems.

    Also: everyone seems excited about the fact you can quickly hack the code in scripts and magically see the result in the server "without having to restart" or reloading the context. Uh. Well: guess what? I develop my actions in IntelliJ IDEA and reload classes without neither restarting tomcat nor resetting the context, when recompiling: this takes 2 or 3 seconds, I realize this can be too much time for the rapid pace of the furious modern developers, but it gives me some nice features such as the fact that I have a real IDE to develop, my code is compiled to byte code, I can debug in a graphical debugger with pop frame capabilities, and so on.

    But our heroes do not stop here: why using an object model? Why using MVC? Most web applications do not need them at all: we can all live happily with scripting tons of code in JSPs, with SQL queries happily flourishing everywhere in our code "with complete control" (which is of course stolen to the good developer by the evil ORM frameworks), and they will demonstrate this truth to the world with an example where 5 lines of java code with an iteration becomes no more than FOUR lines of code in beanshell! Isn't it wonderful?
  11. Davide: "why using an object model? Why using MVC?"

    Nobody is suggesting to throw away MVC as Brian says, MVC is the first step towards maintainable code.

    But combining languages has a long tradition. When you coded in C you did occasional bits in Assembler, when you coded in VB you did critical parts in C and so on. To use Java and scripting is just a natural extension of the same principle.

    In my very first program with JSP I sorely missed Javascript which I had used together with Java objects in my ASP pages. It seemed overkill to do simple things in Java. Of course, at that time we didn't have MVC. But now we can have it all! And Python is much more powerful than Javascript ever was.

    Regards
    Rolf Tollerud
  12. Davide: "why using an object model? Why using MVC?"Nobody is suggesting to throw away MVC as Brian says, MVC is the first step towards maintainable code. But combining languages has a long tradition. When you coded in C you did occasional bits in Assembler, when you coded in VB you did critical parts in C and so on. To use Java and scripting is just a natural extension of the same principle.In my very first program with JSP I sorely missed Javascript which I had used together with Java objects in my ASP pages. It seemed overkill to do simple things in Java. Of course, at that time we didn't have MVC. But now we can have it all! And Python is much more powerful than Javascript ever was.RegardsRolf Tollerud
    Ok, but writing parts of the code in C for a VB program, or assembler parts for a C program had a reason that was identifiable in performance issues, not certainly issues related to productivity: this is the reason why one used VB instead of C, not the opposite. So this is not the case with java and scripting, unless you are telling me that one should build a complete system with beanshell and turn to java classes for performance.

    But what I'm asking here is: do you really think that writing beanshell code instead of java is more productive just because you have no compilation cycle and don't need to statically declare your variables? I'm not sure it would be even in a perfect world where beanshell had as good code development tools as java has, but it certainly is not when I can use IDEA's features for ordinary development: is it?

    My actual problem is really what I've written before: while working with web technologies I don't feel that java in the mvc or backend layer is the productivity bottleneck. I really code at a very rapid pace, with the tool I have (idea...), and it's pretty easy to solve all the tasks related to xml configurations too. I'm sure that JSP + JSP EL + jsp custom tags + struts + html + javascript + css is way heavier in that sense (note that I wasn't much happier when I had to deal with velocity: maybe I have to switch to Tapestry, but Struts was imposed by the consulting firm which gained the contract with the company I work for...).
  13. Davide: "why using an object model? Why using MVC?"Nobody is suggesting to throw away MVC as Brian says
    With regards to that, I misinterpreted a sentence by Russel Beattie in a comment to Eden's post, where he actually stated he does some sort of "simple MVC" by separing jsps without presentation and only including controller code from jsps which format views. I'm not sure how this can quicker than writing normal java actions in IDEA: even when I need to restart tomcat, my embedded version in IDEA takes no more than 8 seconds to start, and that is definitely a time that I can wait, since I do not introduce a new class every so often.
  14. Davide: "the reason that was identifiable in performance issues, not certainly issues related to productivity".

    But the same reason applies here, Java is faster, Python is more productive (or so I am told). But you may well be right; I am not too sure about it myself. But I think it is a good idea that deserves to be explored.

    Regards
    Rolf Tollerud
  15. I don't really understand all the hype about spripting....
    Very well said!!!

    People wake up! Do not be frogs in a boiling pot.
  16. Valeri: "I thought we all were convinced that even for smaller applications separating the code into layers, where each layer has clearly defined responsibility"

    This statement exactly amounts to: "If you use scripting you are idiots". You can use layers and MVC and what you want just as well with scripting as with any other method and anyhow if anyone succeeds to write unstructured code in Spring he deserve some kind of price anyhow! :)

    And as to what Scripting language that is best, why not let the market decide.
    No doubt the team behind Spring will make it possible to choose among a variety of languages, as they done with everything else, OR tools, data access technics, transaction managers etc etc.

    Spring team has taken down a whole industry of (IMO) clumsy "J2EE Application Servers" build from specifications from Sun's "aliens from other space" well-meaning impractical theorists.

    Regards
    Rolf Tollerud
  17. I think this idea could be simplified one step further by
    Spring Framework and Groovy

    Note: This is not a slam against Python or Jython so don't freak out.

    I just came back from the No Fluff, Just Stuff tour in Milwaukee and I was really impressed with Groovy and its capabilities.

    Why would this be simpler?
    1) There was an example of how Groovy could do templating and scripting in the same file? Does this break MVC? Depends but in many cases it would work great, and you could always break out the code if you wanted to.
    2) Groovy scripts can be compiled down to bytecode files for performance if needed. Or also if you wanted your POJOs to talk to your scripts.
    3) Since Groovy is built upon the java platform it is easier to learn for java coders than Python, Ruby, etc.
    4) Groovy is being endorsed and standardized by Sun (along with others) so it should have more vendor support in the future.

    I know other scripting languages are powerful but if you are a java coder and want to see the near future, look at Groovy.

    Downside? You should wait (a year?) untill it has been standardized before using Groovy in production, but could use it right away for experimentation or "one-off" projects.
  18. Wrong Direction[ Go to top ]

    This guy took a feeling that I've been having ever since I started doing Java webapps and took it in completely the wrong direction. I hate using java code in JSPs because I find myself doing stuff like this.

    <%
    List pageData = (List) request.getParameter("pageData");
    Iterator iter = pageData.iterator();
    while (iter.hasNext) {
    busObjectBean item = iter.next();
    %>
    <td><%=item.getName%></td>
    <td><%=item.getOtherData()%></td>
    <% } %>

    (hopefully that made it through the parser intact)
    Anyways I could do this same thing with half as much code in PHP. No big deal in this case but when you have complicated display pages it just ends up being a major PITA. So this guy's solution to that problem is to take the DB queries out of the middle or back tier where they belong and put them in the MVC controller? All you're doing there is creating a whole new set of problems. As for JSPs, I know we have struts tag libraries, JSTL, JavaServerFaces (which i don't even know what those are yet), Velocity templates, groovy (can you embed that in web pages?) and all this other stuff.... what we need is a standard solution to building dynamic web pages with Java. Using a 3 tier design with MVC pattern makes for a tight, adaptable and easy to change project. I know because at my job I'm stuck maintaining a bunch of PHP pages half the time which are a huge mess of copied-and-pasted code snippets all over the place and if we ever had to build something complicated with those it'd be a nightmare. However PHP has one thing going for it -- it was designed to make building dynamic web pages easy. Java is great for all of the project level organization and management. Why don't we have an easy way to build out the dynamic web pages?
  19. I agree with Davide's comments about using IntelliJ IDEA: having such a tool, capable of implementing any idea in a matter of seconds I spend less time writing java code, now time goes mostly into writing config files of all sorts, resource bundles, etc.

    As for the Anthony's blog, I am really surprised. I thought we all were convinced that even for smaller applications separating the code into layers, where each layer has clearly defined responsibility, simplifies maintaining and understanding the app's design. Probably he has seen how the layered design approach is being frequently abused... and now trying to find merits in forgotten JSP Model 1 architecture? Scripting language for controller? We had it with JSP 1.0 and have now with JSTL EL.

    We don’t have PHP or Python equivalent in Java, but I believe Java applications usually have slightly different focus, give more flexibility and options, and with things like iBATIS, Velocity and Spring there is no reason to complain. The problem is that Sun keeps ignoring these great projects, which I think deserve to be as standard as JVM because of great help they provide in developing any Java application (esp. if compared to their official counterparts: JDBC, JSP and JSF).
  20. I would agree that tools like IDEA has made Java coding a lot easier, but I still think there is room for a scripting language for some types of web development. There is a reason why Perl and PHP is so popular, and it is nice to have something just as easy to work with for Java. I prefer a templating language for the view since you can preview the html - just can't get used to putting html in print statements. On the other hand, I prefer to have a conventional programming language for the controller and model rather than scriptlets in a JSP page. Combining Velocity and Jython gave me this plus the option of hooking in Spring's IoC/AOP container. This solutions is not for everyone and also not for every project, but I do expect to come across a few projects where I will be happy to have this combo available. The way I see it, it's all about choice. Someone mentioned Groovy and as Groovy matures I'd be happy to try a solution based on it.
    The problem is that Sun keeps ignoring these great projects, which I think deserve to be as standard as JVM because of great help they provide in developing any Java application (esp. if compared to their official counterparts: JDBC, JSP and JSF).
    That is not entirely true. Ed Burns, who works for Sun and is the spec lead for JSF, is very interested in Spring and has offered to help us with Spring's JSF integration. This is a great opportunity for the opensource community and Sun to work together.

    Thomas
  21. As for the Anthony's blog, I am really surprised. I thought we all were convinced that even for smaller applications separating the code into layers, where each layer has clearly defined responsibility, simplifies maintaining and understanding the app's design. Probably he has seen how the layered design approach is being frequently abused... and now trying to find merits in forgotten JSP Model 1 architecture? Scripting language for controller? We had it with JSP 1.0 and have now with JSTL EL.
    Clearly you misunderstood my point. I absolutely do NOT want to go back to JSP model 1. On the contrary I haven't used JSP for quite some time and I don't plan on going back. I believe a very strong separation of roles and if you look at JPublish you will see that. What I have a problem with is the complexity developers introduce when they adopt all of the various patterns which are recommended by Sun, IBM and so on. If you need 7 classes just to represent a simple process of loading data from a database then that is a problem. Complexity is the enemy of maintainability and I believe that far too many developers fall into the trap of developing systems of unecessary complexity. Using a scripting language for controllers make sense to me because controllers can be best represented in a procedural fashion.

    Sincerely,
    Anthony Eden
  22. Clearly you misunderstood my point. I absolutely do NOT want to go back to JSP model 1. On the contrary I haven't used JSP for quite some time and I don't plan on going back. I believe a very strong separation of roles and if you look at JPublish you will see that. What I have a problem with is the complexity developers introduce when they adopt all of the various patterns which are recommended by Sun, IBM and so on. If you need 7 classes just to represent a simple process of loading data from a database then that is a problem. Complexity is the enemy of maintainability and I believe that far too many developers fall into the trap of developing systems of unecessary complexity. Using a scripting language for controllers make sense to me because controllers can be best represented in a procedural fashion.Sincerely,Anthony Eden
    Although JPublish is based on a very clean model, I find extremely unpractical that one needs to define an xml file to bind every page to the "code-behind" class (at least that is what seemed to me when looking at ofbiz implementation): in my opinion this is the same kind of finicality-mania that brought sun to create the monsters it created. Turbine, which seems to me very similar to Jpublish, does not impose that, unless I'm mistaken.

    My feeling is that when I adopt the patterns suggested by a framework like Spring with Hibernate, then the complexity is greatly reduced, and the amount of code I have to write is reduced to a quantity that really would not benefit from being developed with a scripting language (which could of course introduce other kinds of problems related): if I add the loss of productivity that comes from not being able to code with IDEA, I really can't see the point of having scripted actions.
  23. What's with JPublish.org ? It seems to me that it's down. You used too much scripting on it and when it showed up on TSS it simply didn't handle the load ? :-)

    To get serious, I think scripting is well suited for prototyping and small projects with no special demands on performance, scalability, flexibility, extensibility. When it comes about complex business logic on an application susceptible to change/evolve in the future you'll suddenly be happy that you have a web tier that relies on a services layer which furthermore relies on a persistence(dao) layer.

    And since Spring has been mentioned, isn't Spring enforcing a clear separation between services, dao, raw jdbc and so on, only that it's more on the inside of the framefork rather than in your code ?

    Scripting belongs to it's niche. Complex functionality combined with another ballot of nonfunctional requirements will beat the scope of scripting. If you want to write more than a web email client or a blog or a forum, you might better use Java, of course relying on Spring, Hibernate or iBATIS, a web framework (not mentioning which one to prevent another flamewar), velocity/JSP whatever for view etc. How is this too complex ?
  24. What's with JPublish.org ? It seems to me that it's down. You used too much scripting on it and when it showed up on TSS it simply didn't handle the load ? :-)
    It figures that I would post something and the darn server would be down. Such is life.
    To get serious, I think scripting is well suited for prototyping and small projects with no special demands on performance, scalability, flexibility, extensibility. When it comes about complex business logic on an application susceptible to change/evolve in the future you'll suddenly be happy that you have a web tier that relies on a services layer which furthermore relies on a persistence(dao) layer. And since Spring has been mentioned, isn't Spring enforcing a clear separation between services, dao, raw jdbc and so on, only that it's more on the inside of the framefork rather than in your code
    It seems that quite a few developers (i.e. anyone using Python, Perl, PHP, Ruby, etc.) would disagree with you.
    Scripting belongs to it's niche. Complex functionality combined with another ballot of nonfunctional requirements will beat the scope of scripting. If you want to write more than a web email client or a blog or a forum, you might better use Java, of course relying on Spring, Hibernate or iBATIS, a web framework (not mentioning which one to prevent another flamewar), velocity/JSP whatever for view etc. How is this too complex ?
    It's complex in the details, not in the concept.

    -Anthony
  25. What I have a problem with is the complexity developers introduce when they adopt all of the various patterns which are recommended by Sun, IBM and so on. If you need 7 classes just to represent a simple process of loading data from a database then that is a problem.
    Patterns abuse? Completely agree. I believe, applicability of a given pattern has to be carefully considered for each use case individually. Useless patterns? Of course! Our community managed (with the help of Sun, IBM, Oracle, etc) in a very short time to come up with a number of useless patterns, which lead to unmaintainable applications, but hey they look pretty on resume :)

    I used PHP, and there are certain cases where I'm really missing it in a J2EE project. Probably combining Velocity and Jython is a step in the right direction...

    Regards,
    Valeri
  26. I agree with Davide's comments about using IntelliJ IDEA: having such a tool, capable of implementing any idea in a matter of seconds I spend less time writing java code, now time goes mostly into writing config files of all sorts, resource bundles, etc.
    For what concerns property bundles, I suggest you to check out the excellent Property Editor plugin that Dmitry Kashin is writing for IDEA: it's already a very useful tool.
  27. Simplifying Web Development can be achieved with various methods and at various layers of Web application development, but not necessarily relating to whether you use scripting/template languages. Scripting languages are not necessarily simpler than conventional programming languages like Java, this depends on the context you use them and the programming style you prefer(I never feel JavaScript is simpler than Java, for example, but other people may feel different).

    Componentization and modularization are often more effective in simplifying Web application development IMHO. Here please let me take AppServer Faces--Writing Web applications without pages
  28. Sorry, formating error.
    -----
    Simplifying Web Development can be achieved with various methods and at various layers of Web application development, but not necessarily relating to whether you use scripting/template languages. Scripting languages are not necessarily simpler than conventional programming languages like Java, this depends on the context you use them and the programming style you prefer(I never feel JavaScript is simpler than Java, for example, but other people may feel different).
    Componentization and modularization are often more effective in simplifying Web application development IMHO. Here please let me take AppServer Faces--Writing Web applications without pages
  29. Sorry, still formating error.
    -----
    Simplifying Web Development can be achieved with various methods and at various layers of Web application development, but not necessarily relating to whether you use scripting/template languages. Scripting languages are not necessarily simpler than conventional programming languages like Java, this depends on the context you use them and the programming style you prefer(I never feel JavaScript is simpler than Java, for example, but other people may feel different).
    Componentization and modularization are often more effective in simplifying Web application development IMHO. Here please let me take AppServer Faces--Writing Web applications without pages
  30. I'm so sorry, my fault, missing quote mark. Can anybody delete my previous posts?
    -------------------------
    Simplifying Web Development can be achieved with various methods and at various layers of Web application development, but not necessarily relating to whether you use scripting/template languages. Scripting languages are not necessarily simpler than conventional programming languages like Java, this depends on the context you use them and the programming style you prefer(I never feel JavaScript is simpler than Java, for example, but other people may feel different).
    Componentization and modularization are often more effective in simplifying Web application development IMHO. Here please let me take AppServer Faces as example illustrating how it can simplify Web development without using scripting languages.

    Assuming we want something like BorderLayout view structure to render our content, with AppServer Faces we can define a Java class like:

    public class MyPage extends PageCom implements MyDataBiningInterface{
    private PTable layout; public MyPage(){
    layout=new PTable(3);//three columns
    layout.createRows(3);//three rows
    layout.getRow(0).getCell(0).makeColSpan(3);
    layout.getRow(2).getCell(0).makeColSpan(3);
    //apply CSS styles like: layout.getHtmlUI().applyStyle(PTableStyle style)
    //can also apply styles to any view component contained in the layout object.
    }
    public void setContent1(Object content1){
    //This is one method defined in MyDataBindingInterface
    //put the content1 into one cell of the layout, or wrap it with another PageCom
    //component before put it into the cell.
    ...
    }
    ...
    public void toXML(PageWriter pWriter){
    pWriter.put(layout);//output content
    }
    }

    Now the MyPage class is a reusable view component, it will render the contents in the view structure defined by the private layout component. The user of this MyPage component doesn't know what the layout is, and what styles are applied to it. The application developer just cares what the data binding methods are. Somebody may argue this POJO approach can not have the power as the scripting/template languages in rendering content, but that's not correct. This approach can express any view structure the HTML plus CSS permit. Actually the plain HTML just defines a few means to rendering content, and the table element is used in most cases to do layout. The rich styles can be got by applying CSS styles, and these style rules can be defined outside of the implementation of the PageCom component. AppServer Faces even allows you dynamically define view objects(so the view structure can be dynamically changed), this sometimes is not easy achieved with scripting language. Somebody may also argue a Java programmer is not the right person in designing a nice view component, but in reality many Java programmers today have to design JSP or other template pages. Because the number of common view components is not unlimited, once you have got them, you can reuse them in any project, this will simplify your development.
    Actually not only the pure view components can be developed and reused, but also the full functional modules with sophisticated interaction logic can be written as components with AppServer Faces, and you can reuse them in your Web application developments.

    So my point is to simplify Web application development, componentization is a very effective approach, actually this has been proved in traditional application development.

    Cheers
    Bo Yuan
    AppServer Faces--Writing Web applications without pages
  31. Few Points[ Go to top ]

    1. Jython is more than just about scripting, its compactness not only helps rapid development but makes the code easy to read and therefore debug and maintain. I guess Groovy, as it matures, is similar. If scripting means just javascript or beanshell then yes, the only benefit would be fast prototyping.

    2. In Jpublish you can have a single action definition file (webwork, struts like) but I, for one, actually prefer to have them in individual xml files.

    3. If each workflow can be represented by one action file or small set of action files, it seems logical that going to those actions and finding all the sql and methods in a few scripts would make it very easy to pinpoint and change.
    By using Jython those methods are usually not that long.