|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 59
Messages: 59
Messages: 59
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Shashank Tiwari: JSF in 2007
Shashank Tiwari, on OnJava's "JSF in 2007," is asking if JSF will be a leader and a technology of choice for 2007.SF came at a time when JSP and similar technologies were popular among web application developers. JSF tried to bring the learnings from desktop client UI development to the web. It initiated the possibility of creation of reusable widgets and controls. It provided a sophisticated event model and provided effective management of the round-trip request response cycle.
However, JSF for a while was merely a framework. As implementations and interpretations emerged, the world had moved miles ahead and AJAX had conquered the web2.0 client UI space. Then came the paradigm that AJAX with JSF was not only possible but also a best practice and a way to get the best of both worlds - AJAX and Java together. While many Java developers adopted this paradigm and the followers are growing, its current form with AJAX does appear like a strategy in hindsight and an afterthought.
Some frameworks like JBoss Seam and Apache Shale have provided the missing pieces in the JSF puzzle and commercial vendors have come up with multiple implementations and IDE support. However, the Java camp still looks a little confused about the future of the UI technology. I am positive many people would comment aggressively against this remark and many may even try and justify the contrary, but please remember that this is only my opinion and I am an ardent Java fan and I do believe what I am saying here. I would be happy to hear convincing arguments that disprove me.
So far whatever I have said it pretty much the past, but what about the future. What would JSF be like in 2007 or will there be a new J* UI technology that would replace it or will Java Applets reincarnates flourish or will we keep guessing about it all year long? What do you think about his statement that "the Java camp still looks a little confused about the future of the UI technology"? JSF has a lot of capability for integration; is this a sign that JSF isn't sufficient, or that it's the unifying technology for the future?
|
|
|
Message #224824
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Shashank Tiwari: JSF in 2007
my primary problem with JSF was templating and reuse so i thought that it will still suck but with the release of Facelets i think my problems gone
seam is a really good idea,and a good implementation but it is miss several things: integration with spring(real integration) and its nature make it intrusive,actually very intrusive when u use it in real application
apache shale is'nt catching up,however it integrate several good ideas but it still cannot be considered a community standard as struts was,i think that is because it over complicate things(compare facelets with clay)and not providing enough docs(dialogs vs spring web flow)and no real life examples (tiger ext vs seam)
ajax in jsf is shaping up and personally i prefer ajax$jsf as it use the existing libraries,so i think it must b part of the standard (along with facelets) ,icefaces is really good but again they over complicate things(direct to dom) which i think unneccserry complex and degrade performance
as a conclusion i think JSF took a good shape in 2006 and it must standerdise the best in 2007
|
|
|
Message #224827
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Shashank Tiwari: JSF in 2007
seam is a really good idea,and a good implementation but it is miss several things: integration with spring(real integration) and its nature make it intrusive,actually very intrusive
What do you mean that Seam is intrusive? If you mean that it uses contextual bijections to "glue" your code together, I think this a great idea. Sure, some might complain that it doesn't promote a layered-architecture approach, but that doesn't mean the framework enforces such constraint. If you want layers, go ahead and add them. But I'm beginning to agree that for most applications, this might be over-designing. I am happy to cut down the amount of code, and LOC I have to maintain with Seam.
After evaluating JSF for about 3 months, it was barely manageable to develop applications with it and I had to have Shale, and Facelets. And after discovering Seam, I swapped it out with Shale and haven't looked back. I also haven't even bothered looking at any other web frameworks.
On the other issue with Spring integration, you can inject Spring beans into Seam components currently, but not the other way around. But it is stated in the roadmap, full Spring integration will be provided in the next release. I think many users will find this a welcome feature.
i think JSF took a good shape in 2006 and it must standerdise the best in 2007
My prediction is that Seam/JSF will make a lot of noise in 2007.
|
|
|
Message #224830
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Shashank Tiwari: JSF in 2007
"Its current form with AJAX does appear like a strategy in hindsight and an afterthought."
Hmm ... has this guy ever written a phase listener before? Given an understanding of the JSF phases, it's a pretty easy way to inject an AJAX based solution.
I'll cede the point that JSF does not solve everything, but stating that it has some design shortcomings is a bit of a stretch. If anything, JSF gets criticized for being over-designed, not having design afterthoughts ...
On the JSF front, I expect more component libraries to emerge in 2007, and also facelets to become mainstream. Once that occurs, the JSF offerings will become pretty enticing, with some very good commercial and open source offerings.
However, I still think there is room for GWT as Google does a solid job in executing with their vision. It's hard to ignore Google at anything they do ...
Joe Pardi
dotJ Software
http://www.dotjonline.com
|
|
|
Message #224836
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF version of Swing
To me the existing built-in JSF components are like AWT and the next big thing could be JSF Swing set.
|
|
|
Message #224839
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Shashank Tiwari: JSF in 2007
I agree with Joe.
And I think the JSF - GWT integration is really interesting and I'd like it if that project took off.
|
|
|
Message #224843
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF is too sophisticated
To me, JSF is too sophisticated. After all, it is designed with page-based in mind. If you like Swing, take a look at Echo2, though I'd rather recommend ZK for its amazing simplicity.
|
|
|
Message #224848
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF is too sophisticated
To me, JSF is too sophisticated.
thats nicely said and i agree. I have been doing a lot in JSF lately for my last assignment and it sure is an awfull lot better then struts but it is to damn harsh to get stuff done. And what is this dependecy on html? Why is there indeed not yet an SWING or an SWT renderer, because it is not doable. not my 2 cents but just the way it is.
|
|
|
Message #224854
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF is too sophisticated
I agree. If simplicity and productivity are required, JSF is not the best choice. Rather look at Wicket, and maybe Tapestry.
What I was really dismayed about is the taglib API docs. Even the simplest of all tags, f:verbatim, shows what I mean (and this is by far not the worst example):
Create and register a child UIOutput component associated with the closest parent UIComponent custom action, which renders nested body content
Even after using the tag and reading this for the umpteenth time I still cannot make sense of it..
|
|
|
Message #224857
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF is too sophisticated
and another example of a typical API idiosyncrasy:
the javadocs for the javax.faces.convert.Converter interface state that both methods may receive null values as parameters, and they also prescribe exactly how those values must be handled. This leads to potentially thousand-fold redundant repetition of code like:
if(value == null) return null;
|
|
|
Message #224858
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF is too sophisticated
And what is this dependecy on html? Why is there indeed not yet an SWING or an SWT renderer, because it is not doable. not my 2 cents but just the way it is.
What dependency on html? JSF can render to all kinds of things - WML, XUL, SVG, even to Telnet.
And I would not bet that JSF to Swing or SWT was not doable.
|
|
|
Message #224862
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF is too sophisticated
I think I will repost my comment from oreillynet.
I disagree with the very first Shashank's statement. JSF came definitely at the right time, but it is the wrong product. It has much too high level of abstraction, therefore it is too complex and full of bugs (consequence of complexity). Technologically, it gets beaten by more mature component based frameworks like Tapestry and by more elegantly disigned like Wicket (my current favorite).
JSF design goals were to generate income for consultants, tool vendors, component vendors and consultants, not to facilitate the developers job.
As for the AJAX - it is actually an orthogonal technology and can be integrated (and is integrated) with any web framework.
By the way, the only way to make JSF usable is to use Facelets as ViewHandler, but it is not yet the standard part of JSF. And is also less mature then the other competitors. It looks like a good patch to the bad product.
|
|
|
Message #224864
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF is too sophisticated
JSF design goals were to generate income for consultants, tool vendors, component vendors and consultants, not to facilitate the developers job.
Because having a good range of tools, a large and competitive market for components and extensions, and different implementations of JSF competing on features and quality in no way facilitates the developers job, does it?
As for the AJAX - it is actually an orthogonal technology and can be integrated (and is integrated) with any web framework.
Yes, but it integrates largely transparently with JSF, because of the high level of abstraction you so dislike.
By the way, the only way to make JSF usable is to use Facelets as ViewHandler, but it is not yet the standard part of JSF. And is also less mature then the other competitors. It looks like a good patch to the bad product.
On the contrary, Facelets is not a patch. It is an extension. JSF was designed to allow and encourage such extensions, and to allow different extensions to work at the same time. The reason why facelets is possible is because of the high level of abstraction. This is a sign of a well-designed specification.
|
|
|
Message #224865
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF & Facelets
On the contrary, Facelets is not a patch. It is an extension. JSF was designed to allow and encourage such extensions, and to allow different extensions to work at the same time. The reason why facelets is possible is because of the high level of abstraction. This is a sign of a well-designed specification.
the end result is, however, that you need to put together several "frameworks" (each with its own quirks) to make JSF usable - namely JSF, Facelets and Shale. With Wicket (just to mention one example) you get everything out of the box.
I think one problem with JSF is that it was designed by an isolated group without the constant feedback and refinement of a vibrant OSS community. We have almost a decade of investigation in the field of web frameworks behind us, and I am doubtful whether JSF is the candidate to sum all that up to a final conclusion.
|
|
|
Message #224867
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
On the contrary, Facelets is not a patch. It is an extension. JSF was designed to allow and encourage such extensions, and to allow different extensions to work at the same time. The reason why facelets is possible is because of the high level of abstraction. This is a sign of a well-designed specification.
the end result is, however, that you need to put together several "frameworks" (each with its own quirks) to make JSF usable - namely JSF, Facelets and Shale. With Wicket (just to mention one example) you get everything out of the box.
You don't get all you get with JSF out of the box. No large component market. No ability to use visual tools. No ability to render to many different client-side architectures. No competing implementations.
Also, it is something of an exaggeration to say that you need facelets and other extensions just to make JSF usable. Facelets means I don't have to use JSP, which is nice, but not essential. I have found use of standard JSF along with a good set of components like those from MyFaces is enough to get most things done.
I think one problem with JSF is that it was designed by an isolated group without the constant feedback and refinement of a vibrant OSS community. We have almost a decade of investigation in the field of web frameworks behind us, and I am doubtful whether JSF is the candidate to sum all that up to a final conclusion.
Perhaps not, but in many ways (listed above) it far exceeds what many supposedly vibrant OSS communities have come up with. There tends to be a 'if we don't use it, you won't need it' attitude with many OSS projects, which is why web frameworks tend not to consider tooling or extensions, and tend to stick to plain old HTML.
JSF should be able to protect investment because of its wide scope and extensibility.
|
|
|
Message #224868
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
>the end result is, however, that you need to put together several "frameworks" (each with its own quirks) to make JSF usable - namely JSF, Facelets and Shale.
This is called progress, and it's more than usable IMO once you have all the necessary components. I don't know about you, but I didn't expect everything to be perfect. Sure, JSF in its current state is somewhat disappointing, but I'll be even more disappointed if they didn't include a lot of the enhancements put forth by these additional add-ons in the next revision spec. I'm guessing here, but there was a reason why the JSF spec allows numerous hook-ins, especially with Phase Listeners. Seam, IceFaces, Facelets, Shale, Ajax4jsf, etc. were created to complement the spec. I agree with the previous poster that this is a strength of the JSF spec, and it is well designed. And no, Wicket, nor any other web frameworks comes with ALL the problems solved out of the box.
|
|
|
Message #224876
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
ok, right, figuratively spoken a patch, not literally.
To the large components market... I don't need big fat components with 100 configuration parameters, that at the end still don't provide what my customer needs. I want the possibility to easily design my custom components that do exactly what I need! I don't have this possibility with standard JSF, only with Facelets, and it is still less handy to use than Wicket or Tapestry.
I do not want different implementations for my project, only one that is good.
And I want my application to render to HTML only at the moment. And I bet you will not be able to provide me a success story of a JSF application that renders to different devices at the same time. This possibility is just a pure fiction.
|
|
|
Message #224877
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
all this talk about imperfections, remedy by tools and waiting for the next version reminds me of the early days of EJB entity beans. Also then, we already had well-proven solutions to the relational persistence problem (toplink ORM exists since the mid-90s), yet the J2EE spec presented us with something that I will not spend words on. I suffices to say that 6 years later entity beans have finally become what they should have been all the time, by adopting practices from existing OSS (and commercial) products (let me however add that I do think JSF is better than EJB 1 entity beans).
|
|
|
Message #224883
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
ok, right, figuratively spoken a patch, not literally.
To the large components market... I don't need big fat components with 100 configuration parameters, that at the end still don't provide what my customer needs. I want the possibility to easily design my custom components that do exactly what I need! I don't have this possibility with standard JSF, only with Facelets, and it is still less handy to use than Wicket or Tapestry.
Firstly, of course you have the ability to design your own custom components in standard JSF. Secondly, if you don't like big fat components, choose from the large number of components that are out there that aren't.
Why re-invent the wheel when there probably a JSF component out there that does pretty much what you want?
I do not want different implementations for my project, only one that is good.
One of the advantages of having different competing implementations is that it allows you to choose the best for your project, and move to another if it doesn't suit you.
As an example, a while back I was not satisfied with the state of the JSF RI, so I moved to MyFaces.
And I want my application to render to HTML only at the moment.
So only use the HTML rendering.
And I bet you will not be able to provide me a success story of a JSF application that renders to different devices at the same time. This possibility is just a pure fiction.
It is not pure fiction:
http://www.nyoug.org/Presentations/2005/20050929jsf.pdf
Check out page 37 - it shows the same JSF page designed with ADF components (now open source) rendered well on PalmOS, a standard HTML browser, Telnet and an IM client.
|
|
|
Message #224886
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
all this talk about imperfections, remedy by tools and waiting for the next version reminds me of the early days of EJB entity beans. Also then, we already had well-proven solutions to the relational persistence problem (toplink ORM exists since the mid-90s), yet the J2EE spec presented us with something that I will not spend words on. I suffices to say that 6 years later entity beans have finally become what they should have been all the time, by adopting practices from existing OSS (and commercial) products (let me however add that I do think JSF is better than EJB 1 entity beans).
It is nothing like the same.
First, JSF does not need tools to remedy things (I never use it with tools), it simply allows the use of tools if desired. It isn't a fix - it is a choice.
Secondly, there are no alternative well-proven alternatives that provide the range of multi-rendering that JSF does. There is no 'TopLink' equivalent. In a way, that is good, because JSF could start from scratch, without having to be 'retro-fitted' onto existing solutions.
Thirdly, the extension abilities JSF aren't about promising future fixes, they allow all sorts of interesting functionality to be plugged in right now, like Seam. This extensibility was designed in from the start.
|
|
|
Message #224888
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
Firstly, of course you have the ability to design your own custom components in standard JSF.
Of course, it is possible, Steve, but it is pain in the ass, (ever did it yourself?) and everybody knows it, that's why Jacob Hookom invented Facelets!
Secondly, if you don't like big fat components, choose from the large number of components that are out there that aren't.
Why re-invent the wheel when there probably a JSF component out there that does pretty much what you want?
I think this blog just says it all:
http://chillenious.wordpress.com/2006/05/12/a-word-about-custom-components/
One of the advantages of having different competing implementations is that it allows you to choose the best for your project, and move to another if it doesn't suit you.
As an example, a while back I was not satisfied with the state of the JSF RI, so I moved to MyFaces.
I don't think that is done very often in reality. Once you choose an implementation, you stick to it.
And I bet you will not be able to provide me a success story of a JSF application that renders to different devices at the same time. This possibility is just a pure fiction.
It is not pure fiction:
http://www.nyoug.org/Presentations/2005/20050929jsf.pdf
Check out page 37 - it shows the same JSF page designed with ADF components (now open source) rendered well on PalmOS, a standard HTML browser, Telnet and an IM client.
Thanks, Steve, an interesting presentation, but I was speaking about a real-world application, not a demo. ;)
Usually, an HTML application is pretty different (from the UI point of view) from PalmOS or Telnet one.
|
|
|
Message #224891
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF multirendering
Steve, your emphasis on multi-rendering and extensibility reminds me of the old JDO vs. EJB3 discussions. Was it not even you who argued in favor of JDOs capability to map objects to different data store architectures?
And again, the reply is pretty much the same: I am not willing to pay significantly for a feature that I wont be using in 95% of the cases. Right now, I need a framework that offers optimal support for creating HTML-based web apps. I dont care the least bit for Swing, WAP or any of the other stuff.
There are very good solutions out there for this task, and they are what I measure JSF against, period.
peace, as Cameron says
Christian
|
|
|
Message #224893
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
Firstly, of course you have the ability to design your own custom components in standard JSF.
Of course, it is possible, Steve, but it is pain in the ass, (ever did it yourself?) and everybody knows it, that's why Jacob Hookom invented Facelets!
The difficulty of creating components for JSF is vastly overstated, especially if you only want to create for one rendering type:
http://www-128.ibm.com/developerworks/java/library/j-jsf4/
It isn't trivial, but considering the power of JSF's rendering, it is not that bad.
As for being 'a pain in the ass' - hey, since when did developers get so lazy? I remember when doing something even slightly technical would have been considered fun :)
One of reasons for facelets was to simplify the creation of components, but there were many others, such as the ability to use templates, to use HTML more directly and to remove the need for JSP.
I think this blog just says it all:
It is factually wrong in places. Quality JSF components are rarely commercial now. The Oracle ADF components are high quality, and are open source. The same is true of ICEFaces.
Of course, having the source, you can customise them.
I don't think that is done very often in reality. Once you choose an implementation, you stick to it.
Well, I beg to differ. I have switched implementations of JSF, and I have heard of others who have too.
Thanks, Steve, an interesting presentation, but I was speaking about a real-world application, not a demo. ;)
Usually, an HTML application is pretty different (from the UI point of view) from PalmOS or Telnet one.
So you have gone from saying it is impossible, to wanting a real-world example. OK - Oracle developed the JSF to telnet rendering because specific clients needed it for real life use - it was not simply an academic exercise! Check the oracle forums and you will see that people are really doing this.
Of course an HTML application is different from other rendering situations. Although it can be done, it would be rare for someone to expect the same page to render on all those technologies. That is not the point. It means that you can have the same infrastructure, and re-use the same components and even some of the same forms.
The claim that multiple rendering is not useful because the same page can't always be presented on all technologies is a surprisingly common "straw man" argument against JSF.
|
|
|
Message #224895
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF multirendering
Steve, your emphasis on multi-rendering and extensibility reminds me of the old JDO vs. EJB3 discussions. Was it not even you who argued in favor of JDOs capability to map objects to different data store architectures?
Me, and I am happy to defend that point of view. It is why I have stuck with JDO and there have been real advantages in doing so. and I see exciting developments, like JPOX support for XML and db4o. I currently use Kodo, as I have a use case for quering LDAP with JDO.
And again, the reply is pretty much the same: I am not willing to pay significantly for a feature that I wont be using in 95% of the cases. Right now, I need a framework that offers optimal support for creating HTML-based web apps. I dont care the least bit for Swing, WAP or any of the other stuff.
There are very good solutions out there for this task, and they are what I measure JSF against, period.
peace, as Cameron says
Christian
You still haven't explained why you think you are paying signficantly. I find the component-based architecture of JSF to be a significant saving of time and money, not a source of hassle, as I make considerable use of existing component libraries and extensions.
The only issue with support of different rendering technologies is the complexity of designing components yourself, but if you want to stick with HTML, simply use facelets. JSF with facelets doesn't make you 'pay' - it is rich and simple to use.
And, to badly paraphrase Terry Pratchett, things with a probability of a few percent turn up all the time...
For me, Java has always been significantly about portability. To use a server-side technology that rendered only HTML would feel wrong to me, just like using a persistence technology that was only relational. To me, this is against the philosophy of Java. But maybe I am just wierd in this regard.
|
|
|
Message #224905
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
difficulty of creating components for JSF is vastly overstated, especially if you only want to create for one rendering type:
http://www-128.ibm.com/developerworks/java/library/j-jsf4/
It isn't trivial, but considering the power of JSF's rendering, it is not that bad.
As for being 'a pain in the ass' - hey, since when did developers get so lazy? I remember when doing something even slightly technical would have been considered fun :)
I don't know about you Steve, but I have a wife and kids. It may be considered as fun trying for 3 days to get a radio button to work in a table, but... I also need some other kind of fun in my life. Some other people that I know had other problems with JSF, somehow noone was really fascinated. And I don't think it was because they were lazy or stupid.
The real reason is as already pointed out, the complexity, the high level of abstraction. Such abstractions necessarily leak and will leak for quite a while. Therefore one still need some good external consultants for JSF projects, like you (assuming you are good) but they are quite expensive (aren't you? ;-)). And they are also not so easy to find, at the moment, some guys just pretend to be good.
Ok, the upsides of that level of abstraction are, as you mentioned, the extensibility, the power of JSF's rendering and so on. But I agree with other guys here that the price to pay for some features I might need in the future is rather too high.
Now, after thinking about it all, it seems to me that JSF is not only the wrong product but also at the wrong time ;)
The alternatives (Wicket, Tapestry) have just the right level of abstraction and let me implement just what I need right now in much shorter time and without the help of expensive consultants, expensive tools and third-party components of doubtful quality.
|
|
|
Message #224901
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF multirendering
For me, Java has always been significantly about portability. To use a server-side technology that rendered only HTML would feel wrong to me, just like using a persistence technology that was only relational. To me, this is against the philosophy of Java. But maybe I am just wierd in this regard.
Yup. You're weird. The TSS posters who disagree with you represent the gold standard of normalcy.
|
|
|
Message #224903
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
GWT is totally different from JSF
GWT is a major step forward from webserver-heavy, server-side generation of HTML like all Java web frameworks, of which JSF is the largest and most cumbersome, and therefore "best".
AJAX enables an architecture where the client state can almost totally be stored on the client, where page templating and generation can be performed on the client, and overloaded web servers that have to perform page generation work are stripped down to the basics of xml messaging (hopefully stateless to remove session overhead and timeout from the servers, although paged data sets and caching make that difficult) and static or near-static page serving.
The primary problem with such a suggestion was the prospect of doing it all in JavaScript and browser dependency.
Then came GWT: code in Java, translate to ajax/javascript.
Constrast with JSF, where you have a heavy, multi-layered, abstracted framework where hundreds of thousands of classes instantiate, lazily compile, JIT, in java, facelets, templating languages, plus session tracking overhead, making them lumbering beheamoths with dozens of load-balanced failover servers that can handle maybe 100-200 users at once.
JSF is a dinosaur. GWT is a revolution. If JSF wants to sprinkle AJAX in its components, fine.
But a GWT-JSF "merge" is a pointless suggestion.
|
|
|
Message #224907
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
I don't know about you Steve, but I have a wife and kids. It may be considered as fun trying for 3 days to get a radio button to work in a table, but... I also need some other kind of fun in my life. Some other people that I know had other problems with JSF, somehow noone was really fascinated. And I don't think it was because they were lazy or stupid.
OK, so I made a silly, throw-away comment. What I was trying to say what that writing a component in pure JSF is not simple, but neither is it that hard. I don't see that a good developer should be put off what what I showed in that article.
I agree that things can be tough to get going, but that can be true of any new approach or framework. I would agree that JSF implementations have had their problems, but...
What I also was trying to say was that there was a time when developers would have found the features of JSF more exciting. I mean, I look at the ability to render to different technologies and that excites me - just think of the possibilities! Has development really got so dull that others don't get enthusiastic about that too?
Also, I have a partner and a mortgage. Part of my job is to advise on technology use. Having had experience of so much 'throw-away' software, and technology choices that have tied companies to single vendors and single products, and single technologies. JSF is not a single vendor product, and neither are the components. Its use is increasing significantly, so it will be around long-term. The ability to render to different current (and most likely many future) technologies protects investements in code, tools and skills.
The real reason is as already pointed out, the complexity, the high level of abstraction. Such abstractions necessarily leak and will leak for quite a while. Therefore one still need some good external consultants for JSF projects, like you (assuming you are good) but they are quite expensive (aren't you? ;-)). And they are also not so easy to find, at the moment, some guys just pretend to be good.
A whole lot of generalising going on there.
I personally know of JSF projects developed by individuals who were novices at JSF - they sat in front of (free) tools and simply designed data-linked forms, and drew up the navigation.
So, you don't need expensive external consultants for all JSF projects, and there was no abstraction leak for these developers - the high level of abstraction meant that they could simply sit in front of GUI tool, and start designing.
Ok, the upsides of that level of abstraction are, as you mentioned, the extensibility, the power of JSF's rendering and so on. But I agree with other guys here that the price to pay for some features I might need in the future is rather too high.
For me, these aren't features I might need in the future, these are features useful in current projects. I am using the ability to choose between different component sets in JSF right now, and I have use cases for parellel rendering of parts of pages in different technologies in current projects.
Now, after thinking about it all, it seems to me that JSF is not only the wrong product but also at the wrong time ;)
The alternatives (Wicket, Tapestry) have just the right level of abstraction and let me implement just what I need right now in much shorter time and without the help of expensive consultants, expensive tools and third-party components of doubtful quality.
Firstly, that is precisely why I use JSF. It is the right level of abstraction for me, and it allows me to save time and money by using components rather than having to implement things myself.
Almost all the tools I know about for JSF are totally free, and I think it is unreasonable to call component sets like ADF and ICEFaces 'of doubtful quality'. That insults a lot of developers who have worked hard to produce good code. There are poor components out there, but also very good sets.
A while back, if you had watched me code, you would have heard me cursing at JSF implementations too. But, things have improved, there are good component sets, and things always appear better with experience. I just found the extensibility and flexibility of JSF so appealing that I was prepared to battle through until I found approaches that worked. And now I see that decision paying off.
|
|
|
Message #224906
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Shashank Tiwari: JSF in 2007
I think these comments are pretty fair. JSF certainly has not been the runaway success Sun was hoping for, uniting the Java web community. Its a complex beastie, which really need good tools support for commercial developers to use.
Technologies like Flex are also providing a very strong alternative to JSF and even GWF.
If you are looking for an very easy to use Java web framework for commercial developers, take a look at Click Framework.
regards Malcolm Edgar
http://click.sourceforge.net
|
|
|
Message #224909
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Shashank Tiwari: JSF in 2007
I think these comments are pretty fair. JSF certainly has not been the runaway success Sun was hoping for, uniting the Java web community.
Does anyone ever expect a runaway success? However, there is little doubt that JSF is finally taking off in a big way.
Its a complex beastie, which really need good tools support for commercial developers to use.
This wasn't even good FUD a year ago, and it is pretty tired now. The internal complexity of JSF is largely hidden, and it does not and has never needed tool support for use by serious commercial developers. It is amazing how frequently the fact that JSF allows tool use gets twisted into 'JSF needs tools'.
|
|
|
Message #224910
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
What I also was trying to say was that there was a time when developers would have found the features of JSF more exciting. I mean, I look at the ability to render to different technologies and that excites me - just think of the possibilities! Has development really got so dull that others don't get enthusiastic about that too?
I will just address this one and then leave it. With the last statement you imply that development is dull for people who dont get enthusiastic about the same stuff as you. That implication is of course wrong.
regards,
Chris
|
|
|
Message #224911
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
I look at the ability to render to different technologies and that excites me - just think of the possibilities! Has development really got so dull that others don't get enthusiastic about that too?
Yes it is dull because it is no fun to develop yet another CRUD application with yet another MVC framework and listen to enthusiastic discussions about wheel reinventions.
What is more frustrating is that folks are _truly_ excited about that and do not even realize that they try to reinvent wheels.
|
|
|
Message #224914
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Shashank Tiwari: JSF in 2007
Technologies like Flex are also providing a very strong alternative to JSF and even GWT.
Flash-based solutions suck because Flash is not an integrated part of any OS or browser. A Flash app running in a browser window is even more ridiculous thing than a crippled 32-bit application running on Windows3.1 through win32s thunk. The splotches of Flash UI, which appear here and there in increasing numbers, do not react properly to keyboard, have fixed size, have fixed-sized fonts, have non-standard widgets, are not integrated with other elements of a page or even with another Flash splotches on the same page, the UI itself is painstakingly slow and juddery, Flash objects are reloaded every time you go forward and back (even Google Finance does that, when you return to a page the stock value graph does not recover the parameters you set before leaving the page).
Leave Flash to what it does best -- annoying ads and video clips. For integration with desktop better look in the direction of Microsoft's XAML/Avalon.
|
|
|
Message #224916
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: GWT is totally different from JSF
I understand GWT as a way to have an abstraction over javascript and clientside vs serverside. I did not see that GWT provides stateful components and templating; which is what JSF does. That's why I think they are a good combination.
Maybe there's a conflict in clientside state vs serverside state. But I don't think you can offload all state to the client since the client is untrusted; you lose control that way.
Btw I'd like to ask all the people who are not interested in the future developments of JSf but want to push other frameworks to go away. Start another thread with a fitting subject.
That way people who are interested in JSF can have a fruitful discussion.
The endless off-topic framework pushing on the serverside is the main reason I don't visit this site a lot anymore.
|
|
|
Message #224922
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
What I also was trying to say was that there was a time when developers would have found the features of JSF more exciting. I mean, I look at the ability to render to different technologies and that excites me - just think of the possibilities! Has development really got so dull that others don't get enthusiastic about that too?
I will just address this one and then leave it. With the last statement you imply that development is dull for people who dont get enthusiastic about the same stuff as you. That implication is of course wrong.
regards,
Chris
No, you are personalising things too much. It is not about what I, alone, get enthusiastic about. All I am saying is that I remember a time when most developers I worked with and came into contact with were like engineers and scientists, and would enthusiastically investigate and evaluate new ideas simply for the sake of learning more. The multi-rendering of JSF is the kind of thing that I can imagine those developers at least wanting to enthusiastically investigate, even if they turn out not to need them.
But I increasingly see new ideas (like JSF multi-rendering) dismissed without even investigation - hand-waved away as 'impossible' or 'not practical' without even research.
|
|
|
Message #224923
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
I look at the ability to render to different technologies and that excites me - just think of the possibilities! Has development really got so dull that others don't get enthusiastic about that too?
Yes it is dull because it is no fun to develop yet another CRUD application with yet another MVC framework and listen to enthusiastic discussions about wheel reinventions.
What is more frustrating is that folks are _truly_ excited about that and do not even realize that they try to reinvent wheels.
What I am trying (and obviously failing) to point out is that JSF is not yet another wheel-reinventing MVC framework. It has features and capabilities beyond most of the alternatives - a huge amount of extensibility, the ability to visually compose GUIs and to use different renderkits.
|
|
|
Message #224933
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: GWT is totally different from JSF
Btw I'd like to ask all the people who are not interested in the future developments of JSf but want to push other frameworks to go away. Start another thread with a fitting subject.
That way people who are interested in JSF can have a fruitful discussion.
The endless off-topic framework pushing on the serverside is the main reason I don't visit this site a lot anymore.
These people represent a significant portion of the Java Web community, perhaps the majority. Without them, all JSF forums will become extremely quiet :-)
|
|
|
Message #224934
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
No ability to use visual tools. No ability to render to many different client-side architectures.
With Wicket you can use any wysiwyg editor, like Dreamweaver.
You don't need drag and drop "visual" tools, you don't need a programmer to put your UI together, just a designer.
Regarding client-side rendering alternatives, you can even render Swing with sprockets...
-----
Gustavo.
|
|
|
Message #224935
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
No ability to use visual tools. No ability to render to many different client-side architectures.
With Wicket you can use any wysiwyg editor, like Dreamweaver.
You don't need drag and drop "visual" tools, you don't need a programmer to put your UI together, just a designer.
Regarding client-side rendering alternatives, you can even render Swing with sprockets...
-----
Gustavo.
And with JSF+Facelets, you can design a page in an HTML editor if you like.
If Wicket can have applications that can transparently (at run-time) detect different client technologies and render appropriately, I would be interested. Is this the case?
|
|
|
Message #224947
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
What I am trying (and obviously failing) to point out is that JSF is not yet another wheel-reinventing MVC framework...
It is not MVC framework of course, but it does not make it less of wheel reinvention, and does not make it round wheel.
IMO it would be OK if JSF was round wheel, we would embrace it as 'standard' wheel and could be reasonably happy. But unfortunately JSF is kind of irregular octagon....
But there is money to be made by making JSF into a regular hexadecagon :)
|
|
|
Message #224952
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
What I am trying (and obviously failing) to point out is that JSF is not yet another wheel-reinventing MVC framework...
It is not MVC framework of course
Yes, actually, it is.
but it does not make it less of wheel reinvention, and does not make it round wheel.
IMO it would be OK if JSF was round wheel, we would embrace it as 'standard' wheel and could be reasonably happy. But unfortunately JSF is kind of irregular octagon....
But there is money to be made by making JSF into a regular hexadecagon :)
Nothing like a detailed discussion of technical issues to further the discussion. And that was certainly nothing like a detailed discussion of technical issues...
|
|
|
Message #224970
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
The method for achieving this in Wicket would not be the same as in JSF, but you should be able to achieve the same effect relatively easily. Since Wicket allows you to serve different markup files as variants or styles of a page, you could detect the client using our built-in feature for that and then use that information to set the style/variant. The result would be that different clients would receive different markup.
I don't know much about JSF, but if I understand the renderers concept correctly, you would do that by providing a component subclass and if you want components to behave differently per-client, you would use the usual UI factory pattern to instantiate the components based on the client.
I have not had a need for any of this, but it should work fine. It's straightforward OO programming and all the usual patterns apply.
|
|
|
Message #224971
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
As far as actually doing multi-client rendering goes, I think Wicket is particularly strong in associating markup variants because a designer can just go rework the page in DreamWeaver for the other device. Where there are small differences in components you can make your component construction conditional. Where there are large differences, you probably would have separate pages anyway. it gets harder for the time being where something like Telnet or WML are concerned because while the architecture supports this kind of thing, the actual component classes for other markup languages would have to be written. At the present time, Wicket only implements HTML markup.
|
|
|
Message #224975
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: GWT is totally different from JSF
GWT is a major step forward from webserver-heavy, server-side generation of HTML like all Java web frameworks, of which JSF is the largest and most cumbersome, and therefore "best".
AJAX enables an architecture where the client state can almost totally be stored on the client, where page templating and generation can be performed on the client, and overloaded web servers that have to perform page generation work are stripped down to the basics of xml messaging (hopefully stateless to remove session overhead and timeout from the servers, although paged data sets and caching make that difficult) and static or near-static page serving.
The primary problem with such a suggestion was the prospect of doing it all in JavaScript and browser dependency.
Then came GWT: code in Java, translate to ajax/javascript.
Constrast with JSF, where you have a heavy, multi-layered, abstracted framework where hundreds of thousands of classes instantiate, lazily compile, JIT, in java, facelets, templating languages, plus session tracking overhead, making them lumbering beheamoths with dozens of load-balanced failover servers that can handle maybe 100-200 users at once.
JSF is a dinosaur. GWT is a revolution. If JSF wants to sprinkle AJAX in its components, fine.
But a GWT-JSF "merge" is a pointless suggestion.
Totally agreed. I would even make it bolder: with a totally client side ajaxy solution there's no need for any fat server side component based web framework such as JSF or whatever, because javascript based high level frameworks such as YUI or GWT are nice! Who needs a server side component framework when everything is already in the client side and in a nice and high level fashion?
Ara.
|
|
|
Message #224991
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
Hi Steve,
I think you are polarising what I believe to be a much needed discussion. The issue is how do you create good OO APIs. There are countless papers out there that support the idea that such APIs are best when they emerge over time from real world applications. This way all the features scratch a real world itch, and uneeded complexity is avoided by not adding infrastrure speculatively for features you think you may need in the future. This is the basis of the refactoring argument and YAGNI. The economics of YAGNI are proven IMO and there are many sources that testify to this on the web.
Before responding, this subject is not black and white. To apply Yagni and emergent design well requires judgement. You tend to fall into the trap of two valued thinking. This can limit useful debate IMO. I believe this debate is long overdue and one of the reason why I believe object technology is mostly misunderstood.
So please try to see the plurality of ideas here. BTW I am posting from a PDA which proves that you do not need JSF to render to different devices - the simplest thing that can work?
Paul.
|
|
|
Message #224992
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: GWT is totally different from JSF
Who needs a server side component framework when everything is already in the client side and in a nice and high level fashion?
Ara.
Framework (or better - components) may help you to create that client side code
Dmitry
http://www.servletsuite.com
|
|
|
Message #224993
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
The issue is how do you create good OO APIs. There are countless papers out there that support the idea that such APIs are best when they emerge over time from real world applications. This way all the features scratch a real world itch, and uneeded complexity is avoided by not adding infrastrure speculatively for features you think you may need in the future. This is the basis of the refactoring argument and YAGNI. The economics of YAGNI are proven IMO and there are many sources that testify to this on the web.
Before responding, this subject is not black and white. To apply Yagni and emergent design well requires judgement. You tend to fall into the trap of two valued thinking. This can limit useful debate IMO. I believe this debate is long overdue and one of the reason why I believe object technology is mostly misunderstood.
So please try to see the plurality of ideas here. BTW I am posting from a PDA which proves that you do not need JSF to render to different devices - the simplest thing that can work?
Paul.
I simply don't recognise your description of how I am discussing this, and I think the view you present about APIs is one that limits imagination and innovation.
Also, if you read back through the discussion, you will see that JSF was designed precisely to scratch real world itches - to open up a true market for web components (an approach that had been proved to be very successful for both developers and vendors in previous environments like VB and Delphi) and to design a server-side UI system that was general, and not tied in to just HTML - and this is a real requirement for many projects. In fact, I have this requirement - this 'itch' for current projects I am working on.
And we have already been through the 'yagni' argument, on previous threads. There seems to me to be a common mistake when talking about it, which is to assume that it implies that one should not use a powerful API or product because one might not use all the features. If YAGNI is adopted should be about what the developer has to do in a specific project, not about what the developer uses. Using a rich framework is only an issue if the features of that framework negatively impact the work of the developer. Some would say that the multiple-rendering capabilities of JSF does indeed impact the developer in negative ways because of the extra complexity involved in developing components. I don't think this is much of an impact, but that is one of the things we have been debating here - it is not a 'black and white' matter.
In fact, one could even put the case that choosing a web framework that is somewhat easier to develop components in (as against relying on what is now rich sets of free libraries) because you might want to do that at some point is itself going against YAGNI! I am not saying that - but it shows how YAGNI (You Ain't Going To Need It) is not that helpful for this kind of discussion, as it can mean pretty much what you want it to.
I have no idea why you think I am not seeing the plurality of ideas, on the contrary, I have been arguing that this is what some others need to do, as illustrated by the frequent comments on threads about JSF that multiple rendering is some sort of hypothetical ideal that is impractical. That suggests a rather closed-minded attitude to new ideas to me.
BTW I am posting from a PDA which proves that you do not need JSF to render to different devices - the simplest thing that can work?
That is not the type of rendering to different devices that I am talking about. It is the ability to have the same components (or even the same subset of a page) automatically render to, say, HTML, WML, XUL, or PDF. It is interesting that Wicket has the possibility of doing this as well. It supports my view that this is an exciting and useful feature of server-side GUI frameworks.
|
|
|
Message #224998
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
It supports my view that this is an exciting and useful feature of server-side GUI frameworks.
Actually, I am going to make a prediction. I think that in a few years, the ability to render to different presentation technologies will have gone through the following stages:
1. Dismissed by many as not possible.
2. Recognised as possible, but dismissed as irrelevant.
3. Increasingly found to be useful.
4. Considered to be of major benefit by a significant number of developers.
|
|
|
Message #224999
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
hi Steve
You have totally missed the point of what I'm saying. I suggest that you read "language in thought and action" by Hawakawa. Two valued thinking versus plural thinking sees the world as black and white, good and bad, and does not allow for anything else in between, such as yagni is a powerful principle when applied well. This more complex analysis allows for a plurality of outcomes beyond two. You seem to struggle with this plurality of possibilities, but alas this is often the case in the real world.
With regards to YAGNI and APIs, I am talking about applying the YAGNI principle to the API itself. As for the meaning of YAGNI, the principle is pretty clear to those who practice it.
Your last comment on rendering just shows the gulf in our thinking. I am taking the end user perspective, YAGNI in this context, places no limits on product vision and innovation, hence my point that the user problem of rendering to multiple devices does not nessesitate the technical feature in JSF you describe.
I think like others I'll give up, but I still belief that this is a useful discussion for the Java community to have.
Paul.
|
|
|
Message #225001
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
hi Steve
You have totally missed the point of what I'm saying. I suggest that you read "language in thought and action" by Hawakawa. Two valued thinking versus plural thinking sees the world as black and white, good and bad, and does not allow for anything else in between, such as yagni is a powerful principle when applied well. This more complex analysis allows for a plurality of outcomes beyond two. You seem to struggle with this plurality of possibilities, but alas this is often the case in the real world.
Ouch.
I think you are confusing disagreement with your point of view with lack of understanding.
With regards to YAGNI and APIs, I am talking about applying the YAGNI principle to the API itself.
Which, as I explained, is of no relevance. Let me try again with an example. Hibernate is a great product that allows very agile development. But, it is also a large product which allows many different approaches. However, it would be absurd to dismiss the use of Hibernate "because there is so much 'You Aint Gonna Need' for this project". Applying YAGNI to APIs is largely inappropriate. All that matters is - will using whatever fraction of the API is required help with development?
I would use JSF even if it didn't have rendering to different client types - I like the component approach and I like the extensibility (which I have made use of) and I like the fact that there are different implementations (I have made use of that as well). I have used JSF for projects which were only HTML, and, at least for me, the extra features of JSF added no overhead to that project so, as with Hibernate, to have dismissed JSF because of them would have been unwise.
As for the meaning of YAGNI, the principle is pretty clear to those who practice it.
No, it isn't - you are over-simplifying. YAGNI has always been the subject of controversy, with much debate over how dogmatically it should be applied.
Your last comment on rendering just shows the gulf in our thinking. I am taking the end user perspective, YAGNI in this context, places no limits on product vision and innovation, hence my point that the user problem of rendering to multiple devices does not nessesitate the technical feature in JSF you describe.
You are misunderstanding here again. JSF is not about rendering to multiple devices, but rendering using different presentation technologies. I have given a specific use case that I need in a current project - rendering to HTML, WML and PDF. To do that with the same component set and API certainly does necessitate technical features as found in JSF. This is not a user problem, it is a developer problem - the developer has to choose the approach that can meet this requirement.
I think like others I'll give up, but I still belief that this is a useful discussion for the Java community to have.
Paul.
It is a discussion that has already been had many times over, and I believe that things are moving the way of component-based systems and flexibility. JSF in particular is showing a substantial take-up. We shall have to see whether or not it dominates long term, but for all its quirks and faults, it will have had a positive influence.
|
|
|
Message #225002
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
It supports my view that this is an exciting and useful feature of server-side GUI frameworks.
Actually, I am going to make a prediction. I think that in a few years, the ability to render to different presentation technologies will have gone through the following stages:
1. Dismissed by many as not possible.
2. Recognised as possible, but dismissed as irrelevant.
3. Increasingly found to be useful.
4. Considered to be of major benefit by a significant number of developers.
Maybe. But I would be one of those who is dismissing it right now. I think it is important that a framework can easily detect client capabilities and be able to render to different formats. However, unless you're talking about plain non-interactive documents, I don't think there is a big demand for the ability to render the same components to different formats transparently. Imo, you typically want some controlled transformation that you - the user - can easily change on a component level. A good example imo are the frameworks that render for both HTML and e.g. Swing. I have yet to see one that generates truely decent interfaces (decent as in good looking to non techies) for both formats.
Note however, that I'm not dismissing the multi-render kit ability as total crap. But it looks like it came with a price. In fact, in the early stages of developing Wicket we discussed whether we wanted separate renderers for components. But we decided against this as we didn't think it was worth the added complexity. It's not JSF's greatest flaw either. Imho there are more serious ones, which all come down to the decision to follow the JSP/ scripting route rather than a pure Java based approach. But that's an opinion you may or may not agree with; good thing there is free choice (though a sad thing that JSF was pushed as a standard upfront rather than letting 'the market' decide).
Re the original topic: I think JSF will grow in 2007. Component based development is superior to what - amazingly - still seems today's standard: 'web mvc' (Struts, SpringMVC etc). Though a client-based approach like GWT is a good choice for many projects as well. Good thing about GWT is that it is basically a component based solution as well. Unfortunately, many people seem to have find the new golden hammer in GWT and are turning blind for any disadvantages it might have.
|
|
|
Message #225003
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: GWT is totally different from JSF
GWT is a major step forward from webserver-heavy, server-side generation of HTML like all Java web frameworks, of which JSF is the largest and most cumbersome, and therefore "best".
AJAX enables an architecture where the client state can almost totally be stored on the client, where page templating and generation can be performed on the client, and overloaded web servers that have to perform page generation work are stripped down to the basics of xml messaging (hopefully stateless to remove session overhead and timeout from the servers, although paged data sets and caching make that difficult) and static or near-static page serving.
The primary problem with such a suggestion was the prospect of doing it all in JavaScript and browser dependency.
Then came GWT: code in Java, translate to ajax/javascript.
Constrast with JSF, where you have a heavy, multi-layered, abstracted framework where hundreds of thousands of classes instantiate, lazily compile, JIT, in java, facelets, templating languages, plus session tracking overhead, making them lumbering beheamoths with dozens of load-balanced failover servers that can handle maybe 100-200 users at once.
JSF is a dinosaur. GWT is a revolution. If JSF wants to sprinkle AJAX in its components, fine.
But a GWT-JSF "merge" is a pointless suggestion.
Totally agreed. I would even make it bolder: with a totally client side ajaxy solution there's no need for any fat server side component based web framework such as JSF or whatever, because javascript based high level frameworks such as YUI or GWT are nice! Who needs a server side component framework when everything is already in the client side and in a nice and high level fashion?
Ara.
It's the popular thing to call 'server side' frameworks 'fat'. But why? On what exactly do you base that? And is sending 200kb to your clients, and having 5 client-server calls for what you otherwise would do in one call not 'fat'? It all depends/ the world is not black and white.
YUI and GWT are quite different. GWT actually helps with your programming model up to integration with non-UI layers. YUI less so (but it is a nice widget set to be sure).
Also, when working with a complex domain model, it is often easier and more efficient (because of locality) to process a whole page at once. Also, with a server side framework you can use any object directly (e.g. your Hibernate objects), while with a framework like GWT, you'll have to use DTOs all over the place. Finally, there are a zillion other features you can compare amongst frameworks, like how well localization is supported, what kind of page composition is supported, whether layout managers work for you (personally I hate them) or you want to work with markup directly, etc, etc.
What I'm saying is that GWT is a nice framework, but it has good competition from other frameworks, each having their own pros and conts. You might as well seriously look into that and see what fits your projects best.
|
|
|
Message #225004
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
However, unless you're talking about plain non-interactive documents, I don't think there is a big demand for the ability to render the same components to different formats transparently. Imo, you typically want some controlled transformation that you - the user - can easily change on a component level. A good example imo are the frameworks that render for both HTML and e.g. Swing. I have yet to see one that generates truely decent interfaces (decent as in good looking to non techies) for both formats.
A fair comment, but I have a feeling that the demand will increase. I have a demand, but it is indeed primarily (although not entirely) for non-interactive pages. However, I can see the possibility for significant demand, even for interactive pages, especially with the new UI technologies of Vista.
Note however, that I'm not dismissing the multi-render kit ability as total crap. But it looks like it came with a price. In fact, in the early stages of developing Wicket we discussed whether we wanted separate renderers for components. But we decided against this as we didn't think it was worth the added complexity.
I am still not sure exactly what the price is. It certainly adds complexity for the implementors of JSF, but does it really add that much complexity for the developer using JSF? I think, on balance, it doesn't. My long experience of developing using component-based GUIs is that when there is a good supply of components (as is certainly now the case with JSF), then the developer rarely ends up writing components, so does not often face the complexity. Of course, others disagree with me, as they may have worked in projects where components have had to be developed, but I am talking generally.
Also, surely having renderers for components does have its advantages - it allows for the addition of functionality at the level of components, which is convenient for both component producers and consumers?
It's not JSF's greatest flaw either. Imho there are more serious ones, which all come down to the decision to follow the JSP/ scripting route rather than a pure Java based approach. But that's an opinion you may or may not agree with; good thing there is free choice (though a sad thing that JSF was pushed as a standard upfront rather than letting 'the market' decide).
But the flexibility of JSF means that you don't have to follow the JSP/Scripting route - well, at least not in the way that JSF provides things by default. Facelets is just one example of how you can replace things. I am not quite sure that going down the JSP route (at least for the default use of JSF) was a poor decision - after all, it was a well-established technology. What was certainly poor was the incompatibilities with JSP.
Re the original topic: I think JSF will grow in 2007. Component based development is superior to what - amazingly - still seems today's standard: 'web mvc' (Struts, SpringMVC etc). Though a client-based approach like GWT is a good choice for many projects as well. Good thing about GWT is that it is basically a component based solution as well. Unfortunately, many people seem to have find the new golden hammer in GWT and are turning blind for any disadvantages it might have.
I definitely agree with this last point.
One thing this thread has done is to convince me that I need to take a much deeper look at Wicket.
|
|
|
Message #225011
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
My long experience of developing using component-based GUIs is that when there is a good supply of components (as is certainly now the case with JSF), then the developer rarely ends up writing components, so does not often face the complexity. Of course, others disagree with me, as they may have worked in projects where components have had to be developed, but I am talking generally.
Yes, I am among the others who disagree, just because my experience is different. My customer (a really big one) is very specific about the look and feel of his application's UI. He just doesn't get satisfied with 80 or even 95% complience with his style-guide, he wants all 100%! The standard JSF components might be very good and mighty, but sometimes you have to real struggle to tweak them to fullfill your needs. Somehow it is much easier with Wicket components. Or I just write my own composite components from existing ones because it is so easy.
Well, it's just my experience. If your customer always agree with the standard look and feel - good for you.
One thing this thread has done is to convince me that I need to take a much deeper look at Wicket.
Good, we on the other hand, will certainly look into JSF. I think I already made some contribution to this damn "radio button in a table" problem. ;-)
|
|
|
Message #225012
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
Yes, I am among the others who disagree, just because my experience is different. My customer (a really big one) is very specific about the look and feel of his application's UI. He just doesn't get satisfied with 80 or even 95% complience with his style-guide, he wants all 100%! The standard JSF components might be very good and mighty, but sometimes you have to real struggle to tweak them to fullfill your needs. Somehow it is much easier with Wicket components. Or I just write my own composite components from existing ones because it is so easy.
Well, it's just my experience. If your customer always agree with the standard look and feel - good for you.
I am kind of surprised that there is this difficulty with components, because I my impression and experience was that just about everything about JSF components is usually customisable to the n'th degree. However, I have almost invariably have worked on (and seen) projects that have not had to conform to an existing detailed style guide, so it is interesting to hear that someone has found this to be an issue.
|
|
|
Message #225179
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
Below is an example of a grid component that is associated to six different renderers (HTML, CSV, Excel, PDF, RTF, XML).
It's not the same as HTML vs. WML, but it gives an illustration of the multi-renderer concept.
http://www.dotjonline.com/faces/components/grid/gridScroll.jsf
DISCLAIMER: This is only a beta release.
Joe Pardi
dotJ Software
http://www.dotjonline.com
Hi Joe,
I don't think anyone is questioning whether or not this is technically possible, but the question in my mind is why you would want to do this in the first place?
What is the user problem such a solution addresses? If the issue is users wanting to see the same content formatted in a way suitable for their current viewing device then IMO the ideal solution is one where the client dynamically formats the layout to suite its own needs itself. For example I believe the Opera PDA browser does this with standard HTML, so does IE for PocketPC.
Why would a end user want to see the same content with the same layout but rendered using differing presentation technology?
To me such a feature seems speculative at best, or an example of over-engineering at worst. My point is that all JSF solutions will bear the added complexity needed to support this feature and that only in a very few instances (if any?) will this feature provide any real business value.
This is the argument for YAGNI and keeping things simple. In the rare cases where such a feature adds value, then why not just extend JSF as appropriate? A well designed API should be open for extension. I believe the Wicket author has already pointed out that such functionality could easily be added to Wicket, but that they decided not to provide it out the box for the reasons I describe here.
My argument is that when it comes to APIs that often less is more. IMO the skill is in finding the right less.
Paul.
|
|
|
Message #225239
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
"What is the user problem such a solution addresses?"
In the example of the multi-rendered grid, here are two common use cases that I see very frequently:
- user wishes to see the information in PDF since the print fidelity of the web browser is not very good.
- user wishes to import the data into Excel so that they can manipulate it for their own purposes. Perhaps they wish to add summarizations, or even charts and graphs.
"Why would a end user want to see the same content with the same layout but rendered using differing presentation technology?"
Although technically you have a good point, I would challenge the notion of depending on the client device for various renderings. If you wait around for IE or Opera to solve this for you, you are going to quickly lose a competetive edge over your competition. It's a hard sell to your customers to tell them that they must wait for IE to provide satisfactory print quality rather than spoiling them with out of the box JSF based PDF.
"This is the argument for YAGNI and keeping things simple."
I don't disagree with YAGNI, but applying it in the real world is the hard part. It's often just as hard to predict what you ain't going to need. And when you find out you got it wrong, it can be pretty expensive to retrofit a major feature into a solution, especially one with a large customer base using it. Struts is a very good example of that. Its success quickly started to show its design flaws as developers wanted it to do more and more. When they thought they applied the YAGNI principle in Release 1, it bit them in the butt in subsequent releases.
"My argument is that when it comes to APIs that often less is more. IMO the skill is in finding the right less."
I don't disagree. Did the designers of JSF over-engineer it or cross a line by providing too much? Only time will tell. Remember, Release 1 is easy ... it's Releases 4, 5, and 6 that show how well the design is.
Joe Pardi
dotJ Software
http://www.dotjonline.com
|
|
|
Message #225258
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF & Facelets
Hi Joe,
I found your response well reasoned and balanced. I left out a lot in my post. I'll respond to what you have said then say why I'm troubled by JSF:
"What is the user problem such a solution addresses?"
In the example of the multi-rendered grid, here are two common use cases that I see very frequently:
- user wishes to see the information in PDF since the print fidelity of the web browser is not very good.
- user wishes to import the data into Excel so that they can manipulate it for their own purposes. Perhaps they wish to add summarizations, or even charts and graphs.
This sounds like a valid use case, but I still do not see why multi-renderng needs to be intrinsic to JSF. Here is a link to a Rails Graphing plugin, that does exactly the same thing:
http://liquidrail.com/
The difference is the design approach. Rails started off as a simple web application framework with a clean and open design. This has allowed others to create add-ons, easily and cheaply and for the framework to evolve over time. So if you need multi-renderers just plug them in. With JSF everyone gets this feature whether you want it or not. You also get the added complexity too.
"Why would a end user want to see the same content with the same layout but rendered using differing presentation technology?"
Although technically you have a good point, I would challenge the notion of depending on the client device for various renderings. If you wait around for IE or Opera to solve this for you, you are going to quickly lose a competetive edge over your competition. It's a hard sell to your customers to tell them that they must wait for IE to provide satisfactory print quality rather than spoiling them with out of the box JSF based PDF.
I actually agree here, which is why I said that delegating to the client was the ideal approach, after all that is what markup and SGML/XML/HTML etc, is meant to be all about right?
"This is the argument for YAGNI and keeping things simple."
I don't disagree with YAGNI, but applying it in the real world is the hard part. It's often just as hard to predict what you ain't going to need. And when you find out you got it wrong, it can be pretty expensive to retrofit a major feature into a solution, especially one with a large customer base using it.
Here we go. This is the crux of the argument, and why I am troubled by JSF. JSF became a standard before it became a stable, mature and proven web framework. The proof of the pudding is in the eating, and has people have tried to digest JSF they have found the need to replace and modify large parts of it (e.g. templating).
My dfficulty with JSF is that I see it as an example of big upfront design. As I said in a previous post good OO API design emerges over time through constant refactorings and responding to real business needs across a number of real world applications. JSF just hasn't gone through this process.
Struts is a very good example of that. Its success quickly started to show its design flaws as developers wanted it to do more and more. When they thought they applied the YAGNI principle in Release 1, it bit them in the butt in subsequent releases.
Yes I agree, this makes my point. Struts was another premature standard. It was the simplest thing that could work at the time, but then it became frozen and stopped evolving. YAGNI means adding functionality when you need it. It assumes that the cost of change is low. If you have gone out and built an industry and a whole set of tools based on the current API, then changing things is expensive - this is the problem with premature standardisation not YAGNI.
"My argument is that when it comes to APIs that often less is more. IMO the skill is in finding the right less."
I don't disagree. Did the designers of JSF over-engineer it or cross a line by providing too much? Only time will tell. Remember, Release 1 is easy ... it's Releases 4, 5, and 6 that show how well the design is.
Joe Pardi
dotJ Software
http://www.dotjonline.com
I believe JSF has missed the boat already. Big upfront design by committee just doesn't work with objects. The web framework landscape moved on through real world experiences whilst the JSF specs were still being solidified to keep the bating Java vendor community happy.
There are a number of things I believe that Java frameworks can learn from things like Rails. I think that convention over configuration is a powerful idea, I believe that Wicket has picked up on this. I also think the idea of extending your framework through plug-ins or custom code is very powerful. That way the core framework can remain small and simple. Language features such as mixins in Ruby help with this, but with some imagination it should be possible with Java too.
Above all I think the Java community need to get away from premature standardisation of APIs, and let time and experience decide. The way the JCP works seems skewed to serve the needs of vendors who need certainty upfront about what will be the next big Java API, so that they can get their marketing and engineering machines rolling. But OO design just doesn't work that way. Good OO design emerges over time through experience, constant attention and refactorings.
I believe this basic mistake about how objects work is why many have moved to open source and to alternative languages like Ruby.
Paul.
|
|
|
| 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)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, 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)
|
|
