Yeah sounds reasonable...

2009/5/23 James Carman <jcar...@carmanconsulting.com>:
> 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 <joewic...@gmail.com> 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 <joewic...@gmail.com> 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 
>>> <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
>>>> >> >> >
>>>> >> >>
>>>> >> >
>>>> >>
>>>> >
>>>>
>>>
>>>
>>
>

Reply via email to