Jsf_tree_64

2007-01-30 Thread Gattu, Praveen
with client side save state. I noticed that the framework is using jsf_tree_64 hidden field for all the command links, to store some form of data. What is this field used for in the framework? Is there a way to avoid this hidden field, without using the server side save state? Are there any other

Re: Jsf_tree_64

2007-01-30 Thread Simon Kitching
measures ~300kbyes with client side save state. I noticed that the framework is using jsf_tree_64 hidden field for all the command links, to store some form of data. What is this field used for in the framework? Saving the current component tree. It needs to be stored somewhere, and if you don't

Re: Jsf_tree_64

2007-01-30 Thread Mario Ivankovits
Hi should be looking to solve both load balancing and low page size? Perhaps a sticky load balancer, ie one that is http-session-aware and therefore directs all requests for a specific session to a single tomcat instance? For simplifications I'd prefer the sticky way too, though, it should be

RE: Jsf_tree_64

2007-01-30 Thread Gattu, Praveen
be a bad user experience. I am looking for any other way to get best of the both worlds(low page size and a true load balanced app.) -Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 30, 2007 11:16 AM To: MyFaces Discussion Subject: Re: Jsf_tree_64

RE: Jsf_tree_64

2007-01-30 Thread Gattu, Praveen
Discussion Subject: Re: Jsf_tree_64 Gattu, Praveen wrote: Hi Folks - We are using the myfaces(1.1.5 snapshot). I got couple of questions regarding the state save. So far we were using the server side save state to reduce the page size of our pages, but noticed that with this approach, our app

Re: Jsf_tree_64

2007-01-30 Thread Madhav Bhargava
-Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 30, 2007 11:16 AM To: MyFaces Discussion Subject: Re: Jsf_tree_64 Gattu, Praveen wrote: Hi Folks - We are using the myfaces(1.1.5 snapshot). I got couple of questions regarding the state save. So far we

Re: Jsf_tree_64

2007-01-30 Thread Madhav Bhargava
: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 30, 2007 11:16 AM To: MyFaces Discussion Subject: Re: Jsf_tree_64 Gattu, Praveen wrote: Hi Folks - We are using the myfaces(1.1.5 snapshot). I got couple of questions regarding the state save. So far we were using the server

Re: Jsf_tree_64

2007-01-30 Thread Simon Kitching
Madhav Bhargava wrote: http://www.oracle.com/webapps/online-help/jdeveloper/10.1.3/state/content/navId.4/navSetId._/vtTopicFile.jsf_apps%7Cadfcreate%7Caf_astatesaving~html/

RE: Jsf_tree_64

2007-01-30 Thread Daniel Young
what's the difference?? Thanks, Daniel. -Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Wednesday, 31 January 2007 1:31 PM To: MyFaces Discussion Subject: Re: Jsf_tree_64 Yep, so in other words it's the same as server-side state saving, except that there is also

Re: Jsf_tree_64

2007-01-30 Thread Mario Ivankovits
Hi Daniel! As Simon said, it's basically server-side state saving with a single client-side token. But normal server-side state saving already has a token (the SESSION ID!!) that maps to the HttpSession anyway... so what's the difference?? The thing is to not only find the correct

RE: Jsf_tree_64

2007-01-30 Thread Daniel Young
Cool, that makes sense - thank u so much :) -Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: Wednesday, 31 January 2007 3:55 PM To: MyFaces Discussion Subject: Re: Jsf_tree_64 Hi Daniel! As Simon said, it's basically server-side state saving with a single

Re: BUG? commandLink href URLs too long (jsf_tree_64 value over 6k chars)

2006-07-13 Thread Mike Kienenberger
If you use one form for the entire page, you shouldn't need to have the attribute duplicated in every commandLink (each of which is probably being put into its own form). On 7/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: BUG? commandLink href URLs too long (jsf_tree_64 value over 6k chars

Re: BUG? commandLink href URLs too long (jsf_tree_64 value over 6k chars)

2006-07-13 Thread jraymond
long (jsf_tree_64 value over 6k chars) The length of the value of the 'jsf_tree_64' parameter is 6517 characters long in my case, causing IE6 to render links that do nothing when clicked. When reducing the number of characters in the rendered HTML, IE6 can navigate the links. I recently

Re: BUG? commandLink href URLs too long (jsf_tree_64 value over 6k chars)

2006-07-13 Thread Mike Kienenberger
the attribute duplicated in every commandLink (each of which is probably being put into its own form). On 7/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: BUG? commandLink href URLs too long (jsf_tree_64 value over 6k chars) The length of the value of the 'jsf_tree_64' parameter is 6517

Re: BUG? commandLink href URLs too long (jsf_tree_64 value over 6k chars)

2006-07-13 Thread Dennis Byrne
URLs too long (jsf_tree_64 value over 6k chars) Well, I haven't used tree2 myself, but are all of those command links inside your one form? It almost sounds like an implementation bug. On 7/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Actually, there is only one form on the page. It's

BUG? commandLink href URLs too long (jsf_tree_64 value over 6k chars)

2006-07-12 Thread jraymond
BUG? commandLink href URLs too long (jsf_tree_64 value over 6k chars) The length of the value of the 'jsf_tree_64' parameter is 6517 characters long in my case, causing IE6 to render links that do nothing when clicked. When reducing the number of characters in the rendered HTML, IE6 can

AW: AW: document.getElementById(jsf_tree_64) has no properties

2006-02-07 Thread Luo. Haihua
Hi Volker, in my case the client state saving does work, while server state saving not work! Anyway, now the jsf_tree_64 error is gone with client state saving. Thank you so much! Further javascript error comes, however, :( called element.className has no properties, it indicates

Re: AW: document.getElementById(jsf_tree_64) has no properties

2006-02-07 Thread Martin Marinschek
not work! Anyway, now the jsf_tree_64 error is gone with client state saving. Thank you so much! Further javascript error comes, however, :( called element.className has no properties, it indicates that the error occurs in removeClassName() function in prototype.js Any idea? Cheers

AW: AW: document.getElementById(jsf_tree_64) has no properties

2006-02-07 Thread Luo. Haihua
Hi Martin, do you mean the bug of jsf_tree_64, or the element.className has no properties? Haihua -Ursprüngliche Nachricht- Von: Martin Marinschek [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 7. Februar 2006 10:46 An: MyFaces Discussion Betreff: Re: AW: document.getElementById

Re: AW: document.getElementById(jsf_tree_64) has no properties

2006-02-05 Thread Volker Weber
saving? Thanks! Haihua -Ursprüngliche Nachricht- Von: Volker Weber [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 3. Februar 2006 18:47 An: MyFaces Discussion Betreff: Re: document.getElementById(jsf_tree_64) has no properties Hi, this may be a portlet problem? I don't know

document.getElementById(jsf_tree_64) has no properties

2006-02-03 Thread Haihua Luo
Hi Lists, I want to test the simple sandbox example for inputSuggestAjax. But when I input sth. in the input field, an error occurs in the web page in firefox: document.getElementById("jsf_tree_64") has no properties. Any ideas or comment why it happens? I am using myfaces 1.1.1, J

Re: document.getElementById(jsf_tree_64) has no properties

2006-02-03 Thread Volker Weber
Hi, this may be a portlet problem? I don't know mutch about portlets, but afaik the portlet rewrites the ids to ensure they are unique. When using client-side state saving (which is the default) there are two hidden input fields jsf_tree_64 and jsf_state_64 in which the state is stored. Try