Hi Dan,
first of all I thank you for the quick answer.
Dan Labrecque wrote:
>
>
> I don't believe this is a Woodstock issue. JSF based web apps typically
> set the session timeout via a config property in the web.xml file. For
> example:
>
> <session-config>
> <session-timeout>15</session-timeout>
> </session-config>
>
>
It's not that the problem. I even set session-timeout to 60 minutes ... but
I suffer the same problem.
This is a big problem for me ... users will have IE6 and IE7. :(
Any hint ?
Dan Labrecque wrote:
>
>
> Sorry, but this is not configurable. The older Woodstock 4.0 release
> used server-side JSF renderers to output HTML, but we've been slowly
> moving away from this approach -- too dependent on a single framework.
> There are still a few HTML renderers in the mix, but the majority are
> client-side rendered to better support Ajax features. Eventually, this
> will help us support other frameworks like PHP and JRuby. In fact, bench
> testing shows that the latest Woodstock releases perform as good or
> better than the old HTML renderers used in Woodstock 4.0.
>
> That said, you should consider upgrading from 4.1 to 4.1.1 because there
> are significant performance improvements. Similarly, the 4.2 release has
> even more performance improvements than the previous releases. The GA
> release will be announced when Netbeans 6.1 is made available, but you
> can use it now via the Netbeans 6.1 release candidate.
>
> If you want to tweak performance, look at the tag attributes for the
> head tag. Depending on what widgets are used in the page, webuiAll,
> webuiJsfx, etc. could make a significant difference in the amount of
> requests generated for the page.
>
>
Thank you for the hint. The major problem with client javascript is that all
depends on
client machine performance . Without a dual-core architecture the rendering
is very slow. :( I guess I should use new components' version to mitigate
the performance impact.
Dan Labrecque wrote:
>
>
> You should not be using this function directly -- this is a private API.
> This is used by the JSF components to restore focus after a page has
> been submitted. It requires a knowledge of the underlying HTML elements
> used by the widgets. Pleas note that all the public JavaScript APIs are
> documented in the TLD docs below.
>
> http://webdev2.sun.com/woodstock-tlddocs
>
> Using the textField as an example, there is a getInputElement() function
> you can use to gain access to the underlying HTML input element. To set
> focus, you can use JavaScript similar to this:
>
> var widget = document.getElementById("form:textField");
> widget.getInputElement().focus();
>
> That said, it might be more intuitive if we add a focus() function to
> each widget? If you think this might be useful, please file an RFE.
>
> Thanks,
> Dan
>
>
I use that function because it was the unique way I found to set focus after
one of my submit. I mean:
I have a command button which adds a row to a table but, when pressed, it
has to be disabled. I have to position the focus on a textfield inside the
table !
As the button gets disabled the focus manager cannot restore the focus on
it, and set focus on the first component of the page ... and that is not
good for me ;)
I dislike the solution based on an hidden field which 'remember me' to set
the focus on the right control ... so I used that 'trick'.
Is there a "clean" solution with new components' version ???
Thank you very much
Tony
--
View this message in context: http://www.nabble.com/Session-Expiration-in-IE6-and-IE7-...-tp16613869p16656730.html
Sent from the Project Woodstock - Users mailing list archive at Nabble.com.