The problem was really a question of implementation. We were talking basically about linking in JSF applications to lists from a database. The problem with the standard datatable is as follows:

1) Keep your list in the session. This makes sure that when the user clicks the link that they are getting the right entry. However, you need an explicit refresh function to get the data from the database. Users generally expect the list to refresh when you go back to the page or reload with the browser button.

2) Get the list each time from the database. This creates the problem that forceIndexFormula solves. That if data has changed since you got the screen, link-by-index can fail. We're also assuming that we'll never use the back button again.

forceIndexFormula takes care of this problem, but my question was about implementation. Lets say I request a page with the extDataTable and forceIndexFormula. My code goes to the database to get the list, and displays it. When I click the link, the code has to go to the database again, get the list, then scan through each entry to figure out which one was clicked based on the id value. <-- This is the assumption I'm making about the implementation. My issue was that this does a lot of work unnessarily.

I was then asked how I would implement it. Basically I was thinking that since we're already hacking datatable, maybe another attibute that pointed to a setter function. This function would take the id that the user selected, and if the user had forceIndexFormula set AND this setter function, the code would not grab the list and try to figure out which one was selected by its id value. This was purely for performance reasons.

However, I'm not a jsf expert so I don't really know what that would do to the rest of the event processing, etc.

After that I was thinking that maybe the dataTable component is good for editing a table of entries, but it might not be ideal for simply "walking the database". By that I mean displaying link pages with id values from databases. A different component might be better suited for that.

Thats the summary.

Related forum topics:

http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=82&t=000422

http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=82&t=000383

Sylvain Vieujot wrote:
Hello,

I'm not sure I understand your problem, but I'll try to explain what I can :

If your problem is that in fields in a table, only the first field is updated, then this has nothing to do with forceIndexFormula, and it might very well be a bug. I had a similar problem, but I didn't take the time to dig into it. Another probable bug is that the table content is only updated on the second request. This too might be a bug, and I didn't had time to check it either.

The problem solved by forceIndexFormula is when the backend data can change between requests (order changes, or data insertion/deletion). It makes sure that the right row is updated. This is explained a the bottom of the t:dataTable doc :
http://myfaces.apache.org/tomahawk/extDataTable.html

HTH

Sylvain.

On Wed, 2005-08-31 at 08:53 +0200, Martin Marinschek wrote:

Kevin,

I am trying to get Sylvain involved in this to explain
forceIndexFormula better (hint: this should be in the documentation ;)
- but I believe that his solution is somewhat similar to your
suggestion!

Particularly, you just get the id of the data row as part of the
client-id in your action, and it is your responsibility then to fetch
this row!

regards,

Martin



On 8/30/05, Kevin Galligan <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
My brain is very struts centric as well.  There's some things I like
about the JSF model too though.  Thats why I'm probably landing
somewhere in between.

I generally avoided session scoping anything that didn't need to be,
which I guess is my big reservation with JSF.  I know exactly what you
mean with the lazy list in the form.  You do have some extra effort
involved, like building the property string on the input objects and
tracking the id's in a hidden input component, but there's not as much
going on "behind the curtain" either.

I think that's enough for today though...

Rick Reumann wrote:
> On 8/30/05, Kevin Galligan <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 
wrote:
>
>
>>I think updating several rows at the same time, which might require
>>local copies of the data, and just linking are two different things.
>>They might need two different components.
>
>
> With Struts this was a piece of cake. Your ActionForm has a bean
> property that is a List of the objects you want to update (Helps if
> it's a LazyList if not using session scope), and when your form
> submits BeanUtils (in the background) simply copies your form objects
> to the List in the Action form. Super simple imo.
>
> The only slightly tricky part is validation, but I always provide a
> manual validation method in my Action classes so this was easy to
> handle.





Reply via email to