sure.
wouldn't solve the problem of reordering formcomponents for validation
order.
but it would solve igor's problem.
i don't like the idea that we'd be storing undo information on child
reordering.
maybe we should just remove the method i added and add a more general
adapter to wicket.util.... something more like:
public class OrderedIterator
{
public OrderedIterator(Comparator, Iterator)
}
then igor can say:
new (OrderedIterator(comparator, container.iterator())
it's going to do almost /exactly/ the same thing!! only a generalized
sorted-iterator
class is useful everywhere instead of just in MarkupContainer...
i'd prefer the ordered iterator and leave containers entirely
unsorted... the only
thing we'd guarantee is that FormComponents will be validated in the
order they
are added.
jon
Johan Compagner wrote:
just a thought, we could give a
Iterator iterator(Comparable)
then we are only sorting the output, but the internal children array
stays the same
Maybe with clustering this a bit better so that nothing changes.
Also with the sort() how would the back button exactly work??
Are we going to maintain a pre sort array so that we can restore it?
johan
Jonathan Locke wrote:
actually, scratch that last idea about setModel... for a complex
component, this won't work.
how about this? we have a guaranteed ordering for components in a
container and
then we provide this:
/**
* Sort children using comparator
*
* @param comparator
* The comparator
*/
public void sort(Comparator comparator)
{
if (children instanceof Component[])
{
Arrays.sort((Component[])children, comparator);
}
}
doesn't expose any implementation details and lets you reorder the
children.
would that make you happy?
Igor Vaynberg wrote:
If we don't guarantee the order I think we should at least introduce
two
template methods: onChildAdded(Component) and
onChildRemoved(Component).
These would be called from the add(), remove(), removeall(), etc.
Right now you need to look at the internals to know that autoadd()
calls
add() internally, removeAll() doesn't call remove() for every
object, etc.
Having onChildAdded and onChildRemoved will make it easy to add your
own
ordering logic.
Also making iterator() overridable will further facilitate a
user-implemented ordering at render time, although this might open a
can of
worms.
-igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jonathan Locke
Sent: Monday, August 15, 2005 5:09 PM
To: [email protected]
Subject: Re: [Wicket-develop] [ wicket-Patches-1260172 ] add
getchildren to markupcontainer
a good question. we should add it to the javadoc if it's true. i
think we should at least guarantee that FormComponents are
validated in the order they are added. more than that, i'm not so
sure.
Igor Vaynberg wrote:
On a side note,
Is the fact that iterator() now returns items in the order they
were added going to be a formal contract?
-Igor
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices Agile & Plan-Driven Development * Managing
Projects & Teams *
Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices Agile & Plan-Driven Development * Managing Projects &
Teams * Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
