Until now we've used a custom TransformedList for this, for example:
public class IssueToUserList extends TransformedList<Issue, String> {
public IssueToUserList(EventList<Issue> source) {
super(source);
source.addListEventListener(this);
}
public String get(int index) {
Issue issue = source.get(index);
return issue.getReporter();
}
public void listChanged(ListEvent<Issue> listChanges) {
updates.forwardEvent(listChanges);
}
protected boolean isWritable() {
return false;
}
}
This could of course be generalized to something like this:
public class SimpleFunctionList<S, E> extends TransformedList<S, E> {
private final Function<S,E> function;
public SimpleFunctionList(EventList<S> source, Function<S,E> function) {
super(source);
this.function = function;
source.addListEventListener(this);
}
public E get(int index) {
final S elem = source.get(index);
return function.evaluate(elem);
}
public void listChanged(ListEvent<S> listChanges) {
updates.forwardEvent(listChanges);
}
protected boolean isWritable() {
return false;
}
}
.. and used like this for the above example:
final EventList<Issue> issues = ...
final Function<Issue, String> function = GlazedLists.beanFunction(Issue.class, "reporter");
final SimpleFunctionList<Issue, String> reporters = new SimpleFunctionList<Issue, String>(issues, function);
Is "SimpleFunctionList" (a better name pending) what you've thought about, Kevin?
James/Jesse, what do you think?
Thanks,
Holger
>We frequently find ourselves needing to perform relatively simple
> transformations on lists (for example, pull a value out of a
> composite object):
>
> class A{
> public String val1;
> public String val2;
> }
>
> with a pipeline of:
>
> EventList<A> -> FunctionList<A, String>
>
> so this is pretty simple, right? The Function implementation is
> actually boring it's so simple.
>
> What I'm wondering is if FunctionList is too heavyweight for this
> sort of scenario. It actually holds onto a full list of String
> objects, instead of just delegating the get() to the function. Every
> list mutation winds up with relatively expensive array adjustments.
> The function would have to be forward only, but I rarely find the
> need to do that in these scenarios.
>
> Am I trying to over-optimized things, or is this an area that would
> make sense for a new list implementation? It seems that other lists
> in GL would benefit here (for example, TreeList does this sort of
> thing behind the scenes).
>
>
> - K
______________________________________________________
WEB.DE FreeDSL mit 6.000 Flatrate und Telefonanschluss
für 17,95 Euro/mtl.!
http://produkte.web.de/go/02/---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscribe@...For additional commands, e-mail:
users-help@...