I have a seam application. I am using the debugger to inspect various components.
When I launch the app by entering a URL like this DevicesList.seam?state=MD&city=BALT the parameter map, retrieved thusly:
contains key,value pairs that are nice and predictable: Key: state, value: MD, key: city, value: BALT.
But when I launch my app on the "search page", enter MD in the state field, BALT in the city field, that same parameter map looks nothing like it. The keys look like the id's of the input fields, rather than like the parameters.
Two questions -- what is the difference? I'm guessing it has something to do with GET and POST? Just ignore that if I am completely off-base.
And how do I retrieve the nice and predictable parameter map? This has to be stored somewhere in the FacesContext or ServletContext or something?
I feel I am babbling like an idiot. I hope someone on this awesome forum understands my question. :-)
JSF isn't especially friendly to parameters. One reason is that even if you request a page via HTTP GET, the page will then enter a postback cycle, and (as the name implies), the postback is done via HTTP POST, so the source of parameters shifts from the URL to form fields.
JSF2 added the ability to work better with URL parameters, but I'm not as familiar with the mechanisms as I ought to be, since prior to JSF2, the easiest way to deal with URL parameters was to use PrettyFaces and that's what all my code works with. PrettyFaces implements a servlet filter that injects the URL parameters directly into backing bean properties, eliminating the need to muck around with JSF internal components like the FacesContext. I believe that's also true with the parameterization enhancements in JSF2, which used PrettyFaces as an inspiration.
URL parameters are not the best way to transfer data between JSF pages. It's cumbersome and a potential security hazard and should generally be avoided in favor of interactions between the backing beans themselves. What URL parameters are best for is "bookmarkable" URLs, such as online stores where you want the user to be able to return directly to the page of a product of interest by coding the product's ID as a URL parameter. Or as a part of the overall URL pattern, depending on how you like to do such things.
Customer surveys are for companies who didn't pay proper attention to begin with.