The "more general" component is difficult to use. The closest I've
gotten is to use ColumnDataProvider but this is more of a hack (nice
one, but still...) than anything else. When you're populating a column,
you're not able to see any row information because that's implemented in
a separate class so you never even have the ability to know of your
actual cell index number (in terms of index in the full page) -- you
only see your index relative to the beginning of the row.
I think it is reasonable to expect Wicket to provide easy to use grids
(with columns and rows) if it already supports row-only views.
(2) Can you give a real-life use-case for this?
(3) Sure it is error-prone. Everyone who starts out using populateItem()
mistakenly invokes add() on the component :) I understand *why* the
component works the way it does, but I still think we should simplify it
further if possible. Either throw an exception from component.add() or
just allow users to call it. I personally wouldn't find the latter
confusing.
(5) How is an attribute modifier going to help you hide cells? I don't
want them to render at all.
Gili
Igor Vaynberg wrote:
I would disagree with everything except 1.
(2) wont work because cells might create different hierarchies of components
based on a model, ie insert different panels based on model objects type.
(3) this is not error prone at all. You have to understand that you cannot
add directly into the dataview because it MANAGES ITS CHILDREN itself and
for you. There is nothing stopping you from adding different things into the
dataitem itself.
(4) see the reason for (2) - it would be cheaper to recreate a cell as
opposed to swapping its model which you then need to undo on the back
button.
(5) sure but this is not a requirement - use a detachablemodel and an
attribute modifier.
I think you are trying to create a component that is very specific to your
needs as opposed to creating a more general one and adopting it.
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gili
Sent: Wednesday, August 17, 2005 10:41 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] Re: ColumnedDataProvider
startIndex problems
Ok, I give up :(
I tried simplifying everything by creating a
GridDataView that is a DataView that is explicitly aware of
columns and rows but this is taking up way too much of my
time and I'm getting stuck way too often.
Some points:
1) We need a component which consists of a fixed number of
columns and rows.
2) Ideally, the grid is lazily-initialized *once* with a
DataItem in each cell at the first request. Future requests
do not modify the grid structure.
3) We *don't* invoke populateItem(DataItem) and have to add()
into the item because as we have seen this is error prone.
Users expect to add() directly onto the component, not the
DataItem and as Igor mentioned, there are problems with
allowing Component.add() to be invoked. So...
4) All cells always exist, whether or not there is a live
item inside them.
5) At request-time, DataItems get re-rendered. At render
time, DataItems should reinitialize themselves from the DB --
this means images might change or an image that used to exist
no longer does. DataItems would be responsible for invoking
setVisible() on themselves based upon whether or not there is
an item to render.
I like the above design because it is more consistent
with the Wicket framework. The structure is created *once* at
initialization time. Users get to add() directly onto
components and there is no longer any confusion -- no need to
item.add().
My only problem is that I am not familiar with how
OrderedRepeatingView works in order to figure out how to
implement all of this. I don't think extending the existing
DataView is an option -- it is just too different. I would be
glad to work with Phil or Igor to make the above work -- I
cannot do it all by myself.
Thanks,
Gili
-------------------------------------------------------
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-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
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-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
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-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
