aspose file tools*
The moose likes JSF and the fly likes parameter on every request Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "parameter on every request" Watch "parameter on every request" New topic
Author

parameter on every request

Adrian Bustos
Greenhorn

Joined: Apr 25, 2011
Posts: 8
Hello.

I'm trying to make sure that a specific parameter be send on every request so I can read it from a filter.



This is easy to accomplish if I do something like this:


The problem is that every time I use an UIForm on the page I've to set the hidden tag.

So I thought in writing a custom JSF component that does it for me.

CustomHidden it's just another custom JSF component that spits the hidden HTML code;


the implementation would look like this...

...and works great! Every time a request is made from "a4jfrmMyForm" I see the value of "_parameterName".
The problem is when the forms are reRendered they do not encode CustomHidden added manually from CustomHiddenSetter. So in order to make this works again I have to refresh manually (F5).

I accept any suggestion. The goal, here, is to make sure that every request inside the children forms of CustomHiddenSetter (like "a4jfrmMyForm", "a4jfrmAnotherOne" or "a4jfrmYetAnotherOne"... BUT NOT "a4jfrmOutsiderForm" ) have to carry the parameter "_parameterName" along with its value.

Thanks in advance!
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16303
    
  21

This seems to be a really complicated solution to what appears to be a simple problem.

Why is is necessary to go to the trouble of injecting a parameter on each and every JSF form submit? It's complicating the app, it's extra network traffic, it's a potential security hole, and last - but not least - if the server is just going to "talk to itself", why bother? Why not just keep the information on the server in a session object (or, if it's global, in an application-scope object)?


Customer surveys are for companies who didn't pay proper attention to begin with.
Adrian Bustos
Greenhorn

Joined: Apr 25, 2011
Posts: 8
Tim Holloway wrote:This seems to be a really complicated solution to what appears to be a simple problem.

Why is is necessary to go to the trouble of injecting a parameter on each and every JSF form submit? It's complicating the app, it's extra network traffic, it's a potential security hole, and last - but not least - if the server is just going to "talk to itself", why bother? Why not just keep the information on the server in a session object (or, if it's global, in an application-scope object)?



It would be easy for me to keep that value (wich, by the way it could only be true|false) in the web.xml.
That value is a flag. It says the filter "Do this or do that... in case of...", it does not risk the security of the application at any time and not in all request is necesary.


Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16303
    
  21

One thing that has been shown over the last few years is that there is apparently nothing so harmless that some can't figure out a way to do harm with it.

But I still don't understand why this parameter has to be a a form and sent out and back again. You realize that filters see the HTTPServletRequest object directly, don't you? In fact, one of my favorite filters takes advantage of that to check to see if the user has just logged in.

And JSF session objects are therefore directly accessible to filters, since JSF session objects are just session objects that have been constructed by JSF. Likewise for the other JSF scopes.
Carl Manschold
Greenhorn

Joined: Oct 20, 2011
Posts: 6
What is your purpose with this?
Adrian Bustos
Greenhorn

Joined: Apr 25, 2011
Posts: 8
Carl Manschold wrote:What is your purpose with this?


My purpose is to catch, using this filter, all the exceptions thrown in every request of every form that lies inside a custom JSF component. But not every form in the web site. That's why I can't just set a session value.



In this example, all exceptions thrown by every request of "a4jfrmForm1" or "a4jfrmForm2" will be treated differently than ussual while all exceptions thrown by "a4jfrmForm3" will not.

The catch is that I'm writing a reusable JSF component that handles this automatically. All the programmer has to do is, well to set the filter in his web.xml, and wrap all forms (only those necesary ;)) inside of <xxxx:customHiddenSetter>.
Asking him to also put an <input hidden type... seems a little bit lame and redundant.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16303
    
  21

Thank you.

We're all rather prone to ask questions on specific details when it would be better to ask questions about the actual intended results. That can lead to difficulties, since the answers won't have the goal properly in mind, and often - especially in JSF - there are other (frequently much, much simpler) ways to handle it. And when I say "all", I mean me, too.

I'm still unclear as to what the ultimate desired effect is here, but it offers some possibilities that are a little more finely-tuned.

Among them are:

1. The traditional method of setting an exception interceptor in web.xml. This is done the same for JSF as it is for non-JSF webapps.

2. Catching the exception in the outbound leg of the filter. This one's more questionable, since there may be content already sent out, but at least you can log the status code and squirrel it away in a session parameter or something like that.

3. Subclassing the form tag itself. If you've already gone through the agony of creating custom JSF tags, you've already got the practice. Just produce the parameter as part of the rendering process.

4. Creating a special-action form element tag. This is basically just a way of coding the hidden parameter, except that it's more meaningful in business terms. Plus, it allows you to specify additional options, if desired. This is probably better than subclassing the form tag, since you don't have 2 different types of form tags - just forms tagged with special behavior.
Adrian Bustos
Greenhorn

Joined: Apr 25, 2011
Posts: 8
Tim Holloway wrote:
1. The traditional method of setting an exception interceptor in web.xml. This is done the same for JSF as it is for non-JSF webapps.
Unacceptable. Define de filter, wrap your forms in a custom tag and, also, define an interceptor in you web app? Since to much to remember to make it work.

Tim Holloway wrote:
2. Catching the exception in the outbound leg of the filter. This one's more questionable, since there may be content already sent out, but at least you can log the status code and squirrel it away in a session parameter or something like that.
Could you exlpain a little more? Maybe an example?

Tim Holloway wrote:
3. Subclassing the form tag itself. If you've already gone through the agony of creating custom JSF tags, you've already got the practice. Just produce the parameter as part of the rendering process.
Unacceptable.

Tim Holloway wrote:
4. Creating a special-action form element tag. This is basically just a way of coding the hidden parameter, except that it's more meaningful in business terms. Plus, it allows you to specify additional options, if desired. This is probably better than subclassing the form tag, since you don't have 2 different types of form tags - just forms tagged with special behavior.

Unacceptable

Remember that I made it posibble to add the hidden dinamically iterating the children of CustomHiddenSetter.



Problem is when the UIForm is rerendered.

If that approach is correct. I'm pretty sure I'm missing something in the methods processRestoreState or processSaveState or something like that...
I'm not that experienced with JSF custom component development.

Why to I insist with the hidden? Because is the simplest way to send, in this case, a flag that tells the filter if it should treat the exceptions differently in that particular request
Carl Manschold
Greenhorn

Joined: Oct 20, 2011
Posts: 6
Why don't you write an ActionListener class? If you create an ErrorActionListener extending ActionListenerImpl, and override the processAction(ActionEvent event) method, then you get a handle to the action requests and can catch all exception thrown, you also have an handle to the uicomponent via the ActionEvent and you can do your magic there ?

Write the class and define it in your faces-config.xml as an <action-listener> under the application element.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: parameter on every request