Virtuas today announced a major new release of its TurboM2(TM) framework. In addition, TurboM2 will be contributed to the open-source development community. The release provides many new features and enhancements, resulting in a powerful and flexible foundation for rapid development of web applications.
- Posted by: Greg Pearman
- Posted on: May 06 2003 10:40 EDT
"Since the release of my book a year ago, many readers have been frustrated by the limitations of the Struts framework," said noted technical author and TurboM2 chief architect James Goodwill, "the features and more importantly the support that TurboM2 provides should please many J2EE developers."
TurboM2, previously named the Web Application Model or WAM, was originally designed and released in 1999. It has undergone minor changes since then, but none as dramatic as with the recent release.
Check out TurboM2 at: www.turbom2.org
Some of the features of TurboM2 include:
-- Use of the JSTL and extensions of the JSTL in order to provide
equivalent tag support as the Struts HTML taglib
-- Declarative configuration and error handling
-- Automated conversion of request data into Java data objects
-- Interoperability with the J2EE servlet security model
-- Configurable delegation of requests and responses to
developer-provided application controllers
-- Controller chaining, including configurable decorators, to allow
composing of complex application behaviors from reusable elements
-- Java IDE plug-in for Netbeans and Eclipse users
-- Junit test case frameworks with HTTP mock objects
-- Configurable binding to common utilities, for example, logging
"Developing web applications and services will never be easy per se because organizations' business issues are always non-trivial," stated TurboM2 senior architect Michael Grier, "However, the design of TurboM2 will aim to add significant value to software development through simple declarative mechanisms to minimize the amount of framework-aware code that needs to be generated.
- hm... by Yann Cebron on May 06 2003 14:09 EDT
- Questionable benefits of Model 2 by Rogerio Liesenfeld on May 06 2003 15:40 EDT
Struts offers no Support or Training ?! I guess there are hundreds of companies or freelancers being experts in Struts..
It goes on to say:
Struts does not offer IDE-support.. when has this been written ? There's at least 5 or 6 tools I know of... including visual "designers" for Struts applications.. and including various OS-tools, too.
Not anything against their work or products, but they should not state something that is simply not correct (anymore).
You're right, of course. Many individuals and companies provide training on Struts. Our sister company (www.virtuas.com) provides Struts education. What we're talking about here is the core developers ensuring the coursework meets the current and future design goals of TM2.
James Goodwill, the Chief Architect of TM2, has written a book on Struts, titled 'Mastering Jakarta Struts'. One of the biggest problems he had when writing it was that the future path of Struts was not well defined. The TM2 training, on the other hand, will be built hand in hand with the core developers, and also with an eye towards functionality that will be included in future releases. Struts doesn't provide this.
You're also correct on your IDE statement, and my response is similar to the point you made about training. The IDE's you speak of are written by third party vendors, not the original Struts team. The IDE that you can download on turbom2.org is developed by the same team as developed TM2.
You're points are valid, however, and I'll look into updating the doco to make it more obvious what we're talking about.
thanks for your reply:
The TM2 training, on the other hand, will be built hand in hand with the core developers, and also with an eye towards functionality that will be included in future releases. Struts doesn't provide this.
Well, I don't share your point of view here obviously. There are continuos and ongoing discussions about possible future plans on the struts-dev list (including people making their money with Struts), and this process has been proven successful for all projects at Jakarta as well as for other OS software. If there's something you need, you just add it to the framework or look for it elsewhere (there's quite some extensions available).
As for training, there's now (according to the website) 7 books about Struts (some even written by the developers themselves, just as with TurboM2) which should cover everything you need to learn it, not forgetting a couple of good introductions or other articles available on the net as well as the very responsive struts-user list. I don't see this wide support for TM2 (yet).
The IDE's you speak of are written by third party vendors, not the original Struts team.
I've got no problem with that, why should it matter ? The ones I've tried are upclose to the current feature set and I don't fear a possible lacking support for them in the future (just think about the large user base Struts has). Additionally, there's a bigger choice of tools (Turbo2M just has released yet 1 tool for Netbeans) and alot of them are free.
Now let me count again.. if we'd cut these points off the list, there's only 5 differing points of 20 left ;-)
I'd be interested to see a couple of links to sites built with TurboM2 as well as some thoughts from developers using it.
As for <cite>..in hopes of creating the de facto standard for J2EE web application/services frameworks..</cite>: IMHO other players have taken that field already, and there are already way too much combattants..
PS: I've digged up another point: the article claims that Struts does not offer Client Validation Support. If you're talking about client side input validation (my guess), this is not correct.
In your document "Model2Architecture.pdf", you claim that good web application design requires implementing typical CRUD functionality as a multi-page UI, with one page for "Add", another for "Update", and another for "Delete". I am not convinced. Can you point to any independent studies, examples, or just make more concrete arguments?
And how exactly do traditional HTML links "invite poor segregation between application and presentation logic"?
In the "Benefits" section of this same document, you defend the "decoupling of pages" and that a more "mature security model" can be achieved with Model 2. Concerning the first, why is it so important given that most navigation between pages is static and known at design time. As for the second benefit, how would it compare to the current role-based security model, as described in the Serlvet spec?
No, I don't have any independent studies, just worked on these things before. Your point is somewhat justified by the tag usage TM2 provides to jsp's. It reduces the amount of scriptlet coding and validation coding that a jsp programmer will need to do.
Regardless of that point, however, I still maintain that separating add and update pages is the right thing to do. There are many instances of fields being editable on adds, but not on updates (and vice versa). Also, separating pages reduces the amount of business logic contained in a page (Am I inserting or updating - sounds like business logic to me :->).
Your next point:
Traditional HTML links provide poor segregation between application and presentation logic because links between pages in general represent business logic. - What happens once an Add occurs? The answer is dependant upon what the client/design wants you to do. If you subscribe to the MVC framework, then business logic should not be encapsulated in the View, but as much as possible, be placed in the Model (or in this case, Controller).
Decoupling of pages is important for the reason I just gave above, but it's also important from a maintainability point of view. If you use an MVC framework as I've described it, you can completely change links between pages by modifing the config file, without having to touch the jsp's themselves. Yes, navigation is known at design time, but it's been my experience that it changes often.
I think the servlet security model is pretty much synonymous with what TM2 provides, just happening at the controller level and securitizing (is that a word?) the jsp's ensuring that they don't display if a user doesn't have the appropriate rights.
I still maintain that separating add and update pages is the right thing to do. There are many instances of fields being editable on adds, but not on updates (and vice versa).
Sure, but in most cases (in my experience), the forms for Add and Update are nearly identical. By having them in separate files, you duplicate the UI.
I certainly wouldn't implement all such CRUD operations in the same page for all types of records, but in most cases I believe that would be the best design, both in usability and in ease of development/maintenance.
> Also, separating pages reduces the amount of business logic contained in a page (Am I inserting or updating - sounds like business logic to me :->).
The UI (Web page) design needs to make it clear for the user when he/she is adding a new record, or editing an existing one. I usually achieve this by having a set of 3 buttons, "New", "Save", and "Remove" in the record editing page, and by having the "New" button be disabled once it's clicked. I consider this UI design, not business logic. The business logic in such cases says whether those records can be added/updated/deleted, by who, under what special conditions (if any), what are the validation rules for the fields, if there is any pre- or post-processing, and so on. You can go even further and separate UI design from user-system interaction (Use Cases): it's perfectly possible to have 3 Use Cases, one for Adding a record, another for Updating a record, and yet another for Deleting a record, and still leave open the choice of implementing the UI as a 3-page of 1-page design. In any case, both UIs would still implement the Use Cases and the associated business rules.
> Your next point:
> Traditional HTML links provide poor segregation between application and presentation logic because links between pages in general represent business logic. - What happens once an Add occurs? The answer is dependant upon what the client/design wants you to do. If you subscribe to the MVC framework, then business logic should not be encapsulated in the View, but as much as possible, be placed in the Model (or in this case, Controller).
Again, I don't consider the relations between pages or screens in the UI as being part of the business logic. In MVC, the business logic is inside the model, not the controller. The kind of logic that drives page/screen flow is almost always application (or presentation) logic. In only a few cases (workflows where the next step depends on what was done in the previous step) the business logic drives page flow; and I agree that such cases do require more than HTML links.
> Decoupling of pages is important for the reason I just gave above, but it's also important from a maintainability point of view. If you use an MVC framework as I've described it, you can completely change links between pages by modifing the config file, without having to touch the jsp's themselves. Yes, navigation is known at design time, but it's been my experience that it changes often.
I just cannot see a good real-world example of this. Sure, navigation does change, but why should it be more difficult to change the JSP pages themselves, than an XML configuration file which adds another level of indirection. In practice, there is only one or a few ways to get into any given page.