Hi alli can't see any reaction or statment whether this is good or bad idea , applicable or not should i open a jira for it or there is a big NO from the main committers thanks in advance Joe
On Fri, May 22, 2009 at 9:11 AM, Joe Fawzy <[email protected]> wrote: > Hi allthanks for ur attention > my code is like > > > public abstract class MasterDetailsPanel extends Panel{ > MasterDetailsFactory factory; > public MasterDetailsPanel(String s,MasterDetailsFactory factory) { > super(s); > this.factory = factory; > add(new MasterDataView("id",getProvider(),factory)); > add(factory.getDetailsContainer()); > } > > public IDataProvider getProvider() { > ..... > } > > public static interface MasterDetailsFactory { > MarkupContainer getDetailsContainer(); > Item create(String s, int i, IModel model); > void populateItem(Item item); > } > public static class MasterDataView extends DataView{ > MasterDetailsFactory factory; > > public MasterDataView(String s, IDataProvider iDataProvider, > MasterDetailsFactory factory) { > super(s, iDataProvider); > this.factory = factory; > } > > protected void populateItem(Item item) { > factory.populateItem(item); > } > > @Override > protected Item newItem(String s, int i, IModel model) { > return factory.create(s, i, model); > } > } > } > > > > > as u can see, i am tring to build a reusable panel for all my master > details need inside my application(my actual code is much more comples of > coarse) > i am trying to achieve this, instead of subclassing panel every time, by > using this panel and implementing MasterDetailsFactory interface and > provide an instance to the panel constructor > > > in the current implementation i am using the standard approach , adding to > the standard item component, but i want this piece of reusable code to b > used seamless with fragments and panels, > if Item is an interface my Panels and Fragments can easily implement that > interface ,making it a much natural fit > > and as i said if there is another way, i still think it's better to program > to an interface > > thanks > > On Fri, May 22, 2009 at 8:20 AM, Igor Vaynberg <[email protected]>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 <[email protected]> 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 < >> [email protected] >> >> 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 <[email protected]> >> 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 < >> >> [email protected] >> >> >> 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 <[email protected]> >> 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 >> >> >> > >> >> >> >> >> > >> >> >> > >> > >
