Chris Schalk

author
+ Follow
since Aug 31, 2006
jroller.com
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Chris Schalk

You're welcome! I enjoyed it..

I hope everyone enjoys the book!

Regards,
-Chris
15 years ago
JSF

Originally posted by A. Dusi:
Chris,

I am little confused here. This link says that I cannot queue new messages in invoke application phase. And I have experienced the same; the messages were ignored when I add them in the action methods. Hence I always thought that a backing bean validator method is the best place for all the validation logic. Could you please elaborate on when a message is queued in this phase, should it be displayed if the same page is rerendered? What is the purpose of adding it in this phase?

Thanks in advance.



Just because something is posted on the Internet doesn't mean it's correct.. The link you pointed to states something that is incorrect. It claims that... whenever you return from an action, "it's going to cause a requestDispatcher.forward() or httpServletRespones.sendRedirect(). Both of these cause a new FacesContext instance to be created, your queued message is hence lost. "

This is only partially right. The key thing to observe is that when you create a nav rule and you specify you want a redirect..

<navigation-rule>
<from-view-id>/page1.jsp</from-view-id>
<navigation-case>
<from-outcome>navigate</from-outcome>
<to-view-id>/page2.jsp</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule>

Then httpServletRespones.sendRedirect() is used which causes the browser to initiate a new request and in this case a completely new trip through the lifecycle is done and the old message that got queued is gone. This part is correct.

However the JSF-FAQ is incorrect when it says that when requestDispatcher.forward() is used (this is the case when a nav rule does NOT use redirect), it will also create a new request and new FacesContext. This is wrong. Since its not a redirect navigation, i.e. the browser is not reissuing a new request, the current request remains valid and any queued messages WILL be displayed at the render response phase.

Hopefully that clears things up? This is an important point and in general, the recommendation to use a validation method is a good one.

-Chris
15 years ago
JSF

Originally posted by Sergey Smirnov:
As best I know, JSF does not specify any public API to access to the config files even for read. So, there is no way to manipulate with it programmatically. However, you can do something that is defined in the config file using other API. For example:
* you have no way to add/delete or modify navigation rules
* you can register custom View Handler, validators, converters and so on

Actually, willing to have direct access to config file, especially to navigation rules is very common for people who have experience with Struts previously.

P.S. I speak about default implementation. JSF is very extendable framework. For example, you can create your own view handler and manage navigation based on your own configuration.




That's what I meant. Not changing the file itself, but the elements within the app programmatically.

-Chris
15 years ago
JSF
I don't believe you can literally change the config file itself, but withing the JSF API you have the ability to change things programmatically.

-Chris
15 years ago
JSF
from your first msg:

",i don't know my approach is correct or not "

It is not. Or at least I haven't seen that approach being used. Typically when you invalidate a session, you are done.. fini.. you create a new one by having the browser start a fresh request.
Maybe you shouldn't be invalidating your session if you want to preserve portions of it.

Or, maybe someone has done this, but I have seen this done before.

-Chris
15 years ago
JSF

Originally posted by Ram Gokul:
There was a thread in this forum some time back by developer who went from Struts to JSF and was having lot of performance issues because of the way compoenets are rendering .

To the authors , is the design of JSF such that components that are rendered on the client are downloaded page by page and hence pose a Performance problem . Has the authors faced any such issue ?



Not sure I understand what you are trying to say. Actually they are "rendered from the server" not on the client (I think you meant this).

BTW, you can have components that really render on the client, but this means that the component renders JavaScript and then it takes over rendering - this is an advanced technique and not widely used.

So far, the only performance issues I've seen are with pages that have a unreasonably large (I mean really big) number of components on them - Of course stylistically you probably wouldn't want to have a page with an overly excessive amount of components on them anyway. Just common sense.

-Chris
15 years ago
JSF
Denise,

My guess is you may have an error that you're not seeing because you don't have a h:messages tag on your page. Make sure you add one.

A. Dusi,

Not sure what you mean about not being able to add Faces msgs in action methods. While true you are in the invoke application phase during an action method, but you can still add messages to the queue..

For example here's a quick login action method example:

public String login_action() {
if (inputText1.getValue().equals("chris") && inputSecret1.getValue().equals("schalk")){
return "success";
}
else {

FacesContext ctx = FacesContext.getCurrentInstance();
ctx.addMessage(null, new FacesMessage("Bad Login!"));
return null;
}

If the two input fields don't equal "chris" "schalk", then I create a FacesMessage and don't navigate.

Hope this helps..
-Chris
15 years ago
JSF
Most of the examples I put in the book don't necessarily create component dynamically i.e..purely in a backing bean. Typically what I've seen done - and what we do in the book is to have all the components declared on the page and bound to like UI components in a backing bean. A component could have its rendered attribute be initially set to false and you could then have code to toggle the rendered attribute to true in an actionlistener method.
Techniques for doing this are shown in Chap 8 (event model) and 9 (sample app).

-Chris
15 years ago
JSF
If by sticking to the standard components you mean just using the "Core", and "HTML" libraries that you get from the spec. The answer is a resounding no. The spec was written to be a foundation from which vendors and the open source community can then build on top of. So the "standard" components are pretty basic - just buttons, input fields etc.

MyFaces and other libraries greatly increase the power of the Faces developer by providing a more powerful set of components from which to build apps with. The dataTable is a perfect example. The "standard" dataTable does not have paging/scrolling capabilities built into it. Therefore it makes sense to use a more advanced table such as the one with MyFaces or ADF Faces(trinidad).

With regards to compatibility, if the components are written to spec - they will work together. I haven't seen problems mixing components yet.

Hope this helps..
-chris
15 years ago
JSF
Right on Ed! :-)
15 years ago
JSF
After doing:
HttpServletRequest req = (HttpServletRequest)facesContext.getExternalContext().getRequest();
req.getSession().invalidate();

You don't have to manually create a new session.. just simply navigating to another page will do this automatically.

You can do this by programatically using the Faces navigationhandler:

FacesContext ctx = FacesContext.getCurrentInstance();
Application app = ctx.getApplication();
app.getNavigationHandler().handleNavigation(ctx, "/welcome.jsp", "welcome");


Or by just doing an HttpsendRedirect:

response.sendRedirect("../index.jsp");
return null;
15 years ago
JSF
FYI,

Chapter 9 provides coverage on building a data access layer along with a Hibernate implementation.

Basically I just have an interface that has data operations: getAllTrainingEvents(), getTrainingEventsForUser(), deleteTrainingEvent() etc..
(Training events are the items used in the Virtual Trainer example app)

It then show examples of classes that implement the interface and one of them uses Hibernate to do this.


-Chris
15 years ago
JSF
Here's a little writeup I did awhile back about the plumbing of a specific AJAX request/response.

http://www.oracle.com/technology/pub/articles/schalk-ajax.html

Also, since writing this, AJAX is also taken to mean more than XMLHttpRequest, but more recently it is used to explain rich Internet applications in general. Basically apps that have a lot cooler, more productive interfaces than before..

-Chris

Originally posted by Merrill Higginson:
I'm a relative newbie to JSF. I understand how to link actions with methods in backing beans, but there's one thing I don't understand: Where is the best place to put code that has to execute before a page is displayed?

For example, suppose a page has a select control with a list of options that must be populated before the page is displayed. I understand that I could store this List in the property of a session scoped bean and bind the bean property to the control. But where should I put the code to populate the list? Should it go in the constructor of the session-scoped bean? Is there a "page about to be rendered" event that I can bind a method to?

[ September 12, 2006: Message edited by: Merrill Higginson ]




Hi Merrill,

This one slipped through the cracks. Actually in your case you don't have to always execute a bit of code to prepare data for your page - like a Struts action. You can, but you don't have to. Taking your scenario as an example, you can rely on the managed beans facility within JSF to prepare any and all your Java classes that your JSF application will be using. so for example you have a bean that has a method that returns a collection of values that you need to populate a dropdown list. You would simply register this bean as a "managed bean" in your faces-config file and then you could bind the dropdown list in your page to this method in your managed bean.

Hopefully this explanation makes sense from a high level point of view. The other thing to keep in mind is that JSF doesn't just toss a page your way. Instead, for each request it follows a well defined lifecycle which does a series a specific services such as updating server-side values, checking validation, invoking business logic etc. So at any point in the lifecycle you can - if you want - execute any custom code. This is done with what's called a PhaseListener.

Hope this helps - at least from a conceptual point of view..

Chapter 4 covers the managed bean facility in great detail by the way..
-Chris
15 years ago
JSF

Originally posted by Tony Keith:


Sounds like a book I'm after!

How deep we should know Servlet, JSP, Tag Lib? haven't used much them in my job.

thanks



I would say that you should at least know what they are and perhaps some basic prior experience in developing with them. If you are totally new to J2EE Web development I would also suggest getting a JSP/servlet oriented book or two.
-Chris
15 years ago
JSF