incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pete Muir" <pm...@bleepbleep.org.uk>
Subject Re: JBoss Seam & Trinidad integration
Date Thu, 19 Apr 2007 16:16:05 GMT
Hi

I posted the Seam/Trinidad demo announcement on adffaces-user
yesterday which includes what we've discussed here (well, this stuff
is available as jar, the example just uses it).  Thanks for the help
:) A bit of feedback/questions inline.  I can open JIRA issues for
them if you want - let me know.

On 04/04/07, Adam Winer <awiner@gmail.com> wrote:

> Well, in theory, you'd do this semi-lazily:  have a fetch
> size stored in the model (which, depending on what
> sort of caching you have available, might be a
> multiple of the row count on the component), and then
> on the first request for a particular row, fire the query
> off with a heuristic for setFirstResults() and the fetch
> size for setMaxResults().
>
> The pain comes if you want to do this aggressively
> (e.g., before Render Response).

I did this by assuming that maxResults==rows.  This works well (have
to load the query twice, once for render, once for decode, but I can
work around this in Seam given some time).  Of course, if the user
selects to display all rows, then we get lots of little queries
(again, we can work around this and use at most two queries - the
small one, and if it doesn't return enough results, everything).

At the moment this relies on the developer doing something like
rows="#{query.maxResults}" - would you guys consider adding in a
maxResults (or rows or something) property to CollectionModel.
Ideally, setting <tr:table rows="5" would be reflected in the
CollecitonModel, and setting collectionMode.rows=5 would be reflected
in the table rows property, but unidirectional would be ok as well.
If you think this is ok, I'll add a JIRA issue :)

> > >  (2) Report good permanent row keys, so
> > >    that adding/removing rows gets picked up
> > >    without any off-by-one errors.

This works, but I had one oddity - if I returned an object from
getRowKey, the equals method on it wasn't called (breaking stuff like
row disclosure), wheras returning a primitive was fine.  I tried a
very simple wrapper around a primitive (e.g.

public class Foo {

  public String foo;

  // equals method

}
) with no joy.  I can submit a testcase for this if it would help.  I
solved it by returning an index into a collection of objects (the
identifier for the entity).

> I do think we should have some UI support for at least displaying
> secondary sort criteria, even if there's nothing built in on tr:column
> for activating multiple sort criteria straight from the UI.

Ok, well IIRC, when adding a second element to the List of
SortCriterion, there was no visual indicator on the table that I could
notice.

Best

Pete

Mime
View raw message