[ ] IDataProvider<I,T>
[X] Iterator<IModel<T>> , drop model
[X] Leave as is.
I dont care much between those 2.
But i definitely dont like option 1, because your example gives me exact
the feeling why i dont want that
It gives the wrong idea to peoples mind. If they would do what you do,
Integer list of pks, and then in the model you get the Topics objects,
this would for most OR mapping tools be a real performance issue, and we get
the blame for that for being slow.
johan
On Thu, Apr 24, 2008 at 9:42 AM, Jan Kriesten <[EMAIL PROTECTED]>
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:
>
>
>
>
> 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 above
>
> Would 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]
>
>
