(future-)abilities of JSF !!?? @ JSF-developers

Hi!
We've got a Struts-based WebClient. In the near future we need to decide, wether we'll use the struts-faces integration library or to drop struts completely and integrate client's functionality into JSF.
Now my important question: What will JSF implement in future (compared to current struts-functionality)? eg:
- will JSF be able to handle declarative exception handling?
- will there be a plug-in mechanism like in struts?
- what about sub-application ?
- will JSF-event-handling, etc. be as powerfull as struts' action-mechanism?
maybe i didnt read the spec. enough, but i didnt find anything related to mentioned questions
thanks in advance

Keep in mind that JavaServer Faces is a UI component framework, primarily focused on what is happening inside a single page. It is not (by itself) a web application framework -- at least not in a 1.0 time frame. Further answers and thoughts below:
- will JSF be able to handle declarative exception
handling?The Struts way of doing this (your Action.execute method actually throws an exception) is not supported today; however, you can set up something similar by using logical outcomes to indicate that an error occurred, and creating navigation rules to redirect to a particular output page.
- will there be a plug-in mechanism like in struts?Servlet 2.3 (required minimum for JavaServer Faces) already provides ServletContextListener, which does the same thing as Struts plugins, so we don't need anything special for this in Faces.
- what about sub-application ?JavaServer Faces does not have a concept of sub applications, since it is focused on single pages.
- will JSF-event-handling, etc. be as powerfull as
struts' action-mechanism?I would suggest that JavaServer Faces support for server side event handling is already more powerful than the Struts concept of actions, but you'd have to be more specific about what you'd want to accomplish in order to know if you agree.
maybe i didnt read the spec. enough, but i didnt find
anything related to mentioned questions
thanks in advanceCraig

Similar Messages

Why did Mozilla (v.4) erase all my bookmarks which existed yesterday? Can these kinds of disasters happen again in the future with Firefox? Mozilla developers: we are living in 2011...

Why did Mozilla (v.4) erase all my bookmarks which existed yesterday? Can these kinds of disasters happen again in the future with Firefox? Mozilla developers: we are living in 2011...

Firefox makes bookmark backups daily in the following location: C:\Documents and Settings\{Username}\Application Data\Mozilla\Firefox\Profiles\123xxx.default\bookmarkbackups (where "123xxx.default represents a randomly named folder).
To restore from one of them, hit CTRL+SHIFT+B to open the Bookmarks manager and then click "Import and Export" | Restore and choose a date. See screenshot.
Before you do that though, could you please hit CTRL+I
Can you see any Bookmarks in there?

JSF Shopping List

Hi all....my development team has been working in a web framework for the past 8+ months and we have hit a few serious roadblocks. I'm considering spearheading a switch to JSF, but I need to know if it will meet our requirements. After a perusal of O'Reilly's JSF book, by Hans Bergen, I have a general feel, but I'm interested in your opinions & experiences--e.g., the framework we're using claims to have certain functionality, but it's clearly broken.
Some of the items on this list have obvious answers & some are answerred in the O'Reilly book, but I'm interested in confirmation from you, the folks in the trenches.
Thanks in advance for your help,
- Mike
Shopping List:
General Items:
- what are JSFs biggest drawbacks if I were to use it as an enterprise technology for the next 5 years?
- what are the biggest problems with Facelets?
- if I use Facelets, do I still have to be a JSP guru?
- what are the best books on JSF?
- which is better, MyFaces or RI?
Specific Items:
- does JSF have the ability to create a library of reusable components?
- backwards compatibility of components as new versions are released?
- server-side and client-side validation?
- can I easily create custom validation components?
- does JSF have any glaring concurrency issues?
- can I programmatically add components to a page at run time?
- does JSF require me to use JDK1.5, or can I use 1.4?
- does JSF support a single application properties file for i18n?
- does JSF support per-page properties file for i18n (that override what is in the application file)?
- can I easily display a single page in a different language?
- does JSF allow for page inheritence? (can I create custom sub-pages from a generic parent "SearchPage"?)

I'll answer the things that I can. You cover quite a range with your questions though...
- what are JSFs biggest drawbacks if I were to use
e it as an enterprise technology for the next 5
years?- JSF is still a young technology and will likely undergo a number of changes that will break backwards compatibility.
- Performance could become an issue on very large applications.
- what are the biggest problems with Facelets?- There are a number of little "got'cha's" once you start getting into it. Expect to be writing a number of custom validators and components.
- There is a lack of control over the faces lifecycle, which can frustrate attempts to skip phases.
- if I use Facelets, do I still have to be a JSP
P guru?Not at all. Faces actually takes over for JSP quite nicely, especially once you realize it's full capability. However, it doesn't hurt to have minimal knowledge of JSP. Nothing more than a developer worth his salary couldn't learn in a day or two.
- what are the best books on JSF?I like Core JavaServer Faces by David Geary and Cay Horstmann. Partial book is online:
http://www.horstmann.com/corejsf/
- which is better, MyFaces or RI?Hah! This could start a few wars. Honestly, haven't looked much at MyFaces but I know that it just extends the RI with some extra components. Most people who use MyFaces swear by it. However, I wrote an entire enterprise application with just the RI and my own customs. Works great!
- does JSF have the ability to create a library of
f reusable components?Yes, absolutely. I did this with my app and the new library will be very helpful to future projects.
- backwards compatibility of components as new
w versions are released?Ok... Here you might have a few problems. I've already heard rumours of JSF 1.2 breaking a lot of 1.1. I know that there were major changes between 1.0 and 1.1 too. The JSF developers do not seem to be terribly concerned with backwards compatibility.
- server-side and client-side validation?Server-side only. You'll need to use a client-side technology (such as JavaScript) for client-side validation. However, JSF components offer JavaScript hooks, so you can easily execute functions onchange, onclick, onblur, etc...
- can I easily create custom validation components?Easy is a relative term. =) Not always. Writing customs will require a high learning curve. How easy it is depends on what you're doing and how closely you're tying it into other pre-existing components/validators/converters. After each custom you write, it starts getting a little easier.
- does JSF support a single application properties
s file for i18n?I'll hazard a guess on this one, don't quote me on it. A separate message properties file is required for each locale. The message bundle will choose the appropriate one for each locale.
- does JSF support per-page properties file for i18n
n (that override what is in the application file)?I think not. Again, just guessing here.
- can I easily display a single page in a different
t language?Yes, actually this is quite easy. Assuming you set up the locale properly, you just need to use the h:outputText component with f:loadBundle to retrieve the messages.
Hope this helps,
CowKing

JSF - Where is it going?

Hi All,
I make the following observations relating to SUN's behavior in dealing with JSF developers and early adopters:
1. There has been no response from SUN in regards to what are the fixes and/or enhancements in the NEW EA4 (for lack of a better version scheme).
2. There is a school of thought that for successful software projects you need to release versions often (even with small improvements). This has been amply demonstrated by other projects like Eclipse etc. But we have no idea if for the next two years we will get the next version of JSF. Sounds like a research project to me.
2. The project has progressed extremely slowly. JSF has been in development for more than 2 years now. And what do they have to show for progress?
3. There are a number of bugs and poor design choices.
4. There is an attitude of "We know what is best for you. We will take you along." There is little learning from other projects. Even MyFaces with a few developers have improved the original JSF concepts but there is no acknowledgement that these ideas will get included in JSF future.
5. Very few standard components.
It is very disconcerting that SUN deals with their flagship products in this manner. I call it flagship because JSF is the product that will compete with .NET FORMS which is so successful and lures developers easily.
Is there someone listening here or are we developers making a MISTAKE in devoting our energies to JSF?
Two years and this is the output? Do they realize that this is more important than EJBs?
Does the JSF team even have a Product Manager? Do they have a product road map? Are these communicated to the developers?
I hope developers realize the reality of current state of JSF and unite to ask these and other questions before figuring out how to handle some button events. It is not your fault that the command_button has a bug!
Hoping that these questions will make a few people wake up.
Sincerely,
Vinay Soni

Hello Vinay,
Thank you for your interest in JavaServer Faces. Please understand that
we're not ignoring the forum. The forum is constantly monitored by the
JSF engineering team. Unfortunately, the team has to make resource
allocation decisions that cause forurm replies to be delayed in favor of
developing and increasing the quality of the next release of Faces.
VS> I make the following observations relating to SUN's
VS> behavior in dealing with JSF developers and early
VS> adopters:
VS> 1. There has been no response from SUN in regards to
VS> what are the fixes and/or enhancements in the NEW EA4
VS> (for lack of a better version scheme).
We're not at liberty to share the set of new features just yet, but I
can say that we'll have a beta release out to the public before the end
of calendar year 2003.
VS> 2. There is a school of thought that for successful
VS> software projects you need to release versions often
VS> (even with small improvements). This has been amply
VS> demonstrated by other projects like Eclipse etc. But
VS> we have no idea if for the next two years we will get
VS> the next version of JSF. Sounds like a research
VS> project to me.
Sure, we're aware of and adhere to the XP practice of constantly
releaseable software, but since we're not doing JSF as an open source
project, we have to go through the closed source release machinery.
This reduces the number of releases we can do.
VS> Is there someone listening here or are we developers
VS> making a MISTAKE in devoting our energies to JSF?
You are not making a MISTAKE. You are investing in the FUTURE of web
application UI development.
VS> Does the JSF team even have a Product Manager? Do they
VS> have a product road map? Are these communicated to the
VS> developers?
JSF is not a product. It is a specification and reference
implementation. Several vendors, including IBM, Sun and Oracle, will be
providing product implementations of JSF.
Thanks again for your interest,
Sincerely,
Ed Burns
Co-SPECIFICATION lead of JSF.

Is this a fare assessment of JSF (RI 1.1)?

After playing with JSF for a week, I need to tell my manager what I think of JSF. If anyone takes issue with anything I've written below, I'd be interested to hear from you.
David
JSF generates HTML its own way. The commonly adopted process of producing a page design in pure HTML, getting the layout 'just so', then implementing a dynamic version doesn't work with JSF because you can't hope to generate exactly the same HTML. You find yourself having to adapt the screen design to fit in with JSF's way of doing things, or at least come up with a different HTML solution that can be generated by JSF.
The following is a commonly occurring frustration with JSF development: You know how you would achieve something using fundamental principles (e.g. servlets, HTML and scriptlets) but you can't find a way to make JSF achieve the same thing. It often feels like a battle, trying to get JSF to do something that would be quite straightforward if you had more control.
Some of the UI control types are restricted in the ways they may be used. For example, the h:selectOneRadio component, which models a radio button group, assumes all the buttons are located within the same parent element without any interspersed HTML between the buttons. There are many cases where this is too restrictive, e.g. a design where each row of a table begins with a radio button (as a means of allowing the user to select only a single row of the table).
Some control types are not provided (at least in Sun's Reference Implementation), e.g. HTTP file upload. You can implement your own custom components, but this is not trivial.
Quirky behaviour during development slows you down. For example, actions not firing when command buttons are clicked turns out to be due to unreported page translation problems. Have to deduce what's causing the problem by selectively commenting out different portions of the page.
The Sun JSF RI is buggy. After running into a few problems and consulting the Sun JSF forum it becomes clear that the current Sun RI (1.1) suffers from a significant number of awkward bugs.
Limited ability to manipulate the GUI using client side scripting (e.g. to add new rows to a data entry table without the need for a round trip to the server).
JSF is designed to be used with tools but tool support is currently not great. Sun Java Studio Creator looks good on paper but is rather clunky in practise. Its page layout editor only allows components to be positioned absolutely (i.e. fixed size and co-ordinates). This negates one of the great virtues of HTML, i.e. that it can allow content to flow naturally and components can be positioned according to CSS rules.
In summary, the promise of rapid development with JSF is not achieved in practise due to a variety of problems. Many of the problems are to do with the immaturity of JSF. However, the lack of control over the generated HTML (assuming it's impractical to implement custom components to solve each new requirement for custom HTML) seems to be an inherent restriction.
End

Layout is way to restrictive when using tables for rendering in JSF. This is an RI issue, and most likely not the spec as I am sure the spec does not say layout must be implemented with tables.
I am not sure I agree with your comment that a JSP, Servlet, HTML, CSS, javascript developer is less productive than a competent JSF developer. I think JSF is a great prototyping tool, but I don't think it is as flexible as using the fundamental technologies leveraged by JSF. I run into situations where I have to customize components straight from the fundamental tehcnologies. Based on this experience, I will run into situations where the components in JSF will require some sort of customization for a customer. I have found customers that are picky about the presentation and will move components around sometimes as little as a couple pixels. Or they will require slightly different behavior in a component than what is default. The other thing I have learned working in a corporation is that branding changes every couple years. How much investment should it take to rebrand all your JSF pages when you can make it so your pages created in fundamentals leverages one CSS for the entire site? Then when the rebranding comes, all you need to do is modify the CSS and not the JSFs. In particular, I am referring to layout and not look.
Let's say a new javascript or AJAX library comes out with some whiz bang widgets. It is a lot easier to develop with that code in fundamental technologies than in JSF. We can see this with AJAX. AJAX capabilities have been around for a while now, but JSF is playing catchup. That means, if you wanted to take advatage of the benefits of AJAX when it was first around, you would have to write custom code or wait for the widgets to come out. What would have google done for google maps if they had to wait around for JSF to catch up(if hypothetically they are using j2ee)? After all, I am certain they haven't received nice publicity which turned into revenue of some sort by being an example of AJAX design. Where would AJAX be without compelling examples of AJAX? It might still be a side note or we would be using the javascript calls directly to do the asynchronous call back to the server. So, there is something to be said about not having to wait for JSF components to manifest themselves. However, that is not to say that google couldn't have invested in its own set of components, but I am not google and I consume already created components or I put the new widgets directly in the page without leveraging the JSF lifecycle. But your choice in JSF is either to use f:verbatim or create the JSF components. Does your boss want to invest in creating JSF components that may or may not be reused? This is a tough question all bosses should ask whenever venturing down the road of extra development for purposes of reuse. When is the return going to be realized on the investment in creating components? In addition, corporations like to reorganize their business units such that the project may or may not survive the reorg. Where is the investment now? If I was a boss, I would not want my developers creating reusable components as it is a distraction. If I run a second project, I might then look into creating reusable components out of the work from the first project. But I certainly would not do it on the first project. You have no way of knowing if that code will be reused. Essentially, anytime something new that comes out that could be leveraged swiftly in an HTML page, requires more work on the JSF developers part.
By the way, I have to learn how to use f:verbatim correctly. Currently, code that I have stuck in f:verbatim is being rendered outside a subview. I might be using this incorrectly though. I am also using dwr, which I am unsure if I can incorporate into a JSF subview/view without f:verbatim since dwr requires calling a dwr servlet and not the faces servlet. I guess I might be able to get around this by assigning the action on a form dynamically to call dwr instead of faces.
Just my 1/2 cent(I try not to spend my two cents all at once),
TacoEater

Custom error messages impossible with jsf ea4??

Hello,
Does jsf allow custom error messages for built-in validators?
I was told by a member of the jsf team that what is described in the tutorial applies only to future versions of jsf.
Is this a bug? If it isn't and if it is indeed possible to have your own error messages for built-in validators, I would be grateful for someone of the jsf team to help me.
I have already posted some messages asking for help but I never got any answer.
Julien

If a validator wants to add an error message to the current page, it has to call FacesContext.addMessage() with a javax.faces.application.Message argument. The design intent is that you can look up localized messages (defined in the config file) via MessageResources -- that's the part that does not work right now.
In the interim, though, you can construct your own Message instances by leveraging the MessageImpl class:
context.addMessage
(new MessageImpl(Message.SEVERITY_ERROR,
"You goofed",
"Here are the gory details..."));
or look up the message strings from a resource bundle.
Craig

JSF 1.2 performance is not adequate

Sun JSF developers...
JSF 1.2 performance is not adequate.
Here is a simple use case to prove:
Render a table with ~100 columns and ~1000 rows (with facelets)
(you could increase the numbers to stress test)
using h:dataTable tag.
You have to repeat h:column hundred times in XHTML (to create bigger
UI component tree).
Have a backing bean with 100 properties and JSF action which returns
list of 1000 those beans.
In this case there is no DB interaction, no back-end involved.
Have your application set up with Ajax4Jsf (so it goes via its filter). You could
also compare the results with and without it.
Measure RENDER RESPONSE phase, and overall response time.
Compare with JSP which renders same table from same bean.
This is very simple test case to write and you will see that JSF in current state is really slow.
This test could also be used to measure performance of new versions to see where they stand.
It would be also interesting to see how render time grows with increase of
number of columns (number of components in UI tree) (Is it linear or not?)
How fast does it grow with the number of rows (Is it linear growth with increase of data size?)
I believe this type of tests should be standardized before each release.
Does JSF development team perform regular profiling of JSF RI java code?
Running profiling for this use case could also reveal interesting things which
could be improved.
Regards,
--MG

But you have done nothing here to determine if itscales linearly or not.
See below.
You increase number of columns (rows) and measure
time.
When you draw on a chart how time grows with increase
in number of columns (rows) you will see if it linear
or not.
I understand how to determine the growth rate; I was merely pointing out that you have only claimed to run one test and one cannot determine the growth rate from that.
It would be also interesting to see how render timegrows with increase of
number of columns (number of components in UI tree)(Is it linear or not?)
How fast does it grow with the number of rows (Isit linear growth with increase of data size?)
Unless you are talking about spreadsheets I doubtthese apps are useful.
They are very useful.I bet they would be more useful as native desktop apps.
>
But this is besides the point; my point is that thescenario of having a large number of components on a
page does not occur often in real applications.
Really? You are not serious?Yes I am serious. I can see we have different perspectives here.
>
A much more common performance scenario is highload.
This is separate story. I'm talking about latency of
loading one page.
Please do not confuse latency and bandwidth.I am not talking about bandwidth but throughput.
>
BTW most of the web sites have small number of
concurrent users,
so the most common scenario is actually exactly
opposite.
Low load but complex pages with lots of components on
them.Again, I can see we have different perspectives here. My experiences are the opposite.
>
So your results will be much more useful if youinclude a load test on a moderately sized page. I'm
not dismissing your original test as invalid or
useless.
My results are more useful than what you are
proposing, as they help to pinpoint the cause of
latency. You could run my test with profiler and
investigate the root cause of it.You do not need to increase the number of components on the page to numbers beyond practice in order to determine this. It is sufficient to run profilers on average pages many times and determine where the most time is spent. In fact, your approach may result in an implementation optimized for pages with a large number of components but not for pages with a lower number of components.
>
My point is that the user experience is not degradedby the performance but by the poor presentation of
information. Many web browsers to not take kindly to
such large tables as well.
With JSF user experience is degraded by performance.I'd like to see your numbers and the code you used.
JSF makes it easier
to do nicer user presentation, but performance
suffers to degree that it is not usable in number of
cases.
JSF inability to generate page fast on server side
has nothing to do with browsers.Correct; but I was talking about pages with large tables in general and why they are a bad idea for web applications. A native application is more appropriate. But this is orthogonal to the purpose of this thread.
>
Again, you are missing the point. Perhaps JSFperformance differs between the application servers.
A fair and useful test will determine that. I'm not
talking about the relative performance vs JSP here.
If JSF does things inefficiently in its code it will
show consistently bad results
across all app servers. Again my test is to detect
and pinpoint JSF inefficiencies and not app servers
ones.
Don't you think JSF developers would want to look for
it first rather than investigating why it perform
badly on some particular app server because of
its internal reasons.I'm approaching this from the perspective of a developer evaluating whether to use JSF and which application server to use. This is very useful from this point of view.
As far as the JSF developers go, as I noted above one does not need to scale out the number of components on the page to determine performance bottlenecks in the implementation. An average case is more appropriate.
Also, if you are going to compare JSF to other technologies you need to try a variety of platforms for both. Some application servers might do JSP better than others. If you limit yourself to one platform you run the risk that it is skewing the comparison one way or another.

Replace JSF tag by an own tag

Hi,
I'm trying to replace a <h:inputText> by my own tag. The used HtmlInputText component should not be replaced.
The reason is, that i want to pass permissions to the tag and map them to readonly and rendered attributes. My Problem is, that my own tag doesn't reolv bean values. If i use the <h:inputText> the bean values show up correctly. If i use my own tag, the input text shows "#{myBean.value}".
What could be the problem?
Thx in advance
Henrik
Here is my tag:
import javax.faces.component.UIComponent;
import javax.faces.component.html.HtmlInputText;
import javax.faces.context.FacesContext;
import javax.faces.webapp.UIComponentTag;
import com.arvato.jsf.security.JSFSecurity;
import com.arvato.jsf.security.Permissions;
import com.sun.faces.taglib.html_basic.InputTextTag;
public class ArvatoTextFieldTag extends InputTextTag {
    private String role;
    private String onkeypress;
    private String id;
    private String value;
    public String getRole() {
        return role;
    public void setRole(String permissions) {
        this.role = permissions;
    protected void setProperties(UIComponent component) {
        super.setProperties(component);
        if(id != null) {
            component.getAttributes().put("id", id);
        if(onkeypress != null) {
            component.getAttributes().put("onkeypress", onkeypress);
        if(value != null) {
            component.getAttributes().put("value", value);
        if(role != null) {
            FacesContext facesContext = FacesContext.getCurrentInstance();
            Permissions p = JSFSecurity.getInstance().getPermissionsForRole(role, facesContext);
            if(!p.isWritable()) {
                component.getAttributes().put("readonly", true);
            if(!p.isReadable()) {
                component.getAttributes().put("rendered", false);
        } else {
            component.getAttributes().put("readonly", false);
            component.getAttributes().put("rendered", true);
    @Override
    public String getComponentType() {
        return "javax.faces.HtmlInputText";
    @Override
    public String getRendererType() {
        return null; // no standalone renderer
    @Override
    public void release() {
        super.release();
        role = null;
    public String getValue() {
        return value;
    public void setValue(String value) {
        this.value = value;
    public String getOnkeypress() {
        return onkeypress;
    public void setOnkeypress(String onkeypress) {
        this.onkeypress = onkeypress;
    public String getId() {
        return id;
    public void setId(String id) {
        this.id = id;
}and my tld definition:
<taglib>
   <tlib-version>0.03</tlib-version>
   <jsp-version>1.2</jsp-version>
   <short-name>arvato-jsf</short-name>
   <uri>http://arvato.com/jsf/component/tags</uri>
   <description>Arvato JSF tags</description>
   <tag>
      <name>textfield</name>
      <tag-class>com.arvato.jsf.tag.ArvatoTextFieldTag</tag-class>
      <attribute>
         <name>id</name>
      </attribute>
      <attribute>
         <name>role</name>
      </attribute>
      <attribute>
         <name>value</name>
      </attribute>
      <attribute>
         <name>onkeypress</name>
      </attribute>
   </tag>
</taglib>

In the setProperties method, you've got to resolve the valuebinding (#{blah.whatever}) to get the actual value. But you only want to do that if the attribute is set to a valuebinding.
Here's an example:
      * @see javax.faces.webapp.UIComponentTag#setProperties(UIComponent)
     protected void setProperties(UIComponent component) {
          super.setProperties(component);
          //Set the field reference property
          if (fieldRef != null) {
               if (UIComponentTag.isValueReference(fieldRef)) {
                    ValueBinding vb = getFacesContext().getApplication().
                         createValueBinding(fieldRef);
                    component.setValueBinding("fieldRef", vb);
               } else {
                    component.getAttributes().put("fieldRef", fieldRef);
     }This example shows how to determine if the "fieldRef" attribute is a value binding, and extracts the value accordingly. But there's one more step. In your component class, or anywhere you access the attributes of your custom tag, use the following code:
     public String getFieldRef() {
          if (fieldRef != null)
               return fieldRef;
          ValueBinding vb = getValueBinding("fieldRef");
          if (vb != null)
               return (String)vb.getValue(getFacesContext());
          else
               return null;
     }The above snippet is what you would put in your custom component getter method.
JSF is open source. Something I found very helpful while learning how to create custom components was looking at how the JSF developers created theirs. You should go ahead and download the JSF source code.
CowKing

JSF 1.0 - JSF 1.1 - new Release

JSF 1.0 have the back button bag. For this reason I could not use it for my application or at least I could not release my application with JSF 1.0 because of it.
JSF 1.1 have multiple form bug. I cannot use it as well, because my application needs multiple forms. I tried to switch to one single <h:form> tag encapsulating the entire page but to many buttons are not working any more. I need <f:verbatim> tags to put some static HTML like flash for example. All buttons after <f:vrbatime> .. </f:vrbatime> are not working any more.
I think there is definitely a need for an JSF 1.1 beta or whatever you call it, that will have fixed these two bugs. They are so essential that more than 30% all postings in last moths are only dealing with these issues.
My project is getting delayed because of this and I will soon have problem explaining our customer why they have to wait longer.
I would appreciate it very much if JSF developers could please comment this and let us at least know if we can expect the new release soon. I think the most people in this forum have same problems delaying projects because of these two bugs.
Thanks a lot in advance:
Nermin B.

Hi,
Why don't you try MyFaces ?
it works great !
No problem with what you talked about with it.
Frederic

JSF 1.2 + Tiles 2

Dear JSF developers,
I tried to find a working example of JSF1.2 + Tiles 2 but I failed.
Do you know where I can get one in internet? I made a lot of example by myself including the example for Core JSF book, ch.8. It always has problems.
Thanks in advance for any idea.
Pengyou

try this link [examples from JavaPassion|http://www.javapassion.com/handsonlabs/jsftiles/]

Help me about Initialization in JSF

Could JSF developers give me a way to call method (ex: obj.init();) once when the first visitor visit my site?
Many thanks

3. code just use general jsp and java code(can't work):
<%
UserListBean userlistBean = (UserListBean)FacesUtils.getManagedBean("userlistBean");
int start = userlistBean.getStartPageOfShowPage();
int end = userlistBean.getEndPageOfShowPage();
%>
<%
for(int i = start; i < end; i ++){
System.out.println(i);
%>
<td>
<h:commandLink action="#{userlistBean.searchAction}">

<h:outputText value="<%=i%>"/>
<f:param name="pageNo" value="<%=i%>"/>
</h:commandLink>
</td>
<%
%>
BTW, I think that JSF must provide a standard iterate or direct use JSTL�s <c:forEach> tag, <h:dataTable> is a nice choice for tabled data but not so good for common var iterate just like my need.
Someone had told me that oracle' ADF is a choice. but I refuse to use oracle's ADF and like to find a standard and easy way. I think high of simple and independent solution.

Need help on JSF Development

Hi guys,
I've been used to create web applications by using JSP and Servlet technologies as well as NetBeans 5.5 for business classes development and Dreamwaver for visual web pages development.
So far so good, however, from now on, due to customer requirements, some new small projects must be created by using JSF technologies.
I've already read both JavaServer Faces in Action book from cover to cover and J2EE 1.4 Tutorial chapters which covers JSF, so that I could gain a good understanding and knowledge regarding commmon things needed to start developing by using JSF.
The problem which I need your help guys is regarding which tools you "JSF Developers" use to create your web applications.
Althrough Dreamwaver is a great tool for visual html formatting and I'm very used to, I found very painful to replace the common html tags by the jsf tags right after the page layout is done.
I would like to include such jsf tags in the first time I design the web page layout instead of first develop the page layout and then replace the html tags.
Maybe Facelets could help but I have no knowledge on how to use it. Could you please clarify ?
Trying to solve such problem, I gave a try to NetBeans Visual WEB Pack but I found it poorer than Dreamwaver for page layout design.
What you guys have been using to create your JSF applications.
Could you please give me some light on this ?
Thanks in advance.

The problem which I need your help guys is regarding
which tools you "JSF Developers" use to create your
web applications.Developers team use Eclipse JBoss IDE.
Designers team use Dreamweaver and Eclipse WTP.
Althrough Dreamwaver is a great tool for visual html
formatting and I'm very used to, I found very painful
to replace the common html tags by the jsf tags right
after the page layout is done.Use Facelets to make some templates.
Maybe Facelets could help but I have no knowledge on
how to use it. Could you please clarify ?Google it , read some tutorials.
Cya.

JSF with Rich GUI Renderers - Swing

Has any one developed a renderer for a Thick Client/GUI such as swing. I know JSF is for web-based applications but with a suitable renderer it could be made to work with a non browser frontend, no ?

You are right.
Don't known about Swing implementation but other interesting ones are available. Have a look at XULFACES for example: http://xulfaces.sourceforge.net/getting-started.html
Anyway AJAX looks to be the "future" of rich JSF implementations. For example MyFaces Tomahawk is working to make a Dojo -http://dojotoolkit.org/- JSF implementation.
I don't known of other JSF implementations for devices like blackberry or Nokia S6x, but would be great too.

[ANNOUNCE] JSF 1.1_02 released!

Please see the announcement here:
https://javaserverfaces.dev.java.net/servlets/NewsItemView?newsItemID=3606

Congrats to the JSF developers on releasing this recent version. Keep up the good work!
CowKing

Announce: Guise framework addresses JSF shortcomings

JSF developers may be interested in learning of the release of a new framework named Guise(TM), which is now available free for development use:
http://www.javaguise.com/
I've been involved in the JSF forum for many months, as I spent countless frustrating hours trying to coax JSF into doing what I believed were simple, obvious things. As you can see on this forum, I've written a whole new value-binding expression syntax and framework just so I could pass parameters to methods. I've had to rewrite several JSF renderers just so the output it creates would not break my XHTML files. I've had to create a new component and associated framework just to upload files. I've kept the JSF community updated with my progress, but eventually I found myself rewriting the JSF framework more than I was writing application code. Guise(TM) is the solution I created for my JSF problems.
I'll admit that I first approached JSF with the wrong mindset, thinking that it was some sort of procedural scripting language like JSP. I soon adopted a component mindset whole-heartedly, only to be disillusioned: although JSF may claim to be definition-file agnostic, in reality it was built on top of JSP and jumps through a thousand crazy hoops just so people can define their components in JSP. Hans Bergsten infamously advocated (see http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html ) dumping JSP to save JSF, but even getting rid of JSF would still leave a framework that scatters type-unsafe strings throughout the source code and multiple configuration files, and provides wildly inefficient event delgation through many error-prone levels of an impotent expression language. That's not even considering finding the right combination of component IDs so that I can send back a validation error that will appear in the correct location on my web page.
I was getting ready to recommend to one of my clients a framework for their redesigned web application. I pondered what I would recommend---JSP+EJB? Struts? JavaServer Faces? In the end I realized that none of these provide anything close to the simple, safe, robust UI frameworks we're used to working with on the client. I wanted something that can be used like Java Swing, yet is simpler and more elegant, and uses generics. Since I was calling the shots, I decided that I wanted the UI to work on the client or across the web with no code changes.
So I wrote Guise(TM)---a graphical user interface framework in Java designed from the ground up to be both simple and elegant. Consider this example "Hello User" program, available at http://www.javaguise.com/demonstration
public class HelloUserFrame extends DefaultFrame
public HelloUserFrame(GuiseSession<?> session)
    super(session, new FlowLayout(Orientation.Flow.PAGE));
    getModel().setLabel("Guise\u2122 Demonstration: Hello User");
    Label helloUserLabel=new Label(session);
    helloUserLabel.setVisible(false);
    add(helloUserLabel);
    TextControl<String> userInput=new TextControl<String>(session, String.class);
    userInput.getModel().setLabel("What's your name?");
    userInput.getModel().setValidator(new RegularExpressionStringValidator(session, "\\S+.*", true));
    userInput.getModel().addPropertyChangeListener(ValueModel.VALUE_PROPERTY,
        new AbstractPropertyValueChangeListener<String>()
          public void propertyValueChange(PropertyValueChangeEvent<String> propertyValueChangeEvent)
            String user=propertyValueChangeEvent.getNewValue();
            helloUserLabel.getModel().setLabel("Hello, "+user+"!");
            helloUserLabel.setVisible(true);
    add(userInput);
}No, this isn't Swing---it's Guise. The above example is all type-safe; the only hard-coded strings for this example is a declaration in the web.xml file binding the class to a navigation path. Forget "backing beans". Forget unsafe strings littering a multitude of configuration files. Try Guise, and you be the judge.
Here are some reasons you may like Guise:
* No JSP!
* Allows the web equivalent of modal dialogs.
* Quick and easy setup.
* Elegant ultra-MVC, with encapsulated models and controllers. No need for complicated backing beans and inflexible expression language---just use Java like you normally would.
* Instantiate components, plug in validators, add action listeners, and report errors directly instead of using cumbersome, error-prone, and type-unsafe strings scattered in various configuration files and source code.
* Java generics supported throughout.
* File uploads built in.
* Customizable, robust, authentication and authorization built in. Client-based authentication and login-based authentication can be seamlessly intermixed.
* Buttons are rendered with real buttons that allow icons and other rich content, and automatically work around the IE button bugs.
* Output is 100% XHTML compliant, with automatic downgrading from content type "application/xhtml+xml" to "text/html" for buggy clients (such as IE 6) which crash when the W3C specification for XHTML content type is followed.
* Validation errors are automatically associated with components, and appear automatically on the web page. An error dialog box is also presented indicating the errors.
* Internationalization is built in. Each application is aware of its supported locales and the selected locale of each session. Set a control model's resource key, and the correct value will automatically be loaded at runtime.
* Parameters can be sent in the URI query string.
* Multiple components can share the same model.
* List selection controls implement the java.util.List interface and support generic values.
* The Guise framework is thread-safe.
I realize that although it's likely the release of Guise will be of interest to the JSF community, in-depth discussion of the framework is probably off-topic for the JSF Forum. I welcome further discussion of Guise, along with inquiries, at [email protected] . Further information may be found at http://www.javaguise.com/ .
Sincerely,
Garret

Ed,
I appreciate your innovation in creating a new
Framework, I'm of course very interested to hear
specifics about why you chose to do so. Which
shortcomings in JSF exactly are you trying to fix?Thanks for the concern. If you look through the posts I've made to this forum, you'll get an idea of the heartache I've went through with JSF. Let me give you an overview. (I've provided appropriate citations to the related forum discussions.)
Iteration
One of the big newbie complaints you'll hear is that JSF won't work with JSTL---in particular, the JSTL iterators. I ran into this problem early on, and decried the lack of no iterator replacement. Adam Winer explained all the "pain... pain... more pain" it would take to create an iterator in JSF that would work with other components. After I became experienced with JSF and dug through the source code for months, I pointed out that UIData already goes through all this pain and needs to be refactored---UIData is really a UIIterator with a tad bit of table-specific stuff thrown in. http://forum.java.sun.com/thread.jspa?threadID=557278
But the complaints and debates about iteration reveal a more fundamental problem with JSF. At its heart it is declarative---a fault it inherits from its close relationship with JSP. Tables, for example, are defined as a static relationship defined forever-in-stone in (for example) a JSP. Because we all want dynamic data in tables, JSF allows us to declare a programmatic relationship between table rows and the table, resulting in secret counters that get incremented and decremented in the background as rendering occurs, along with associated bugs in nested tables. A render phase is simply not the place to put dynamic application logic, but in JSF that's the only place to put it if you follow the paradigm. And you must do the same strange variable counts in the the other phases, just so you can wind up with the correct bindings for the correct row.
Because JSF forces application logic into the render phase, I have to create something like a UIAssignment component that pretends to be a static component in the hierarchy, yet really performs variable assignment as JSF goes through the rendering process. I have to rely on the implementation rendering in the correct order, and I have to add with intricate logic to work around hidden/visible settings that might alter the rendering procedure and hence defeat the assignment algorithm. http://forum.java.sun.com/thread.jspa?forumID=427&threadID=576178
Guise is not built on top of JSP, and hence doesn't force one to put rendering-related hacks into the application code. Check out the elegant Guise table model, for instance. It's very similar to the Swing table model, but simpler, more elegant, and with generics. Rather than play with counters and rendering in the application logic, you can just reference Java objects as you would normally. This entire issue of iteration is also related to the "Loose, Late Binding" issue and the "Impotent Expression Language" problem, which I discuss below.
Loose, Late Binding
Because JSF uses the "pretend not to be tied to JSP but support JSP in the archictecture" paradigm, the components are so uncoupled from the application code that any event logic must use a separate expression language. This language is not checked until runtime. I could put the string "Bill Murray" in an expression, and I'd never know about the problem until someone tries to access that page. Similarly, any expressions are so loosely bound that I don't know to what extent they actually work with my code until I start up the web server.
What happens if I want to respond to an event in JSF? Well, first I have to create a "backing bean," a special mediator to help my components and application work together. Then I have to create an un-typesafe string in a non-Java language that binds something that happpens on the component with the backing bean, which will in response do something with my application. Something like:
<h:commandButton action="#{myBackingBean.doSomething}" value="Test"/>Then (as if this weren't enough) I have to find some configuration file somewhere in order to define my backing bean (it doesn't work automatically). Needless to say, this definition also isn't typesafe and is not verified until runtime. All this just to respond to a button being pressed?
Guise doesn't need an expression language, backing beans, or backing bean configuration files. If I want to repond to a button being pressed, I just listen for it---right in the Java code:
myButton.getModel().addActionListener(...)Everything is typesafe (with generics, I might add). If there's a syntax problem, you'll know it when your program doesn't compile. Your code becomes much more efficient because the expression string doesn't have to be parsed, a variable-binding object doesn't need to be created, and a backing bean doesn't need to be looked up every time the page renders. It just works like you expect Java to work. Simple and elegant.
But the loose, late binding doesn't stop at the expression language. Binding components to IDs in faces-config.xml isn't typesafe. Assigning renderers in faces-config.xml isn't typesafe. In fact, even programmatically creating a component at runtime forces me to use some arbitrary string that isn't tied to anything except some lookup map somewhere that I hope has been properly configured by faces-config.xml and the various components and renderers. Changing component properties at runtime requires several levels of un-typesafe string processing. String, strings, strings---JSF brings Java back to BASIC, as it were.
If I want to create a component in Guise, on the other hand, I do it like I'd create anything else in Java:
Label=new Label(session);If I want to associate a controller with a component in Guise, I'm not just passing around opaque strings. Here's a line out of XHTMLControllerKit:
registerController(Label.class, XHTMLLabelController.class);
Impotent Expression Language
It's bad enough that we have to mess with expression languages, but the JSF expression language is impotent that I can't even pass arguments to methods! (The argument that JSP doesn't allow them either falls on deaf ears---JSF isn't tied to JSP, right?) Doing simple things like selecting an item from a list becomes virtually impossible (if you want to keep your elegantly-factored backend code) without argument passing. That's why I was forced to create an entire new expression language on top of JSF-EL just to allow parameters to methods. http://forum.java.sun.com/thread.jspa?forumID=427&threadID=561520 And (combined with the iteration problem, above) I had to create a UIAssignment that pretends to be a component yet really performs variable assignment in the background, using my extended JSF-EL. http://forum.java.sun.com/thread.jspa?forumID=427&threadID=563036
Internationalization
Support for internationalization in JSF (and even in Swing) is provided in a sort of ad-hoc, last-minute manner. Guise has internationalization support built in from the ground up. Each component model can be given a resource key, which will automatically get the correct data based upon the session locale.
Guise handles internationalization of component layout automatically as well. Check out the internationalization demo at http://www.javaguise.com/demonstration ---just by changing the session locale, the entire component hierarchy reorients itself automatically and loads the correct resources. That's done with one line of application code!
File Uploads
JSF doesn't support file uploads, and I had to concoct an entire file upload framework for JSF. http://forum.java.sun.com/thread.jspa?forumID=427&threadID=464060
Guise has elegant, validating file upload support built in.
In the end, I just wanted to write an application for the web like I would for Swing, without resorting to a mindset of a couple of decades ago when typesafeness was unknown and event delegation wasn't elegant. Since we have Java 5.0, I also wanted to use generics. I just wanted to program using best practices rather than setting up endless text-based configuration files. I wanted Guise(TM). So I wrote it.
Also, would you consider joining the JCP expert group
working on JSF? The whole point of the JCP is to
allow people with big ideas like yourself to help
grow the core platform.On 21 October 2004, I wrote on this forum, "I'm willing (and eager) to join the expert group and put in my effort to help effect these changes in the specification..." http://forum.java.sun.com/thread.jspa?forumID=427&threadID=565052
I then requested directly to join, and Roger Kitain replied that, "Currently, the group has quite a few members, so I'm not adding any more members unless their background is an exceptionally good fit." On 24 January 2005 I provided extensive coverage of my qualifications to both you and Roger.
On 17 March 2005 I indicated I was still willing to join, but Roger had already pointed out the catch on 7 February 2005: in order for me to spend my time and provide my expertise to contribute to the advancement of JSF, I must pay Sun $5,000. It wasn't enough that I was offering my services for free---Sun wanted me to pay them to allow me to contribute to bettering JSF.
I hope this overview answers your question about the shortcomings of JSF. If you have any more questions, I'll be happy to answer them. You may be interested in reading more about the basics of the Guise(TM) framework at http://www.javaguise.com/overview and constrasting the Guise approach to that of JSF.
Sincerely,
Garret

(future-)abilities of JSF !!?? @ JSF-developers

Similar Messages

Maybe you are looking for