You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Guy Bashan <gu...@gmail.com> on 2008/05/04 14:54:17 UTC
Pretty urls
Hi,
I read about JSF pretty url solution, for solving JSF post problem, when url
parameters are getting lost after submitting the page.
As far as I understand, the parameters in the url are injected directly to
the bean.
The thing that I cannot understand, in what cases this solution is usable?
In most of the pages, parameters used to load data to the object.
For example, for editing car details I would use: car_details.jspx?carId=5.
The data of the form is being loaded in the constructor.
So I will do something like this in the bean constructor:
Id = getParamFromRequest("carId");
If (Id != null) // Edit existing car
{
car = loadCar(Id);
}
Else // Enter new car details
{
Car = new Car();
}
Now, how can I use prett url? By injecting the parameter directly to the
bean, the constructor will be activated first, then the setter.
One may say, initialize the Car object in the setter method of the bean.
Is it a trivial solution? (It looks a bit not neat initializing object in a
setter method).
Why JSF has never supplied a decent solution to this problem? This is a
critical issue in web development (not loosing parameters after a post
operation).
Why are parameters does not stay after post? In regular JSP post operation,
the parameters are preserved.
Thanks,
Guy.
Re: Pretty urls
Posted by Andrew Robinson <an...@gmail.com>.
You seem to be ranting about JSF but are not trying to do things that
are designed for JSF. Lazy loading is no more messy than creation of
data in a constructor. There are many ways to do this.
1) use a managed property to set your backing bean from a request
parameter and load your object on set. This gets called when the bean
is created -- same time as the constructor pretty much
2) use Seam request parameter annotation on a setter method
3) use an on-load library (search the myfaces wiki for on-load or
onload, I am on an iPod so I can't copy & paste)
Just don't start ranting about that you can't do things the same way
in JSF as in JSP. JSP sucks for many reasons and it just doesn't do
anyone any good to complain.
On 5/4/08, Guy Bashan <gu...@gmail.com> wrote:
> Hi,
>
>
>
> I read about JSF pretty url solution, for solving JSF post problem, when url
> parameters are getting lost after submitting the page.
>
> As far as I understand, the parameters in the url are injected directly to
> the bean.
>
> The thing that I cannot understand, in what cases this solution is usable?
> In most of the pages, parameters used to load data to the object.
>
> For example, for editing car details I would use: car_details.jspx?carId=5.
>
> The data of the form is being loaded in the constructor.
>
> So I will do something like this in the bean constructor:
>
> Id = getParamFromRequest("carId");
>
> If (Id != null) // Edit existing car
>
> {
>
> car = loadCar(Id);
>
> }
>
> Else // Enter new car details
>
> {
>
> Car = new Car();
>
> }
>
>
>
> Now, how can I use prett url? By injecting the parameter directly to the
> bean, the constructor will be activated first, then the setter.
>
> One may say, initialize the Car object in the setter method of the bean.
>
> Is it a trivial solution? (It looks a bit not neat initializing object in a
> setter method).
>
>
>
> Why JSF has never supplied a decent solution to this problem? This is a
> critical issue in web development (not loosing parameters after a post
> operation).
>
> Why are parameters does not stay after post? In regular JSP post operation,
> the parameters are preserved.
>
>
>
> Thanks,
>
> Guy.
>
>
Re: Pretty urls
Posted by Andrew Robinson <an...@gmail.com>.
On Mon, May 5, 2008 at 9:03 AM, Guy Bashan <gu...@gmail.com> wrote:
> Andrew, thanks a lot for your very serious answer.
> I hope you are not too mad at me... ;-)
Don't worry about it. I sound angrier in email than I really am. I was
just a little bummed by the quick overview of my reply.
> Maybe promoting these technologies on
> MyFaces site will be a bit helpful.
I think MyFaces would probably like to achieve its own ownership of
this space eventually. JBoss is LGPL and not compatible with AL2. As a
result, MyFaces cannot ship addons or other libraries to integrate
with JBoss products like Seam. As a result, IMO, MyFaces is not the
proper place to be promoting other libraries. The best place to go
that I am aware of is http://www.jsftutorials.net/. I never spend much
time there at all just because it is a bit overwhelming (too much
info. if anything) and I don't have the time to tackle that much
content, but it should be really good for learning about JSF libraries
and techniques.
As for JSF, I definitely admit that it is very hard to setup a
bookmark friendly application, but at least there are some ways around
it. It is the pro and con of the complex JSF navigation system. The
application simply does not know what the next view ID will be until
after the POST back is processed. There are ways around this, but all
seem to have pros & cons. Perhaps someday some of us can help tackle
this with a controller type add on library here @ myfaces.
RE: Pretty urls
Posted by Guy Bashan <gu...@gmail.com>.
Andrew, thanks a lot for your very serious answer.
I hope you are not too mad at me... ;-)
I do love Java and I do love JSF concepts.
I made a hard decision more than 3 years ago (JSF was a bit younger), as a
co-founder of a company to use JSF technology, and I am not sorry for a
single minute (ok, there were times I was little...).
The things I wrote about are not my complains only, I was dealing with these
complains on a daily basis.
I was not aware about all JSF complementing technologies you wrote about (I
mainly know and used Shale framework). Maybe promoting these technologies on
MyFaces site will be a bit helpful.
Guy.
-----Original Message-----
From: Andrew Robinson [mailto:andrew.rw.robinson@gmail.com]
Sent: Sunday, May 04, 2008 10:46 PM
To: MyFaces Discussion
Subject: Re: Pretty urls
You are making some incorrect assessments of JSF in this email. You
don't seem to be grasping how JSF works and what architectural APIs
are available for you to work with. I want to address your
misstatements first:
First, JSF does not forward. There is only one servlet, the
FacesServlet. This one servlet is not the cause of the URL not being
in sync. The cause is the URL that is rendered in the default
implementation provided by the JSF core libraries. You can fix this if
you wish to work like struts, it just doesn't come that way out of the
box.
Second, you have chosen to use redirecting without intelligence as a
solution to the bookmarking issue. This was your decision, not JSFs.
JSF does not make it impossible to pass parameters using a redirect,
so please do not use absolutes. Just because you have yet to find a
way to do something does not make it impossible. More on this below.
Third, your "pretty" URL can actually be considered ugly. You probably
mean able to be bookmarked, not "pretty". I don't think any URL with
QS params is "pretty".
Fourthly, you keep trying to put business logic in a managed bean
constructor. This is not a good idea as business logic should be
reserved for methods, not business logic. How many people write EJB
session beans that have a lot of logic in a constructor? You just need
to correctly author you beans and look into what people are
suggesting. If you want people to help, then you should spend the time
looking into suggestions and doing some research before replying. I
don't think that the one hour you gave in your reply gave you adequate
time to look up and research managed properties, and the 3 on-load
libraries documented in the WIKI.
To address your problems:
1) JSF doesn't have to post back to the same page that rendered it.
That is just the behavior of the default JSP view handler. The view
handler has the functionality you need along with UIForm to be able to
use struts-style actions. The restoreView function of a view handler
is responsible for taking a request and turning it into a JSF
UIViewRoot:
http://tinyurl.com/4xqofb
The view ID can be just part of the URL. For example, if you register
*.jsf for the faces servlet and use JSPs it looks for a page with
*.jsp and not *.jsf. Therefore, the view handler is able to do
anything it wants as long as it returns a UIViewRoot instance.
As for UIForm, if you look at the JavaDoc (http://tinyurl.com/594r3x),
there is no requirements on how the action of the form should be
rendered. I am not sure of the specification and I don't have time now
to search through the PDF for you, but I believe there is no issue
with changing the action. In fact you can do this in the view handler
as well. See the getActionURL function: http://tinyurl.com/4y3pfx
This means that instead of using editCar.jsf in the URL, then you
could have anything you want. Then in your custom view handler
(wrapper), you can translate your action URL to a JSF view ID.
But do not say that JSF requires you to use redirect for bookmarking,
there are other ways. They may just not be as simple and quick.
2) JSF can easily pass on parameters on a redirect. JSF uses the
standard redirect mechanism of HTTP (custom code is used for AJAX). If
you don't feel like writing the code yourself, then use JBoss Seam.
Its filter allows you to append QS values onto redirects and even
allows you to put EL in the URL that will be parsed before sending the
URL down to the browser. The documentation for this is here:
http://tinyurl.com/4qfr26
The thing to realize is the JSF is just a framework, it is not an
engine. The Servlet container is the engine and therefore if you can
do it with servlets, you can do it with JSF. JSF after all is just a
servlet.
3) --
4) Please look at the on-load functionality. It is usually considered
bad OOD for object constructors to have logic. This is why Java
technologies heavily use the factory pattern. You should perform logic
based on method calls. If you use setSomeProperty, you have to be able
to handle exceptions in a property setter. This may mean throwing a
custom exception and using a registered JSF error handler to process
the error. This really only works if you need only one parameter to
look up something. If you are trying to execute GET requests that
perform logic like "searchCars?color=blue&year=1998&minGasMilage=30"
then you need to do this logic on GET not in an action. There are too
many different solutions for me to type them here, including filters,
phase listeners, view handlers, navigation handlers, etc.
What can tell you is that an easy way is via on-load technologies that
I already made reference to. They allow you to run a JSF action on a
GET request. This will allow you to not only run an action on GET but
also redirect if needed (for example if the QS was not valid for your
car search)
Since I am now on a computer, not a iPod, I can give you the URL:
http://wiki.apache.org/myfaces/Execute_action_on_page_load
Please review this and read the JSF spec and view handler JavaDoc for
the APIs and see what you can do before responding. If you feel this
is over your head, I would suggest using JBoss Seam as it gives almost
everything you are looking for.
-Andrew
On Sun, May 4, 2008 at 8:20 AM, Guy Bashan <gu...@gmail.com> wrote:
> First I have to say, I never use JSF navigation mechanism for these
reasons:
> - forward is never an option because the url is not in sync.
> - you are left with redirect which makes it impossible to pass parameters
in
> a reasonable way.
> When I say reasonable way, I mean request parameters.
>
> So when I navigate to a page I use parameters.
> For example: http://localhost//car_details?carId=5
> When command is activated on the page (requesting the server), JSF
refreshes
> the view
> And taking off the parameters of the original request.
>
> In regular JSP form post, the url parameters are preserved.
>
> Now, the pretty url as far as I understand, comes to solve this problem
in
> jsf.
> So beside of being "pretty", there are no request parameters that can
> "disappear" after a refresh. There is only a url path. Therefore if page
is
> refreshed, parameters are still there. Which is a nice and acceptable
> solution.
> But, then we come to the problem of the original post:
> I do initialization in the constructor. But the pretty url will inject
the
> parameters directly to the bean, causing
> The constructor to be activated first... So how can I initialize my page
> objects in proper way?
>
>
>
>
> -----Original Message-----
> From: Andrew Robinson [mailto:andrew.rw.robinson@gmail.com]
> Sent: Sunday, May 04, 2008 4:48 PM
> To: MyFaces Discussion
> Subject: Re: Pretty urls
>
> Why do you say that parameters do not stay put? JSF uses the normal
> servlet API to handle parameters, the code is excactly the same as JSP
> which also just uses the servlet container code
>
> On 5/4/08, Guy Bashan <gu...@gmail.com> wrote:
> > Hi,
> >
> >
> >
> > I read about JSF pretty url solution, for solving JSF post problem,
when
> url
> > parameters are getting lost after submitting the page.
> >
> > As far as I understand, the parameters in the url are injected directly
to
> > the bean.
> >
> > The thing that I cannot understand, in what cases this solution is
usable?
> > In most of the pages, parameters used to load data to the object.
> >
> > For example, for editing car details I would use:
> car_details.jspx?carId=5.
> >
> > The data of the form is being loaded in the constructor.
> >
> > So I will do something like this in the bean constructor:
> >
> > Id = getParamFromRequest("carId");
> >
> > If (Id != null) // Edit existing car
> >
> > {
> >
> > car = loadCar(Id);
> >
> > }
> >
> > Else // Enter new car details
> >
> > {
> >
> > Car = new Car();
> >
> > }
> >
> >
> >
> > Now, how can I use prett url? By injecting the parameter directly to
the
> > bean, the constructor will be activated first, then the setter.
> >
> > One may say, initialize the Car object in the setter method of the
bean.
> >
> > Is it a trivial solution? (It looks a bit not neat initializing object
in
> a
> > setter method).
> >
> >
> >
> > Why JSF has never supplied a decent solution to this problem? This is a
> > critical issue in web development (not loosing parameters after a post
> > operation).
> >
> > Why are parameters does not stay after post? In regular JSP post
> operation,
> > the parameters are preserved.
> >
> >
> >
> > Thanks,
> >
> > Guy.
> >
> >
>
>
Re: Pretty urls
Posted by Andrew Robinson <an...@gmail.com>.
You are making some incorrect assessments of JSF in this email. You
don't seem to be grasping how JSF works and what architectural APIs
are available for you to work with. I want to address your
misstatements first:
First, JSF does not forward. There is only one servlet, the
FacesServlet. This one servlet is not the cause of the URL not being
in sync. The cause is the URL that is rendered in the default
implementation provided by the JSF core libraries. You can fix this if
you wish to work like struts, it just doesn't come that way out of the
box.
Second, you have chosen to use redirecting without intelligence as a
solution to the bookmarking issue. This was your decision, not JSFs.
JSF does not make it impossible to pass parameters using a redirect,
so please do not use absolutes. Just because you have yet to find a
way to do something does not make it impossible. More on this below.
Third, your "pretty" URL can actually be considered ugly. You probably
mean able to be bookmarked, not "pretty". I don't think any URL with
QS params is "pretty".
Fourthly, you keep trying to put business logic in a managed bean
constructor. This is not a good idea as business logic should be
reserved for methods, not business logic. How many people write EJB
session beans that have a lot of logic in a constructor? You just need
to correctly author you beans and look into what people are
suggesting. If you want people to help, then you should spend the time
looking into suggestions and doing some research before replying. I
don't think that the one hour you gave in your reply gave you adequate
time to look up and research managed properties, and the 3 on-load
libraries documented in the WIKI.
To address your problems:
1) JSF doesn't have to post back to the same page that rendered it.
That is just the behavior of the default JSP view handler. The view
handler has the functionality you need along with UIForm to be able to
use struts-style actions. The restoreView function of a view handler
is responsible for taking a request and turning it into a JSF
UIViewRoot:
http://tinyurl.com/4xqofb
The view ID can be just part of the URL. For example, if you register
*.jsf for the faces servlet and use JSPs it looks for a page with
*.jsp and not *.jsf. Therefore, the view handler is able to do
anything it wants as long as it returns a UIViewRoot instance.
As for UIForm, if you look at the JavaDoc (http://tinyurl.com/594r3x),
there is no requirements on how the action of the form should be
rendered. I am not sure of the specification and I don't have time now
to search through the PDF for you, but I believe there is no issue
with changing the action. In fact you can do this in the view handler
as well. See the getActionURL function: http://tinyurl.com/4y3pfx
This means that instead of using editCar.jsf in the URL, then you
could have anything you want. Then in your custom view handler
(wrapper), you can translate your action URL to a JSF view ID.
But do not say that JSF requires you to use redirect for bookmarking,
there are other ways. They may just not be as simple and quick.
2) JSF can easily pass on parameters on a redirect. JSF uses the
standard redirect mechanism of HTTP (custom code is used for AJAX). If
you don't feel like writing the code yourself, then use JBoss Seam.
Its filter allows you to append QS values onto redirects and even
allows you to put EL in the URL that will be parsed before sending the
URL down to the browser. The documentation for this is here:
http://tinyurl.com/4qfr26
The thing to realize is the JSF is just a framework, it is not an
engine. The Servlet container is the engine and therefore if you can
do it with servlets, you can do it with JSF. JSF after all is just a
servlet.
3) --
4) Please look at the on-load functionality. It is usually considered
bad OOD for object constructors to have logic. This is why Java
technologies heavily use the factory pattern. You should perform logic
based on method calls. If you use setSomeProperty, you have to be able
to handle exceptions in a property setter. This may mean throwing a
custom exception and using a registered JSF error handler to process
the error. This really only works if you need only one parameter to
look up something. If you are trying to execute GET requests that
perform logic like "searchCars?color=blue&year=1998&minGasMilage=30"
then you need to do this logic on GET not in an action. There are too
many different solutions for me to type them here, including filters,
phase listeners, view handlers, navigation handlers, etc.
What can tell you is that an easy way is via on-load technologies that
I already made reference to. They allow you to run a JSF action on a
GET request. This will allow you to not only run an action on GET but
also redirect if needed (for example if the QS was not valid for your
car search)
Since I am now on a computer, not a iPod, I can give you the URL:
http://wiki.apache.org/myfaces/Execute_action_on_page_load
Please review this and read the JSF spec and view handler JavaDoc for
the APIs and see what you can do before responding. If you feel this
is over your head, I would suggest using JBoss Seam as it gives almost
everything you are looking for.
-Andrew
On Sun, May 4, 2008 at 8:20 AM, Guy Bashan <gu...@gmail.com> wrote:
> First I have to say, I never use JSF navigation mechanism for these reasons:
> - forward is never an option because the url is not in sync.
> - you are left with redirect which makes it impossible to pass parameters in
> a reasonable way.
> When I say reasonable way, I mean request parameters.
>
> So when I navigate to a page I use parameters.
> For example: http://localhost//car_details?carId=5
> When command is activated on the page (requesting the server), JSF refreshes
> the view
> And taking off the parameters of the original request.
>
> In regular JSP form post, the url parameters are preserved.
>
> Now, the pretty url as far as I understand, comes to solve this problem in
> jsf.
> So beside of being "pretty", there are no request parameters that can
> "disappear" after a refresh. There is only a url path. Therefore if page is
> refreshed, parameters are still there. Which is a nice and acceptable
> solution.
> But, then we come to the problem of the original post:
> I do initialization in the constructor. But the pretty url will inject the
> parameters directly to the bean, causing
> The constructor to be activated first... So how can I initialize my page
> objects in proper way?
>
>
>
>
> -----Original Message-----
> From: Andrew Robinson [mailto:andrew.rw.robinson@gmail.com]
> Sent: Sunday, May 04, 2008 4:48 PM
> To: MyFaces Discussion
> Subject: Re: Pretty urls
>
> Why do you say that parameters do not stay put? JSF uses the normal
> servlet API to handle parameters, the code is excactly the same as JSP
> which also just uses the servlet container code
>
> On 5/4/08, Guy Bashan <gu...@gmail.com> wrote:
> > Hi,
> >
> >
> >
> > I read about JSF pretty url solution, for solving JSF post problem, when
> url
> > parameters are getting lost after submitting the page.
> >
> > As far as I understand, the parameters in the url are injected directly to
> > the bean.
> >
> > The thing that I cannot understand, in what cases this solution is usable?
> > In most of the pages, parameters used to load data to the object.
> >
> > For example, for editing car details I would use:
> car_details.jspx?carId=5.
> >
> > The data of the form is being loaded in the constructor.
> >
> > So I will do something like this in the bean constructor:
> >
> > Id = getParamFromRequest("carId");
> >
> > If (Id != null) // Edit existing car
> >
> > {
> >
> > car = loadCar(Id);
> >
> > }
> >
> > Else // Enter new car details
> >
> > {
> >
> > Car = new Car();
> >
> > }
> >
> >
> >
> > Now, how can I use prett url? By injecting the parameter directly to the
> > bean, the constructor will be activated first, then the setter.
> >
> > One may say, initialize the Car object in the setter method of the bean.
> >
> > Is it a trivial solution? (It looks a bit not neat initializing object in
> a
> > setter method).
> >
> >
> >
> > Why JSF has never supplied a decent solution to this problem? This is a
> > critical issue in web development (not loosing parameters after a post
> > operation).
> >
> > Why are parameters does not stay after post? In regular JSP post
> operation,
> > the parameters are preserved.
> >
> >
> >
> > Thanks,
> >
> > Guy.
> >
> >
>
>
Re: Pretty urls
Posted by Rafa Pérez <ra...@gmail.com>.
Hi,
if you need all your URLs to be bookmarkables, maybe JSF is not a good
option. I think JSF is a standard that tries to make development of
web applications more in a desktop application development way. Thus,
JSF provides different mechanisms than JSP and therefore a change on
the way it is used is needed.
On Sun, May 4, 2008 at 4:20 PM, Guy Bashan <gu...@gmail.com> wrote:
> First I have to say, I never use JSF navigation mechanism for these reasons:
> - forward is never an option because the url is not in sync.
> - you are left with redirect which makes it impossible to pass parameters in
> a reasonable way.
> When I say reasonable way, I mean request parameters.
>
> So when I navigate to a page I use parameters.
> For example: http://localhost//car_details?carId=5
> When command is activated on the page (requesting the server), JSF refreshes
> the view
> And taking off the parameters of the original request.
>
> In regular JSP form post, the url parameters are preserved.
>
> Now, the pretty url as far as I understand, comes to solve this problem in
> jsf.
> So beside of being "pretty", there are no request parameters that can
> "disappear" after a refresh. There is only a url path. Therefore if page is
> refreshed, parameters are still there. Which is a nice and acceptable
> solution.
> But, then we come to the problem of the original post:
> I do initialization in the constructor. But the pretty url will inject the
> parameters directly to the bean, causing
> The constructor to be activated first... So how can I initialize my page
> objects in proper way?
>
>
>
>
> -----Original Message-----
> From: Andrew Robinson [mailto:andrew.rw.robinson@gmail.com]
> Sent: Sunday, May 04, 2008 4:48 PM
> To: MyFaces Discussion
> Subject: Re: Pretty urls
>
> Why do you say that parameters do not stay put? JSF uses the normal
> servlet API to handle parameters, the code is excactly the same as JSP
> which also just uses the servlet container code
>
> On 5/4/08, Guy Bashan <gu...@gmail.com> wrote:
> > Hi,
> >
> >
> >
> > I read about JSF pretty url solution, for solving JSF post problem, when
> url
> > parameters are getting lost after submitting the page.
> >
> > As far as I understand, the parameters in the url are injected directly to
> > the bean.
> >
> > The thing that I cannot understand, in what cases this solution is usable?
> > In most of the pages, parameters used to load data to the object.
> >
> > For example, for editing car details I would use:
> car_details.jspx?carId=5.
> >
> > The data of the form is being loaded in the constructor.
> >
> > So I will do something like this in the bean constructor:
> >
> > Id = getParamFromRequest("carId");
> >
> > If (Id != null) // Edit existing car
> >
> > {
> >
> > car = loadCar(Id);
> >
> > }
> >
> > Else // Enter new car details
> >
> > {
> >
> > Car = new Car();
> >
> > }
> >
> >
> >
> > Now, how can I use prett url? By injecting the parameter directly to the
> > bean, the constructor will be activated first, then the setter.
> >
> > One may say, initialize the Car object in the setter method of the bean.
> >
> > Is it a trivial solution? (It looks a bit not neat initializing object in
> a
> > setter method).
> >
> >
> >
> > Why JSF has never supplied a decent solution to this problem? This is a
> > critical issue in web development (not loosing parameters after a post
> > operation).
> >
> > Why are parameters does not stay after post? In regular JSP post
> operation,
> > the parameters are preserved.
> >
> >
> >
> > Thanks,
> >
> > Guy.
> >
> >
>
>
RE: Pretty urls
Posted by Guy Bashan <gu...@gmail.com>.
First I have to say, I never use JSF navigation mechanism for these reasons:
- forward is never an option because the url is not in sync.
- you are left with redirect which makes it impossible to pass parameters in
a reasonable way.
When I say reasonable way, I mean request parameters.
So when I navigate to a page I use parameters.
For example: http://localhost//car_details?carId=5
When command is activated on the page (requesting the server), JSF refreshes
the view
And taking off the parameters of the original request.
In regular JSP form post, the url parameters are preserved.
Now, the pretty url as far as I understand, comes to solve this problem in
jsf.
So beside of being "pretty", there are no request parameters that can
"disappear" after a refresh. There is only a url path. Therefore if page is
refreshed, parameters are still there. Which is a nice and acceptable
solution.
But, then we come to the problem of the original post:
I do initialization in the constructor. But the pretty url will inject the
parameters directly to the bean, causing
The constructor to be activated first... So how can I initialize my page
objects in proper way?
-----Original Message-----
From: Andrew Robinson [mailto:andrew.rw.robinson@gmail.com]
Sent: Sunday, May 04, 2008 4:48 PM
To: MyFaces Discussion
Subject: Re: Pretty urls
Why do you say that parameters do not stay put? JSF uses the normal
servlet API to handle parameters, the code is excactly the same as JSP
which also just uses the servlet container code
On 5/4/08, Guy Bashan <gu...@gmail.com> wrote:
> Hi,
>
>
>
> I read about JSF pretty url solution, for solving JSF post problem, when
url
> parameters are getting lost after submitting the page.
>
> As far as I understand, the parameters in the url are injected directly to
> the bean.
>
> The thing that I cannot understand, in what cases this solution is usable?
> In most of the pages, parameters used to load data to the object.
>
> For example, for editing car details I would use:
car_details.jspx?carId=5.
>
> The data of the form is being loaded in the constructor.
>
> So I will do something like this in the bean constructor:
>
> Id = getParamFromRequest("carId");
>
> If (Id != null) // Edit existing car
>
> {
>
> car = loadCar(Id);
>
> }
>
> Else // Enter new car details
>
> {
>
> Car = new Car();
>
> }
>
>
>
> Now, how can I use prett url? By injecting the parameter directly to the
> bean, the constructor will be activated first, then the setter.
>
> One may say, initialize the Car object in the setter method of the bean.
>
> Is it a trivial solution? (It looks a bit not neat initializing object in
a
> setter method).
>
>
>
> Why JSF has never supplied a decent solution to this problem? This is a
> critical issue in web development (not loosing parameters after a post
> operation).
>
> Why are parameters does not stay after post? In regular JSP post
operation,
> the parameters are preserved.
>
>
>
> Thanks,
>
> Guy.
>
>
Re: Pretty urls
Posted by Andrew Robinson <an...@gmail.com>.
Why do you say that parameters do not stay put? JSF uses the normal
servlet API to handle parameters, the code is excactly the same as JSP
which also just uses the servlet container code
On 5/4/08, Guy Bashan <gu...@gmail.com> wrote:
> Hi,
>
>
>
> I read about JSF pretty url solution, for solving JSF post problem, when url
> parameters are getting lost after submitting the page.
>
> As far as I understand, the parameters in the url are injected directly to
> the bean.
>
> The thing that I cannot understand, in what cases this solution is usable?
> In most of the pages, parameters used to load data to the object.
>
> For example, for editing car details I would use: car_details.jspx?carId=5.
>
> The data of the form is being loaded in the constructor.
>
> So I will do something like this in the bean constructor:
>
> Id = getParamFromRequest("carId");
>
> If (Id != null) // Edit existing car
>
> {
>
> car = loadCar(Id);
>
> }
>
> Else // Enter new car details
>
> {
>
> Car = new Car();
>
> }
>
>
>
> Now, how can I use prett url? By injecting the parameter directly to the
> bean, the constructor will be activated first, then the setter.
>
> One may say, initialize the Car object in the setter method of the bean.
>
> Is it a trivial solution? (It looks a bit not neat initializing object in a
> setter method).
>
>
>
> Why JSF has never supplied a decent solution to this problem? This is a
> critical issue in web development (not loosing parameters after a post
> operation).
>
> Why are parameters does not stay after post? In regular JSP post operation,
> the parameters are preserved.
>
>
>
> Thanks,
>
> Guy.
>
>