You are right. *Theoritically*, it is possible to save state in GET requests by means of normal request parameters. I'm not at all a friend of this POST things, especially the POST via Javascript. I already adressed this in very early MyFaces days. We even had a feature called "Minimizing State Saving" that gzip compressed the necessary information. But unfortunately there are two main reasons, why GET requests cannot be used for state saving: 1. Main reason is browser inabilities. Browsers do not allow unlimited request urls. Some browsers crash, some simply cut off the url. There is no way to limit the url, because there will always exist pages that have so many input components, that the url will get too long. Even if we used high sophisticated compression algorithms. 2. You loose values that you just entered in a form. Imagine a text input in a form and a link on the same page. If the link acts like a standard HTML link, all input gets lost on the GET. This behaviour is what experienced HTML developers know of and expect. But it's not the behaviour that people expect, who simply want to write a rich webapp that behaves simliar to a fat client. After all, that's one goal of JSF: Give people a simple to use webapp framework without the need to bother about HTML and browser issues.
-M On Mon, 28 Mar 2005 19:55:34 -0800, Korhonen, Kalle <[EMAIL PROTECTED]> wrote: > > -----Original Message----- > > From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] > > Subject: Re: navigation component (or POSTs in JSF) > > In JSF everything is a POST, > > that is because of JSF is restoring the component tree from > > the view that creates a page. > > If you use GET, it means that you give up any possibility of > > component tree restoring. > > Hmm. Theoretically, I don't see a reason why you couldn't store the > state of a component tree into a GET request.. Anything I'm missing? > Sure, there are some practical considerations, but those aside, why > wouldn't it be possible? > > Kalle > > > > Matt Conway wrote: > > > Matthias Wessendorf wrote: > > > > > >> in short to 2) that is *normal* in JSF > > > > > > > > > Strange - if you feel like it could you (or someone else) > > explain why > > > this is so I can get a better understanding of JSF internals? I > > > assume this is something that will addressed in future > > specs? It just > > > doesn't seem right that something so basic being broken is > > considered normal. > > > > > >> use <redirect/> inside of your navigation rules and you'll see the > > >> *right* page. > > > > > > > > > Thanks - I tried this and while it does show the right > > page, now the > > > active navigation entry is no longer higlighted! > > > > > >>> 1) If I go to another page (which also has a > > commandNavigation link) > > >>> via some other action like a commandLink, the active > > >>> commandNavigation does not get updated. > > >>> 2) The URL in the location bar reflects the last page > > navigated to > > >>> rather than the current one. > > >> > > >
