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