Home

News: New Open Source Web Framework Released: Verge

  1. New Open Source Web Framework Released: Verge (62 messages)

    The Verge Web Framework, formerly known as the Inversoft Portal Framework is now open source under the GNU Lesser General Public license. This latest release, version 2.1, provides various new features in addition to the new licensing and availability of the entire source code. These features include the ability to have multiple JavaBeans available on any form, long transaction support and a newly redesigned ActionFlow system that includes support for forms and model objects.

    The ability to use many JavaBeans (also known as formbeans) on a single form has been a feature that many frameworks were lacking. Although this feature was available in previous release of the Verge Web Framework, it was only partially supported. Now the entire MVC system of the Verge Web Framework allows for this flexibility.

    One of the most interesting new features is the long transaction support. This has been a concept that many companies have needed and have been forced to write by hand in the past. What this feature provides is the ability to display a wait page to the user while the application is processing. This is useful when an application is aware that a particular function can take long enough that without telling the user that the application is working, the user is likely to leave. To circumvent this, companies such as Orbitz, Expedia, and the like have used wait pages that inform the user that the application is indeed working. This functionality is now built into the Verge Web Framework and is completely configurable using the configuration files or at runtime.

    Like previous releases, Inversoft spends enormous efforts to test the framework for correctness. This release is no different. Our test cases still provide nearly 95% code coverage. We also had the opportunity to performance test our code and found that logging accounted for 80% of the overall processing time, meaning that Verge code was only 20% of the overall processing time.

    Links

    Read about the Verge Open Source Web Framework.

    Visit the download area.

    Threaded Messages (62)

  2. YAOSF[ Go to top ]

    yet another open source web framework..... (yawn.... yawn....)

    How many do we need.

    Niraj
  3. Not just another framework[ Go to top ]

    One thing that distinguishes the Verge framework from others is how robust and tested it is. So, yes it is another open source framework, but I hoping that it will be the best out there.

    Instead of having one MVC system, I built two and also built in the ability to create new systems quickly and easily. PLUS, those new systems use some of the same tag libraries as the current ones.

    I also built in lots of features that others don't have and that companies need. For example, the long transaction support is something that many companies use heavily (just check out Expedia, Orbitz, nearly every bank, etc.).

    The last part that really separates Verge from others is that I don't believe that code can be released unless it is tested. So, I took the time to write a test class for almost every class I wrote. Double the work, but I can make changes quickly and instantly see if I have broken other code. That is very powerful. Here's an example. I add the long transaction support, which by the way drastically changed the fundamental processing of requests, in just 6 hours. I added tests for it and ran my regression tests and fixed any problems it caused. The whole thing took mere hours while others may have taken weeks to accomplish the same goal.
  4. Not just another framework[ Go to top ]

    Posted By: Brian Pontarelli on January 12, 2004 @ 11:03 AM


    > One thing that distinguishes the Verge framework from others is how robust and tested it is. So,
    > yes it is another open source framework, but I hoping that it will be the best out there.

    Is it your claim that Struts, Webwork and Spring are not robust and well tested?
  5. Not just another framework[ Go to top ]

    Posted By: Brian Pontarelli on January 12, 2004 @ 11:03 AM

    >
    > > One thing that distinguishes the Verge framework from others is how robust and tested it is. So,
    > > yes it is another open source framework, but I hoping that it will be the best out there.
    >
    > Is it your claim that Struts, Webwork and Spring are not robust and well tested?

    Struts and WebWork are good products, don't get me wrong. I just feel that they have a ways to go still. In terms of robustness, Struts and WebWork lack many features. They also lock you into a strict methodology with no room for change. They also are not fully tested using unit tests. They have some, but Verge has a lot more. That's what I was saying.
  6. New JBoss Hire?[ Go to top ]

    Brian,

    Do you work for JBoss? Seems like you would fit in great! :)
  7. If Not JBoss Then Maybe CoCoBase[ Go to top ]

    If JBoss doesn't work out then maybe you could consider Thought the makers of CoCoBase. Your MVC framework would gain the benefits of being "faster that straight SQL".
  8. YAOSF[ Go to top ]

    ENOUGHT ALREADY!
  9. Ok,

    So there are many frameworks out there, but why blast someone for contributing free software? Maybe someone will come up with something interesting, something better than what's already out there ...

    S
  10. Ok,

    >
    > So there are many frameworks out there, but why blast someone for contributing free software? Maybe someone will come up with something interesting, something better than what's already out there ...
    >
    > S

    I agree. I use to wonder why produce yet-another-web-framework when there are already so many out there but with each release there is innovation (hopefully). Maybe Verge doesn't get off the ground, maybe it does, but hopefully the community grows and gains something in the process. Now lets all hug each other -;)

    To play devils advocate for a moment, what nerves me is when folks create a frameworks or tools that have nothing unquie in it, no innovation. But luckily that doesn't happen to often so my nerves are usually OK

  11. > I agree. I use to wonder why produce yet-another-web-framework when there are already so many out there but with each release there is innovation (hopefully). Maybe Verge doesn't get off the ground, maybe it does, but hopefully the community grows and gains something in the process. Now lets all hug each other -;)
    >
    > To play devils advocate for a moment, what nerves me is when folks create a frameworks or tools that have nothing unquie in it, no innovation. But luckily that doesn't happen to often so my nerves are usually OK

    But if long transaction support is it, then, to quote someone I know "That's a feature, not a product".
  12. But Did You Look At It?[ Go to top ]

    The problem is that the code in the downloadable library has nothing unique in it. The author could probably have started with another framework and expanded on it adding the features which he appearantly values so much. It is possible that the author began his work prior to the release or Struts and WebWork, although I highly doubt it. Even so if a better or more highly accepted solution comes along sometimes it is better to take your innovations and apply them where it will really make a difference.

    To continue on the framework itself: It is unclear where the improved features described in the press release are coming from. There are other libraries which come in JAR form with the framework, but it is unclear as to what they have in them. Which leads me to another point: if you are going to distribute something and it's open source then either a.) include all of the source or b.) include a reference to the source in the documentation. Which of course brings us to the question of documentation for which there is none, at least in the download.
  13. Now lets all hug each other -;)


    Blessed are the peacemakers, eh Kris? So now you have to update your web application framework comparison matrix yet again (what's the count now? 37, 38?). And you'll have to add it to the Wafer project or get Brian to do it.

    We're just starting to pick a WAFr and there are just too many to choose from. I can understand the frustration at having to consider another. Based on your glowing review of WebWork2, that is my first candidate. My co-worker wants to check out Verge because of its simplicity (not sure what that means at this point).

    I like the REV (resume enhancement value) of Struts, so Expresso has some appeal, too. Going to have to figure out a way to shoehorn EJBs into my designs, too, for REV reasons. ;-)

    ..Bob.
  14. YAOSF[ Go to top ]

    Not until the number of web frameworks equals the number of Java IDEs can we stop producing them.
  15. It's time to move beyond all of these MVC frameworks in my opinion, and just make it easier for developers to do the 80% that they need for web applications. From my perspective, there should be a default mechanism for defining a form in HTML or maybe a field list, and that's it. Just plug tha form into the system and it will handle all of the form storage, retrieval, provide query methods, etc. for your forms. So many web applications just need that. Then make it easy to extend and customize from their so you can store the form data elsewhere, add support for long transactions, etc. Until I see this, I'm not going to get excited about any web framework.
  16. Just plug tha form into the system and it will handle all of the form

    > storage, retrieval, provide query methods, etc. for your forms. So many web
    > applications just need that.

    I'm interested in seeing the same thing! The closest solution I've come up with so far is using an open source XForms implementation like Chiba @ http://chiba.sourceforge.net/.

    cheers,
    Markus
  17. I'd like to see one that can take a use case diagram (or something like it) that shows page flow, page type (simple, form) then by pressing a button a skeleton app is created that covers the 80% you speak of. All J2EE, of course.
  18. I strongly recommend you to check AndroMDA. It's amazing how it does exactly what you described. Even better I suppose.
  19. I'd like to see one that can take a use case diagram (or something like it) that shows page flow, page type (simple, form) then by pressing a button a skeleton app is created that covers the 80% you speak of. All J2EE, of course.



    BEA has created just that. Unfortunately it has a huge price tag on it. It is my vision to add a complete tool set to Verge that allows the same thing. However, in the short term I'd like to finish the Portal and Portlet server and the User management system first. If I can get some more developers, I could have people working on tools like that at the same time.
  20. It's time to move beyond all of these MVC frameworks in my opinion, and just make it easier for developers to do the 80% that they need for web applications. From my perspective, there should be a default mechanism for defining a form in HTML or maybe a field list, and that's it. Just plug tha form into the system and it will handle all of the form storage, retrieval, provide query methods, etc. for your forms. So many web applications just need that. Then make it easy to extend and customize from their so you can store the form data elsewhere, add support for long transactions, etc. Until I see this, I'm not going to get excited about any web framework.




    Actually, Verge does some of this. You can define a plain HTML form in a JSP and then setup model objects using the Web Model system. This is done using the standard jsp:usebean tag and then the Verge model tag library. This will not provide any mechanism for controllers, so it would be best to define the form and actions using the Form-Based MVC and then using the Web Model for the model objects. You can even specify validation on the JSP page with the Verge tag libraries.

    It is a hybrid solution, but almost what you are talking about. The next step to achieve what you want would be to implement a new controller system that would have all the form/action setup defined in the JSP. This new system could be configured into Verge easily and then you would finish it off by creating a new tag library for the form, submit and image tags (and optionally an anchor tag). This may be something I could add to Verge. It could be called Web MVC and be an extenstion to the Web Model MVC that already is written.
  21. Say hello to .NET[ Go to top ]

    Before you dismiss me as a .NET junkie, let me tell you that I am a Java fan, except I've been left disillusioned as to how you still have to assemble systems using nuts and bolts and have become thoroughly overwhelmed by the number of MVC frameworks. Not only that, the horrible XML config files are really stupid ini files in disguise.

    Contrast this with what .NET offers. I can build really complex UIs in a fraction of the time. Granted MS still has years to go before they get out of their single tier app mentality, but I see so many java apps using EJBs, entity beans, JMS etc. etc. just because they want to use cool technologies. So if you haven't experimented with .NET and C#, I'd advice you give it a shot without prejudice.
    I also predict that with Avalon and Indigio frameworks in Longhorn, MS will make a huge leap in making HTML obsolete for biz apps - something that Java should have done ages ago (ok, they tried with the applet but failed miserably )
  22. Say hello to .NET[ Go to top ]

    Contrast this with what .NET offers. ... So if you haven't experimented with .NET and C#, I'd advice you give it a shot without prejudice.<

     
    Heretic! :-)
  23. At least it has a funny name[ Go to top ]

    "Verge", in French, refers to either a corporal punishment instrument or a part of the body (I let you guess which one :-).
  24. At least it has a funny name[ Go to top ]

    "Verge", in French, refers to either a corporal punishment

    >instrument or a part of the body (I let you guess which one :-).

    Also, Inversoft is an Irish toilet paper brand.
  25. At least it has a funny name[ Go to top ]

    It would be nice if the comments came from someone who as actually used the product. If he had donated this code to struts would he have been a hero ........
  26. At least it has a funny name[ Go to top ]

    It would be nice if the comments came from someone who as actually used the product. If he had donated this code to struts would he have been a hero ........


    It's all open source; they can grab the source and integrate if they want to. I have contact Apache in the past and received a lot of push back. I don't really feel the need to continue that pain.

    I was thinking of making a new MVC system inside Verge (which I've already mentioned is easy) that supports the Struts APIs and configuration. That way you can use Struts and Verge side by side. For now, I'm taking a little break from code.
  27. Feature Matrix[ Go to top ]

    The feature matrix on ur site shows comparison with Struts and Webwork. Can u add Spring and Shocks too.
  28. Feature Matrix[ Go to top ]

    The feature matrix on ur site shows comparison with Struts and Webwork. Can u add Spring and Shocks too.


    Or at least make your feature matrix somewhat correct? Many of the features you list are covered by both WebWork 1.x and WebWork2 (I don't know Struts that well, others will have to stick up for it). And what the hell are these:

    * New model systems with the same tags

    * New controller systems

    * Full W3C compliance

    The much vaunted long transaction feature is simple enough... i think transactional form tokens to prevent double-posting is tougher (especially when it saves the first request processing state and will re-draw the same screen over and over without re-executing), which I implemented in WebWork2. I think I could probably implement long transaction support in a couple of hours, if I had good requirements.

    How about Interceptors? Integration with IoC containers, etc?

    There's a lot more to an MVC framework than people realize, so people shouldn't snicker when they see a new one, as it's a lot of work... But it's important to see what else is out there when you're trying to do a comparison.
  29. Matrix is blatantly wrong[ Go to top ]

    I agree with Jason, the feature matrix is ridiculous, and whether it's through ignorance or lack of research, is just wrong. For example, all versions of webwork support:

    Complex data structures (you can traverse pretty much anystructure)

    i18n error messages

    Full w3c compliance (what on earth do you mean by it though? Webwork tags are all xhtml)

    Full checkbox and radio tag support with no code

    Single tag library
  30. Feature Matrix[ Go to top ]

    * New model systems with the same tags


    This means that Verge allows developer to build new ways of handling model objects. Most frameworks currently only support a single system. For example Struts allows you to defined a single Form bean for each Form. This is the only model system that Struts will allow you to use if you want to leverage the automatic JavaBean population and tag library that they have written.

    Verge allows any number of systems to be written and figures out at runtime which one to call. A new system can be created and then registered with Verge (kinda plugin style). Currently Verge has three model systems: Form-Based Model, ActionFlow Model, and Web Model.

    > * New controller systems

    Same as above, just with the controller system. Right now Verge has two controller systems: Form-Based Controller and ActionFlow Controller.

    > * Full W3C compliance

    The Verge tag libraries support every attribute defined in the HTML 4.01 specification publish by the W3C.

    > How about Interceptors? Integration with IoC containers, etc?

    I have plans to add interceptors or something similar in the next release. Currently Verge has a simple IoC container called the Repository. It is very simplistic right now, but I am hoping that some people will help out in adding more features to it.
  31. Replies to everything posted[ Go to top ]

    First of all, those that gave suggestions, thank you. Now onto the good stuff.

    I created this framework because every other framework lacked things at the fundamental level. This is progress not just me wanking. Here's an example. In Struts, if you associate a property with a radio tag, you need to implement a method that resets the value of the JavaBean property associated with that radio tag. This sucks and is error prone. The framework should be able to handle this with no code. Verge does.

    Second, the feature matrix is not wrong. It is accurate and took a bit of research to compile. Struts and WebWork are NOT 100% compliant with the W3C HTML 4.01 specification. There are attributes of HTML tags that they can not handle. I won't go any further with the comparison, but everything there is accurate.

    One other thing about how Verge succeeds where others have failed is that at its core, any thing inside Verge can be changed, extended or replaced. For example, Struts has Action classes. These handle the actions and then return a JSP in some fashion. You can't have Struts call other Action classes in a chain. At the core of Struts this is handled and to change it or to make Struts handle both cases (single Actions and chained Actions) would be a bit of work. Verge bypasses that and has an architecture that allows you to create new methods of handling requests and model values (i.e. the form parameters) and integrate them seamlessly with everything else already there. This is obvious if you read the documentation. Look at the Form-Based MVC and the ActionFlow MVC. Two completely different ways of handling the MVC concept, running side-by-side and nearly transparent to the developer. Plus, if I wanted to create a state machine MVC, I could just drop it in Verge and it would run along side the Form-Based MVC and the ActionFlow MVC. That's the power of Verge.

    As for the features that Verge has that others don't, they include long transaction support and others as well. When you develop enterprise applications, not just small web apps to handle corporate address books, but things like internal process management, workflows, etc., you need more behind you then most of the frameworks out there can offer. Having worked for and with companies like BEA, Orbitz, US Freightways, Virgin, US Bank, and others, these companies run huge systems, and end up implementing a lot on their own because the frameworks just don't cut it. What I did was start providing a framework that is design around the needs of these companies. Take a look at the URL generator. That is a core feature and built into the entire Verge framework. Most companies either hack together something like this or end up implementing their own. AND most times it doesn't integrate easily with the MVC framework they are using.

    As for the IoC and interceptors, these are extremely simple concepts. They are on the list of things to add to Verge, I just don't like how others have done it and need to spend some time figuring out the best way to implement them. In addition, I agree that long transaction support is simple, but no one else has it. The double submit problem is much more difficult. But I think I have a good solution for that and it should be available in Verge 2.2. It's not really about the simplicity of a feature, its about Verge having done already.

    To put it simply, I think that Verge has many features that others don't. Verge is also lacking a few features that others have, but these are minor. I would also argue that Verge is has double the test coverage of other frameworks. I would lastly argue that put up against Struts, JSF, WebWorks, Spring, anything, Verge is just better, simpler, more robust and has the ability to grow quickly.
  32. Replies to everything posted[ Go to top ]

    {For example, Struts has Action classes. These handle the actions and then return a JSP in some fashion. You can't have Struts call other Action classes in a chain.}
    I hope u r kidding :)
  33. Replies to everything posted[ Go to top ]

    Would be nice if u cud have a small description of each of the comparison points in the matrix except for the ones which are really evident. Like when u speak of W3C compliance, u cud give examples so that people are really convinced.
  34. Pah[ Go to top ]

    What bullshit.

    For one thing, webwork has the action chaining mechanism you say struts doesn't support. Your claim of your piddly little framework being derived from the result of your work with all these big names is also awfully immature. I can assure you, there are many many industrial strength applications and deployments of webwork and struts. Even if your product were technically superior (which increasingly, it doesn't seem to be), trying to pimp your work experience as a way to legitimise it is childish and insulting at best.

    Finally the dismissive hand-waving about how verge has all the important features, and anything that other frameworks have that yours doesn't is minor stuff verges (haha!) on the insane. Since when is the author an impartial third party who can dispense such words of wisdom?

    I have little to no doubt that your framework will go the way of countless others. You'll get a few users, but that's about it. Your attitude and disparaging (uninformed) remarks about other products just means that the only people who might give your framework a try (gpl weenies) are now alienated too. Well done!
  35. My last post[ Go to top ]

    This forum is getting out of hand. I think that this topic is obviously very touchy subject to many people. I hope that I have not alienated anyone here, however it seems impossible to avoid that considering.

    I'd also like it to be known that I did not bash any other framework. I think that the other frameworks out there are good pieces of software and have their place. I simply built something that I felt was an improvement and attempted to explain what caused me to start working on it and what it has. Whether or not it is is up to the users.

    This is my last post. I don't think getting into flame wars does anyone any good. I would urge everyone to discuss the framework or other frameworks rather than continuing this overtly aggressive discussion.


    Brian Pontarelli
    Inversoft.com
  36. I'd also like it to be known that I did not bash any other framework. I think that the other frameworks out there are good pieces of software and have their place. I simply built something that I felt was an improvement and attempted to explain what caused me to start working on it and what it has. Whether or not it is is up to the users.


    I'm sorry, but the first thing anybody reads about your framework are phrases like "The Verge MVC is so robust that other frameworks such as Struts, WebWork, Spring, Velocity could be placed inside of the Verge MVC.", "Here is a brief comparison of the features provided by other frameworks and the Verge Web Framework. <stupid matrix is following>" and "Our test cases still provide nearly 95% code coverage.".

    If you state these things upfront and create announcements that sounds more like marketing than simple statements to say what has been released, then you should expect people to take you up on these statements and destroy whatever is wrong, badly researched or naïve.

    I briefly looked at your framework and I honestly fail to see much new or revolutionary. The emphasis on long transaction support seems futile and, for me, discredit it more than praise it (ie. is that all that differentiates it). Finally, I have trouble finding a simple example to start playing with. Since there are so many alternatives you have to expect people to be spoiled and not taking too much effort to dig in deep.
  37. If you state these things upfront and create announcements that sounds more like marketing than simple statements to say what has been released, then you should expect people to take you up on these statements and destroy whatever is wrong, badly researched or naïve.


    You have to expect some level of marketing though. Companies don't just pick up new frameworks and run with them unless someone non-technical can look and say, "yeah, that thing looks pretty good. Let's let the developers try it out."

    > I briefly looked at your framework and I honestly fail to see much new or revolutionary. The emphasis on long transaction support seems futile and, for me, discredit it more than praise it (ie. is that all that differentiates it). Finally, I have trouble finding a simple example to start playing with. Since there are so many alternatives you have to expect people to be spoiled and not taking too much effort to dig in deep.


    URL Generation, multiple form beans, support for domain models, three different MVC systems, complete integration with the Repository (simple IoC), radio and checkbox support, no inheritance, ability to add new MVC systems and possibly use some of the same tag libraries, the Web model which allows the usage of any model object in any J2EE scope (request, session, application) without configuration, thorough documentation, complete JavaDoc, JUnit testing framework for running inside and outside a container (even though I've heard word of the mock object anti-pattern, I still think running outside of a container can and should be done. It promotes more testing rather than less because of the pain of running tests inside a container.), jBeans API which is a JavaBean API.

    These are in the works: Portal and Portlet server, user management, some type of interceptors or similar functionality.

    The download contains one slightly cheesy example called MadLibExample. I need to build out some more examples, just haven't had time yet. That example is complete and along with the docs should have enough information to allow someone to get started.
  38. Give Mr Verge a break![ Go to top ]

    Come on guys, give the guy a break! How many of these fervent nattering critics have ever put a similar amount of effort into releasing a public piece of software? I for one, salute the authors of Verge, even though I may never use their product, for the courage to come forth with what *they* believe is an innovative product. If this is the way new products/tools are greeted in the Java/J2EE world, woe to innovation in our field! A bit or respect and perspective is due!
  39. Give Mr Verge a break![ Go to top ]

    Yes, give them a break.

    Forums like this are very difficult to communicate the benefits of a framework. All the frameworks do solve similar problems but in different ways. Explaining the differences is hard because in the end they all use the same base technologies/APIs meaning that the descriptions of how they work are made up of the same terminology.

    To see the real flexibility of an MVC architecture you need to look at the implementation itself to have an opinion. Only when you feel the restrictions of a specific framework do you know what it is/is not capable of.

    The real benefit of a framework is in the time you save implementing your application and the benefits of the architecture for future growth, and maintainability.

    All frameworks could learn from each other.

    Dan
  40. Give Mr Verge a break![ Go to top ]

    How many of these fervent nattering critics have ever put a similar amount of effort into releasing a public piece of software?


    Well, I think that statement is a bit inappropriate here: The main critics of Brian's *style* in this thread are all active committers on open source projects like WebWork1, WebWork2, and Spring. I believe I personally qualify for having put quite a bit of effort into a public piece of software.

    Juergen
  41. HTML 4.01 compliance[ Go to top ]

    WebWork is not W3C compliant because it doesn't support every possible element

    >> attribute? You know you don't have to use the UI tags, right? This is just
    >> stupid.

    > Yes. The W3C specification requires that certain attributes be supported by
    > implementors. Taking this into the framework level is just the next step.

    > If you
    > don't support all the attributes, you are not compliant.


    This is not true. The W3C HTML 4.01 specs make no reference to 'implementors', only to the document that an implementation might generate. If a generator creates markup which validates according to the DTD, then it is compliant.

    So you can't say that a markup generator such as an MVC framework is 'compliant' or 'not compliant' - only that it generates compliant or non-compliant markup.

    It is NOT necessary for an implementation be able to emit every tag and attribute in the specification in order for it to generate compliant markup - it is only necessary that (a) it emits all mandatory tags and attributes, and (b) it emits no invalid markup.

    It know for a fact that it is possible to use Struts and Spring to generate validating HTML 4.01, because I've done it many times. I haven't used WebWork enough to make the same claims, but I'd be astounded if it any different in that respect.

    So the most that you could say about this aspect of your framework is something like 'supports more HTML 4.01 attributes than some of it's competitors'. You can't claim to be any more or less compliant (since that is an attribute of the document, not the generator) and you certainly can't claim that other frameworks are 'not compliant'

    I note in passing that since spring (and webwork, from the sound of things) doesn't rely on using taglibs to generate form elements, you can create documents with whatever attributes you like - so you can't even claim to support more attributes than any mainstream framework


    Chris
  42. HTML 4.01 compliance[ Go to top ]

    WebWork is not W3C compliant because it doesn't support every possible element

    > >> attribute? You know you don't have to use the UI tags, right? This is just
    > >> stupid.
    >
    > > Yes. The W3C specification requires that certain attributes be supported by
    > > implementors. Taking this into the framework level is just the next step.
    >
    > > If you
    > > don't support all the attributes, you are not compliant.
    >

    >
    > This is not true. The W3C HTML 4.01 specs make no reference to 'implementors', only to the document that an implementation might generate. If a generator creates markup which validates according to the DTD, then it is compliant.

    > So you can't say that a markup generator such as an MVC framework is 'compliant' or 'not compliant' - only that it generates compliant or non-compliant markup.

    > It is NOT necessary for an implementation be able to emit every tag and attribute in the specification in order for it to generate compliant markup - it is only necessary that (a) it emits all mandatory tags and attributes, and (b) it emits no invalid markup.


    Before I begin, you are correct about the DTD. However, my statement above, i.e. "Yes. The W3C specification requires that certain attributes be supported by implementors. Taking this into the framework level is just the next step," is accurate with respect to the user agent implementor and I simply applied the user agent rules to the frameworks. My wording on my website is what I feel is accurate. It goes like this:

    "Full W3C compliance that allows the use of every supported HTML attribute in the HTML 4.01 specification"

    I agree that my original statement is not 100% accurate. However, here's why I used the wording I did.

    The specification talks about two types of implementors or agents. The first is the author, which is a person or program that generates HTML. The second is the user agent, which is a program that consumes HTML and produces UI. The second must support all the attributes to be compliant. The first only needs to verify against the DTD to be compliant.

    Taken literally, frameworks are authors. Not providing support for the 'dir' attribute for example, is not non-compliance because a DTD will still pass without this attribute existing. Adding the ability to add a new attirbute named 'FOO' would be non-compliance. My point was that authors should be pro-actively-compliant rather than passively-compliant. DTD compliance is passive compliance because of the nature of DTDs. To be a better and more complete solution, authors should try and support all attributes available. Although not required, this would mean more support and a better overall product (in my opinion). This would be pro-active compliance. By ensuring that not only the DTD was satisfied, but also providing the support for the entire DTD, the author is not only compliant as an author, but also as a user agent (minus the rendering).

    So, what is a better way to word this... "100% W3C DTD support and validation". No one will understand that. If someone can think of a better wording let me know. For now I'll leave what I have on the website as is.

     

    > It know for a fact that it is possible to use Struts and Spring to generate validating HTML 4.01, because I've done it many times. I haven't used WebWork enough to make the same claims, but I'd be astounded if it any different in that respect.

    Yes, this is true. Though I do feel that their attribute set is not pro-actively compliant.


    > So the most that you could say about this aspect of your framework is something like 'supports more HTML 4.01 attributes than some of it's competitors'. You can't claim to be any more or less compliant (since that is an attribute of the document, not the generator) and you certainly can't claim that other frameworks are 'not compliant'

    Yes, but this is not as strong and does point to the competitors, which I have been making all efforts to stop doing.


    > I note in passing that since spring (and webwork, from the sound of things) doesn't rely on using taglibs to generate form elements, you can create documents with whatever attributes you like - so you can't even claim to support more attributes than any mainstream framework

    True. I'm not sure that this is ideal, but is how they have choosen to go. I feel that JSPs generating markup is not ideal either, but a necessary evil given the enormous constraints placed on everyone by the W3C and HTML over HTTP.
  43. My last post[ Go to top ]

    It simply doesn't make a good start to tell people stuff like: "I would lastly argue that put up against Struts, JSF, WebWorks, Spring, anything, Verge is just better, simpler, more robust and has the ability to grow quickly." Particularly if you haven't even bothered checking out all frameworks you mention.

    Its not about a touchy topic, it's about your tone and your lack of at least a pinch of humility. I'll be the last to say that you shouldn't be allowed to promote a product that you're convinced of, but at least *admit* that you don't know the other products that you're talking about in detail. And don't claim to re-implement all the functionality of those products in the twinkling of an eye.

    Juergen
  44. Leave him alone guys[ Go to top ]

    That's probably best thing you can do for him...and his framework :)))
  45. My last post[ Go to top ]

    Brian:
    The forum is not getting out of hand. This usually happens when something new is introduced. The thing is u need to backup ur statements. There are atleast 40 MVC frameworks out there. When u come up with a new one and claim that it is the best, u better know how to back it up. U cannot just run away from the forum and expect people to try out ur framework. People dont have time to try out 40 frameworks. So u need to sound convincing enough to make us try out yours. So rather than just telling that urs is the best, u need to provide detailed answers to all those questions posed at you. Look at how Alex Rupp handled the shocks thread and how Rod Johnson handled the Spring thread. U have to stay on this thread till the very end and prove ur worth. And it is quite possible that Verge may be the best one till date. So please dont miss out on a chance to introduce it properly to a great serverside community.
  46. My last post[ Go to top ]

    Brian:

    > The forum is not getting out of hand. This usually happens when something new is introduced. The thing is u need to backup ur statements. There are atleast 40 MVC frameworks out there. When u come up with a new one and claim that it is the best, u better know how to back it up. U cannot just run away from the forum and expect people to try out ur framework. People dont have time to try out 40 frameworks. So u need to sound convincing enough to make us try out yours. So rather than just telling that urs is the best, u need to provide detailed answers to all those questions posed at you. Look at how Alex Rupp handled the shocks thread and how Rod Johnson handled the Spring thread. U have to stay on this thread till the very end and prove ur worth. And it is quite possible that Verge may be the best one till date. So please dont miss out on a chance to introduce it properly to a great serverside community.


    I think you are correct. Thanks for such a great reply. Also, I'd like to announce that Verge has received so many downloads that it has crashed my website. My bandwidth has been exceeded and it looks like I'll need to move the project to somewhere like SourceForge or Java.net. If anyone has strong opinions as to which one they prefer, please email me at brian at inversoft dot com. For now, please be patient while I remedy the situation.

    I'll spend some time today going through each of the replies. I have a new outlook this morning and I'm planning on focusing on the software and what it can do. Also, I've taken a few suggestions and I did remove the matrix from the website. I'd also love to hear more constructive criticisms and ideas for going forward with this project.

    Thanks,
    Brian Pontarelli
  47. Re: My last post[ Go to top ]

    I have a new outlook this morning and I'm planning on focusing on the software and what it can do.


    Glad to hear it Brian. I thought the "feedback" you got on this thread was over the top, and I was wondering how you would react to it.
  48. Pah[ Go to top ]

    I'd agree with Hani. That was the most mindboggling piece of rubbish I've seen on this forum for a long time (and that says a lot). To first publish lies like the feature matrix, then huff and puff about how it is correct when it is in fact not, and then whine about "flame wars" when said behaviour is pointed out, is remarkably silly.

    The additional huffing and puffing how other frameworks are "not doing it right" is pretty shallow as no details are given. Hand waving will only get you so far, Brian.

    'nuff said.
  49. Pah[ Go to top ]

    What bullshit.


    I think that this is one of the more harsh comments and I'll respond to this one only. But please in the future, curtailing the language and making clear points and constructive criticism would be appreciated.

    > For one thing, webwork has the action chaining mechanism you say struts doesn't support. Your claim of your piddly little framework being derived from the result of your work with all these big names is also awfully immature. I can assure you, there are many many industrial strength applications and deployments of webwork and struts. Even if your product were technically superior (which increasingly, it doesn't seem to be), trying to pimp your work experience as a way to legitimise it is childish and insulting at best.

    Yes, WebWorks does allow chaining. "[My] claim" that the framework is a derivitive of experience gained from large companies is true and I think it is valid. I have worked on many J2EE applications of all sizes. I have learned a lot about how this space operates and what it takes to make a successful application. That knowledge was what lead me to work on this framework. Technology is about innovation and improvement. Without those the world goes nowhere.

    > Finally the dismissive hand-waving about how verge has all the important features, and anything that other frameworks have that yours doesn't is minor stuff verges (haha!) on the insane. Since when is the author an impartial third party who can dispense such words of wisdom?

    The features that Verge has many other frameworks have. Some features other frameworks have Verge does not. Some Verge features are unavailable elsewhere. My point is that I saw things that I personally thought were fundamental flaws and others disagree (which is fine). For example, Struts forces inheritance for model objects. This means that you can not use an existing domain model without writing adapters which use this inheritance. I thought this was a problem from many companies who have hundreds if not thousands of objects in an existing domain model. They should not have to implement all these form objects that extend the Struts classes just to get the data off a form. Verge does not require inheritance. This means an existing domain model can be used in the view. Likewise, my claim of MDD is thereby validated because MDD focuses on domain modeling.

    > I have little to no doubt that your framework will go the way of countless others. You'll get a few users, but that's about it. Your attitude and disparaging (uninformed) remarks about other products just means that the only people who might give your framework a try (gpl weenies) are now alienated too. Well done!

    This I leave up to the community. I people feel that Verge is a good product, I hope that they will support me and use it. If not, they are always free to use other frameworks. I hope though that my website statistics continue as they have yesterday and today and that Verge continues to be downloaded and evaluated.
  50. Replies to everything posted[ Go to top ]

    As for the IoC and interceptors, these are extremely simple concepts. They are on the list of things to add to Verge, I just don't like how others have done it and need to spend some time figuring out the best way to implement them.


    (finding hardly any words to say in face of this mix of ignorance and arrogance)

    Have you ever cared to actually check what you're talking about in depth, in particular the fine-grained notions of IoC and interceptors? I guess you'll also add O/R mapping and transaction support in the twinkling of an eye.

    > Verge is also lacking a few features that others have, but these are minor. I would also argue that Verge is has double the test coverage of other frameworks. I would lastly argue that put up against Struts, JSF, WebWorks, Spring, anything, Verge is just better, simpler, more robust and has the ability to grow quickly.

    (finding even less words to say in face of this mix of even more ignorance and even more arrogance)

    Have you ever cared to check the actual test coverage of other frameworks? Do you have the faintest idea of what Spring is about? You could at least *try* to understand the gist of the projects that you're discrediting here so broadly.

    Juergen
    (Spring Framework developer)
  51. Replies to everything posted[ Go to top ]

    Have you ever cared to actually check what you're talking about in depth, in particular the fine-grained notions of IoC and interceptors? I guess you'll also add O/R mapping and transaction support in the twinkling of an eye.


    It is my plan to add O/R mapping or integrate with another project. Of course it won't be in the "twinkling of an eye", but will eventually be there.

    > Have you ever cared to check the actual test coverage of other frameworks? Do you have the faintest idea of what Spring is about? You could at least *try* to understand the gist of the projects that you're discrediting here so broadly.

    I never explicitly stated any benchmark test coverage for any other framework. I also never stated anything relating to specific frameworks (BTW there are frameworks out there that are not open source). Some of the available frameworks are poorly tested; that's all I was saying.
  52. Replies to everything posted[ Go to top ]

    I never explicitly stated any benchmark test coverage for any other framework. I also never stated anything relating to specific frameworks (BTW there are frameworks out there that are not open source). Some of the available frameworks are poorly tested; that's all I was saying.



    Okay, foot in mouth. I did say that Struts and WebWork weren't very well tested. This was me being an idiot under fire. These frameworks actually have test cases and are tested. I don't know what the coverage is, but they are tested. What I meant was that I have seen frameworks out there that are not tested or tested very poorly.
  53. Spring[ Go to top ]

    Brian,

    Thanks for responding to all the posts. However, statements like "I would lastly argue that put up against Struts, JSF, WebWorks, Spring, anything, Verge is just better, simpler, more robust and has the ability to grow quickly" are both arrogant and naive. You have obviously never checked out Spring and don't know anything about it, so why do you feel inclined to make such broadly discrediting statements?

    BTW, Spring does have very good test coverage, particularly for a framework of its breadth with so many third-party integrations. But at least you've already apologized for that "Verge has double the test coverage of other frameworks" statement.

    To give you a brief introduction to Spring: It is a lightweight Java/J2EE application framework with a sophisticated IoC container and a state-of-the-art AOP framework at heart, plus a lot of out-of-the-box middle tier support like declarative transactions, Hibernate/JDO/iBATIS integration, various remoting strategies, etc. As far as possible, all of these parts can be reused in any environment, ranging from applets to J2EE containers.

    Spring just happens to also offer a web MVC framework on top of this, using the same configuration style. We believe it's a good and non-intrusive way to do web MVC, with particular nice access to Spring-managed middle tier components - but it is by no means required or central to Spring.

    We have straightforward integration strategies for all major web frameworks, allowing any web tier to access a Spring-managed middle tier. People are actively using Struts, WebWork1, WebWork2, and Tapestry with a Spring-managed middle tier, and of course Spring's own web MVC framework. There's also interest from the Barracuda community, and an obvious strategy for JSF.

    So constructively speaking, what you might want to consider is adopting Spring as middle tier foundation with a Verge web layer on top, instead of reinventing all the middle tier support. I believe it's absolutely preferable to integrate with an existing middle tier container instead of building your own IoC/AOP container plus middle tier services. That's the way that all other web frameworks (with the notable exception of Expresso) have adopted.

    Juergen
  54. Spring[ Go to top ]

    Brian,

    >
    > Thanks for responding to all the posts. However, statements like "I would lastly argue that put up against Struts, JSF, WebWorks, Spring, anything, Verge is just better, simpler, more robust and has the ability to grow quickly" are both arrogant and naive. You have obviously never checked out Spring and don't know anything about it, so why do you feel inclined to make such broadly discrediting statements?

    First of all, that statement was a bit off the handle. I was taking a bit excessive beating, publicly no less, and I did respond a few times in haste. However, I do feel that since Verge is currently only an MVC (although will be growing soon), comparison of MVC features is warranted. I would never compare Verge to BEA Platform 8.1, that would be a joke considering I have 10% or less of the functionality of BEA. However, comparing Verge to the MVC inside BEA Platform 8.1 seems acceptable.

    One thing I did notice off the bat about Spring's MVC from the public documentation, is that it seems to be lacking a lot of the modern MVC features. For example:

        ## now bind on the name of the company
        <spring:bind path="Company.name">
            ## render a form field, containing the value, the expression
            Name: <input
                type="text"
                value="<c:out value="${status.value}"/>"
                name="<c:out value="${status.expression}"/>">
                ## if there are error codes, display them!
                <c:if test="${status.isError}">
                    Error codes:
                    <c:forEach items="${status.errorMessages}" var"error">
                        <c:out value="${error}"/>
                    </c:forEach>
                </c:if>
        </spring:bind>

    This seems cumbersome to me considering how many other MVC implementations provide the means to bind widgets to model objects. That is one of the pieces of the MVC idea. Likewise, this could become very cumbersome for instances where the HTML tags needs to suppress the value, requiring large chucks of JSTL inside the value attribute. This also makes the JSP page not XHTML compliant and difficult to verify. Likewise, generating select, radio and checkboxes is also complex. Radio and checkboxes are again only handled internal to the application by having some method of reseting the JavaBean property values since HTML 4.01 requires that radio and checkbox tags suppress an HTTP parameter when unchecked.

    In addition, this is not W3C compliant. The name field must contain the expression (or so it appears - the docs do not cover in detail if this is even handled) so that the MVC container can properly set the values on form submission. This means the application developer is forced to use the ID field to name the HTML tag and has no choice but to make the name attribute the expression. The name attribute should not be constrained by the framework in order to tell the server how to handle the JavaBean properties. The developer should be able to supply a name attribute freely.

    Please correct me if I am wrong on anything above.


    > BTW, Spring does have very good test coverage, particularly for a framework of its breadth with so many third-party integrations. But at least you've already apologized for that "Verge has double the test coverage of other frameworks" statement.

    That is great. My philosophy is that testing is equal in importance to coding.


    > So constructively speaking, what you might want to consider is adopting Spring as middle tier foundation with a Verge web layer on top, instead of reinventing all the middle tier support. I believe it's absolutely preferable to integrate with an existing middle tier container instead of building your own IoC/AOP container plus middle tier services. That's the way that all other web frameworks (with the notable exception of Expresso) have adopted.

    That sounds like a good idea. I'll definitely take a look into that. More likely to leverage the middle-tier portions of the framework.

    Thanks,
    Brian
  55. Spring[ Go to top ]

    Brian,

    Let's finally forget about those statements on better, simpler, whatever - let's keep concentrating on constructive stuff. Regarding Spring's own *web MVC*: This is now a fair comparison, as Verge is a web MVC framework and does by no means compete with Spring as a whole (just like Struts, WebWork, and Tapestry). Point taken regarding docs: We're working on improving those.

    Spring's view support follows the principle to not create *any* HTML code from Java code, not even from JSP tag implementations. That's what you see in the bind example: Every single HTML character is contained in the JSP, the tags simply fill dynamic content in. We do not focus on JSP here: With similar helper objects, we provide the same level of support for Velocity and co.

    The expression in name fields of forms is a simple convenience. You can manually name them "firstName" for a "firstName" bean property of your form object: The expression simply does that for you, no matter how nested the property path might be. Note that it's straightforward to code forms with Java scriptlets, possibly using the RequestContext helper class. The tags are pure convenience.

    Your example refers to automatic binding: If you want to do manual binding of request parameters to form object properties, you are absolutely free to do so. Note that in contrast to Struts, Spring provides multiple levels of coding controllers. The simplest is the Controller interface, with a plain "ModelAndView handleRequest(HttpServletRequest, HttpServletResponse)" method. All others like the form controllers are simply pre-built implementations of this interface.

    So it's arguable that Spring's web MVC framework is rather puristic web MVC in that it does not aim to provide any higher-level UI abstractions - similar to Struts and WebWork, but even more puristic than those in terms of no HTML getting generated from tags. A further important point is support for diverse view technologies, currently: JSP/JSTL, Velocity, Tiles, PDF, Excel, XSLT (the Countries sample app illustrates some of those).

    For higher-level UI development, you are free to use *any* other web framework on top of a Spring-managed middle tier, like Tapestry or JSF. As long as you have access to the ServletContext, accessing the Spring application context from such UI layers is a one-liner. This is also easy from any plain Servlet or JSP: The full power of Spring's middle tier support and lower levels is *completely* independent from Spring's own web MVC framework.

    Again, Spring is primarily a middle tier framework: focussing on wiring of business objects, DAOs, and resources - including transaction services and remoting -, building on basic infrastructure for IoC, AOP, source-level metadata, etc. An important part is the pre-built support for a variety of O/R Mapping tools like Hibernate, JDO, and iBATIS. We have numerous users that use Spring for the middle tier of Swing applications, and - as I outlined - many that combine it with their web framework of choice.

    In terms of integration with a web framework like Verge, the nice thing is that you don't need to do anything special: For simple purposes, it's sufficient to provide easy access to the ServletContext from within your web controller classes, to allow for easy lookup of the Spring application context. Of course, you can try to add more sophisticated means of wiring your web controllers with Spring-managed middle tier beans, like Atlassian did for WebWork2 (used in their new product Confluence).

    Juergen
  56. Spring[ Go to top ]

    FYI, a couple of links on integration of third-party web frameworks with a Spring-managed middle tier:

    http://www.springframework.org/docs/web_mvc.html
    http://www.springframework.org/docs/integration/tapestry.html
    http://struts.sourceforge.net/struts-spring/index.html
    http://wiki.opensymphony.com/space/Spring+Framework+Integration
    http://www.mail-archive.com/opensymphony-webwork at lists dot sourceforge dot net/msg05955.html

    Note that the latter already focus on more sophisticated means of wiring. The simple option of using Spring's WebApplicationContextUtils.getWebApplicationContext(ServletContext) to look up the Spring middle tier context in a service locator style is always available without any special integration effort.

    Juergen
  57. Spring and Verge integration[ Go to top ]

    So constructively speaking, what you might want to consider is adopting Spring as middle tier foundation with a Verge web layer on top, instead of reinventing all the middle tier support. I believe it's absolutely preferable to integrate

    with an existing middle tier container instead of building your own IoC/AOP
    container plus middle tier services. That's the way that all other web frameworks (with the notable exception of Expresso) have adopted.

    > That sounds like a good idea. I'll definitely take a look into that. More likely to leverage the middle-tier portions of the framework.

    I suppose one can easily call a Spring component from Verge's ActionHandlers, but
    if Verge obtains the ActionHandlers from the Spring's BeanFactories the two frameworks will be truely integrated.

    I would very much like to see that!
  58. Spring and Verge integration[ Go to top ]

    That sounds like a good idea. I'll definitely take a look into that. More likely to leverage the middle-tier portions of the framework.

    >
    > I suppose one can easily call a Spring component from Verge's ActionHandlers, but
    > if Verge obtains the ActionHandlers from the Spring's BeanFactories the two frameworks will be truely integrated.
    >
    > I would very much like to see that!

    This would actually work very well. Verge already has full ActionHandler support for the very simple IoC container that I built, called Repository. So, just expanding on that principle and loading a Spring container managed bean instead should be very simple.

    I'll have to look into all this stuff next week. I'm also planning on working on Velocity integration (if possible) and a few other display technologies. I'll keep everyone posted here and at Inversoft.com.
  59. WebWork is not W3C compliant because it doesn't support every possible element attribute? You know you don't have to use the UI tags, right? This is just stupid.

    So it's got long transaction support "and others as well". Ahh. I can tell you from implementing WebWork2 that if you don't have Interceptors your framework architecture is probably too coupled. WebWork2 makes heavy use of them and allows you to customize the call stack for core features like setting request parameters into whatever order you like. I agree that IoC and Interceptors are simple concepts, but the difference between theory and practice is that in theory, there is no difference :-)
  60. WebWork is not W3C compliant because it doesn't support every possible element attribute? You know you don't have to use the UI tags, right? This is just stupid.


    Yes. The W3C specification requires that certain attributes be supported by implementors. Taking this into the framework level is just the next step. If you don't support all the attributes, you are not compliant. The transitional DTD is still the preferred method of compliance. The presentation attributes are deprecated, but not removed.


    > So it's got long transaction support "and others as well". Ahh. I can tell you from implementing WebWork2 that if you don't have Interceptors your framework architecture is probably too coupled. WebWork2 makes heavy use of them and allows you to customize the call stack for core features like setting request parameters into whatever order you like. I agree that IoC and Interceptors are simple concepts, but the difference between theory and practice is that in theory, there is no difference :-)

    Well, my statements may be bold, but this is just as bold. "If [I] don't have interceptors [my] framework architecture is probably to coupled." That is pretty sweeping. Interceptors are a good pattern, but not the only decoupling pattern. I think assuming that interceptors is the only way to decouple is a narrow view. I decoupled using an entirely different mechanism and still decoupled things nicely. Adding interceptors for each layer of my decoupling should be possible, if I choose to go that route. I could also leave my MVC systems (Form-Based MVC, ActionFlow, Web) tightly coupled as individual units and allow the decoupling to take place at the Mediator and Parser level (the mediator and parsers control the MVC at a higher level as interceptors do).

    In terms of theory and practice. I think that good designs can lead to easy practice regardless of theory.
  61. Great documentation[ Go to top ]

    I started reading through the documentation - outstanding work. It looks to me that it is quite complete, something I really miss in WebWork.

    Another advantage that I spotted - the tags support style, lang and dir attibutes, which also is missing in WebWork 1.

    I am definetly planning to give a test drive to this one.
  62. Manager wanted ![ Go to top ]

    "Features
    A complete MVC for building more robust web applications where data can be reused across your entire enterprise. Support for Model-Driven Design (MDD) by allowing existing object models to be used The Verge Repository which allows objects of any type to be created, stored and initialized in a single line of code Coming soon a complete user management system for customizing your applications as well as a portal/portlet system for building the best visual experience for your users"

    Wow ! Looks very ambitious. Brian, if you care about it, I think Verge has many very interesting insights.

    Anybody remember Oracle´s pages in PC-Magazine in early 90 ? Very agressive and ambitious ! In fact, even today companies like Microsoft is also agressive in their "independent researches" reports, or marketing adds (see last Linux ROI report). So IMHO why not be condescending with a (probaly) former commercial project/product that now is Open Source ? Note, they speak marketing language..

    Ok, lets suppose Brian has build their coll features on top of :

    1) An architectural pattern : stuff like cell,node,server and cluster, clone. Concepts of Websphere 5. Model it all
       and implement it in plain java code.
    2) Some concepts from Acme Group ADL specification. Create some "architectural stereotipes / scenarios"
    3) An IOC container like Spring. WAS 5 JNDI namming (HiverMind here?) compatible.
    4) Groovy script support. May be actions or rules ? The business user works here ! He reads use case documents (funcional requiriments) together with architectural spec...
    5) AOP support for architectural concerns (non funcional requirement) like security, cache, cluster, services protocols, etc. The
       architect/programmer works here. He read the project´s architectural specification.
    6) "Live" applications/workflows like Shocklets wants to deliver and with on line "managed code" (JMX is necessary ?)

    Hum, also may be tools like MDA models translators (UML-XMI->Java code or DB schema <-> Java code) via Velocity, etc. Eclipse plug-ins when applicable.

    Please, this is just a brainstorm but IMHO this would be great. But I think may be he was very busy doing his job and he simply decided to start his own framework. How many of us did´nt start it before ? Think again...

    I think everyone that start building an ambitious project deserve some credibility. Probaly he is a talentous guy
    who deserve a real (appears to be missing) LEADER in your team/network. I am sure a GOOD manager could help Brian convincing him to contribute to
    an existing open source project or at least explaining how to introduce his valuable contribuiton to our community, but I know these guys are very, very rare so...
  63. Seriously how many presentation tier frameworks does one need.
    I'd much rather see frameworks that make developing the middle tier easier
    Still looking into spring, it looks pretty promissing in that regard, their dao support (http://hibernate.bluemars.net/110.html) look pretty kickass and I imagine it safes you a lot of work.