What are the pros and cons of echo3 framework compared to other java web frameworks?
Echo3 is still under development. Echo2 is stable (but old). The main "pro" is that you don't write javascript or html, you write Java GUI code. The main "con" is that it has not been widely adopted. I've used Echo2 5 years ago and it was a nice framework, but the development of Echo3 is slow (thought it has not stopped).
Perhaps it is worth taking a look at other similar frameworks like GWT or Vaadin.
These (Echo, GWT, Vaadin) differ from traditional frameworks (like spring mvc, struts, wicket) in the fact that you don't write HTML, css and javascript. That's why they are more suitable for highly-interactive web-applications that would resemble a desktop application. If you, for example, need to have bookmarkable URLs, want to rely on browser navigation and such browser-intrinsic things, don't go for Echo/GWT/Vaadin (although they do provide some support for these things)
I went to the Echo3 website and found an argument that discouraged me from testing it. It seems that it is a dead project:
the current version of Echo3 is 3.0.beta8, released August 6, 2009
Technically, I don't know...
Recently the final 3.0.1 version has been released. A 3.1 version (with WebSocket integration etc.) is just around the corner.
The original creator/maintainer has all but dissapeared, but there are considerable community efforts in reviving the project (and make it less dependent on a single (albeit very gifted) person).
Old question, but some people may still ask it...
I've been working with Echo3 for some time now, and the biggest problems are indeed that is is not widely adopted, as already mentioned and that the development progresses very slow.
When choosing a framework, you normally limit yourself to it's technologies, and Echo3 simply lacks a few things that I always missed in my projects. For example, the Echo3 table component offers no scrolling, no pagination and no sorting. And a table is one of the most important a components a framework can offer (Echolot has a nice table component, but it only supports text values and currently has no sorting).
So have a good look at the Echo3 showcase at http://demo.nextapp.com/echo3csjs/ and at the widget libraries at http://echo.nextapp.com/site/echo3/addons and see if that is enough for you.
Also, it changes the way you can design and layout your applications. Echo3 gives you the usual desktop components, like rows, columns, grids and panels. However, it doesn't offer layout manager concepts like Swing does and also does not have any CSS support. When having to follow exact design rules which involve exact positionings and behaviours of components you might have trouble doing this with Echo3.
Related
I am torn between Wicket and Vaadin. I am starting a micro-isv and need to make a choice of web framework. I have narrowed down my choices to Wicket and Vaadin. I have used both frameworks and I love them both. however I need to make a choice.
If If I choose Vaadin:
I wont have to worry much about the look and feel. It comes with nice themes.
I will do all my programming in Java which am very good at and wont have to spend time hacking CSS which am not very good at.
And most of the components that I will need for a business applications are there OUT OF THE BOX including, desktop like layout, tooltips, Keyboard shortcuts, tables with draggable and collapsible columns to name a few.
However, if I go the Vaadin way:
I will loose the ability to create UI declaratively.
I wont have the fallback feature if the browser doesn't support JavaScript - e.g most non Webkit mobile browsers.
Vaadin company is selling some components - e.g the JPAContainer so am not sure the company will be committed to offering full open-source framework. Business interests will always come first.
Vaadin applications will be mostly for the intranet. They are not very suitable for the internet with a web look and feel.
If I go the Wicket way:
I will have to style my applications and I can hardly give them a desktop look and feel.
Any advice? Anyone with experience on either framework kindly tell me the cons and pros and how you made your decision.
I think I've invested some time for both frameworks. I really like both because they bring the Swing-alike coding to web development. And I don't know easier ones for me (although there is click but I don't like the velocity templating thing)
And yes, there are differences.
I wont have to worry much about the look and feel.It comes with nice themes
true, but every serious company will style its app differently (unless you are prototyping)
I will do all my programming in java which am very good at and wont have to spend time hacking css which am not very good at
Then Vaadin would be 'better'.
i will loose the ability to create UI declaratively.
What are the advantages of that? (BTW: you could code declarative in groovy ;-))
But ok. I know what you mean: if you can afford a few separate designers then wicket is 'better'.
i can hardly give them a desktop look and feel.
Why not? Or what do you mean here? Wicket supports ajax and there are components which supports nice 'desktop-alike' things (ajaxlink, lazycomponent, autocompletion, progressbar, see wicket stuff + extensions). ok, for any more complex component you'll have to code in javascript BUT BTW did you know that you could even use GWT within wicket
Some minor experiences:
Vaadin is surely faster while coding (no css, html stuff). But if you go production keep in mind that the ease of programming can come to the cost of performance on the client side: e.g. if you use the 'wrong' layouts such as Horizontal/VerticalLayout, ... the massive use of javascript could slow down old browser.
But Vaadin is not slow! Use appropriate layouts such as CssLayout or FastLayout and also old browser can serve it. (Although if you would use CssLayout your coding-style is really wicket-alike.)
One issue with Vaadin is that it is a bit harder to profile, because you don't see easily where the client needs all the CPU and the nested divs gets cryptic id-names.
One great thing about Wicket is its warp persist integration
(Guice can be integrated in Vaadin and Wicket)
Testing the UI should be easy with Vaadin (although I didn't found unit testing stuff) and is very easy with wicket.
Last but not least creating lists/tables is VERY easy in Vaadin compared to wicket.
I've worked extensively with Wicket but I've not had any experience with Vaadin so this might be (a little) biased.
I'd recommend Wicket for obvious reasons, but what's probably of interest to you is Wickets openness. As Gweebz rightly pointed out, Wicket uses basic HTML markup as its foundation, so any structural or cosmetic changes are often trivial to implement.
Personally one of the things I really enjoy about out wicket work is the flow between front end presentation and the data backend, we've implemented Spring & JPA/Hibernate which means that any changes in the front end can be translated back into the data base with a single line of code thanks to Wickets model based architecture.
Again I can't say much for Vaadin having never worked with it, but if you're looking for architectures to start off with, I'd also recommend you have a look at GWT.
(continued from the comment in the first Wicket-related answer)
The major difference between Vaadin and Wicket is with how UI composition and client side code is written. With Vaadin you usually compose your UI without any templates or HTML at all and you get a sleek, fully Ajax'ed UI out of the box. However, if you prefer the templating approach just use CustomLayout which does exactly that.
Client side coding is rarely needed, but when it is you do it with the Java-based GWT which is IMO a lot more nicer than writing Javascript by hand. Besides, with GWT you automatically get cross-browser compliant solution instead of having to deal with those issues yourself.
When comparing frameworks you also should take a look at community activity and documentation. With Vaadin both of those are excellent. Also note the Vaadin Directory which currently contains 100+ very useful UI components and other addons.
I have a limited amount of experience with each but I prefer Vaadin. It allowed a richer experience with the web application I was developing. The main benefit that sold us though was how easy it was to write unit tests around our UI classes, ensuring the components functioned correctly when interacted with in the expected ways. This is also possible with Wicket however it was more difficult in my experience.
I will also mention that either framework will require some styling. Wicket starts off as plain old HTML and Vaadin starts off with a MacOSX-like theme by default but almost any web-app you write will require at least SOME customization. With this in mind, customizing the CSS of a Wicket app is SIGNIFICANTLY easier than Vaadin for the simple reason that you control the markup. Vaadin hides the markup from you and generates elements with weird IDs and structures so it is harder to customize the look. Just remember this when making your decision.
I am currently working with Wicket and I have worked in the pass with Vaadin. I wil be short in my observations:
Vaadin is entitled to be free but IMO, is not so beautiful like that. If you need support, help, documentation for that painful and tricky problems that you encounter, then you are screwed because you do not have so good documentation/community when compared with Apache Wicket. Vaadin have guys to help you, but you have to pay for it.;
To program in wicket you need to be a strong programmer. Vaadin also requires good Java knowledge but you can easily do some spaghetti code if you want (just saying, not doing..);
Apache Wicket really separate the web technologies (Javascript, HTML, etc.) from the framework technology (Java). Vaadin also try to do it, but IMO is not so elegant and transparent on that.
Appart from that, we are talking about two different types of frameworks, two different approach, which have pros and cons that I advice you to search and compare and see what really fits your needs.
Edit: Oh, and about the look and feel, for instance you always have Wicket Bootstrap
Also do notice that even though Vaadin base framework is free, for some additional functionality you might need to buy extensions.
Ex - If you need to integrate a good charting solution such as Highcharts, you'd have to pay and buy the vaadin charts extension (even though highcharts is available free for FOSS apps, the vaadin charts plugin built on that is not given free for FOSS apps).
Thank you for your question.
The answer is short and simple
Vaadin is a great tool for java developers who needs to develop web apps, but it is a powerful WAR Machine if you have moderate javascript knowledge, and some basic css skils.
Vaadin is not slow, it is even faster than React and Angular.
If your app is slow, it's because you designed it wrong, and that's true to any framework you use.
Keep in mind this, Vaadin uses web components, so most of the UI is built on the client, no heavy rendering on the server
In your case you said you don't have css knowledge, two options:
Use Vaadin, or hire frontend developer.
I am a web developer for more than 10 years, and I have started as a php developer and a javascript developer.
I can tell you that once I've got into Vaadin, I can not develop another way.
What to choose depends primarily on the business requirements (see points 2 and 4 of your question)
However, if I go the Vaadin way:
I will loose the ability to create UI declaratively.
You can try using the ZK framework - similar to Vaadin with a declarative user interface in XML
Almost the same question has been asked a year ago, but the there has been some new development in this area.
Selecting a (data binding) framework for swing application seems to be quite difficult. JSR-295 is abandoned, many swing frameworks which provide binding are work-in-progress, abandoned or too heavy for my quite simple app. JGoodies Swing suite is expensive, but luckily its libraries are free.
Has anyone any real-world experience of new UFaceKit. It looks promising, but quite immature. I am particularly interested in Swing implementation and documentation. Any insight on UFaceKits development schedule would be appreciated, because I can hold by framework choice for a while. Requirements are not anything fancy, just working binding with a nice API.
I also found Mogwai dataBinding, but it seems quite incomplete and requires manual synchronization activation, which makes it useless compared to coarse grained synchronization easily written by hand.
Incomplete frameworks include at least Spring RCP and many JSR-296 forks.
So, is the JGoodies data binding really the only realistic choice? Or are there any other viable solutions available?
Edit:
This question seems to rank quite high in google and the accepted answer reflects the time question was originally asked. Anyone who seeks to build new swing application that uses databinding should check all the answers, they have information about latest progress in this area.
BBB (pretty much the official fork of JSR 295) works just fine.
The Beanfabrics framework contains some sort of data binding. In fact it is an implementation of the Presentation Model pattern: http://code.google.com/p/beanfabrics/
This project also has a data binding to forms that's easy to use, I'm created this project 2 years ago and it's growing from my ideas and some collaborators since that.
https://github.com/MarkyVasconcelos/Towel
I'm writing a library that has support for Swing data binding using Views, Binders and ControlAccessors for Swing Components.
See http://www.jdal.org/doc/swing/jdal-swing-binding.php
Melasse project can glue UI and beans togather w/o creating class: Binder.bind(/* source, target, options */).
e.g. To enable an action/button only when textfield is not empty: https://github.com/cchantep/melasse/blob/master/README.md#bind-buttonaction-to-provided-value .
We are going to use now Eclipse WindowBuilder, and I think it should go well
See Swing Data Binding Example at http://code.google.com/javadevtools/
It is uses beansbinding-1.2.1.jar, that is jdesktop.org project. If it is related to JSR-295, I don't know (please edit)
I would like to write a somewhat complex web gui application.
It will be used to edit certain content by displaying panels and allowing the user to drag items to edit the content.
The explanation is somewhat abstract, but the point is that i'm looking for a modern gui writing technology, the more standard it is the better odds of me finding information and samples to using it.
I've been using JavaFaces to write some simple web pages and have taken a look at RichFaces for purposes of writing the app described above.
I would love to hear recommendation of similar technologies (For example - What was used to write this website?)
Thank you!!!
Update: Thanks for the answers so far, Since I was asked for more clarification I'll try to explain the use of the app:
It will be used to edit a complex script. There will be one panel with the actions of the scripts (The phases) and the other panel will show the content of the currently selected action. To each action type there will be a different set of attributes to modify.
You will be able to reorder actions by dragging them to a new location (Kinda like powerpoint slides organizer or flickr photo organizer) and also copy them that way.
The content of the action attribute panel will be able to display various types of content such as html text and buttons and all kinds of stuff.
Hope that helps. Thanks Again!
Update2: After reading this StackOverflow Thread I'm leaning towards RichFaces for it's vast support and standardization.
It seems you need a RIA. The Java worlds offers the following options:
Google Web Toolkit - a powerful RIA technology, which will require you to go through a steep learning curve. Nice component frameworks are SmartGWT, gwt-ext and ExtGWT. In my opinion all of them have some drawbacks, but in your case you might not observe them.
RichFaces - quite powerful as well, and since you have JSF experience, I'd recommend this.
ZK - never used it and I don't like some aspects of it (at least a while ago when I last checked it), but it's still an option.
Echo3 - similar to GWT in the way of development, but very different in the actual result. I'm not sure, however, whether it's still in development
JavaFX - if you are adventurous, and your application won't be used by the open public, try it.
ASP.NET MVC was used to write this site.
To your question: you should use the technology you like. If you've used to Java, you may wish to explore various MVC frameworks for that. Or you can try out new unfamiliar to you (yet) technologies.
Take a look to GWT and SmartGWT. Together are quite a powerful combination to write RIA webapps.
An interesting framework that I would be glad if I had the time to look deeper into is Cappuccino. Look at 280Slides for an example.
Flex is also nice open source option to create Rich Internet Applications. If you would like to stick to the JavaScript then you can use JQuery, YUI etc
There is also one very interesting thing called Vaadin check it http://demo.vaadin.com/sampler/
ICEfaces is one possibility. Demos here.
I used richfaces including drag and drop functionality, realy nice to offer good usability.
If you like the Java Web Technologies take a look at zk. It promises the same things as ICEFaces. I don't know if it can live up to that promises but IceFaces coul certainly not for me.
ZK should enable you to build your web app like a common swing app.
I'd suggest that you do not invest into technologies/frameworks which are based on integration of browser side ajax capabilities with server side frameworks if you'll need advanced functionality in the browser.
What is advanced and what is not is a completely different topic of course, but just to give you a heads up, as you start facing more and more complex UI requirements, you'll discover that the connectivity to back end framework (like JSF) will become more of a problem than a capability. Especially with things like JSF lifecycle, and most of the server side frameworks being based on the idea of an HTTP post (for client-server communication), you'll have issues.
An example: you'll be requested to develop a very specific UI widget that has drag and drop capability. If the Ajax-jsf integration framework of your choice does not contain this widget, your problem is born at this point. You'll start looking for ways of injecting data into existing channels, and it will get messy.
To avoid further speculation, let me just repeat that if you are sure that your chosen technology setup will give you 90%+ of the capabilities you'll need, that is ok. If you end up developing too much custom stuff, then consider an integration between a powerful client side (javascript or flex or silverlight) layer and a simpler server side layer (resteasy etc) Initial development may not be as fast as the other options, but if you'll need flexibility, this will end up being a much cleaner setup. I'd suggest you take a look at DOJO, and ExtGWT .
Cheers
Seref
It looks like XHTML + JavaScript could be enough for the dragging & dropping functionality you describe. This means you can use just about any web framework of your choice. If you need frequent asynchronous server calls (AJAX) then GWT is the most standard Java framework I think, although it has its peculiarities. Personally I like Wicket because it does not use XML configurations, relies heavily on code and has a nice community around it. Wicket also offers good AJAX support btw.
I work in a medium to small team ( 10 people ) developing and supporting several web enterprise applications.
We have a dozen of them built with a house-made framework with asp-classic working against ms-sql server.
We are evaluating the migration to a new development stack.
We'd like it to be open (free) and simple.
I've been looking around the java web frameworks, but all of them seem to be extremely overbloated for our needs (with the possible exception of http://www.playframework.org/, which I couldn't study yet...)
We are thinking about porting our own framework to this new stack, rather than adopting a whole new stack that we are unaware of ...
so far now, we though about the following possibilities
plain java - jsp - jsf
groovy - gsp (no grails at all)
jruby (no rails at all)
we feel really comfortable working with dynamic languages (well, as dynamic as classic asp can be) and with a lean and understandable framework...
I see no small and simple web frameworks for java, like there are for php or ruby...
I really like groovy, but I see no web implementations outside of grails... Besides the language documentation doesn't seem to be quite complete (I might be looking in the wrong place, perhaps)
php could be an option, but I think it would be hard to advocate for it in my current work...
any other option, advice, pros and cons?
thanks a lot
--
edit
some related link Can anyone recommend a simple Java web-app framework?
I'd suggest you take another look at Grails. It does use hibernate and spring under the covers, but for most situations, you don't need to know the details of those frameworks. There's a large community and lots of documentation/blogs/mailing lists for support, as well as a thriving plugin community with over 300 plugins solving pretty much any need.
If you're still put off by grails, you could look into the play framework. I don't have any experience with it, but there has been some traffic recently around it on hacker news and the like. I know it uses groovy for the templating language.
I cannot recommend anything, but strongly recommend that you consider these things:
Rapid development. Basically you want to save a page file, and reload it in the browser. Instantly! It can be done, do not settle for long deployment times.
Plain, readable text files!
Convention coding instead of explicit coding - big XML files will eventually drive one or more developers insane. The less, the better.
Good tool support (just having syntax coloring may be a big help)
Consider the long term support of your choice. You are basically remarrying with your software - will it still be maintained in 10 years? By whom? Will you have alternatives (JSR's are great - look at the amount of servlet engines)?
And WHEN you choose - get the source code for it, and ensure that it builds correctly. It will never be easier than now, and some day you WILL need to fix something inside. On short notice! (You may even consider allocating resources for donating documentation/patches/time to the open source project you are building your business on).
EDIT: A few more things:
You want to be able to verify things at compile time. One of the things that make it possible to build cathedrals in Java is that the static typechecking prevents a lot of nasty runtime errors. "Oh, THAT method? Well, it's not here, sorry. Boom!"
You want good error reporting. Built in! Try throwing a NullPointerException deep, deep down and see what 1) the user and 2) the developer is told about it. Anything that requires going to a log file to get the details WILL cause calls at 3 AM eventually.
Look into scalability from the start. Any non-trivial customer will need to and the world goes to multicores, so you might as well think about it already now. What will you do when all the magic pixie performance dust has been used and it just isn't enough: The application requires more than a single box.
And read this: http://www.pragprog.com/titles/mnee/release-it
You're forgetting about the other major player in this field: the LAMP stack (linux, Apache, MySQL and mod_perl). All components are free, there are many books available on LAMP development and each of these components, and there are vast numbers of libraries and components already available.
Apache: the Definitive Guide
Learning Perl: by SO's brian d foy
Practical mod_perl
If you are afraid of Grails and need Java, try Stripes and read the excellent Stripes book (http://www.stripesbook.com/blog/). You can buy the eBook pdf for $23. The book covers the framework in amazing detail. Stripes is a very strong, lightweight MVC framework that deals with all the common problems of web development (templates, url mapping, form validation, security, internationalization, testing) but it won't automagically create the database layer for you unless you want it to by using Stripernate. You can also use Groovy with it. You can use it standalone or with Spring.
I've had great success in simple web projects using Spring MVC with JSTL JSPs. Spring MVC is a framework that can be kept pretty darn simple (1 additional XML file used for configuration). You can eschew all the fancy options and just specify a set of JSPs that you want to associate with view names, then forward to those views by specifying their names in the controller.
Spring MVC can also easily scale up and be as complex as you need, letting you switch from JSTL to JSTL with Tiles, or Struts, or JSF, or Wicket. It can also handle complex web flows using the Spring Web Flow project. But for most projects I just keep it simple -- build a JSTL JSP, create a controller that provides the objects that JSP needs, and associate them by having the controller return that view. Once you get the project set up and you're familiar with the configuration, it takes maybe a couple minutes to wire a new page into place.
If you like Groovy but don't like Grails you could try Gaelyk, which is a lightweight Groovy framework. However, AFAIK you can only use Gaelyk if you're hosting the app on the Google App Engine
If your apps won't be hosted on GAE, and you really don't want to use Grails, another option is to use Groovlets, Groovy template servlet, GSPs.
However, personally I think it's a big mistake to dismiss Grails. It really is a great framework, and you can go a long way without knowing much about Spring and Hibernate. One of your complaints is a lack of Grails documentation. I think you must have been looking in the wrong place, because in addition to all the books available, there's a very extensive reference document and a lot of other documentation available on the website. Finally, there's a very active mailing list.
My platform of choice is JRuby - Rails (3) because of its very rich and powerful ecosystem, but mainly because:
* very easy to use
* many MANY libraries
* fast support via IRC
* deep documentation
You can also check out Scala + Lift Web Framework ( imho best static typed language, nice framework )
Apache Wicket ( http://wicket.apache.org/ ) and Apache Tapestry ( http://wicket.apache.org/ ) are both component oriented web frameworks - contrary to action based frameworks like Stripes - by the Apache Foundation. Both allow you to build your application from components in Java. They both look very similar to me.
What are the differences between those two frameworks? Has someone experience in both? Specifically:
How is their performance, how much can state handling be customized, can they be used stateless?
What is the difference in their component model?
What would you choose for which applications?
How do they integrate with Guice, Spring, JSR 299?
Edit: I have read the documentation for both and I have used both. The questions cannot be answered sufficently from reading the documentation, but from the experience from using these for some time, e.g. how to use Wicket in a stateless mode for high performance sites. Thanks.
Some relevant differences as I see them:
Tapestry uses a semi-static page
structure, where you can work with
conditionals and loops to achieve
dynamic behavior. Wicket is
completely dynamic; you can load
components dynamically, replace them
at runtime, etc. The consequences of
this are that Tapestry is easier to
optimize, and that Wicket is more
flexible in it's use.
Both frameworks
are roughly equally efficient in
execution, but Wicket relies on
server side storage (by default the
current page in session, and past
pages in a 'second level cache' which
is default a temp file in the file
system). If that bothers you, think
about how many concurrent sessions
you expect to have at peak times and
calculate with say ~100kb per session
(which is probably on the high side).
That means that you can run roughly
support 20k concurrent sessions for
2GB. Say 15k because you need that
memory for other things as well. Of
course, a disadvantage of storing
state is that it'll only work well
with session affinity, so that's a
limitation when using Wicket. The
framework provides you with a means
to implement stateless pages, but if
you're developing fully stateless
applications you might consider a
different framework.
Wicket's goal is to support static typing to the fullest extent, whereas Tapestry is more about saving lines of code. So with Tapestry your code base is likely smaller, which is good for maintenance, and with Wicket, you much is statically typed, which makes it easier to navigate with an IDE and check with a compiler, which also is good for maintenance. Something to say for both imho.
I have read a few times by now that people think Wicket works through inheritance a lot. I would like to stress that you have a choice. There is a hierarchy of components, but Wicket also supports composition though constructs like IBehavior (on top of which e.g. Wicket's Ajax support is built). On top of that you have things like converters and validators, which you add to components, globally, or even as a cross cutting concern using some of the phase listeners Wicket provides.
REVISED after studying Tapestry 5.
Wicket's goal is an attempt to make web development similar to desktop GUI one. They managed to do it really well at the expense of memory usage ( HTTPSession ).
Tapestry 5's goal is to make very optimized (for CPU and memory) component oriented web framework.
The really big pitfall for me was responses "Wicket supports stateless component!" to the arguments "Wicket is memory hungry". While Wicket indeed supports stateless components they are not "a focus of Wicket development". For example a bug in StatelessForm was not fixed for a very long time - see StatelessForm - problem with parameters after validation fails.
IMHO using Wicket is a bit eaiser until you are going to optimize/ fine-tune web application parameters
IMHO Wicket is harder to study if you have programmed web applications and want to think in terms of request processing
Tapestry 5 automatically reloads component classes as soon as you change them. Both frameworks reload component markup.
Wicket forces markup/ code separation, Tapestry 5 just give you this ability. You can also use less verbose syntax in Tapestry 5. As always this freedom requires more cautions to be taken.
Wicket's core is easier to debug: user components are based on inheritance while Tapestry 5 user components are based on annotations. From the other side that could make transitions to the future versions easier for Tapestry then for Wicket.
Unfortunately Tapestry 5 tutorial does not stress that Tapestry code example like 't:loop source="1..10"...' can be a bad practice. So some effort should be put into writing Tapestry usage conventions/ good practices if your team is not very small.
My recommendations:
Use Wicket when your pages structure is very dynamic and you can afford spending 10-200 Kbs of HttpSession memory per user (these are rough numbers).
Use Tapestry 5 in cases when you need more efficient usage of resources
Here's a pretty thorough comparison from IBM's Developer Works.
http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=drs
Update: link is dead, but you can find the page on http://web.archive.org/web/20131011174338/http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=drs
I think Wicket is a simpler framework to use.
Also, Wicket does allow for class reloading via your IDE's hot-code replace system. This is all that is required for Wicket to run off modified versions of a currently running application's classes. The usual restrictions apply for hot-code replace, such as having to run in Debug mode (Eclipse) and not being able to change structural aspects of a class (i.e. class name, changing method signatures etc...).
I don't like the Tapestry programming model and I know of many developers leaving Tapestry because of too much changes and incompatibilities in development. See: http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
Wicket is very good web framework. Best from all what i'm know. I'm use it since version 1.3 and always get what i'm want.
Wicket has excellent integration with Spring - just use #SpringBean annotation in you code to inject any spring bean to your classes.
Try http://incubator.apache.org/click/ .
It is amazing java web framework.
Some people call it “Wicket made right” ;-)
As I said when 4.1 was the official stable release:
You should take a very good look at the development history of Tapestry before committing to use it. Tapestry has done a lot of non-compatible upgrades, with no continuation of support of older versions. Patches to 4.1 are not processed anymore within a reasonable timeframe. That is in my point of view not acceptable for the official stable version.
Committing to use Tapestry 5 means:
you should become a committer;
you need to keep up with all new development, abandon old versions as fast as possible;
maintain stable versions yourself.