well, a big -1 on this until component and markupcontainer are interfaces. -igor
On Thu, May 21, 2009 at 11:15 PM, Joe Fawzy <joewic...@gmail.com> wrote: > hi dear Igoryes u r right , i am doing a lot of casts ,and i think that > Component and MarkupContainer must also b interfaces , and our custom > interfaces for composite components extends them > BUT it is a major refactoring and not suitable at this stage, so i decided > to discuss it later,on planning the next release > thanks > Joe > > On Fri, May 22, 2009 at 8:20 AM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote: > >> What methods will the interface contain? Component is not an interface >> so will your code have to cast an interface to component to access it? >> That's not really coding to an interface. >> >> -Igor >> >> On Thursday, May 21, 2009, Joe Fawzy <joewic...@gmail.com> wrote: >> > hi dearactually i am not doing a reflection based component >> > i am implementing a composite control in which DataView or ListView is >> just >> > one component, this composite component intended to b used by >> implementing >> > some factory methods, so i thought it will be a good idea to make Item an >> > interface so the factory method can return it, and let the component >> users >> > determine what the actual component is ,Panel, Fragment or ordinary >> > MarkupContainer >> > alse if this happens it will be nice to provide default Item >> implementation >> > for Panels and Fragments ItemFragment,ItemPanel >> > >> > also i think ,even if this refactoring will not save any code, it is >> still >> > a good design decision (at least to me) as it favour programming to >> > interfaces >> > thanks >> > joe >> > >> > On Thu, May 21, 2009 at 3:47 AM, Jeremy Thomerson < >> jer...@wickettraining.com >> >> wrote: >> > >> >> I'm just not convinced that it would actually save any code... If >> >> you're trying to make an reflection-based ListView subclass, you could >> >> do that now without any change. >> >> >> >> Give a sample of how code would be shortened by using an interface. >> >> >> >> -- >> >> Jeremy Thomerson >> >> http://www.wickettraining.com >> >> >> >> >> >> >> >> >> >> On Wed, May 20, 2009 at 6:14 PM, Joe Fawzy <joewic...@gmail.com> wrote: >> >> > Hi dearthanks for prompt reply >> >> > actually i am using this all the time , and this was a repetitive >> piece >> >> of >> >> > code all over my project so i am trying to make listView subclass >> which >> >> take >> >> > a panel class in its constructor and instantiate it on demand by using >> a >> >> > supplied factory interface whick takes care of differences between >> panel >> >> and >> >> > fragments but produce the same interface which is the suggested IItem >> or >> >> > DataItem and set it as the item >> >> > doing this with the current api is possible but require lot of >> tweaking >> >> to >> >> > allow both panels and components to b used >> >> > i thought that the suggested refactoring will b a better choice and >> also >> >> a >> >> > good programming practice (programming to interfaces) but i will >> respect >> >> ur >> >> > decision any way >> >> > >> >> > thanks again >> >> > Joe >> >> > >> >> > On Thu, May 21, 2009 at 1:57 AM, Jeremy Thomerson < >> >> jer...@wickettraining.com >> >> >> wrote: >> >> > >> >> >> You can't just use item.add(new YourCustomPanel(id, getModel())? >> >> >> >> >> >> -- >> >> >> Jeremy Thomerson >> >> >> http://www.wickettraining.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, May 20, 2009 at 5:54 PM, Joe Fawzy <joewic...@gmail.com> >> wrote: >> >> >> > Hi allcan we refactor org.apache.wicket.markup.repeater.Item to an >> >> >> interface >> >> >> > IItem or DataItem or so , and make the standard Item class >> implement >> >> this >> >> >> > interface , this will maintain backward compatibility but allow us >> to >> >> use >> >> >> > panels and fragments as Item implementation (by overriding the >> >> newItem() >> >> >> > method) instead of being restricted to MarkupContainer which is not >> as >> >> >> > reusable as panels and fragments >> >> >> > thanks >> >> >> > joe >> >> >> > >> >> >> >> >> > >> >> >> > >> >
