hi igor,
sorry, but i dont buy this. models are not meant for factoring out business concerns, only crosscutting concerns. so you can have the model and the iterator wrapper delegate to the same util class that transforms the url string to the feed.
it doesn't make sense to do wrapping/transforming things twice - especially with this example when url-calls are involved. database calls are cached, rss feeds are freshly lookuped each time.
the method where the object is being build just happens to be named 'model' - imho that has nothing to do with the model being used to do business concerns.
i'm arguing that the way IDataProvider is generified makes things worse in some (maybe only my) cases then with v1.3x - and that shouldn't be.
there needs to be a way to only create a model once!
new idataprovider<t>() { imodel<t> iterator(int first, int last) {
return new modeliteratoradapter<t>(db.iterator(first, last)) {
imodel<t> model(T t) { return new ldm(t); }}}
is a lot uglier then the code you need now with a factored out model factory.
that's not that bad when you're using linebreaks actually. ;-) there are worse examples with implementations needing to override inner structures with wicket.
- - have IDataProvider one generic for iterator and one for model.then 99% of people out there have to declare a redundant type. you arethe minority here. that is my view of course.
i might be the minority, but i find it rather strange to cut out options which were availabe in 1.3 and are dropped for the price of 6 bytes java code per IDataProvider in 1.4.
generics with java are sometimes hell - they're verbose and not always very readable. but in this case this isn't actually a big problem. how much work/hassle would it cost you to actually change the fingerprint - no ten minutes with your 50 occurrences i suppose.
best regards, --- jan.
