Do you think it's a good idea to have method calls to a API or DAO in the
getter methods? I really havent seen that before in any other apps, but
maybe it is a best practice that I haven't seen yet. Or maybe we just didn't
understand the impact it would have in the lifecycle of JSF in our early,
unexperienced JSF development.
So, what if we keep the getters/members of the class as is... give them a
setter to conform to javabean spec and set/populate all of them in a) the
constructor or b) in some kind of setup method for that backing bean? That
way they can be called as many times as the framework wants, but only one
service call is made in the inital setup of the bean.
This way, the framework can brutally call whatever it wants and we won't
always be trying to prevent some kind of new behavior/enhancement.
This isn't trying to excuse the isRendered calls, but if the architecture of
the backingBean is that important, then I consider this very important info
for a high traffic, highly visible application.
Wes
On 5/10/07, Adam Winer <[EMAIL PROTECTED]> wrote:
On 5/10/07, Wesley Hales <[EMAIL PROTECTED]> wrote:
> Yeah, we tried Adam's proposal before I posted the patch... It worked up
> until Ajax4JSF usage and components like UIColumn were not updating.
I'd like to know why that's so - Ajax4JSF must be
doing something at least a little unusual for this
to break.
-- Adam
>
> So, after using the patch and making changes to not extend
> UIComponentBaseCached in UIColumn and UIGraphic *we had problems with
items
> in datatable not updating* - Everything seems to be working fine.
>
> Again, I know this is not an elegant solution, especially when you have
to
> pick and choose which base components are using the isRendered cache.
>
> Thanks again for looking into this Adam, Simon, Andrew.
> Regards,
> Wesley
>
>
> On 5/10/07, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > Thanks Adam. That makes good sense.
> >
> > All that is needed now is a volunteer to implement it :-).
> >
> > I might have a go if I can find some spare time but it won't be soon.
I
> > will try to find time to record this as an enhancement in JIRA so it
> > doesn't get lost.
> >
> > Regards,
> >
> > Simon
> >
> > Adam Winer wrote:
> > > Technically, rendered is supposed to be:
> > > - Constant across
> encodeBegin()/encodeChildren()/encodeEnd()
> > > - Constant across processDecodes()/processValidators()/
> > > processUpdateModel().
> > >
> > > Unfortunately, the latter doesn't help - since a component inside
> > > a table would have processDecodes() called repeatedly,
> > > then processValidators() repeatedly, etc. - and "rendered"
> > > could be different from one row to the next.
> > >
> > > But the former should be fine - if you always fetch and
> > > store the value in encodeBegin() (whether or not encodeBegin()
> > > has previously been called), then use that in encodeChildren()
> > > and encodeEnd(), you should be fine.
> > >
> > > -- Adam
> > >
> > >
> > > On 5/8/07, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > >> Andrew, are you just stating what currently happens or are you
saying
> > >> that there is a *reason* for evaluating "rendered" in encodeBegin,
> > >> encodeChildren and encodeEnd?
> > >>
> > >> I can't initially see any reason why it would need to be evaluated
more
> > >> than once.
> > >>
> > >> UIComponentBase does indeed call isRendered in encodeBegin,
> > >> encodeChildren and encodeEnd. It also implements isRendered as an
> > >> evaluation of the EL expression (myfaces 1.1.3 implementation).
> > >>
> > >> But As Wesley asks, why would it ever make sense for rendered to be
> true
> > >> in encodeBegin, but false in encodeEnd? I cannot see any way that
would
> > >> be useful, so why not just compute it once then cache it somewhere
for
> > >> the rest of that render cycle (eg in a "transient" member of the
> > >> component)? This would be a significant performance boost..
> > >>
> > >> Wesley, your proposed modification which stores the rendered state
into
> > >> _rendered is not good because setting _rendered will permanently
> > >> override the rendered EL expression, not just for the current
render
> > >> cycle but for the lifetime of that component. What is needed is to
> > >> figure out when the first call to isRendered is done *during the
render
> > >> cycle* and then cache that until rendering finishes. Note that
> > >> isRendered is also called during postback processing, and it's
> perfectly
> > >> reasonable to change this value between postback and render so
caching
> > >> really should only be done between encodeBegin() and encodeEnd().
So
> > >> implementing this optimisation is a little tricky - but not
impossible
> > >> I'm sure.
> > >>
> > >> Regards,
> > >>
> > >> Simon
> > >>
> > >> Andrew Robinson wrote:
> > >> > At the very least rendered is called during encodeBegin,
> > >> > encodeChildren, and encodeEnd.
> > >> >
> > >> > On 5/8/07, Wesley Hales <[EMAIL PROTECTED]> wrote:
> > >> >> Hello - Why do we continually call isRendered after
encodeBegin()?
> > >> >> Once the
> > >> >> begin tag is written out, it shouldn't matter what the body and
end
> > >> >> rendered
> > >> >> states are.
> > >> >>
> > >> >> Facelets 1.1.11
> > >> >> Myfaces 1.1.5 & 1.2
> > >> >>
> > >> >> So if I have <t:div rendered="#{MyBean.alerts > 0}"...
> > >> >> The #{MyBean.alerts method is called 5 times! and it is like
this
> for
> > >> >> every
> > >> >> EL eval on the page. I do know that EL can only bind to the
> > >> >> FaceletsContext
> > >> >> and no other scopes... So are there any other options than what
I
> have
> > >> >> listed below?
> > >> >>
> > >> >> 1. Tried to modify MyFaces src in UIComponentBase:
> > >> >> public boolean isRendered()
> > >> >> {
> > >> >> if(_rendered == null){
> > >> >>
> > >> >> // our modification! Only compute the rendered value
> > >> once, and
> > >> >> cache for the rest of the lifecycle.
> > >> >> Boolean rend = getExpressionValue("rendered",
_rendered,
> > >> >> DEFAULT_RENDERED);
> > >> >> _rendered = rend.booleanValue();
> > >> >> }
> > >> >> return _rendered;
> > >> >> }
> > >> >> This didn't work :( - Something happend to A4J and we had no
ideas
> > >> >> what the
> > >> >> implication would be on all components.
> > >> >>
> > >> >> 2. Tried using Facelets <ui:param and <c:set to store the EL in
a
> page
> > >> >> scoped variable, then have the variable evaluated in the
rendered
> > >> >> attribute.
> > >> >> This didn't work either because it is on FacesContext.
> > >> >>
> > >> >> So this may just be me not fully understanding what JSF does
> > >> behind the
> > >> >> scenes of component rendering, or some people say that the spec
is
> > >> >> screwed
> > >> >> up when it comes to this. I'm sure some of the pros can help me
out
> > >> >> here :).
> > >> >>
> > >> >> Thx,
> > >> >> Wesley Hales
> > >>
> > >>
> >
> >
>
>
