On 7/21/05, Aleksei Valikov <[EMAIL PROTECTED]> wrote:
> Hi.
>
> > I haven't been following the previous entries in this thread, but, in
> > this example, the easiest solution is to create a method in one's bean
> > called, for example, getListSize():
> >
> > public int getListSize() {
> > return this.getList().size();
> > }
> >
> > and then code it in one's JSP as:
> >
> > <h:outputText value="#{bean.listSize}"/>
>
> The point was that you can't use JSTL functions in JSF method bindings.
>
> > True, it means creating another method in one's bean, but it makes the
> > JSP easier to follow. The code has to be written either way. Using
> > JSF, it is written in the bean, and it results in more concise and
> > self-documenting code in the JSP.
>
> Take a look at the previous message in the thread, from Mike Kienenberger.
>
> The discussion is #{editor.load(document)} versus
> #{editor.loadCurrentlySelectedDocument}.
>
> In the first version, you have a bit greater part of controller defined
> in the JSP page, that's what many people don't like. What I personally
> don't like about the second version is that I have to introduce some
> additional notions (like "currently selected document") into the model,
> even if they logically don't belong there. In the example with "current"
> document, my DAO which could be simply used to list documents is
> becoming stateful.
>
Think of the backing bean you added this to as part of the view, not
the model, and you should feel better about it :-).
More seriously, this also lets you do some interesting things like
caching the list of documents (perhaps with freshness checks so that
the document list is only reloaded when it changes) ... or even a
complete change in the mechanism by which the data is acquired. All
without your page developer having to know anything about it, since
the expression syntax doesn't change.
> Bye.
> /lexi
Craig
