You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Korbinian Bachl <ko...@whiskyworld.de> on 2007/12/15 11:17:33 UTC
1.4 Wish List
Hi,
i added following items to it:
(http://cwiki.apache.org/confluence/display/WICKET/Wicket+1.4+Wish+List)
Add Rapid Prototyping Forms
The Idea of Alistair Maw and Jonathan Locke (ROR? No. Wicket on Wheels.)
should be included in next Wicket. A set of nice looking
Defaultformcomponents and a Beanresolver to automatically let create
forms from just the plain bean but still allow to customize it later by
overiding parts of it. Beside nice looking (to show/ even may go live
with it in first place) and fast it should have enabled possibility to
integrate security on a Form as well as Field-level.
Clean up/ Have a look at Models
With now having a CompoundPropertyModel that has the same abilities as
BoundCompundPropertyModel it might be nice to have someone overwork all
models and decide if we really need all. Stiping out/ Migrating ino one
e.g.: BoundCompoundProperty and CompoundProperty model as well as others
(if possible) would really ease wicket for beginners as well as save
experienced users some thoughts about what model to use.
Any opinions about these from the core-devs?
Best,
Korbinian
Re: 1.4 Wish List
Posted by Eelco Hillenius <ee...@gmail.com>.
> With now having a CompoundPropertyModel that has the same abilities as
> BoundCompundPropertyModel it might be nice to have someone overwork all
> models and decide if we really need all. Stiping out/ Migrating ino one
> e.g.: BoundCompoundProperty and CompoundProperty model as well as others
> (if possible) would really ease wicket for beginners as well as save
> experienced users some thoughts about what model to use.
Actually, on second thought... I don't think this is important enough.
Deprecation with a note that this model isn't really needed anymore
should be good enough. Not important enough to break clients over
imho.
I think the models are they are now are fine. We've tweaked them a lot
in the last few releases, and now is the time for stability.
Eelco
Re: 1.4 Wish List
Posted by Eelco Hillenius <ee...@gmail.com>.
On Dec 15, 2007 6:18 PM, dtoffe <dt...@yahoo.com.ar> wrote:
>
> Hi !!
>
> Excuse me for stepping into a developer's thread. Creating forms
> automatically from Beans, with defaults but also with the ability to
> customize it later if necessary, sounds a lot like Wicket Web Beans:
>
> http://wicketwebbeans.sourceforge.net/
>
> I've tried it and plan to use it in a new project. Perhaps it's not
> exactly what you had in mind, but it sounds close.
I forgot about that one. Well, that's one item less on the list then :-)
Eelco
Re: 1.4 Wish List
Posted by dtoffe <dt...@yahoo.com.ar>.
Hi !!
Excuse me for stepping into a developer's thread. Creating forms
automatically from Beans, with defaults but also with the ability to
customize it later if necessary, sounds a lot like Wicket Web Beans:
http://wicketwebbeans.sourceforge.net/
I've tried it and plan to use it in a new project. Perhaps it's not
exactly what you had in mind, but it sounds close.
Daniel
Korbinian Bachl wrote:
>
>
> Add Rapid Prototyping Forms
>
> The Idea of Alistair Maw and Jonathan Locke (ROR? No. Wicket on Wheels.)
> should be included in next Wicket. A set of nice looking
> Defaultformcomponents and a Beanresolver to automatically let create
> forms from just the plain bean but still allow to customize it later by
> overiding parts of it. Beside nice looking (to show/ even may go live
> with it in first place) and fast it should have enabled possibility to
> integrate security on a Form as well as Field-level.
>
>
--
View this message in context: http://www.nabble.com/1.4-Wish-List-tp14349485p14357577.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: 1.4 Wish List
Posted by Korbinian Bachl <ko...@whiskyworld.de>.
Hi Eelco,
Eelco Hillenius schrieb:
>> Add Rapid Prototyping Forms
>>
>> The Idea of Alistair Maw and Jonathan Locke (ROR? No. Wicket on Wheels.)
>> should be included in next Wicket. A set of nice looking
>> Defaultformcomponents and a Beanresolver to automatically let create
>> forms from just the plain bean but still allow to customize it later by
>> overiding parts of it. Beside nice looking (to show/ even may go live
>> with it in first place) and fast it should have enabled possibility to
>> integrate security on a Form as well as Field-level.
>
> Nice idea, but personally I think this has all the potential of
> becoming a big can of worms fast. Know where to stop/ what not to
> cover will probably be very important. Also, several people, including
> myself, have given this idea a go, and it seems hard to end up with
> something that everyone likes, that is flexible enough to use yet
> simple.
>
> I think the best thing we can do here is to leave it up to people to
> do this in wicket-stuff.
Can you please tell me what you mean why this could become a "big can of
worms"? what security problems do you see here?
>
>> Clean up/ Have a look at Models
>>
>> With now having a CompoundPropertyModel that has the same abilities as
>> BoundCompundPropertyModel it might be nice to have someone overwork all
>> models and decide if we really need all. Stiping out/ Migrating ino one
>> e.g.: BoundCompoundProperty and CompoundProperty model as well as others
>> (if possible) would really ease wicket for beginners as well as save
>> experienced users some thoughts about what model to use.
>
> Sure. I can't think of much else than just those models though.
Well - cant you integrate 3 into 1? (BoundCompound, Compound and
Property into just a slightly bigger Proeperty?) I mean an enhanced
PropertyModel could eleminate the need for the other 2, so we only have
the Detachables/ Loadables left. Possible?
>
> A general remark about this list is that I also think this actually
> should be 1.4.1. We agreed a long time ago that 1.4 would be only the
> last missing parts of 2.0 (Java 5 related things, most notably
> generics). Like I predicted back then, it is taking us a long time to
> reach 1.3, and we should have the discipline of sticking to what we
> promised way back: 1.4(.0) is about the last 2.0 ports, and after we
> have a good 1.4.0 final, we can start on new features again.
well - my suggestion is to call it 1.5 then and make 1.4 = 1.3 +
Generics + Minor
Best,
Korbinian
Re: 1.4 Wish List
Posted by Eelco Hillenius <ee...@gmail.com>.
On Dec 15, 2007 10:31 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> are we ok with this? the policy so far has been that minor releases
> are binary compatible, so we cant have api breaks between 1.4.0 and
> 1.4.1 just for sake of adding new features... that is why i said after
> 1.4.0 is out we would have to immediately start on 1.5.0....
I guess. So then the naming changes. But the same idea applies: we
don't support 1.4.0 as a separate entity.
Where do you think we'll need API breaks to start with btw?
Eelco
Re: 1.4 Wish List
Posted by Frank Bille <fr...@apache.org>.
On Dec 15, 2007 7:50 PM, Martijn Dashorst <ma...@gmail.com>
wrote:
> I'm not ok with dropping binary compatibility for 1.4.1. Why call it
> 1.4.1if it is in fact
> 1.5 or 2.0?
> I'd rather implement a milestone schedule for 1.4, like the Eclipse
> project
> does:
>
> 1.4-M1 – just generics/left overs from 2.0, bug fixes from 1.3
> 1.4-M2 – additional 1.5 features (mount annotations? varargs?), other
> stuff, bug fixes from 1.3
> 1.4-M3 – other stuff, bug fixes from 1.3
> 1.4-RC1 – bug fixes...
> 1.4-RC2 – bug fixes...
> 1.4-RC3 – bug fixes...
> 1.4 – final
>
+1
I think that fits very well with how we have been doing things.
Frank
Re: 1.4 Wish List
Posted by Johan Compagner <jc...@gmail.com>.
+1
This is what i am telling from the start, generics as soon as possible
after 1.3 (or 1.3.1) as a beta or milestone release of 1.4. People can
use that for development and if we try to not alter many other
things, for production also if needed. But we do say that after the
first b1/m1 there can be some needed breaks and changes before 1.4 is
final (for me around middle of next year)
By the way i have no problem doing the generifying again asap except
that i wont be around from 23 dec to 20 jan.. Holiday!
Johan
On 12/15/07, Martijn Dashorst <ma...@gmail.com> wrote:
> I'm not ok with dropping binary compatibility for 1.4.1. Why call it
> 1.4.1if it is in fact
> 1.5 or 2.0?
> I'd rather implement a milestone schedule for 1.4, like the Eclipse project
> does:
>
> 1.4-M1 – just generics/left overs from 2.0, bug fixes from 1.3
> 1.4-M2 – additional 1.5 features (mount annotations? varargs?), other
> stuff, bug fixes from 1.3
> 1.4-M3 – other stuff, bug fixes from 1.3
> 1.4-RC1 – bug fixes...
> 1.4-RC2 – bug fixes...
> 1.4-RC3 – bug fixes...
> 1.4 – final
>
> Martijn
>
> On Dec 15, 2007 7:31 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>
> > are we ok with this? the policy so far has been that minor releases
> > are binary compatible, so we cant have api breaks between 1.4.0 and
> > 1.4.1 just for sake of adding new features... that is why i said after
> > 1.4.0 is out we would have to immediately start on 1.5.0....
> >
> > -igor
> >
> >
> > On Dec 15, 2007 9:56 AM, Eelco Hillenius <ee...@gmail.com>
> > wrote:
> > > > i am fine with 1.4 being _just_ generics if after 1.4 comes out we
> > > > drop support for 1.3. otherwise it will be like what johan says:
> > > >
> > > > most bugs will affect 1.3 and 1.4 since they are the same code base
> > > > sans generics. after 1.4 comes out we have to start 1.5 immediately
> > > > because 1.4 will be a very short release (just generics). so the said
> > > > bug will most likely affect 1.5 as well. so now we have to merge the
> > > > fix into 1.3, 1.4, 1.5 <== 3 branches to maintain. sucks big time.
> > >
> > > I think you guys have a different idea than I have. I was talking
> > > about 1.4.1 before doing 1.4.1. The idea is to quickly release 1.4.0,
> > > and then go on with 1.4.1 without supporting 1.4.0 as a separate
> > > branch.
> > >
> > > So for clarity, the focus for 1.4.0 is to get those last things of 2.0
> > > in asap. That shouldn't be too hard, and once were done, we'll have a
> > > stable (because we didn't introduce too much new functionality)
> > > release that people will feel comfortable using. Then we start 1.4.1
> > > and don't look back.
> > >
> > > > so if we drop support for 1.3 as soon as we branch 1.4 im fine with
> > > > 1.4 having just generics.
> > >
> > > We had that idea of dropping 1.3/ focussing on one release anyway.
> > > Dropping is too harsh though. We should EOL 1.2 (in fact we already
> > > did) and once we start on 1.4.x, we should only fix important things
> > > in 1.3.x for those who really can't go Java 5. My hunch is that by
> > > now, that group will be quite small, and since 1.4.0 will be backwards
> > > compatible (unless you're not using Java 5 and up), most people will
> > > be fine upgrading to 1.4.0 as if it were a minor release.
> > >
> > > So our plan of attack should be:
> > > * Focus on the missing 2.0 features for 1.4.0 (that's really only the
> > > generics, right?) and release just that.
> > > * We work on 1.4.x as if it were a minor release. The only real
> > > difference is going Java 5. That means that we don't maintain 1.3
> > > separately except for urgent bugs/ people specifically requesting it
> > > (like we've done with 1.2)
> > > * After 1.4.0 is released, we can go on with 1.4.1. Some API breaks
> > > between 1.4.0 and 1.4.1 would be fine, but let's learn from our 2.0
> > > debacle (which still bite me today, as I'm still fixing some of the
> > > last things in WIA!!!) and Tapestry's errors and try to keep those
> > > minimal. There are plenty of things that can be improved without
> > > overhauling the API again, and cosmetic improvements shouldn't be our
> > > priority anymore.
> > >
> > > Eelco
> > >
> >
>
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0-rc1 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
>
Re: 1.4 Wish List
Posted by Eelco Hillenius <ee...@gmail.com>.
On Dec 15, 2007 10:50 AM, Martijn Dashorst <ma...@gmail.com> wrote:
> I'm not ok with dropping binary compatibility for 1.4.1. Why call it
> 1.4.1if it is in fact
> 1.5 or 2.0?
> I'd rather implement a milestone schedule for 1.4, like the Eclipse project
> does:
>
> 1.4-M1 – just generics/left overs from 2.0, bug fixes from 1.3
> 1.4-M2 – additional 1.5 features (mount annotations? varargs?), other
> stuff, bug fixes from 1.3
> 1.4-M3 – other stuff, bug fixes from 1.3
> 1.4-RC1 – bug fixes...
> 1.4-RC2 – bug fixes...
> 1.4-RC3 – bug fixes...
> 1.4 – final
That's fine too. The main point I'm trying to make is that we should
hold back on implementing new API break functionality until we lived
up to our promise of delivering the last 2.0 ports. But we should it
in such a way that we don't hold back any new development for the next
year either.
Eelco
Re: 1.4 Wish List
Posted by Martijn Dashorst <ma...@gmail.com>.
I'm not ok with dropping binary compatibility for 1.4.1. Why call it
1.4.1if it is in fact
1.5 or 2.0?
I'd rather implement a milestone schedule for 1.4, like the Eclipse project
does:
1.4-M1 – just generics/left overs from 2.0, bug fixes from 1.3
1.4-M2 – additional 1.5 features (mount annotations? varargs?), other
stuff, bug fixes from 1.3
1.4-M3 – other stuff, bug fixes from 1.3
1.4-RC1 – bug fixes...
1.4-RC2 – bug fixes...
1.4-RC3 – bug fixes...
1.4 – final
Martijn
On Dec 15, 2007 7:31 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> are we ok with this? the policy so far has been that minor releases
> are binary compatible, so we cant have api breaks between 1.4.0 and
> 1.4.1 just for sake of adding new features... that is why i said after
> 1.4.0 is out we would have to immediately start on 1.5.0....
>
> -igor
>
>
> On Dec 15, 2007 9:56 AM, Eelco Hillenius <ee...@gmail.com>
> wrote:
> > > i am fine with 1.4 being _just_ generics if after 1.4 comes out we
> > > drop support for 1.3. otherwise it will be like what johan says:
> > >
> > > most bugs will affect 1.3 and 1.4 since they are the same code base
> > > sans generics. after 1.4 comes out we have to start 1.5 immediately
> > > because 1.4 will be a very short release (just generics). so the said
> > > bug will most likely affect 1.5 as well. so now we have to merge the
> > > fix into 1.3, 1.4, 1.5 <== 3 branches to maintain. sucks big time.
> >
> > I think you guys have a different idea than I have. I was talking
> > about 1.4.1 before doing 1.4.1. The idea is to quickly release 1.4.0,
> > and then go on with 1.4.1 without supporting 1.4.0 as a separate
> > branch.
> >
> > So for clarity, the focus for 1.4.0 is to get those last things of 2.0
> > in asap. That shouldn't be too hard, and once were done, we'll have a
> > stable (because we didn't introduce too much new functionality)
> > release that people will feel comfortable using. Then we start 1.4.1
> > and don't look back.
> >
> > > so if we drop support for 1.3 as soon as we branch 1.4 im fine with
> > > 1.4 having just generics.
> >
> > We had that idea of dropping 1.3/ focussing on one release anyway.
> > Dropping is too harsh though. We should EOL 1.2 (in fact we already
> > did) and once we start on 1.4.x, we should only fix important things
> > in 1.3.x for those who really can't go Java 5. My hunch is that by
> > now, that group will be quite small, and since 1.4.0 will be backwards
> > compatible (unless you're not using Java 5 and up), most people will
> > be fine upgrading to 1.4.0 as if it were a minor release.
> >
> > So our plan of attack should be:
> > * Focus on the missing 2.0 features for 1.4.0 (that's really only the
> > generics, right?) and release just that.
> > * We work on 1.4.x as if it were a minor release. The only real
> > difference is going Java 5. That means that we don't maintain 1.3
> > separately except for urgent bugs/ people specifically requesting it
> > (like we've done with 1.2)
> > * After 1.4.0 is released, we can go on with 1.4.1. Some API breaks
> > between 1.4.0 and 1.4.1 would be fine, but let's learn from our 2.0
> > debacle (which still bite me today, as I'm still fixing some of the
> > last things in WIA!!!) and Tapestry's errors and try to keep those
> > minimal. There are plenty of things that can be improved without
> > overhauling the API again, and cosmetic improvements shouldn't be our
> > priority anymore.
> >
> > Eelco
> >
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-rc1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
Re: 1.4 Wish List
Posted by Igor Vaynberg <ig...@gmail.com>.
are we ok with this? the policy so far has been that minor releases
are binary compatible, so we cant have api breaks between 1.4.0 and
1.4.1 just for sake of adding new features... that is why i said after
1.4.0 is out we would have to immediately start on 1.5.0....
-igor
On Dec 15, 2007 9:56 AM, Eelco Hillenius <ee...@gmail.com> wrote:
> > i am fine with 1.4 being _just_ generics if after 1.4 comes out we
> > drop support for 1.3. otherwise it will be like what johan says:
> >
> > most bugs will affect 1.3 and 1.4 since they are the same code base
> > sans generics. after 1.4 comes out we have to start 1.5 immediately
> > because 1.4 will be a very short release (just generics). so the said
> > bug will most likely affect 1.5 as well. so now we have to merge the
> > fix into 1.3, 1.4, 1.5 <== 3 branches to maintain. sucks big time.
>
> I think you guys have a different idea than I have. I was talking
> about 1.4.1 before doing 1.4.1. The idea is to quickly release 1.4.0,
> and then go on with 1.4.1 without supporting 1.4.0 as a separate
> branch.
>
> So for clarity, the focus for 1.4.0 is to get those last things of 2.0
> in asap. That shouldn't be too hard, and once were done, we'll have a
> stable (because we didn't introduce too much new functionality)
> release that people will feel comfortable using. Then we start 1.4.1
> and don't look back.
>
> > so if we drop support for 1.3 as soon as we branch 1.4 im fine with
> > 1.4 having just generics.
>
> We had that idea of dropping 1.3/ focussing on one release anyway.
> Dropping is too harsh though. We should EOL 1.2 (in fact we already
> did) and once we start on 1.4.x, we should only fix important things
> in 1.3.x for those who really can't go Java 5. My hunch is that by
> now, that group will be quite small, and since 1.4.0 will be backwards
> compatible (unless you're not using Java 5 and up), most people will
> be fine upgrading to 1.4.0 as if it were a minor release.
>
> So our plan of attack should be:
> * Focus on the missing 2.0 features for 1.4.0 (that's really only the
> generics, right?) and release just that.
> * We work on 1.4.x as if it were a minor release. The only real
> difference is going Java 5. That means that we don't maintain 1.3
> separately except for urgent bugs/ people specifically requesting it
> (like we've done with 1.2)
> * After 1.4.0 is released, we can go on with 1.4.1. Some API breaks
> between 1.4.0 and 1.4.1 would be fine, but let's learn from our 2.0
> debacle (which still bite me today, as I'm still fixing some of the
> last things in WIA!!!) and Tapestry's errors and try to keep those
> minimal. There are plenty of things that can be improved without
> overhauling the API again, and cosmetic improvements shouldn't be our
> priority anymore.
>
> Eelco
>
Re: 1.4 Wish List
Posted by Jan Vermeulen <ja...@isencia.com>.
done.
Johan Compagner wrote:
>
> For this do make 2 issues in our jira. So that we really don't overlook it
>
> johan
>
--
View this message in context: http://www.nabble.com/1.4-Wish-List-tp14349485p14403286.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: 1.4 Wish List
Posted by Johan Compagner <jc...@gmail.com>.
For this do make 2 issues in our jira. So that we really don't overlook it
johan
On Dec 18, 2007 11:21 AM, Jan Vermeulen <ja...@isencia.com> wrote:
>
>
> Johan Compagner wrote:
> >
> >>
> >> * alternate parents: in 2.0, there was a possibility to define an
> >> alternate
> >> parent to add child components.
> >
> >
> > isn't this transparent resolver?
> >
>
> No, it's not. It's allowing users to add child components to a 'blackbox'
> component directly, while they are actually added to some internal
> container
> (that you don't want to expose). One option was to allow the 'add()' to be
> overridden, but that seemed to be unacceptable. The other was to have an
> interface IAlternateParent that was considered within the add(). That was
> what 2.0 offered.
>
> Is there any chance we get something similar in 1.4 ?
>
>
> Johan Compagner wrote:
> >
> >>
> >> * markup fragments: in 1.3, calling renderComponent() (for Ajax
> requests)
> >> fails if no markup is associated with that component or the direct
> parent
> >> of
> >> that container. In 2.0, this was no problem (I suppose because of the
> way
> >> markup fragments were assigned to components)
> >
> >
> > why would you call render() on something that has no markup? and
> > then an error shouldn't be thrown?
> > I guess in 2.0 this was an impossible situation. There was always markup
> > attached.
> > because that was already done in the constructor.
> >
>
> I did not explain correctly the problem: renderComponent() fails for
> components that are dynamically created and contained in a RepeatingView.
> Since MarkupFragmentFinder tries to locate a markup element with the id of
> the component, it fails to locate any markup for these components.
>
> This occurs if we want to render separately a single row in a table or a
> single button in a dynamically constructed menu. This was possible in 2.0,
> but it's not in 1.3. For now, we have to render the whole table or the
> whole
> menu to refresh a single line or button.
>
> Would it not be nice to allow this in 1.4 ?
>
> Jan.
> --
> View this message in context:
> http://www.nabble.com/1.4-Wish-List-tp14349485p14390821.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com<http://nabble.com/>
> .
>
>
Re: 1.4 Wish List
Posted by Jan Vermeulen <ja...@isencia.com>.
Johan Compagner wrote:
>
>>
>> * alternate parents: in 2.0, there was a possibility to define an
>> alternate
>> parent to add child components.
>
>
> isn't this transparent resolver?
>
No, it's not. It's allowing users to add child components to a 'blackbox'
component directly, while they are actually added to some internal container
(that you don't want to expose). One option was to allow the 'add()' to be
overridden, but that seemed to be unacceptable. The other was to have an
interface IAlternateParent that was considered within the add(). That was
what 2.0 offered.
Is there any chance we get something similar in 1.4 ?
Johan Compagner wrote:
>
>>
>> * markup fragments: in 1.3, calling renderComponent() (for Ajax requests)
>> fails if no markup is associated with that component or the direct parent
>> of
>> that container. In 2.0, this was no problem (I suppose because of the way
>> markup fragments were assigned to components)
>
>
> why would you call render() on something that has no markup? and
> then an error shouldn't be thrown?
> I guess in 2.0 this was an impossible situation. There was always markup
> attached.
> because that was already done in the constructor.
>
I did not explain correctly the problem: renderComponent() fails for
components that are dynamically created and contained in a RepeatingView.
Since MarkupFragmentFinder tries to locate a markup element with the id of
the component, it fails to locate any markup for these components.
This occurs if we want to render separately a single row in a table or a
single button in a dynamically constructed menu. This was possible in 2.0,
but it's not in 1.3. For now, we have to render the whole table or the whole
menu to refresh a single line or button.
Would it not be nice to allow this in 1.4 ?
Jan.
--
View this message in context: http://www.nabble.com/1.4-Wish-List-tp14349485p14390821.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: 1.4 Wish List
Posted by Johan Compagner <jc...@gmail.com>.
>
> * alternate parents: in 2.0, there was a possibility to define an
> alternate
> parent to add child components.
isn't this transparent resolver?
>
> * markup fragments: in 1.3, calling renderComponent() (for Ajax requests)
> fails if no markup is associated with that component or the direct parent
> of
> that container. In 2.0, this was no problem (I suppose because of the way
> markup fragments were assigned to components)
why would you call render() on something that has no markup? and
then an error shouldn't be thrown?
I guess in 2.0 this was an impossible situation. There was always markup
attached.
because that was already done in the constructor.
johan
Re: 1.4 Wish List
Posted by Jan Vermeulen <ja...@isencia.com>.
As I see the only leftover from 2.0 you're talking about is generics, I would
like to mention a few more. Back in may (when 1.3 was about to be released
half of june), backporting of a few things from 2.0 has been postponed to a
1.4. As we had to backport our code from 2.0, I remember these:
* alternate parents: in 2.0, there was a possibility to define an alternate
parent to add child components.
* markup fragments: in 1.3, calling renderComponent() (for Ajax requests)
fails if no markup is associated with that component or the direct parent of
that container. In 2.0, this was no problem (I suppose because of the way
markup fragments were assigned to components)
Is there any chance that these get backported ?
Jan.
Eelco Hillenius wrote:
>
>> i am fine with 1.4 being _just_ generics if after 1.4 comes out we
>> drop support for 1.3. otherwise it will be like what johan says:
>>
>> most bugs will affect 1.3 and 1.4 since they are the same code base
>> sans generics. after 1.4 comes out we have to start 1.5 immediately
>> because 1.4 will be a very short release (just generics). so the said
>> bug will most likely affect 1.5 as well. so now we have to merge the
>> fix into 1.3, 1.4, 1.5 <== 3 branches to maintain. sucks big time.
>
> I think you guys have a different idea than I have. I was talking
> about 1.4.1 before doing 1.4.1. The idea is to quickly release 1.4.0,
> and then go on with 1.4.1 without supporting 1.4.0 as a separate
> branch.
>
> So for clarity, the focus for 1.4.0 is to get those last things of 2.0
> in asap. That shouldn't be too hard, and once were done, we'll have a
> stable (because we didn't introduce too much new functionality)
> release that people will feel comfortable using. Then we start 1.4.1
> and don't look back.
>
>> so if we drop support for 1.3 as soon as we branch 1.4 im fine with
>> 1.4 having just generics.
>
> We had that idea of dropping 1.3/ focussing on one release anyway.
> Dropping is too harsh though. We should EOL 1.2 (in fact we already
> did) and once we start on 1.4.x, we should only fix important things
> in 1.3.x for those who really can't go Java 5. My hunch is that by
> now, that group will be quite small, and since 1.4.0 will be backwards
> compatible (unless you're not using Java 5 and up), most people will
> be fine upgrading to 1.4.0 as if it were a minor release.
>
> So our plan of attack should be:
> * Focus on the missing 2.0 features for 1.4.0 (that's really only the
> generics, right?) and release just that.
> * We work on 1.4.x as if it were a minor release. The only real
> difference is going Java 5. That means that we don't maintain 1.3
> separately except for urgent bugs/ people specifically requesting it
> (like we've done with 1.2)
> * After 1.4.0 is released, we can go on with 1.4.1. Some API breaks
> between 1.4.0 and 1.4.1 would be fine, but let's learn from our 2.0
> debacle (which still bite me today, as I'm still fixing some of the
> last things in WIA!!!) and Tapestry's errors and try to keep those
> minimal. There are plenty of things that can be improved without
> overhauling the API again, and cosmetic improvements shouldn't be our
> priority anymore.
>
> Eelco
>
>
--
View this message in context: http://www.nabble.com/1.4-Wish-List-tp14349485p14370194.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: 1.4 Wish List
Posted by Eelco Hillenius <ee...@gmail.com>.
> I think you guys have a different idea than I have. I was talking
> about 1.4.1 before doing 1.4.1.
must be: about 1.4.1 before doing 1.4.0.
Eelco
Re: 1.4 Wish List
Posted by Eelco Hillenius <ee...@gmail.com>.
> i am fine with 1.4 being _just_ generics if after 1.4 comes out we
> drop support for 1.3. otherwise it will be like what johan says:
>
> most bugs will affect 1.3 and 1.4 since they are the same code base
> sans generics. after 1.4 comes out we have to start 1.5 immediately
> because 1.4 will be a very short release (just generics). so the said
> bug will most likely affect 1.5 as well. so now we have to merge the
> fix into 1.3, 1.4, 1.5 <== 3 branches to maintain. sucks big time.
I think you guys have a different idea than I have. I was talking
about 1.4.1 before doing 1.4.1. The idea is to quickly release 1.4.0,
and then go on with 1.4.1 without supporting 1.4.0 as a separate
branch.
So for clarity, the focus for 1.4.0 is to get those last things of 2.0
in asap. That shouldn't be too hard, and once were done, we'll have a
stable (because we didn't introduce too much new functionality)
release that people will feel comfortable using. Then we start 1.4.1
and don't look back.
> so if we drop support for 1.3 as soon as we branch 1.4 im fine with
> 1.4 having just generics.
We had that idea of dropping 1.3/ focussing on one release anyway.
Dropping is too harsh though. We should EOL 1.2 (in fact we already
did) and once we start on 1.4.x, we should only fix important things
in 1.3.x for those who really can't go Java 5. My hunch is that by
now, that group will be quite small, and since 1.4.0 will be backwards
compatible (unless you're not using Java 5 and up), most people will
be fine upgrading to 1.4.0 as if it were a minor release.
So our plan of attack should be:
* Focus on the missing 2.0 features for 1.4.0 (that's really only the
generics, right?) and release just that.
* We work on 1.4.x as if it were a minor release. The only real
difference is going Java 5. That means that we don't maintain 1.3
separately except for urgent bugs/ people specifically requesting it
(like we've done with 1.2)
* After 1.4.0 is released, we can go on with 1.4.1. Some API breaks
between 1.4.0 and 1.4.1 would be fine, but let's learn from our 2.0
debacle (which still bite me today, as I'm still fixing some of the
last things in WIA!!!) and Tapestry's errors and try to keep those
minimal. There are plenty of things that can be improved without
overhauling the API again, and cosmetic improvements shouldn't be our
priority anymore.
Eelco
Re: 1.4 Wish List
Posted by Igor Vaynberg <ig...@gmail.com>.
well, those discussions were all based on the fact that we release 1.3
somewhere in june if i recall correctly.
i am fine with 1.4 being _just_ generics if after 1.4 comes out we
drop support for 1.3. otherwise it will be like what johan says:
most bugs will affect 1.3 and 1.4 since they are the same code base
sans generics. after 1.4 comes out we have to start 1.5 immediately
because 1.4 will be a very short release (just generics). so the said
bug will most likely affect 1.5 as well. so now we have to merge the
fix into 1.3, 1.4, 1.5 <== 3 branches to maintain. sucks big time.
so if we drop support for 1.3 as soon as we branch 1.4 im fine with
1.4 having just generics.
-igor
On Dec 15, 2007 5:43 AM, Gwyn Evans <gw...@gmail.com> wrote:
> On 15/12/2007, Eelco Hillenius <ee...@gmail.com> wrote:
> > A general remark about this list is that I also think this actually
> > should be 1.4.1. We agreed a long time ago that 1.4 would be only the
> > last missing parts of 2.0 (Java 5 related things, most notably
> > generics). Like I predicted back then, it is taking us a long time to
> > reach 1.3, and we should have the discipline of sticking to what we
> > promised way back: 1.4(.0) is about the last 2.0 ports, and after we
> > have a good 1.4.0 final, we can start on new features again.
>
> Totally agree - I think I saw a comment on users@ from Johan or Igor
> to the effect that we hadn't had a discussion as to what 1.4 was,
> whereas my recollection is that we certainly stated what 1.4.0 was to
> be, i.e. as above.
>
> Personally, I'd be very against anything going into 1.4 that wasn't
> either a bug-fix found in 1.3.x or directly related to a 'missing' 2.0
> feature.
>
> /Gwyn
> --
> Download Wicket 1.3.0-rc2 now! - http://wicketframework.org
>
Re: 1.4 Wish List
Posted by Johan Compagner <jc...@gmail.com>.
I disagree with this and i will always vote this down.
1.4 will not be just a 1.3 with generics. If we do that then i will
tell everybody now that i will not merge over 3 branches.
Also 1.4.1 with suddenly api breaks?? 1.4.x should be api stable. So
all the new features then will be 1.5. So then we have 3 branches
then.
So we just should do something else. After 1.3 make a timeframe let
say july 2008 we will try to release 1.4 and then try to get things in
what we can.
Johan
On 12/15/07, Gwyn Evans <gw...@gmail.com> wrote:
> On 15/12/2007, Eelco Hillenius <ee...@gmail.com> wrote:
> > A general remark about this list is that I also think this actually
> > should be 1.4.1. We agreed a long time ago that 1.4 would be only the
> > last missing parts of 2.0 (Java 5 related things, most notably
> > generics). Like I predicted back then, it is taking us a long time to
> > reach 1.3, and we should have the discipline of sticking to what we
> > promised way back: 1.4(.0) is about the last 2.0 ports, and after we
> > have a good 1.4.0 final, we can start on new features again.
>
> Totally agree - I think I saw a comment on users@ from Johan or Igor
> to the effect that we hadn't had a discussion as to what 1.4 was,
> whereas my recollection is that we certainly stated what 1.4.0 was to
> be, i.e. as above.
>
> Personally, I'd be very against anything going into 1.4 that wasn't
> either a bug-fix found in 1.3.x or directly related to a 'missing' 2.0
> feature.
>
> /Gwyn
> --
> Download Wicket 1.3.0-rc2 now! - http://wicketframework.org
>
Re: 1.4 Wish List
Posted by Gwyn Evans <gw...@gmail.com>.
On 15/12/2007, Eelco Hillenius <ee...@gmail.com> wrote:
> A general remark about this list is that I also think this actually
> should be 1.4.1. We agreed a long time ago that 1.4 would be only the
> last missing parts of 2.0 (Java 5 related things, most notably
> generics). Like I predicted back then, it is taking us a long time to
> reach 1.3, and we should have the discipline of sticking to what we
> promised way back: 1.4(.0) is about the last 2.0 ports, and after we
> have a good 1.4.0 final, we can start on new features again.
Totally agree - I think I saw a comment on users@ from Johan or Igor
to the effect that we hadn't had a discussion as to what 1.4 was,
whereas my recollection is that we certainly stated what 1.4.0 was to
be, i.e. as above.
Personally, I'd be very against anything going into 1.4 that wasn't
either a bug-fix found in 1.3.x or directly related to a 'missing' 2.0
feature.
/Gwyn
--
Download Wicket 1.3.0-rc2 now! - http://wicketframework.org
Re: 1.4 Wish List
Posted by Eelco Hillenius <ee...@gmail.com>.
> Add Rapid Prototyping Forms
>
> The Idea of Alistair Maw and Jonathan Locke (ROR? No. Wicket on Wheels.)
> should be included in next Wicket. A set of nice looking
> Defaultformcomponents and a Beanresolver to automatically let create
> forms from just the plain bean but still allow to customize it later by
> overiding parts of it. Beside nice looking (to show/ even may go live
> with it in first place) and fast it should have enabled possibility to
> integrate security on a Form as well as Field-level.
Nice idea, but personally I think this has all the potential of
becoming a big can of worms fast. Know where to stop/ what not to
cover will probably be very important. Also, several people, including
myself, have given this idea a go, and it seems hard to end up with
something that everyone likes, that is flexible enough to use yet
simple.
I think the best thing we can do here is to leave it up to people to
do this in wicket-stuff.
> Clean up/ Have a look at Models
>
> With now having a CompoundPropertyModel that has the same abilities as
> BoundCompundPropertyModel it might be nice to have someone overwork all
> models and decide if we really need all. Stiping out/ Migrating ino one
> e.g.: BoundCompoundProperty and CompoundProperty model as well as others
> (if possible) would really ease wicket for beginners as well as save
> experienced users some thoughts about what model to use.
Sure. I can't think of much else than just those models though.
A general remark about this list is that I also think this actually
should be 1.4.1. We agreed a long time ago that 1.4 would be only the
last missing parts of 2.0 (Java 5 related things, most notably
generics). Like I predicted back then, it is taking us a long time to
reach 1.3, and we should have the discipline of sticking to what we
promised way back: 1.4(.0) is about the last 2.0 ports, and after we
have a good 1.4.0 final, we can start on new features again.
Eelco