|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 39
Messages: 39
Messages: 39
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
Ed Burns has posted a reference to the proposal for JSF 2.0 on his blog.
The proposal focuses on ease of development (no config XML files), the use of templates, bookmarkable urls, and many more elements, including REST and AJAX usage in JSF. They're also focusing on ease of deployment, meaning that components should be "hot-deployable."
The drivers for JSF 2.0, from the proposal:2.5 What need of the Java community will be addressed by the proposed specification?
While JavaServer Faces has succeeded in becoming the standard way to build web application user interfaces while ensuring maximum container portability and minimizing vendor lock-in, the state of the art of web application user interface development has advanced significantly since the first major droft of the specification. The Java community finds itself in a similar situation to that in which the first version of the JavaServer Faces specification was initiated: Many great ideas but no standard specification that delivers them to developers and the marketplace. In fact, many of these great ideas are built on top of the JavaServer Faces Specification but, are not, themselves, standards. It is time to harvest these ideas and bring them to a wider audience in manner consistent with the rest of the Java Platform. This is aimed at Java EE 6, so it's likely to be quite some time - the initial proposal suggests March of 2008.
If you're interested in JSF becoming a more viable standard, feel free to contribute to this JSR. Whether you're a JSF supporter or not, JSF is here to stay, and there's no point in not being part of it - even if your opinion is that it should go the way of JDO and become a static specification from the JCP's point of view.
|
|
|
Message #230270
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Huh?
>>>While JavaServer Faces has succeeded in becoming the standard way to build web application user interfaces while ensuring maximum container portability and minimizing vendor lock-in
That is a silly statement
|
|
|
Message #230271
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
Looks very interesting and it seems to address many of the gripes of JSF.
The only problem is that we need this now, latest in a few months. Waiting another year just for the spec is a lifetime in the field of web development.
|
|
|
Message #230274
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
Looks very interesting and it seems to address many of the gripes of JSF.
The only problem is that we need this now, latest in a few months. Waiting another year just for the spec is a lifetime in the field of web development.
I agree, this needs to be handled more quickly. It would be much nicer to see this in a JEE 5.1 release, rather than waiting until JEE 6.
The unfortunately reality is that JEE 5 has been out for a year, and yet it is still only supported in a released form by one or two small niche players. If the spec doesn't even make it out until 2008, this won't make it into the real world until 2010! :(
|
|
|
Message #230276
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
The unfortunate reality is that JEE 5 has been out for a year, and yet it is still only supported in a released form by one or two small niche players. If the spec doesn't even make it out until 2008, this won't make it into the real world until 2010! :( Hmm. Niche players... Sun? SAP?
Also, the "other" niche players like BEA, Geronimo, JBoss are likely to have Java EE compliant servers out fairly soon.
|
|
|
Message #230277
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
My other concern is that JSF is still pretty much competing with .Net at the ASP.Net level.
The new buzz is WPF in .Net 3.0 and frankly speaking right now Java has nothing comparable to that. And don't tell me applets could do it. They've been dead long enough.
I've seen WPF demos done here at work by my colleagues in the .Net team and I hope someone at Sun isn't asleep at the wheel and coming up with something that can compete with that level of eye-candy. It makes quite the initial impression.
http://en.wikipedia.org/wiki/Windows_Presentation_Foundation
|
|
|
Message #230278
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No JEE 5 in JBoss? This is news to me.
Also, the "other" niche players like BEA, Geronimo, JBoss are likely to have Java EE compliant servers out fairly soon.
Which aspect of JEE 5 is not supported by JBoss 4.0.5? This is news to me as I'm using it right now for EJB 3.0 and JPA.
I've been a long-time loyal Tomcat user, but with EJB 3.0 showing so much potential, my team is actually seriously considering moving my employer's production applications to a full JEE server with our next upgrade cycle. We've already deployed a few applications using JSF and found that it is superior to competing specs, but still had a lot of room for improvement.
|
|
|
Message #230281
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
My other concern is that JSF is still pretty much competing with .Net at the ASP.Net level.
The new buzz is WPF in .Net 3.0 and frankly speaking right now Java has nothing comparable to that.
Maybe I'm missing something, but that sounds a lot like Java Web Start. "A WPF application can be deployed on the desktop or hosted in a web browser." Sure there might be some differences -- I don't know .Net or WPF well enough (read: at all) -- but it sure sounds at least *similar* to JWS.
|
|
|
Message #230283
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No JEE 5 in JBoss? This is news to me.
Which aspect of JEE 5 is not supported by JBoss 4.0.5? This is news to me as I'm using it right now for EJB 3.0 and JPA.
I've been a long-time loyal Tomcat user, but with EJB 3.0 showing so much potential, my team is actually seriously considering moving my employer's production applications to a full JEE server with our next upgrade cycle. We've already deployed a few applications using JSF and found that it is superior to competing specs, but still had a lot of room for improvement.
The last time I used JBoss 4.x, which, admittedly was a long time ago (we're a GlassFish shop now), JBoss' EE 5 implementation in the 4.x product was using a non-final version of the spec, so certain things like, iirc, jar file names in the ear, library file locations, remote session bean names, etc were not compliant with the final spec. So, in my experience, it wasn't that things weren't supported, necessarily, but that the support was not compliant with the final spec. Granted, that was probably almost a year ago, and I quit following JBoss compliance when we decided to run with GlassFish, so things have likely changed. JBoss AS 5 should fix any remaining issues.
|
|
|
Message #230287
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
My other concern is that JSF is still pretty much competing with .Net at the ASP.Net level.
The new buzz is WPF in .Net 3.0 and frankly speaking right now Java has nothing comparable to that. And don't tell me applets could do it. They've been dead long enough.
I've seen WPF demos done here at work by my colleagues in the .Net team and I hope someone at Sun isn't asleep at the wheel and coming up with something that can compete with that level of eye-candy. It makes quite the initial impression.
http://en.wikipedia.org/wiki/Windows_Presentation_Foundation
you are comparing apples and oranges with respect to JSF 2.0. it's like saying ASP.NET and WPF are one and the same thing-- I'd like to see JSF 2.0 do a better job of facilitating technologies from Adobe or other rich clients, but if you want something to compete with WPF, then bark at the swing folks.
|
|
|
Message #230290
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
Hmm. Niche players... Sun? SAP?
Also, the "other" niche players like BEA, Geronimo, JBoss are likely to have Java EE compliant servers out fairly soon.
Yep, Sun has little market share (though their leadership in getting JEE 5 support via Glassfish has helped), and SAP isn't exactly a big player in the market for JEE server (aside from the people who run SAP, obviously).
Weblogic, Websphere, and JBoss are the big players, and none of those have released final JEE 5 implementations.
I think they will have them fairly soon, too, though. It's just that fairly soon will be closer to the end of this year (1.5 years after spec)!
|
|
|
Message #230291
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
Yes, but MS is pushing WPF as the "new" way to do web development as well (since WPF apps can be deployed either in the browser or stand-alone).
I just hope someone at Sun is paying attention to it as a competitive threat and figuring out which parts of the Java stack (be it Swing, applets or JSF) that need to be enhanced to have a compelling alternative.
|
|
|
Message #230292
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
I like to see those people he mentioned join the jcp, amongst others , facelets as standard view technologie, integeration with web beans jsr, some sort of standard way that ide’s can incorporate other components (ie icefaces and other third party components), line precise error reporting (facelets already does this), better page flow support, some sort standard templating (facelets already does this too), better standard components, tighter integration with ejb3/JPA (seam style). Many of these can be done now, maybe just a matter of standardization.
|
|
|
Message #230295
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No JEE 5 in JBoss? This is news to me.
and found that it is superior to competing specs
exactly what competing specs are you speaking about ? :)
|
|
|
Message #230297
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
Yes, but MS is pushing WPF as the "new" way to do web development as well (since WPF apps can be deployed either in the browser or stand-alone).
I just hope someone at Sun is paying attention to it as a competitive threat and figuring out which parts of the Java stack (be it Swing, applets or JSF) that need to be enhanced to have a compelling alternative.
So you can either launch an application as a standalone application (like JWS) or within the browswer (like an Applet).
I'm bet the "features" with which Java needs to compete are:
3. Only really works on Windows (and recent versions at that)
2. Weak-by-default security model
1. It's made by Microsoft.
Of course those items translate into better user experience for 90% of computer users.
Maybe with Java under the GPL MS will take another crack an "innovating" with Java.
|
|
|
Message #230299
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
So you can either launch an application as a standalone application (like JWS) or within the browswer (like an Applet).
No, that's not a Java equivalent of WPF. A Java equivalent would be design an application using JSF (you can pick something else here if you like, but this whole was on JSF), and then being able to compile-deploy into either a web application that renders HTML/CSS/JS or a desktop application with the same functionality plus the ability to work offline. Take things a step further and you can also compile/deploy your application to mobile devices.
I don't think WPF has quite made it to that goal, yet. You can go download MS Expression Blend and get an app that will create the UI in XAML. Thus it could theoretically be rendered as a web app in HTML, but I don't think they have anything that will do that just yet. Maybe Orcas (next-generation of Visual Studio) will have (or already does, it's in beta right now) this capability.
I actually don't think this is too far from the original design of JSF. That being said, I think the Java community is making the right choice to pursue advancing web development technologies instead of trying to compete with WPF. Adobe has gone the other way and is trying to compete with WPF via their new product Apollo.
|
|
|
Message #230301
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
competing specs
exactly what competing specs are you speaking about ? :)
I'd compare JSF to the various Open Source web frameworks that are presently "fashionable." I think Struts and Spring WebFlow are the current leaders. I've personally done several struts projects while others I work with are experts in WebFlow. We've all concluded that JSF is a better choice, especially considering the wealth of readily available AJAX widgets, such as those offered by IceFaces, RichFaces, and a few Tomahawk components that are so easily integrated into your application. I don't think JSF is even close to perfection, but it's far superior too the frameworks I've worked with in the past.
In fairness, I consider JSF superior due to it's wide support from many vendors and rich widgets rather than its inherent design. I am not intimately familiar with the inner workings of all of the competing specs, but I am pretty confident that at this exact moment in time, they cannot match JSF (especially with seam and the 3rd-party AJAX widgets). However, I concede that my research on a half-dozen or so alternatives was relatively shallow, consisting of reading sample code, tutorials, and whitepapers rather than actually writing a full application with the technology.
|
|
|
Message #230303
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF and JDO do have a lot in common...
Whether you're a JSF supporter or not, JSF is here to stay, and there's no point in not being part of it
On a similar note, even if you disagree with the war in Iraq you should still support the president, right?
The goals listed for JSF sound great. That's mostly because they are cherry-picked from more innovative projects. For example, the use of annotations and zero-XML configuration is something already seen in Stripes. Tying into JPA? Sounds a lot like Seam. Make it easy to create CRUD apps? Sounds a lot like Grails (which is inspired by Rails of course.) Moving more of the controller bits to the client sounds a lot like GWT.
The problem is that by the time JSF gets around to all this, there will be new innovations out there.
|
|
|
Message #230308
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BEA JEE5 Released
There have been some comments about the lack of major vendor support for JEE5.
BEA WebLogic Server 10 is now GA and is fully JEE5 compliant.
You can download the final version as of today, although a tech preview that passed JEE5 certification has been available for awhile.
James Bayer
BEA Systems
|
|
|
Message #230310
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What the deal with JDO?
The goals listed for JSF sound great. That's mostly because they are cherry-picked from more innovative projects. For example, the use of annotations and zero-XML configuration is something already seen in Stripes. Tying into JPA? Sounds a lot like Seam. Make it easy to create CRUD apps? Sounds a lot like Grails (which is inspired by Rails of course.) Moving more of the controller bits to the client sounds a lot like GWT.
The problem is that by the time JSF gets around to all this, there will be new innovations out there.
This is actually good. Real developers need a well aligned combination of innovation and stability. I do agree with many of others that JSF is superior, bat far from perfection. We need one more step.
And I do not get what the deal with JDO.
|
|
|
Message #230317
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What the deal with JDO?
And I do not get what the deal with JDO.
Me neither. What is a "static specification" ? JDO 2.1 is being developed and implemented. JDO 2.x takes ORM to a level higher than any other current specification. Perhaps it was just an editorial comment that can be categorised in the "personal opinion" section and best ignored.
|
|
|
Message #230323
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
Rather than Sun being asleep at the wheel, I think it's the Java team in your organization that has got fat and is in deep slumber.
Seriously, STOP scavenging open source and do some work for yourself. Youl'll wow everybody not just windows users.
Webstart + Swing(or SWT) + HTTP will swallow up WPF effortlessly. It's not vaporware which WPF still is.. atleast the cross-platform part.
Try it, you'll be pleasently surprised.
|
|
|
Message #230325
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
The unfortunate reality is that JEE 5 has been out for a year, and yet it is still only supported in a released form by one or two small niche players. If the spec doesn't even make it out until 2008, this won't make it into the real world until 2010! :( Hmm. Niche players... Sun? SAP?
Also, the "other" niche players like BEA, Geronimo, JBoss are likely to have Java EE compliant servers out fairly soon.
Yep, frankly, in J2EE server market, SUN is... niche. SAP is almost exclusivelly tied to SAP product portfolio. Frankly i've never seen company using NetWeaver without having, before, SAP installed. Even they have SAP, they use NetWeaver as a SAP addition, serving J2EE applications on IBM, BEA, Oacle etc...
What about BEA, IBM, JBOSS or Oracle? They are in 'prevew' stage still.
Artur
|
|
|
Message #230331
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
See BEA above
They apparently have it in GA, and with JBoss due out in late April (my bet on Red Hat's announcement for middleware that Szulik alluded to the other day), you have well over 50% of the Total App Server market.
Oralce and SAP basically have the same JEE effort, unless you think OC4J has any independent market share, which I can't believe they would. BEA and IBM are essentially locked in a tie for enterprise deployments.
And JBoss certainly makes up for Geronimo's delay. You would have to be completely locked in to the app server vendor if you didn't at least test out JEE5, which is certainly possible, but then, wouldn't you look in to an evolution of the spec. to see if you can become less locked-in?
|
|
|
Message #230333
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who cares ?
This may be fine if you develop just another MS fanboy site because it probably runs only on Windows, requiring IE - perhaps even IE7 and some Vista "uber" edition.
For everything else it's even more retarded than doing a whole site in flash (at least every OS has a flash plugin).
Therefore I don't consider this as important as long it isn't platform independent as well as vendor independent.
|
|
|
Message #230334
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Most of it is already possible
Most of the mentioned stuff is already possible with JBoss Seam!
E.g.:
ease of development (no config XML files); after writing some initial configuration files in xml one doesn't need to write more of it because Seam uses annotations
the use of templates: I'm fine with facelets although some stuff is missing, i.e. https://facelets.dev.java.net/issues/show_bug.cgi?id=202 (<- vote for it plz ;))
bookmarkable urls, and many more elements, including REST and AJAX usage in JSF: REST is possible with Seam page actions. AJAX4JSF i.e. for AJAX integration or Icefaces, ...
They're also focusing on ease of deployment, meaning that components should be "hot-deployable.": This is at least partly possible since the 1.2.1 release.
With Seam probably being for the WebBeans JSR what Hibernate is for JPA and WebBeans & JSF working hand in hand and the facelets, ... integration I have high hopes :D
|
|
|
Message #230336
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: competing specs
Struts and spring webflow are not specifications and on top of that, they are not even component frameworks. they are front controller frameworks. An apples to apples comparison would be jsf - tapestry or jsf - wicket. Btw. spring webflow is only used for flow logic. Even the authors don't recommend writing your entire application with it.
|
|
|
Message #230338
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: competing specs
Struts and spring webflow are not specifications and on top of that, they are not even component frameworks. they are front controller frameworks. An apples to apples comparison would be jsf - tapestry or jsf - wicket. Btw. spring webflow is only used for flow logic. Even the authors don't recommend writing your entire application with it.
But you also mix ton of stuff here :
Jsf and I believe Tapestry and Wicket are also front controller based, check out the JsfServlet. The fact that a component abstraction exists doesn't disallow the use of a front controller.
About Spring web flow, you are like a lot of people confusing the input controller as the C in MVC and the application controller which according to fowler books are two very different beasts. Spring Web Flow is used to implement the applications controller not the input controler even though most of the time the input controller only delegate to the application controler but the fact remains : you still need an input controller. Hence web flow prove some integration layers to be able to plug in with most of the different MVC frameworks out there.
|
|
|
Message #230339
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF and JDO do have a lot in common...
Whether you're a JSF supporter or not, JSF is here to stay, and there's no point in not being part of it
On a similar note, even if you disagree with the war in Iraq you should still support the president, right?
The goals listed for JSF sound great. That's mostly because they are cherry-picked from more innovative projects. For example, the use of annotations and zero-XML configuration is something already seen in Stripes. Tying into JPA? Sounds a lot like Seam. Make it easy to create CRUD apps? Sounds a lot like Grails (which is inspired by Rails of course.) Moving more of the controller bits to the client sounds a lot like GWT.
The problem is that by the time JSF gets around to all this, there will be new innovations out there.
Isnt that the goal of a spec, a spec should not be state of the art, but one step behind, because, then you can use patterns which work best. Sorry to say that but if you go the spec route then you are more or less on the save side, if you dont, you will get the latest toys. btw. one of the things you listed here already is heavily jsf based (Seam)
|
|
|
Message #230351
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: competing specs
Struts and spring webflow are not specifications and on top of that, they are not even component frameworks. they are front controller frameworks. An apples to apples comparison would be jsf - tapestry or jsf - wicket. Btw. spring webflow is only used for flow logic. Even the authors don't recommend writing your entire application with it.
But you also mix ton of stuff here :
Jsf and I believe Tapestry and Wicket are also front controller based, check out the JsfServlet.
I mean FacesServlet...
|
|
|
Message #230352
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
concepts
Jsf and I believe Tapestry and Wicket are also front controller based, check out the JsfServlet. I mean FacesServlet...
of course all these frameworks have some technical mechanism to integrate with the underlying servlet technology, and you may call that a front controller if you choose.
The significant point is however, that this mechanism, and thus most of the "controller" concepts mentioned here, are at a much lower level of abstraction than the metaphors used by frameworks like JSF, Tapestry and Wicket (where I really hesitate to include JSF). The latter are event- and object-oriented, while I would call the former request- or action-oriented.
|
|
|
Message #230354
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JavaServer documentation
on thing I really think they need to improve on is the API/Tag library documentation. I have never seen anythin as bad as the stuff that comes with JSF (see http://java.sun.com/javaee/javaserverfaces/1.2/docs/tlddocs/index.html). Just have a look at the simplest of all examples, the docs for the f:verbatim tag:
Create and register a child UIOutput component associated with the closest parent UIComponent custom action, which renders nested body content
This IMO carries absolutely NO immeiately usable information for the end user, who should be the prime audience for this text. In fact most of the docs read like a low-level JSF implementation spec.
The fact that this has gone so little noticed demonstrates to me how little the technology is actually being used.
|
|
|
Message #230358
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JavaServer documentation
on thing I really think they need to improve on is the API/Tag library documentation. I have never seen anythin as bad as the stuff that comes with JSF (see http://java.sun.com/javaee/javaserverfaces/1.2/docs/tlddocs/index.html). Just have a look at the simplest of all examples, the docs for the f:verbatim tag:
Create and register a child UIOutput component associated with the closest parent UIComponent custom action, which renders nested body content
This IMO carries absolutely NO immeiately usable information for the end user, who should be the prime audience for this text. In fact most of the docs read like a low-level JSF implementation spec.
The fact that this has gone so little noticed demonstrates to me how little the technology is actually being used.
Well what you linked is just basically the javadoc generated documentation, this is enough if you already know how to apply the tags.
I agree Sun could work on beginners docs on their site,
like they did with java in the early days. But I do not agree with the conclusion, there are lots of jsf users out there, you can see that at the traffic in the myfaces mailinglist, the main thing is, that most of them revert probably to other resources like http://www.jsfcentral.com/
( a quick googeling towards jsf tutorial will also reveal links ),
for their beginners documentation. All I can see is a lack of documentation for beginners on Suns site, but the documentation issue is not a problem of the core specification, more a problem on Suns part and could be fixed outside of a jsr. (and should be IMHO asap)
|
|
|
Message #230361
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JavaServer documentation
I dont know about everybody else, but I usually look at the javadoc comments for immediate usage tips, and I certainly dont expect to find stuff like the example below, which is from the javadoc for the h:message tag. "apalling" is the word that comes to my mind when I see this. Note that the formatting is exactly as in the original.
Obtain the "summary" and "detail" properties from UIMessage component. If not present, keep the empty string as the value, respectively. Obtain the first FacesMessage to render from the component, using the "for" property of the UIMessage. This will be the only message we render. Obtain the severity style for this message. If the severity of the message is FacesMessage.SEVERITY_INFO, the severity style comes from the value of the "infoStyle" attribute. If the severity of the message is FacesMessage.SEVERITY_WARN, the severity style comes from the value of the "warnStyle" attribute, and so on for each of the severities, INFO, WARN, ERROR and FATAL. The same rules apply for obtaining the severity style class, but instead of "infoStyle, warnStyle", etc use "infoClass, warnClass", etc. Obtain the "style", "styleClass" and "layout" attributes from the UIMessage component. If we have a "style" attribute and a severity style attribute, use the severity style attribute as the value of the "style" attribute. If we have no "style" attribute, but do have a severity style, use the severity style as the value of the "style" attribute. The same precedence rules apply for the style class. Obtain the value of the dir and lang attributes
|
|
|
Message #230363
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: concepts
Jsf and I believe Tapestry and Wicket are also front controller based, check out the JsfServlet. I mean FacesServlet...
of course all these frameworks have some technical mechanism to integrate with the underlying servlet technology, and you may call that a front controller if you choose.
Yes I call this a front controller because it is exactly one according to the pattern : a single point in charge of handling the request and dispatching the treatment to the corresponding event handler.
In fact, the only difference between a front controller and a page of servlet is that in the case of a front controller there is only one servlet handling all the different requests while in a page controller application, you have usually one servlet for one type of request. So all the frameworks using only one servlet as a single point entry are front controller based and therefore it's wrong to pretend JSF as I have seen many times is not based upon the front controller pattern.
The significant point is however, that this mechanism, and thus most of the "controller" concepts mentioned here, are at a much lower level of abstraction than the metaphors used by frameworks like JSF, Tapestry and Wicket (where I really hesitate to include JSF). The latter are event- and object-oriented, while I would call the former request- or action-oriented.
It has nothing to do with the front controller pattern and that's my point. In all those frameworks, maybe it be Struts, Spring MVC, JSF, Tapestry, Wicket, ... there is only one place where is the request first handled (one servlet) : the front controller. After that the controller dispatch to the correct event handler. In action oriented frameworks the events are not fine grained and so map to request events while in a component based framework they map to component events in a more fine grained fashion. Even if the nature of the events is different in those two frameworks, it doesn't change the facts that it is the front controller job to dispatch to the correct handler. You can't say JSF is not front controller oriented even though it used a component metaphor. The front controller pattern just states that a central point handles and dispatch all the request, that's all.
I understand that the OP wanted to distinguish action and component oriented frameworks but the terminology wasn't right at all and confusing. I just wanted to correct it. Other than that, I agree those kind of frameworks are very different.
|
|
|
Message #230479
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF and JDO do have a lot in common...
The goals listed for JSF sound great. That's mostly because they are cherry-picked from more innovative projects. For example, the use of annotations and zero-XML configuration is something already seen in Stripes. Tying into JPA? Sounds a lot like Seam. Make it easy to create CRUD apps? Sounds a lot like Grails (which is inspired by Rails of course.) Moving more of the controller bits to the client sounds a lot like GWT.
The problem is that by the time JSF gets around to all this, there will be new innovations out there.
Sure. That's the nature of standards. JSF is a spec, not a product. The best we can do is ensure that it's a good spec which incorporates as many current innovations as possible. There will always be something else out there that's doing something different and innovative. Hopefully, we'll be able to incorporate those innovations in the next rev of the spec.
---
Kito D. Mann - Author, JavaServer Faces in Action
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
|
|
|
Message #230489
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF and JDO do have a lot in common...
Sure. That's the nature of standards. JSF is a spec, not a product. The best we can do is ensure that it's a good spec which incorporates as many current innovations as possible.
The problem is that unlike JSP, which started as a product and then became a spec, JSF started as a spec from day 1.
|
|
|
Message #230498
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF and JDO do have a lot in common...
Sure. That's the nature of standards. JSF is a spec, not a product. The best we can do is ensure that it's a good spec which incorporates as many current innovations as possible.
The problem is that unlike JSP, which started as a product and then became a spec, JSF started as a spec from day 1.
Not quite true, JSF started as a product from Oracle and then became a spec.... (Ok the original Oracle framework didnt have too much in common with the final 1.0 jsf specs, but nevertheless, the origins are there.)
|
|
|
Message #230544
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF and JDO do have a lot in common...
Werner, that's simply not true. And as the Oracle rep on the JSF EG from day one, I'd know... I'm assuming you're talking about UIX here. While I do know that some of the ideas in UIX did make it into JSF (named children became facets) or are analogous (BoundValues are like ValueBindings), JSF in no way started as UIX.
|
|
|
Message #230563
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSF and JDO do have a lot in common...
Werner, that's simply not true. And as the Oracle rep on the JSF EG from day one, I'd know... I'm assuming you're talking about UIX here. While I do know that some of the ideas in UIX did make it into JSF (named children became facets) or are analogous (BoundValues are like ValueBindings), JSF in no way started as UIX.
Ok then sorry for this, It was sort of a misunderstanding from my side, I was talking about UIX... thanks a lot for the clarification.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
