Any other comments/concerns? If not, is there anything else that
needs to happen process-wise before moving forward on with this
change?
Andy
If noboby beats me I'll commit it 2morrow
sent from my Android phone
On Aug 16, 2010 10:11 PM, Andy Schwartz andy.g.schwa...@gmail.com wrote:
Any other comments/concerns? If not, is there anything else that
needs to happen process-wise before moving forward on with this
change?
Andy
Great, thanks Matthias!
Andy
http://svn.apache.org/viewvc?view=revisionrevision=986196
On Mon, Aug 16, 2010 at 11:51 PM, Andy Schwartz
andy.g.schwa...@gmail.com wrote:
Great, thanks Matthias!
Andy
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
On Tue, Aug 10, 2010 at 9:29 PM, Andy Schwartz
andy.g.schwa...@gmail.com wrote:
Gang -
Blake implemented client id caching back in March (r921628 on
trinidad-1.2.x). However, this behavior was intentionally left
disabled by default in order to allow testing to occur before we turn
this on.
On Wed, Aug 11, 2010 at 8:50 AM, Matthias Wessendorf mat...@apache.org wrote:
small comment. For the JSF2 version, should we log a warning in case the
ProjectStage is PRODUCTION, but the CLIENT_ID_CACHING prop is OFF/DEBUG ?
Nice idea Matthias! I'll fix up my patch to include this.
Andy
New version of the patch uploaded here:
https://issues.apache.org/jira/secure/attachment/12451819/trinidad-1669-take2.patch
Includes Matthias' suggestion of logging a warning when client id
caching is disabled in production mode.
Andy
Gang -
Blake implemented client id caching back in March (r921628 on
trinidad-1.2.x). However, this behavior was intentionally left
disabled by default in order to allow testing to occur before we turn
this on. I would like to propose that we now enable this
functionality by default. This
No need to get defensive, I apologize that I must have been too tired
last night and I suppose that I should not have been replying to
coding emails in that state. The point that I was making, is simply if
JSF core, both Mojarra and MyFaces cache the client IDs in
UIComponentBase and clear that
Andrew,
This is what I wrote in my original e-mail
if we put in JIRA-1668--Speed up UIXComponent.getId(), we could, since
that JIRA solves the problem of how to add programmatic logic to
get/setId()
as a side-effect. The issues then would be quality and some performance.
The
No comments on 1668, it looks good to me and your expertise on the
FacesBean exceeds mine by quite a bit, so I defer to your approach for
how to handle that interaction. I'm on board with your approach to
that issue as well as this one.
Thanks,
Andrew
Why isn't UIXComponentBase caching the client ID? The JSF core
components already cache their client ID. Part of the spec. is that
setId() calls on the component clear the cache. In Trinidad, we must
recursively call setId on child components when indexes change
(tr:iterator, tr:table, etc.) so
Andrew Robinson said the following On 1/4/2010 2:38 PM PT:
Andrew,
Thanks for commenting on this.
Why isn't UIXComponentBase caching the client ID?
Because of stamping and because I suspect that FacesBean would have
complicated things.
The JSF core
components already cache their client ID.
The JavaDoc is part of the spec, and according to JSF 1.2, the
getClientId has this restriction (see http://goo.gl/eula):
The return from this method must be the same value throughout the
lifetime of the instance, unless the id property of the component is
changed, or the component is placed in a
Oh, I thought it was clear from my e-mail that I know how the RI
implements setClientId(). Note that the RI implementation isn't really
compatible with the spec language. The UIData doesn't change the
children id attributes in any Java sense of the word (precisely the same
instance is used).
Calling UIXComponentBase.getClientId consumes a great deal of transient
memory. Under light loads, this doesn't matter--the objects are
extremely short-lived and are allocated out of the first-generation
heap. However, when large numbers of users are accessing the server
simultaneously these
16 matches
Mail list logo
