Re: [VOTE] Release Apache Wicket 1.4 Milestone 1
Can I have some more votes please? This is our first 1.4 release so it would be nice with a lot of eyes on it. Frank On Sun, Apr 20, 2008 at 10:09 PM, Frank Bille <[EMAIL PROTECTED]> wrote: > Hi all, > > First milestone release of Wicket 1.4 has been build. This release is > the first to have java 1.5 as minimum requirement. > > The distribution artifacts can be downloaded from here: > http://people.apache.org/~frankbille/releases/apache-wicket-1.4-m1/dist/ > > The maven staging repository can be found here: > http://people.apache.org/~frankbille/releases/apache-wicket-1.4-m1/m2-repo/ > > There is also a RAT report for the distribution: > > http://people.apache.org/~frankbille/releases/apache-wicket-1.4-m1/apache-wicket-1.4-m1.rat > > The artifacts has been signed with my (Frank Bille) public key which > can be found in the keys file: > http://people.apache.org/~frankbille/releases/apache-wicket-1.4-m1/KEYS > > > I have tested the following: > * "mvn clean install" the distribution/src > * Check the RAT file. Can't see anything new > * Various testing in wicket-examples (winxp+ie6, winxp+ie7, macosx+safari) > > > Frank > > [ ] +1 Release Apache Wicket 1.4 Milestone 1 > [ ] -1 Don't release, because... >
Re: About the coupling between design and code
Hello Radev, > I've also developed some applications with Lotus, and there the abstraction > between the design and the code is bound only by the name of the elements. > There is no need to know anything about nesting of the elements. Such > decoupling between the design and code could make the process of development > more parallel and rapid. > that sounds interesting to me. Can you post some examples how it goes within Lotus? Best, Korbinian
Re: About the coupling between design and code
there have been a couple of threads on this over time. you can search the mailing list archives for the discussions. i think the result has always been that there are certain very useful things we get from the components being in hierarchy that we do not want to give up. -igor On Tue, Apr 22, 2008 at 9:55 AM, George Radev <[EMAIL PROTECTED]> wrote: > Hi All, > > > > I found Wicket quite challenging framework for web applications and has many > advantages upon other competitors. I'm quite pleased with its flexibility > and find it suitable for many complex interfaces. > > > > Wicket has quite interesting separation between Design and Code (HTML and > JAVA file), though it is quite coupled. It is very hard to send the HTML > files to the designer and parallel this process with coding, since we have > many a_component.add(another_component) dependency, which we need to write > twice (once in the HTML and once in Code ). > > Possible decoupling is: > - to take dependency from the HTML file since it is read and validated. > This will make code more decoupled from the design by just calling > add(Component) within the class context. > > > > - while iterating items with ListView it is easy to have the iterating part > within the tag and calling add(Component) within populate defines the > context to be according to iterating tag content. > > > > I've also developed some applications with Lotus, and there the abstraction > between the design and the code is bound only by the name of the elements. > There is no need to know anything about nesting of the elements. Such > decoupling between the design and code could make the process of development > more parallel and rapid. > > > > Thank you, > > Cheers > > George Radev >
About the coupling between design and code
Hi All, I found Wicket quite challenging framework for web applications and has many advantages upon other competitors. I'm quite pleased with its flexibility and find it suitable for many complex interfaces. Wicket has quite interesting separation between Design and Code (HTML and JAVA file), though it is quite coupled. It is very hard to send the HTML files to the designer and parallel this process with coding, since we have many a_component.add(another_component) dependency, which we need to write twice (once in the HTML and once in Code ). Possible decoupling is: - to take dependency from the HTML file since it is read and validated. This will make code more decoupled from the design by just calling add(Component) within the class context. - while iterating items with ListView it is easy to have the iterating part within the tag and calling add(Component) within populate defines the context to be according to iterating tag content. I've also developed some applications with Lotus, and there the abstraction between the design and the code is bound only by the name of the elements. There is no need to know anything about nesting of the elements. Such decoupling between the design and code could make the process of development more parallel and rapid. Thank you, Cheers George Radev
Re: Generics: Wildcards
i agree that there are some benefits to wildcards, and thanks for the info, i wasnt aware of a lot of the things you described. that said, you have to keep in mind that we are a framework, not a library. that means that there are plenty of places where the user never creates the list returned and so there is no need to widen the generics. eg - protected List getBehaviors(Class< ? extends IBehavior> type) + protected List getBehaviors(Class< ? extends IBehavior> type) there is no point to making that change. the user never creates the list, the framework does. now in IDataProvider that made total sense since it is the user returning the Iterator. -igor On Tue, Apr 22, 2008 at 2:22 AM, Johannes Schneider <[EMAIL PROTECTED]> wrote: > Hi, > > during the last days I have created several patches that introduce > wildcards to generified collections. > And very often I have to describe why this is necessary. > > > So I think it might be useful to discuss that topic once and for all. > > Java developers tend to avoid the wildcards (e.g. List Serializable>). I don't know exactly why, but most of the time people > don't understand why those are necessary - so I try to describe it. > > > > List: This declares *any* type of list that > contains objects that implement Serializable. That could be a List of > Strings or a List of Integers. We just don't know exactly. All we know > is that the elements implement Serializable. > Those Lists only offer read access. It is not possible to add any > elements. > > > Some example assignments: > > //contains all kinds of Serializables > List l = new ArrayList<Serializable>(); > > //contains *only* Strings > List l = new ArrayList(); > > //contains *only* Integers > List l = new ArrayList(); > > //contains *only* the given kind (that implments Serializable > List l = new ArrayList<*anything that > implements Serializable*>(); > > > > List: This declares a list that contains Serializables - > but *all* kinds of Serializables. So it is possible to store Strings > *and* Integers (and all other objects that implement Serializable) > within that list. > > It is *only* possible to assign a List: > List l = new ArrayList<Serializable>(); > > > It is *not* possible to assign those: > List l = new ArrayList(); DOES NOT WORK !!! > > > So what is the problem now: If an interface method forces me to return a > List it is *not* possible to return e.g. a List. > Instead I have to do fancy things to work around and be able to return > that list. > > > But there is just one simple rule that fits nearly every case: > As long as you only *read* a collection or return an unmodifiable > collection, *always* use wildcards. Only if you need or offer write > access, it is necessary to specify a collection exactly. > > > This discussion is necessary, since it is an incompatible change to add > wildcards later. This will break your API! > There are several bad examples out there that did this error (GlazedList > anyone?). It is very hard to fix those issues afterward. So I strongly > advice to do those things right before releasing 1.4. > > > > Regards, > > Johannes Schneider > > > > > > > > > > > > > > > > > > >
Re: 1.4 Generics
this is fine yes:
TextField tf = new TextField(new
ResourceModel("key"));
the tf.getModel() returns a Model else it cant and getModelObject
also returns a String.
But i agree for a Button if you dont give a model to it it doesn't make
sense
But if you give a model it does make sense.
But for a Textfield it makes sense that you generify it even without a model
because it does inherit the model from its parent..
so yes its a bit of a split what is nice and what you want to do.
johan
On Tue, Apr 22, 2008 at 3:28 PM, mnwicket <[EMAIL PROTECTED]> wrote:
>
> Thanks Igornot sure if you really answered what I was getting at
> though.
> I understand generics however there are cases in wicket where I'm
> wondering
> what is best practices.
>
> ie, using your example, a TextField using a ResourceModel, which way would
> you go;
>
> TextField tf = new TextField(new
> ResourceModel("key"));
>
> or just
>
> TextField tf = new TextField(new ResourceModel("key"));
>
> And what do you use as a generic with the following code block;
>
> class MyForm extends Form {
>
> public MyForm() {
>
> add(new AjaxButton('id', this));
>
> }
>
> }
>
>
>
> igor.vaynberg wrote:
> >
> > generic type on Component represents the type of the modelobject that
> > component will hold.
> >
> > eg TextField tf=new TextField(...);
> > means that tf.getModelObject() is of type Integer
> >
> > -igor
> >
> >
> > On Mon, Apr 21, 2008 at 5:30 PM, mnwicket <[EMAIL PROTECTED]> wrote:
> >>
> >> Ok, so I starting messing around with the new generics version of
> >> wicketand I guess I was a little confused as to how many generics
> >> there
> >> are. Silly question is when people are doing development are they
> >> turning
> >> off all generic warnings in eclipse...that is if you are using
> eclipse?
> >>
> >> I only ask because I come across components like TextField that takes
> a
> >> ResourceModel...I understand why the ResourceModel would use a generic
> >> but
> >> in this case am I forced to put on the TextField.
> >>
> >> Another example is AjaxButton that is being added to a form, what
> >> generic do
> >> I use here? The forms object model type? What if the form doesn't
> have
> >> a
> >> model, say it is using a ValueMap that is a global member of the
> >> form...ie
> >> I've seen this usage in some login example of wicket.
> >>
> >> Just looking for some guidance here guys.
> >> --
> >> View this message in context:
> >> http://www.nabble.com/1.4-Generics-tp16819308p16819308.html
> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/1.4-Generics-tp16819308p16824264.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: 1.4 Generics
Thanks Igornot sure if you really answered what I was getting at though.
I understand generics however there are cases in wicket where I'm wondering
what is best practices.
ie, using your example, a TextField using a ResourceModel, which way would
you go;
TextField tf = new TextField(new
ResourceModel("key"));
or just
TextField tf = new TextField(new ResourceModel("key"));
And what do you use as a generic with the following code block;
class MyForm extends Form {
public MyForm() {
add(new AjaxButton('id', this));
}
}
igor.vaynberg wrote:
>
> generic type on Component represents the type of the modelobject that
> component will hold.
>
> eg TextField tf=new TextField(...);
> means that tf.getModelObject() is of type Integer
>
> -igor
>
>
> On Mon, Apr 21, 2008 at 5:30 PM, mnwicket <[EMAIL PROTECTED]> wrote:
>>
>> Ok, so I starting messing around with the new generics version of
>> wicketand I guess I was a little confused as to how many generics
>> there
>> are. Silly question is when people are doing development are they
>> turning
>> off all generic warnings in eclipse...that is if you are using eclipse?
>>
>> I only ask because I come across components like TextField that takes a
>> ResourceModel...I understand why the ResourceModel would use a generic
>> but
>> in this case am I forced to put on the TextField.
>>
>> Another example is AjaxButton that is being added to a form, what
>> generic do
>> I use here? The forms object model type? What if the form doesn't have
>> a
>> model, say it is using a ValueMap that is a global member of the
>> form...ie
>> I've seen this usage in some login example of wicket.
>>
>> Just looking for some guidance here guys.
>> --
>> View this message in context:
>> http://www.nabble.com/1.4-Generics-tp16819308p16819308.html
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/1.4-Generics-tp16819308p16824264.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Generics: Wildcards
Hi, during the last days I have created several patches that introduce wildcards to generified collections. And very often I have to describe why this is necessary. So I think it might be useful to discuss that topic once and for all. Java developers tend to avoid the wildcards (e.g. List). I don't know exactly why, but most of the time people don't understand why those are necessary - so I try to describe it. List: This declares *any* type of list that contains objects that implement Serializable. That could be a List of Strings or a List of Integers. We just don't know exactly. All we know is that the elements implement Serializable. Those Lists only offer read access. It is not possible to add any elements. Some example assignments: //contains all kinds of Serializables List l = new ArrayList<Serializable>(); //contains *only* Strings List l = new ArrayList(); //contains *only* Integers List l = new ArrayList(); //contains *only* the given kind (that implments Serializable List l = new ArrayList<*anything that implements Serializable*>(); List: This declares a list that contains Serializables - but *all* kinds of Serializables. So it is possible to store Strings *and* Integers (and all other objects that implement Serializable) within that list. It is *only* possible to assign a List: List l = new ArrayList<Serializable>(); It is *not* possible to assign those: List l = new ArrayList(); DOES NOT WORK !!! So what is the problem now: If an interface method forces me to return a List it is *not* possible to return e.g. a List. Instead I have to do fancy things to work around and be able to return that list. But there is just one simple rule that fits nearly every case: As long as you only *read* a collection or return an unmodifiable collection, *always* use wildcards. Only if you need or offer write access, it is necessary to specify a collection exactly. This discussion is necessary, since it is an incompatible change to add wildcards later. This will break your API! There are several bad examples out there that did this error (GlazedList anyone?). It is very hard to fix those issues afterward. So I strongly advice to do those things right before releasing 1.4. Regards, Johannes Schneider smime.p7s Description: S/MIME cryptographic signature
