tonyweb wrote:
> 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 ?
>
>
I don't know what web container you're using, but you might want to
check its documentation regarding session timeouts.
> 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.
>
Yes, please use 4.2, if you can. I believe the 4.2 release candidate has
been posted and will be the GA. We simply cannot rename it as "GA" until
Netbeans releases 6.1.
>
>
> 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 ???
>
The example I provided above will allow focus to be set. Again, if you
feel that an explicit focus function will help, please log an RFE.
Dan