[ ] IDataProvider<I,T> [X] Iterator<IModel<T>> , drop model [ ] Leave as is.
Regards, Sebastiaan Jan Kriesten wrote:
Hi,I have a usecase where the current proposed generic Interface for IDataProvider with upcoming v1.4 of Wicket would break the implementation concept working with Wicket 1.3. The usecase needs different types for iterator + model. Example and explanation are found below the vote:VOTE: [ ] IDataProvider<I,T> [ ] Iterator<IModel<T>> , drop model [ ] Leave as is. Example: new IDataProvider<Integer, Topics> {public Iterator<Integer> iterator( int first, int count ) { getForum().getTopics( first, count ); }public int size() { getForum().getTopicsCount(); }public IModel<Topics> model( Integer id ) { return new TopicsDetachableModel( id ); }}The current proposed IDataProvider<T> would enforce model + iterator to be of the same type, resulting in the above not working without hassle. I.e. either to work without type safetey (always use Object to comply), or wrapping/querying the type within iterator + model (which could cause time consuming lookups when remote services are involved).To get around this, there are 2 solutions: - drop the 'model' method and have iterator return an Iterator<IModel<T>>That would fit this usecase since the Model could just be wrapped within iterator and no extra lookups would be necessary. Implementation code of iterator might get a bit uglier, though.- add a second type as shown with example aboveWould lead to "redundant" type definitions for many usecases where iterator + model actually return the same type.I'd really like to see support for generics with these cases as well. Best regards, --- Jan. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
