I'd open a JIRA for it anyway. These discussions can get lost in the mailing lists. If we have a JIRA and the rationale behind the "NO" is documented as comments there, then we have a "paper trail" to follow to understand the decision.
On Sat, May 23, 2009 at 3:08 PM, Joe Fawzy <[email protected]> wrote: > 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 >>> >> >> > >>> >> >> >>> >> > >>> >> >>> > >>> >> >> >
