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
