|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 41
Messages: 41
Messages: 41
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
JavaServer Faces Presentation from TheServerSide Java Symposium
The need for a common API for Java-based web application user interface components was obvious – by the time that the Java Specification Request (JSR) for this API was started, there were over thirty open source and commercial libraries that covered all or part of this functional space. JSF's goals included gaining consensus on a common API for building interoperable components, but it was also more aggressive in its goals: it was also to be the leading edge of a movement towards making Java APIs easier to use, as well as easier for tools vendors to create high quality design time experiences around that API. This presentation will briefly review the history of JSF, and examine the ecosystem around this API, plus talk about what might be useful in the future.
Watch the presentation
|
|
|
Message #173466
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JavaServer Faces Presentation from TheServerSide Java Symposium
FWIW, Adam Winer and I will be presenting on JavaServer Faces in Minneapolis later this month. We will be dispelling the myths and talking about interoperability between JSF and existing frameworks from an enterprise level.
http://www.otug.org/meeting/20050621.html
-- Jacob (JSR 252 EG)
|
|
|
Message #173509
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JavaServer Faces Presentation from TheServerSide Java Symposium
I think JSF is too much complex to increase its market share.
I know that it should be edited with a visual IDE to integrate the view model, so JSF should be built with a WYSIWYG, but, the code is too long to understand, and always it´s needed to see the source code at the end.
As I have several times before in these forums... why should we return to NetDynamics model? Does someone remember this app. server? :)
Joserra
Nuevos modelos de Negocio basados en Software Libre
|
|
|
Message #173512
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JavaServer Faces Presentation from TheServerSide Java Symposium
Very interesting stuff. Many thanks to theServerSide team for providing the video of this presentation on-line. Actually, the content is pretty old (March, 2005). I wonder, how many key materials are held for the future :-)
...there were over thirty open source and commercial libraries that covered all or part of this functional space....
I think, Craig sounds too optimistic about third party component libraries market. Most of those thirty libraries dead on arrival or frozen. Writing the jsf components is still a very complicated process and requires expert knowledge about the JSF architecture. I can say that only Oracle ADF library has reached the maturity level now.
--
Sergey : jsfTutorials.net
|
|
|
Message #173514
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Misunderstood... :)
...there were over thirty open source and commercial libraries that covered all or part of this functional space....
I think you misunderstood him here. I think he was talking about the number of web frameworks in existence before JSF, trying to make a point about the need to standardize.
|
|
|
Message #173517
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Misunderstood... :)
I think you misunderstood him here. I think he was talking about the number of web frameworks in existence before JSF, trying to make a point about the need to standardize. You are right, I had quoted the wrong part of the original text accidentally, but if you count the number of libraries that declared to be a JSF libraries, you can find about 30-40 of them on the internet for last one year. Actually, I did it when I gather the data for jsfTutorials.net. I found only 8 of them that actually had some activity. The rest ones just dead of frozen.
--
Sergey : jsfTutorials.net
|
|
|
Message #173520
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JavaServer Faces Presentation from TheServerSide Java Symposium
I only hope JavaServer Faces aren't another beast like were Entity Beans for the Database Integration ...
|
|
|
Message #173527
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ironic difference in POV
Somewhere Craig McClanahan says something about frontends implemented in JSF needing roughly the same number of lines / construts as something comparable in implemented Struts (if I remember correctly, I can't get at the video to check as I'm behind a firewall now).
From his point of view, that was certainly meant as an argument in favour of JSF. To many listeners, the same statement is probably seen as an absolutely damning argument against JSF...
|
|
|
Message #173533
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Misunderstood... :)
I found only 8 of them that actually had some activity. The rest ones just dead of frozen
And why it is so? What do you think?
Marina
Coldtags
|
|
|
Message #173539
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JavaServer Faces Presentation from TheServerSide Java Symposium
I think JSF is too much complex to increase its market share.
I'd be interested to know why you say this. I have found it to be one of the simpler frameworks.
I know that it should be edited with a visual IDE to integrate the view model, so JSF should be built with a WYSIWYG, but, the code is too long to understand
In the talk, Craig says that JSF certainly need not be built with a WYSIWYG visual IDE. Personally, I code by hand and find this easy to do, and it does not require long code.
|
|
|
Message #173541
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF just not there yet
JSF with nice IDE, such as JDeveloper, IBM Websphere Studio/Rational Application Developer, it is good for a developer to develop a quich and simple database driven web application. It does not work well for those well designed front-end web application. Also I was not happy with any current JSP implementation yet and would like wait to see the best to come.
|
|
|
Message #173549
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF just not there yet
JSF with nice IDE, such as JDeveloper, IBM Websphere Studio/Rational Application Developer, it is good for a developer to develop a quich and simple database driven web application. It does not work well for those well designed front-end web application.
Why not? A list of the issues you have come across which make you think that it does not work well would be interesting. Personally, I have found few problems in this area.
|
|
|
Message #173562
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Relative complexity...
I think JSF is too much complex to increase its market share.
Just ditto-ing what Steve Zara said, I've been doing a like-for-like port of the Spring PetClinc application from Spring MVC to Spring + JSF, I'll do a tally when I've finished but the number of lines of Java code is about equivilent, JSF actually has less XML metadata at the moment. The Spring MVC implementation is slightly winning out in terms of page size.
I don't have a Struts version to compare but I'd expect the UI and metadata portions of a Struts implementation to be pretty similar as well, although I suspect there would be more Java code.
From a code complexity point of view the JSF impl is certainly the simplest to understand if you know neither framework.
|
|
|
Message #173569
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Relative complexity...
Duncan and Steve are right on the mark.
The thing to take away from Craig's presentation is that it's geared to make it simpler for developers. Yeah, there is new XML markup to learn-- but as Craig stated, it's no heavier than Struts and Duncan mentioned it's actually lighter than Spring MVC.
On the Java end of things, JSF works with POJO beans-- which appals me that someone would compare JSF to EJB 2-- it's more like EJB 3 in development requirements. You don't have to extend ActionForm or Action, you don't have to implement some listener interface to get what you need done-- JSF just magically wires all of that together.
In terms of scales, for large projects, you are free to replace/modify any part of JSF's application stack with your own implementation or integrate Shale or Spring on many levels.
IMHO, traditional MVC (Spring MVC and Struts) has their consequences in terms of UI scalability. JSF's component lifecycle corrects a lot of those issues and allows for much more robust UI development-- visual editor or not.
-- Jacob
|
|
|
Message #173584
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Flash video is awesome
I like the Flash video. You may have noticed the other tss videos used either MS video or Real video. I like the flash.
Can you guys give us any info on what issues are involved in setting that up? Does it use less bandwidth?
|
|
|
Message #173599
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry
To me Tapestry html templating is far less intrussive and coupled with OGNL it looks simpler to use as well.
|
|
|
Message #173659
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JavaServer Faces Presentation from TheServerSide Java Symposium
NetDynamics?
Wouldn't that be the app server Sun bought so they could (more or less) kill it and co-develop Sun One with AOL/Netscape?
That certainly worked out well...for BEA anyway.
|
|
|
Message #173663
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry
To me Tapestry html templating is far less intrussive and coupled with OGNL it looks simpler to use as well.
I fully agree. Templates ensure that your UI is sufficiently stupid that you really can't code in it, which means you have some decent ui code / content separation in your apps.
Personally I favor Velocity. It's basically impossible to do anything complex in it, so it quite literally forces you to code any bizarre behavior in java objects where it belongs. That and it isn't yet another framework trying to control the universe. It's merely a templating tool.
|
|
|
Message #173667
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry
To me Tapestry html templating is far less intrussive and coupled with OGNL it looks simpler to use as well. I fully agree. Templates ensure that your UI is sufficiently stupid that you really can't code in it, which means you have some decent ui code / content separation in your apps.Personally I favor Velocity. It's basically impossible to do anything complex in it, so it quite literally forces you to code any bizarre behavior in java objects where it belongs. That and it isn't yet another framework trying to control the universe. It's merely a templating tool.
IMHO, the use of OGNL allows for more intrusive scripting than JSP/JSF's use of EL :-)
|
|
|
Message #173670
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Relative complexity...
JSF specification just doesn’t address all issues you will meet in a JSF based application. This is general problem in Java standards.
Fortunately, JSF is well designed and it isn't very hard to solve those issues.
Unfortunately, there is no standard framework, or best practice for most common issues and you have to spend some time to make your own mini framework.
Nebojsa
|
|
|
Message #173687
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
Unfortunately I have to say, that the JSF component API is one of the hardest I had yet to deal with.
I just have started to write some components, and here is the cruelity you have to deal with.
Normally it is just like. derive a component from an existing, write your own functionality, or if it is mvc deal with a separate renderer, connect them over pojo mechanisms, be done with it.
Not so in JSF.
You have to deal with a taglib tld, you have to deal with a component descriptor xml, both of them are connected over obscure names which are requested by callbacks in the tag descriptor and in the component descriptor. There is no easy base mechanism to traverse the standard datatypes between the componetn and the taglib (most libs implement their own, building on the small number of foundation functionality methods)
Add to that that you also have to implement a renderer, and you have in the extreme case 5 files you have to deal with per component, maybe 6 if you have to root into something else.
It comes worse, once you have the tag up and running, you might thing you can plug and play it into the ide. No, there is no standard API to hook that stuff into your favorite RAD tool, every RAD tool vendor is brewing its own soup, and just to add something to that, you basically have to deal yet with another bunch of artefacts to get things into the ide graphically and to the worse, basically different for every ide.
It is not, that JSF is not powerful and there are some parts which are easy to handle, but the Component API definitely is not one of them. I has been a long time, since I had seen such a complexity on component level before I made my dive into the JSF components.
Another of those headache parts is the scope mechanism which fortunately is currently resolved by Shale Dialogs, the third one is the Datamodel, which basically does not have any good possibility to have a small session/transaction time, keep the objects dataset detached mechanism.
The datamodel makes paging mechanisms unsuitably hard, by enforcing to feed one dataset per call, without a single demarkation line for being able to close a transaction or session.
Dont get me wrong, there is great stuff in JSF, for instance all the data validation stuff, the conversion api, the page flow system, but the deeper you dive into the system the messier things get unfortunately.
|
|
|
Message #173814
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
Unfortunately I have to say, that the JSF component API is one of the hardest I had yet to deal with.I just have started to write some components, and here is the cruelity you have to deal with.Normally it is just like. derive a component from an existing, write your own functionality, or if it is mvc deal with a separate renderer, connect them over pojo mechanisms, be done with it. Not so in JSF.
JSF does provide base UIComponents that take care of input/validation/conversion for you-- UIData, UIInput, UIOutput, etc. Yeah, it can be tricky to add components that are overly complex.
You have to deal with a taglib tld, you have to deal with a component descriptor xml, both of them are connected over obscure names which are requested by callbacks in the tag descriptor and in the component descriptor. There is no easy base mechanism to traverse the standard datatypes between the componetn and the taglib (most libs implement their own, building on the small number of foundation functionality methods)Add to that that you also have to implement a renderer, and you have in the extreme case 5 files you have to deal with per component, maybe 6 if you have to root into something else.
You don't need to create a renderer. The renderer can be null and you can override the render methods on your component itself to always output XHTML or XML if you want. RenderKits are used in a lot of the vendor libraries in order to provide the most flexibility, but by no means is it required.
http://jsf.iatp.org.ua/customcomponent/jsf_emailcustomcomponent.html
The JSP taglibs are a pain, but soon the JSF-RI group will be releasing a framework called Facelets which doesn't require separate tag files and works directly with your UIComponents.
http://facelets.dev.java.net
Also, pertaining to the faces-config itself. It is recommended that you add all of your component properties/attributes to the XML file, but not required. You can mount your component either via one method call in Java or with about 4 lines in the XML file. For some though, even this is too much work, but I consider it no more work than mounting an Action or ActionForm in Struts.
It comes worse, once you have the tag up and running, you might thing you can plug and play it into the ide. No, there is no standard API to hook that stuff into your favorite RAD tool, every RAD tool vendor is brewing its own soup, and just to add something to that, you basically have to deal yet with another bunch of artefacts to get things into the ide graphically and to the worse, basically different for every ide.
This is a problem that is being corrected in the EG with the help of Oracle. It's not nearly as bad as you describe it since again, properties and attributes are elements used by all IDEs and many of the elements in the config file include optional descriptions and icons. Maybe you are thinking of the JSF 1.0 release before Oracle stepped forward to standardize some of this?
|
|
|
Message #173833
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
We must also remember that in relative terms, the cost of writing a component is of much less importance than the cost of consuming them, so it's not something to get hung up on. I agree though that design time compatibility is key to this all working well.
In the meantime there is obviously a good market for a book on JSF component writing (and IDE plug-ins to help in the process). Now as it happens Jonas Jacobi at Oracle is writing a book on this as we speak - I'm sure he won't mind me plugging it.
|
|
|
Message #173841
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Valid answers to valid concerns
As some people already have answere my gripes with component writing.
First, yes there is some movement to make component writing easier.
The approach with facelets will be the best thing which might happen in the long run, but the real power will be there as soon as you can make a facelet and plug it into the IDE.
Unfortunately from what I could gather from the facelets this stuff is not there yet.
And yes, the component writing to app writing ratio is not really that relevant, but having an overly complicated API is not really well suited to get a good set of components out, or encourage people to write components.
|
|
|
Message #173845
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Valid answers to valid concerns
As some people already have answere my gripes with component writing.First, yes there is some movement to make component writing easier.The approach with facelets will be the best thing which might happen in the long run, but the real power will be there as soon as you can make a facelet and plug it into the IDE.Unfortunately from what I could gather from the facelets this stuff is not there yet.
Facelets is there, it just can't be released yet. I'm working on preparing a demo of the technology later this month in Minneapolis.
IDE wise, I've already been fielding ideas from one of Oracle's leads for component integration, where you can actually put a couple elements in the faces-config extension points and 'wallah'.
There's room to grow with facelets, but if you want to email the project lead with any ideas-- that would be awesome!
|
|
|
Message #173918
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF - A Good Answer
By now, I have used struts, the spring mvc framework, and now JSF. So far, jsf is one my favorites.
I stayed away from jsf because of my previous misconception about its complexity. However, once I started using it, I realize that it was lighter and less demanding than other MVC frameworks out there.
People complain about the complexity of JSF and how intrusive it can be. I would argue that jsf, like any other new technology from the Java community, will require some usage patterns to emerge which will make coding more effective. And because major open source IDE’s lag behind JSF integration, people spend more time figuring out usage patterns then enjoying the technology.
As far as comparing jsf to WebForm in ASP.net, let's not forget that from day one, WebForm was supported by the .Net IDE. No ASP developer I know ever had to write ASP.Net WebForm code in notepad (or similar). They were never exposed directly to the complexity of the technology, as are Jsf developers. So, the ASP.Net developer guy had effective IDE integration and support, they spend more time enjoying the technology rather then figuring out usage and plumping.
On the other hand, most people being introduced to JSF are doing so using IDE's that do not support the technology inherently (and when they do have support, some do a poor job at it). Therefore, the developer becomes responsible not only to learn JSF, but to also devise an effective usage pattern that fit their development requirements.
I think once integration of JSF into open source IDE’s becomes more mature, its complexity will be invalid.
vmatters.
|
|
|
Message #174002
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF
I am quite happy with the JSF
Especially, because I hate to write the UI. I prefer the 'drag and drop'. Writing a code like 'TextField' drives me crazy. I am not a robot. I require an automatization ...
I downloaded the SUN Java Creator and with couple of tutorials I was able to develop simpler apps very quickly.
Now I use the SUN Java Studio and SUN Java Creator.
I am able to develop a simple CRUD (CMP EJB 2.1, DAO wrapper, Session EJB, BD wrapper, 1 JSF page with 1 table, 3 buttons and 1 text field) for 1 DB table in about 20 minutes.
Nothing fancy, but for a corporate web site it is OK.
IMO JSF+EJB3 look like a technologies of choice in a near future.
DF
|
|
|
Message #174103
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry
IMHO, the use of OGNL allows for more intrusive scripting than JSP/JSF's use of EL :-) Sounds like FUD spread.
1st - EL is weak and smeels like wheel reinvention, OGNL is much more powerful and mature than EL, but for EL type of use their syntaxes are virtually the same; IMO EL shoul not be developed at first place.
2nd - Tapestry template can have jwcid attributes ONLY, that makes it cleanest template on the market. entry like <input jwcid="dateField" /> will be correctly displayed by any HTML editor (WYSIWYG or not) no matter how complex the component definition is.
If there is separate UI designer then it makes sense to keep templates clean to allow true team work, if developer wears designer's hat too then Tapestry allows shortcuts:
<input jwcid="@DatePicker" value="ognl:startDate"/> they really might oscure template, but that is optional in Tapestry.
|
|
|
Message #174105
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
Yeah, it can be tricky to add components that are overly complex.
Such thing is easy in Swing, in Tapestry too. Why it has to be comples in JSF?
The renderer can be null and you can override the render methods on your component itself to always output XHTML or XML if you want. Exactly like servlet :)
One day I looked at some JSF components in one well known portal project and was horryfied by number of println statements in them.
|
|
|
Message #174109
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
Yeah, it can be tricky to add components that are overly complex. Such thing is easy in Swing, in Tapestry too. Why it has to be comples in JSF?
Because Swing and Tapestry don't render for multiple presentation technologies. With Swing you have the Graphics methods and with Tapestry you can code HTML directly. JSF components should be able to render using different methods, so may need to output HTML, XML, SVG, Flash etc.
The renderer can be null and you can override the render methods on your component itself to always output XHTML or XML if you want. Exactly like servlet :)One day I looked at some JSF components in one well known portal project and was horryfied by number of println statements in them.
It is not like servlet at all, because servlet does not have a separation of view. I don't understand why anyone would be horrified by the println statements. JSF rendering has to emit markup somehow.
|
|
|
Message #174122
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
The renderer can be null and you can override the render methods on your component itself to always output XHTML or XML if you want. Exactly like servlet :)One day I looked at some JSF components in one well known portal project and was horryfied by number of println statements in them.
It is not like servlet at all, because servlet does not have a separation of view. I don't understand why anyone would be horrified by the println statements. JSF rendering has to emit markup somehow.
It is a specialized writer that operates a lot like the stax API with methods to write a startElement, attribute, endElement, etc. Performance wise, this is a bonus and no different than generating any other XML document within Java.
For those of you who are still stuck on mixing presentation and structure in your XHTML document (and tapestry makes you feel more comfortable)-- you should take some time and read about web standards. Once you separate out your 'rendered' structure, printing from JSF Components doesn't seem far fetched at all and actually seems to provide better long term maintainability. That would be nice wouldn't it? Rather than mixing your document with a bunch of little layout quirks. "Get out of the 90's" ;-)
http://www.weeklystandards.com/features/att/
|
|
|
Message #174253
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
JSF components should be able to render using different methods, so may need to output HTML, XML, SVG, Flash etc. And that is presumably ... good?
There is an old adage that seems to fit into the situation: jack-of-all-trades, master of none.
In nowadays speak it looks like “silver bullet” pattern.
Could somebody show me an example when “one-size-fits-all” really lived up to its promise?
|
|
|
Message #174261
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
JSF components should be able to render using different methods, so may need to output HTML, XML, SVG, Flash etc. And that is presumably ... good?
Why shouldn't it be? The alternative is to have to use an entirely different MVC toolkit for each technology, which is wasteful. If I have code for handling, say, customer authentication and account details presentation, I want to be able to use the same infrastructure, for the web, for WML and for a richer client interface such as flash. Obviously I would not try and replicate the entire UI on each platform, but any re-use is good. As well as re-use, this means there is a dramatic saving on retraining and retooling. JSF, which will be mostly used for HTML can subsequently be used for a new project even if the target UI is SVG or WML.
There is an old adage that seems to fit into the situation: jack-of-all-trades, master of none.In nowadays speak it looks like “silver bullet” pattern. Could somebody show me an example when “one-size-fits-all” really lived up to its promise?
Yes. Java.
|
|
|
Message #174295
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
There is an old adage that seems to fit into the situation: jack-of-all-trades, master of none.In nowadays speak it looks like “silver bullet” pattern. Could somebody show me an example when “one-size-fits-all” really lived up to its promise? Yes. Java.
Which one: J2SE or one of J2ME?
By the way, where is Java replacement for MSWord? Adobe Photoshop ot GIMP?
And why is there a plethora of scripting languages for JVM?
|
|
|
Message #174308
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
There is an old adage that seems to fit into the situation: jack-of-all-trades, master of none.In nowadays speak it looks like “silver bullet” pattern. Could somebody show me an example when “one-size-fits-all” really lived up to its promise? Yes. Java.
Which one: J2SE or one of J2ME?
Both. They indicate how a single language can be used in a wide range of situations.
By the way, where is Java replacement for MSWord? Adobe Photoshop ot GIMP?
Because Java has only been a high-performance language in recent years, and there seems little point in re-writing existing applications with a large codebase in a new language.
However, this does not stop some developers! You will see the photoshop and gimp features in programs such as JPhotoBrush Pro.
And why is there a plethora of scripting languages for JVM?
Because developers like choice, and like to work in different styles.
I don't understand the point you are making. If a technology is versatile and flexible and able to deal with a range of situations, but may not not perfect in all of them (as regarding JSF and user interfaces), you would suggest abandoning all the benefits and switch to highly specific alternatives that limit your choices?
In that case, why are you using Java?
|
|
|
Message #174354
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
They indicate how a single language can be used in a wide range of situations. Because developers like choice, and like to work in different styles. Do not you think that the statements above a kind of ... contradictory?
I would say even more: certain styles/approaches work better for particular areas. I beaten example would be SQL vs Java, or Shell ws AWKI don't understand the point you are making.
Point: certain technologies exist to fulfill particular requirements, address a problem in a certain way, in other words: for good reasons. Bringing them to some (lowest) common denominator does not seem beneficial. And additional complexity because of that attempt hurts even more.
In that case, why are you using Java? It pays the bills, and it is not _that_ bad. And by the way I use much more than Java(language) and Java(platform)
|
|
|
Message #174358
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
They indicate how a single language can be used in a wide range of situations. Because developers like choice, and like to work in different styles. Do not you think that the statements above a kind of ... contradictory?
Not at all. Just because a language like Java is capable of being used in a wide range of situations does not mean that everyone likes using it in all those situations. Some people prefer Python, Smalltalk, Prolog etc - languages which are also available on the JVM.
I don't understand the point you are making. Point: certain technologies exist to fulfill particular requirements, address a problem in a certain way, in other words: for good reasons. Bringing them to some (lowest) common denominator does not seem beneficial. And additional complexity because of that attempt hurts even more.
I feel that this is a mistaken argument. Just because some technologies are very versatile (like Java) does not mean that they are less-than-satisfactory lowest common denominators.
Regarding JSF, I certainly don't accept that it is a lowest common denominator. Just because it is able to have pluggable renderkits for different user interface types does not mean it is not able to provide an easy method of defining high-quality HTML pages.
I would agree that there is some additional complexity in current JSF versions regarding component building, but in my experience most developers are component users, not builders, as there is a rich set of components already out there (this is getting to be the case with JSF), and the process of defining components is being simplified in future versions of JSF.
I think my attitude can be explained because I like to protect my code, and I expect it to be long-lived. Therefore, I always aim to use technologies that are adaptable, and which will allow me to preserve as much of my work as possible as requirements change. I see JSF helping to meet this need, as I would expect that I should be able to deal with an increasing variety of 'remote' user interfaces - Web, WML, Flash, and whatever comes next. I would hope to be able to migrate and extend client sites to use new technologies with some re-design accompanied by the use of an increasing range of renderkits. I may be being optimistic about this, but as I see few disadvantages in currently using JSF to produce HTML, I believe it makes sense to use a technology that at least gives the possibility of saving me and my clients considerable time and expense.
|
|
|
Message #174498
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
So you admit that even when one language (Java) can do the same thing as another, many people prefer the alternative( Python, etc).
But with HTML/Flash/Swing we are talking about technologies with vastly different capabilities and underlying ‘philosophies’.
I certainly understand your desire to preserve you code, but I thing that you are making a mistake assuming that JSF will help you here.
Lets consider Cocoon: Cocoon’s promise is very similar to JSF. Cocoon allows defining data as XML(could be ‘active’) and then provide series of XSLT transformations to render information for the target client: Browser/WAP/etc. I would say that Cocoon is not much of a success in the area.
I certainly don't accept that it is a lowest common denominator. Just because it is able to have pluggable renderkits for different user interface types does not mean it is not able to provide an easy method of defining high-quality HTML pages. IMO It means
- that an HTML oriented framework(like Tapestry) would do HTML interfaces easier than JSF;
- that Flash oriented framework would do Flash interface easier than JSF;
- that Swing oriented FW will do Swing interface easier than JSF;
I yet to see a JSF application that would work with Browser/WAP/Flash/Swing interfaces simultaneously ( saw Browser/WAP one), will be convenient to develop, and will use strengths of particular client technology.
In my experience it is much easier to create any type of NECESSARY UI with specialized tools as long as application is properly layered.
|
|
|
Message #174537
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
So you admit that even when one language (Java) can do the same thing as another, many people prefer the alternative( Python, etc).
Of course, but that does not detract from Java's abilities in these areas.
I certainly understand your desire to preserve you code, but I thing that you are making a mistake assuming that JSF will help you here.
The JCP and major commercial and open-source backers of JSF disagree with you.
I would say that Cocoon is not much of a success in the area.
Cocoon is not a JCP standard back by major commercial and open-source companies and organisations.
Just because it is able to have pluggable renderkits for different user interface types does not mean it is not able to provide an easy method of defining high-quality HTML pages.
The renderkits issue is irrelevant. JSF certainly allows the definition of high quality web pages. I am currently using it to produce (if I may be immodest) high-quality and full featured web sites.
IMO It means - that an HTML oriented framework(like Tapestry) would do HTML interfaces easier than JSF;-
I don't understand why. The renderkits are irrelevant. You use can HTML + JSP tags which allow full use of all the richness of CSS and JavaScript.
that Flash oriented framework would do Flash interface easier than JSF;- that Swing oriented FW will do Swing interface easier than JSF.
You are misunderstanding JSF. JSF is not a replacement for these technologies - it is an interface to them. The renderkits for Flash would use Flash; renderkits for Swing would use Swing, just as renderkits for HTML use HTML + JSP.
I yet to see a JSF application that would work with Browser/WAP/Flash/Swing interfaces simultaneously ( saw Browser/WAP one), will be convenient to develop, and will use strengths of particular client technology.
You are again misunderstanding JSF. The idea that an entire website would be able to simultaneously render in all these technologies is, of course, not sensible IMO. What JSF will allow is that parts of a site can be re-used for different rendering under certain conditions. The components, backing beans and the interface to business logic can make up these sections of the site be re-used to render these sections in different ways. For example, I can use the same components, backing beans and controller logic to render an input form in WML as in HTML (although, of course, the components would be embedded in different pages depending on the required mark-up).
In my experience it is much easier to create any type of NECESSARY UI with specialized tools as long as application is properly layered.
As I am using JSF to rapidly create good websites, I can only disagree with you.
|
|
|
Message #174588
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
You are misunderstanding JSF. Why do not give me a little credit and assume that I do understand JSF?
Please try re-read my arguments with the assumption that I do understand JSF, and you do not quite understand what I am saying.
As for your argument of wide JSF support...well Entity Beans were once widely supported, slavery, segregation etc.
So what?
|
|
|
Message #174622
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About the third party components
You are misunderstanding JSF. Why do not give me a little credit and assume that I do understand JSF?Please try re-read my arguments with the assumption that I do understand JSF, and you do not quite understand what I am saying.As for your argument of wide JSF support...well Entity Beans were once widely supported, slavery, segregation etc. So what?
I read your comments in great detail. How can I assume you understand JSF if, for example, you are comparing it to Entity Beans? Entity Beans are generally assumed to have been (so far) a clumsy and rather slow technology that is tricky to use and hard to test, whereas JSF is simple to use and allows rapid production of applications and is easy to test.
An example of how I think you are misunderstanding JSF is when you say
I yet to see a JSF application that would work with Browser/WAP/Flash/Swing interfaces simultaneously ( saw Browser/WAP one), will be convenient to develop, and will use strengths of particular client technology.
Not only are you putting forward a 'straw man' argument - that an entire application should be able to 'simultaneously' render all these ways, and assuming it can't use the strengths of a particular client technology when, of course, it obviously can, as the renderkits can use all the features of a client technology.
As proof that JSF can indeed work in this way, go to Oracle's site and look up information about their JSF components - 'ADF Faces':
"All these components currently use HTML and WML as the markup languages, so that they can be used indistinctively on a normal browser or a mobile phone or PDA."
"You can group renderers in render kits, this way you can have a render kit for HTML and another one for WML (mobile phones). The logic of the component remains independent from the device it's being displayed." (my bolding).
The ADF Faces components can even render on telnet!
"Additionally, ADF Faces has a render kit for telnet devices. You might be wondering why, but the sheer amount of telnet devices that exist out there today makes a business case all by it self. Most factories and warehouses use such kind of devices, and they are used on a daily basis"
And as for quality, JSF can, for example, use the full features of HTML, CSS and Javascript, so there is no reason why websites of the highest quality should not be developed.
As far as I can tell, you seem to be repeatedly putting forward the general argument that a versatile technology can't also be of high quality - the 'jack of all trades but master of none' argument. I would suggest that with JSF this is simply not the case. If you have some specific technical reason why you believe that JSF can't be used to produce quality sites, I would be interested to hear it, with evidence to back this up.
I shall be continuing to use it. After all, not only is it easy to use, it is a JCP standard, has multi-vendor support (including high-quality open source versions), and, as the information about ADF proves, will allow me to be to move parts of my site to different rendering technologies if this becomes necessary.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore 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.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
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)
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)
|
|
