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 > >> >> > > >> >> > >> > > >> > > >
