|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
|
Message #233199
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Don't get the comparison
I really do not get the comparison between JSF and Wicket. To me they address different spaces. All wicket does is gives you a way to put "code behind" HTML (and conceed that it does it pretty darn well). JSF is a component framework that is designed to go beyond HTML promising pre-built components allowing you to build presentations using XML (JSPX)and/or programatically in a manner similar to swing supporting a well defined restful server-side lifecycle.
Having said that I have to admit that if you are going to compare JSF's lame HTML components with Wicket then there is NO comparison. My comment to people has always been that if you are going to use JSF then you need to find a good set of components because JSF's HTML components will not get you far. Look at Oracle's new Rich Faces Component suite (http://www.oracle.com/technology/products/adf/adffaces/11/doc/multiproject/adf-richclient-api/enhanced-tagdoc.html) and you can see the promise of JSF.
But Wait you say, Wicket does have components and yes it does. Ah but for all of these new component frameworks. Problem is none of the emerging frameworks have a comprehensive suite of components; makes one long for one stable framework with a deep set of components; .NET maybe ... but I jest
Probally the best liked feature of all of these new frameworks is the fact that they eliminate JSP which by now the community has to admit is pure evil. It may be that JSP that is the devil in the JSF specification. I will say that I have delivered an entire application, built using ADF (or Trinidad) that nary used a stich of embedded HTML or JSF HTML components. Almost all JSF examples I tend to see have HTML embedded in them, a dead giveaway to a frustrated JSF developer (but I digress).
My point is not that JSF is better than Wicket but to compare the two is meaningless without context. Use Wicket if you want to remain grounded in HTML and the component suite suites your needs, it will get the job done ... but so will a good JSF implementation.
|
|
|
Message #233217
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Don't get the comparison
@Steven
You are right about the fact that Wicket is grounded in HTML (and XML/ XSL if you need that actually). Though there is no reason why other markup variants can't be supported, they aren't implemented right now. However, I wonder how many people actually need other markup variants. Especially the pluggable view that JSF provides: great for selling the framework, but I wonder how many real-life projects actually benefitted from this.
But more importantly, you make the assumption that JSF has an edge over Wicket because JSF has a selection of 3rd party component libraries. I wonder whether that is true for two reasons:
* Wicket actually has quite lot of very high-quality components shipped with the core projects, and some of the wicket-stuff (which is a low barrier component projects repository) projects. It doesn't have all the components that say ADF has, but otoh, it has a couple that ADF doesn't have. I also believe the Wicket components are generally easier extendible so all the af:panelXX components are really moot.
* Wicket components are very easy to write. I find a component like the af:chooseColor funny rather than useful. If you need such a component, you can write one in an hour or two with Wicket and have exactly what you need.
|
|
|
Message #233234
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Don't get the comparison
@Steven
You are right about the fact that Wicket is grounded in HTML (and XML/ XSL if you need that actually). Though there is no reason why other markup variants can't be supported, they aren't implemented right now. However, I wonder how many people actually need other markup variants. Especially the pluggable view that JSF provides: great for selling the framework, but I wonder how many real-life projects actually benefitted from this.
I'm really tired of hearing this. There is a whole world beyond browser html support. Actually if you want to trully build a reusable/componentized front end, xml/xslt is the best and browser-side xslt support makes it much faster than downloading huge html payloads, etc... Though you can use ajax to support smaller requests, each time a page is reloaded, all the html info is again downloaded. In xml/xslt world, you have a cachec xslt stylesheet on the client which supports all small xml payload transformations that is just simply a container for your model.
Either way, flex is great for gui construction and their mxml component model is awesome.
I think wicket is great and I will use it for any application that I know I won't have to support anything other than html, but these are getting lesser and lesser each year.
Ilya
|
|
|
Message #233277
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Don't get the comparison
@Steven
You are right about the fact that Wicket is grounded in HTML (and XML/ XSL if you need that actually). Though there is no reason why other markup variants can't be supported, they aren't implemented right now. However, I wonder how many people actually need other markup variants. Especially the pluggable view that JSF provides: great for selling the framework, but I wonder how many real-life projects actually benefitted from this.
I'm really tired of hearing this. There is a whole world beyond browser html support. Actually if you want to trully build a reusable/componentized front end, xml/xslt is the best and browser-side xslt support makes it much faster than downloading huge html payloads, etc... Though you can use ajax to support smaller requests, each time a page is reloaded, all the html info is again downloaded. In xml/xslt world, you have a cachec xslt stylesheet on the client which supports all small xml payload transformations that is just simply a container for your model.
Either way, flex is great for gui construction and their mxml component model is awesome.
I think wicket is great and I will use it for any application that I know I won't have to support anything other than html, but these are getting lesser and lesser each year.
Ilya
Wow,
I've heard it all now. Justifying the use of the over-engineered, poorly designed, prematurely standardised, JCP endorsed JSF over something simple and to the point like Wicket by suggesting that JSF provides better support for Flex?
What ever happened to keeping things simple? And if you want to use Flex then how about Webwork or Rails?
Talk about being obsessed with your own (JCP) navel!
Paul.
|
|
|
Message #233306
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Don't get the comparison
* Wicket components are very easy to write. I find a component like the af:chooseColor funny rather than useful. If you need such a component, you can write one in an hour or two with Wicket and have exactly what you need.
Eelco,
Allow me to pick on you for the first time :-).
The argument that writing similar component in Wicket would be so easy you could achieve it in a couple of hours doesn't hold much water to me in this context. Logically speaking, someone using JSF could save a couple of hours because the component exist already. Imagine being a consultant charging 90 euros an hour. A company could save a fine hundreds of euros with JSF, right?
Having said that, I still believe Wicket is one of the finest, if not the finest, web frameworks around. Just trying to grab the opportunity to pick on you once :-).
Jan
|
|
|
Message #233320
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Code behind is worse than JSP
Look at .NET code behind. junk.
Its total crap.
It actually takes the normal JSP layer that deals with markup and presentation and pushes that back into the web view/controller layer and then tries to push back forward into the request layer. junk.
Code behind is crap. Call JSP a hack call it what you want.
There IS a need for an intelligent renderer of HTML with code intertwined. If there wasnt then we wouldnt be where we are.
You dont have to look far back to rich client applications to see they wanted to achieve the same PERFECT separation of layers.
Yet not a single GUI client app ever did.
|
|
|
Message #233427
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: AI tech built from wicket
Let's say you have a component you wish to update via ajax. First, you have to create the component, add it and call setOutputMarkupId(true):
final Component component = new MyPanel("panel");
add(component);
component.setOutputMarkupId(true)
This makes it sure that the html markup the component is attached to has a dom id in the generated html (so javascript can find and update it).
Let's say you have a link on your page and when the user clicks on it, you wish to update this component. You just add an AjaxLink like this:
add(new AjaxLink("link") {
public void onClick(AjaxRequestTarget target) {
target.addComponent(component);
}
});
That's it. Clicking on the link will update your component in the browser.
Let's say you want to have your component auto updated every 60 seconds. You also want to update another component (a label with an id "label"). No problem:
component.add((new AjaxSelfUpdatingTimerBehavior(Duration.ONE_MINUTE) {
protected void onPostProcessTarget(final AjaxRequestTarget target) {
target.addComponent(label);
}
});
I hope you get the idea. It's dead simple... clear object oriented design. I've developed a web cms library in a year, working off hours and weekends that powers www.szeretgom.hu in wicket... refactored it several times during last year. Professionaly we built wicket based applications for two banks and a consulting firm. It just works, and works well. It's a bit hard for people to grasp the IModel hierarchy at first, but I think that's the hardest part of it all...
|
|
|
Message #233449
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Don't get the comparison
I really do not get the comparison between JSF and Wicket. To me they address different spaces. All wicket does is gives you a way to put "code behind" HTML (and conceed that it does it pretty darn well). JSF is a component framework that is designed to go beyond HTML promising pre-built components allowing you to build presentations using XML (JSPX)and/or programatically in a manner similar to swing supporting a well defined restful server-side lifecycle.
Having said that I have to admit that if you are going to compare JSF's lame HTML components with Wicket then there is NO comparison.
Wow, that has got to be the most impressive piece of saying absolutely nothing but trying to make it sound smart I have heard in at least a few weeks. What JSF IDE vendor do you work for?
JSF hasn't caught on because it is a steaming pile of donkey turd. It is a useless, pointless piece of junk.
Bleeding abstractions (by far its biggest flaw, out of many many flaws), "everything is a POST", slow, over-engineered, high learning curve, yet-another-tag-language etc etc.
All of JSF is just a great big anti-pattern and signifies everything bad that ever came out of Java-land.
JSF should have been smothered in the craddle and quickly forgotten.
Wicket on the other hand is pretty darned pleasent acquintance.
|
|
|
Message #233458
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Don't get the comparison
Either way, flex is great for gui construction and their mxml component model is awesome.
Sure. The project I'm working on currenly actually uses *both* Wicket and Flex for different parts of the application. Works great.
The point I tried to make with my reply is that I don't believe in the way JSF promisses to be render client specific code. You either have a programming model that is agnostic to the kinds of clients it runs on (XForms, Flex etc) or you develop variants for each of the client types you expect. The way JSF does it imho is half baked and while I have a hunch it may be of use for someone here and there, in general it's probably not worth the extra complexity.
|
|
|
Message #233459
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Don't get the comparison
* Wicket components are very easy to write. I find a component like the af:chooseColor funny rather than useful. If you need such a component, you can write one in an hour or two with Wicket and have exactly what you need.
Eelco,
Allow me to pick on you for the first time :-).
Sure, as long as you don't start flame wars with competitors ;)
The argument that writing similar component in Wicket would be so easy you could achieve it in a couple of hours doesn't hold much water to me in this context. Logically speaking, someone using JSF could save a couple of hours because the component exist already. Imagine being a consultant charging 90 euros an hour. A company could save a fine hundreds of euros with JSF, right?
That holds true if and only if that component does exactly what you want and has the L&F you need or that this is easily customizable. Also, take into account that JSF components typically are configured using string parameters, whereas Wicket components can be configured using any kinds of objects and are often customized by e.g. extending them and overriding a method. It's much easier to create a layer of in-between (abstract) components so that if the more specialed doesn't exactly do what you need, you can look at the parent and see whether you can use that with a bit of filling the gaps.
|
|
|
Message #233460
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Code behind is worse than JSP
Look at .NET code behind. junk.
Yes. But why? Because it is half-assed. It doesn't manage the state of your pages (you have to use viewstate objects for that, and it's still page-, not component based) and the templates are full of foreign (to HTML) constructs. Just like JSF and many others.
It actually takes the normal JSP layer that deals with markup and presentation and pushes that back into the web view/controller layer and then tries to push back forward into the request layer.
If you're bitching about how Wicket does it: I don't think you get the point. With Wicket you seperate the view from the controller and model The templates for presentation are clean consisting only of static elements and hooks for dynamic parts and the dynamic parts (the logic) are implemented using Java - a 3GL well suited for coding arbitrairy logic such as when to show what and how to get it. The seperation means that you let your designers mock up pages and you - the developer - will fill in the dynamic parts. They can use their favorite tools, don't have to be afraid they mess up application logic, etc. And even if you don't use seperate designers, you'll definitively benenfit from having templates that can be 1-1 (or almost) with your design rather than having to strip/ add the logic all the time you have to get back to the drawing board.
|
|
|
Message #233544
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Code behind is worse than JSP
Look at .NET code behind. junk. Yes. But why? Because it is half-assed. It doesn't manage the state of your pages (you have to use viewstate objects for that, and it's still page-, not component based)
This is not exactly true. Viewstate is managed on component level. By default viewstate of all components on a page (so in this sense viewstate is page-based) is combined into one binary chunk, encrypted and saved into _viewstate hidden field, therefore you need to use a chain of HTML forms to keep state of related pages or to keep state of one logical page after it has been submitted.
This is an Achilles heel of this approach, but on a plus side you can choose to save viewstate in a session or in a database or in any arbitrary object of your choice, there are callbacks for that. Also, you can choose to turn on or off viewstate for specific components or for all components on a page.
|
|
|
Message #233559
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Code behind is worse than JSP
Look at .NET code behind. junk. Yes. But why? Because it is half-assed. It doesn't manage the state of your pages (you have to use viewstate objects for that, and it's still page-, not component based)
This is not exactly true. Viewstate is managed on component level. By default viewstate of all components on a page (so in this sense viewstate is page-based) is combined into one binary chunk, encrypted and saved into _viewstate hidden field, therefore you need to use a chain of HTML forms to keep state of related pages or to keep state of one logical page after it has been submitted.
This is an Achilles heel of this approach, but on a plus side you can choose to save viewstate in a session or in a database or in any arbitrary object of your choice, there are callbacks for that. Also, you can choose to turn on or off viewstate for specific components or for all components on a page.
The thing that I don't like about viewstate is that it is a seperate (non-typed) map. Can can create member variables of pages and components, but .NET won't keep the values of them. So it provides you a programming model that is half-baked OO-ish.
|
|
|
Message #233632
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Don't get the comparison
@Steven
You are right about the fact that Wicket is grounded in HTML (and XML/ XSL if you need that actually). Though there is no reason why other markup variants can't be supported, they aren't implemented right now. However, I wonder how many people actually need other markup variants. Especially the pluggable view that JSF provides: great for selling the framework, but I wonder how many real-life projects actually benefitted from this.
I'm really tired of hearing this. There is a whole world beyond browser html support. Actually if you want to trully build a reusable/componentized front end, xml/xslt is the best and browser-side xslt support makes it much faster than downloading huge html payloads, etc... Though you can use ajax to support smaller requests, each time a page is reloaded, all the html info is again downloaded. In xml/xslt world, you have a cachec xslt stylesheet on the client which supports all small xml payload transformations that is just simply a container for your model.
Either way, flex is great for gui construction and their mxml component model is awesome.
I think wicket is great and I will use it for any application that I know I won't have to support anything other than html, but these are getting lesser and lesser each year.
Ilya
Wow,
I've heard it all now. Justifying the use of the over-engineered, poorly designed, prematurely standardised, JCP endorsed JSF over something simple and to the point like Wicket by suggesting that JSF provides better support for Flex?
What ever happened to keeping things simple? And if you want to use Flex then how about Webwork or Rails?
Talk about being obsessed with your own (JCP) navel!
Paul.
Dude, where in my post did you see a mention of JSF? I actually advocated no JSF and no Wicket, and simple REST/SOAP based back end that connects to the flex front end. Flex effectively replaces the component based server side frameworks, with a stateful component based client framework.
Ilya
|
|
|
Message #234062
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Don't get the comparison
* Wicket components are very easy to write. I find a component like the af:chooseColor funny rather than useful. If you need such a component, you can write one in an hour or two with Wicket and have exactly what you need.
Eelco,
The argument that writing similar component in Wicket would be so easy you could achieve it in a couple of hours doesn't hold much water to me in this context. Logically speaking, someone using JSF could save a couple of hours because the component exist already. Imagine being a consultant charging 90 euros an hour. A company could save a fine hundreds of euros with JSF, right?
That holds true if and only if that component does exactly what you want and has the L&F you need or that this is easily customizable. Also, take into account that JSF components typically are configured using string parameters, whereas Wicket components can be configured using any kinds of objects and are often customized by e.g. extending them and overriding a method. It's much easier to create a layer of in-between (abstract) components so that if the more specialed doesn't exactly do what you need, you can look at the parent and see whether you can use that with a bit of filling the gaps.
Parameterizing a component using an object is very powerful; the more ways you have for customizing a component, the more useful pre-built components become.
However, requiring a user to pass in an object means defining an interface or abstract object class for the user to implement; that's a lot of overhead, especially when usually you just want the user to define one or two methods.
Also, because the custom behavior typically needs to access data in the caller's context, the user will usually want to pass an instantiation of an inner class he created.
Rather than customizing pre-built components by passing in objects, I usually found myself creating lots of anonymous subclasses of Wicket components, each of which overrode one or two component methods -- with the overriding methods accessing variables in the outer class' namespace. But this doesn't seem to be a very intuitive approach to teach a web developer who's had maybe one Java programming course.
I suspect that if Java ever gets a really good closure construct, the Wicket API could take advantage of that to make sophisticated component re-use much more understandable. Have any of the Wicket framework developers discussed the use of closures in Wicket programming?
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
