Dear community,Several users have requested our vision on what to do next now 1.2 is out. After several months of hard work for getting
1.2 out of the door and thinking about what next, the core contributors
have come to the following roadmap. We asked you previously about what
the future should
If we do this (java5 and constructor change at once)Then we need to support 2 really different versions1.2 like it is now and a pretty much changed wicket by internals (constructor) and java5.If we don't we only really have to support
1.3 and 2.0 but those wickets are pretty much the same except
I agree with Justin, if you are already introducing a break, put them all into 1 release. Let's say you break the constructors (I'm sorry I'm not farmiliar exactly with what was refactored) and then a certain number of people re-normalize ontop of it, then you break it all over again for Java 5,
The difference between these two changes is though, that people can
always 'fix' their code to work with the constructor change, but they
might not be able to move to Java 5 due to external factors (ie they
can't run on a platform with Java 5 support).
Eelco
On 2/16/06, Riyad Kalla [EMAIL
*puts on his Vote for Igor shirt*On 2/16/06, Johan Compagner [EMAIL PROTECTED] wrote:
igor is ofcourse 100% right !We all should really listen to what igor has to say on this matter!!I always completely agree with igor! We all should follow him!!johan
On 2/16/06, Igor Vaynberg [EMAIL PROTECTED]
it doesnt matter how the post started, you have to read the entire thing.first he said what the constructor refactor isthen he asked when we should do it.there was never a question of /how/ the refactor will look.
furthermore, i asked gili not to post any discussion into /this/ thread. is that so
igor is ofcourse 100% right !We all should really listen to what igor has to say on this matter!!I always completely agree with igor! We all should follow him!!johan
On 2/16/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
it doesnt matter how the post started, you have to read the entire thing.first he
So, if we wrap up this thread, I think this is roughly the outcome:
Most people are +1 on the JDK 5 move.
About half (not an exact count) think we should do do it in one
release, the others think seperately is a better idea.
I think having seperate releases (1.3. for the constructor change, 2.0
Eelco Hillenius wrote:
SNIP
Only thing for us is that we have to support both 1.2 and 1.3.
Does that mean supporting 3 branches; 1.2, 1.3 and eventually 2.0? Or
did you mean support 1.2 and 1.3 until 2.0 comes out; then supporting
1.3 and 2.0?
Just curious on how much I should pity the
Yeah, that would mean supporting 1.2 and 1.3 as branches. 2.0 would be
HEAD. For us it would be way less work if we'd move to 1.2 directly.
But that would probably be a bummer for people that don't want to make
the move to JDK 5, but who do want to take advantage of the
constructor change.
Eelco
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
The constructor change is going to be disruptive enough that maybe
switching both at once wouldn't be so bad. That'd mean only two
branches to maintain which would be a lot less work on you guys. That'd
be my vote. It sucks for those who can't
Certainly true.
On 2/16/06, Justin Lee [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
The constructor change is going to be disruptive enough that maybe
switching both at once wouldn't be so bad. That'd mean only two
branches to maintain which would be a lot
I think is better make the tow changes in 1.3, i think is less work
for you the developers and for us end users.
On 2/16/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Certainly true.
On 2/16/06, Justin Lee [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
The
Hey,
What about RFE 1249933?
It would be really useful to have more formal CSS/JS support in Wicket
such that we can use them as markup files and insert dynamic elements.
We can currently hack this though without formal support there is no
previewability and it's definitely harder
I tend to agree... could we perhaps have another thread for a formal vote? I've read through this thread and I just don't see that many people who both don't want 1.5 and do want the constructor change.Perhaps a survey like:
1. I need the constructor change NOW, but don't want 1.52. I don't care
Gili wrote:
From past experience, whenever classes require arguments in their
constructors there is always some flexibility lost. For example, you
absolutely cannot invoke any code before super() if you subclass such
a class so if the value of one of the arguments needs to be calculated
How is this method any different with our current Component.setParent(), called in Component.add() Then we still don't have the parent (==page) already available in the constructor.And what does that last part (flexibility lost) have to do with adding a parent in the constructor
You just have to
I know I'm not an wicket expert. But would it help to change the
constructors in wicket to factory methods?
On 2/15/06, Johan Compagner [EMAIL PROTECTED] wrote:
How is this method any different with our current Component.setParent(),
called in Component.add()
Then we still don't have the
You have a big problem when a class depends on the behavior of a
sub-class during construction time. This is because sub-classes are
initialized after the initialization of the base-class. When there is no
dependency, there is no problem.
So, although I recognize Gili's point in general, I
urghhHow would factory methods help?and how would i use standaard factory methods to create components/panels and the like?What then when i want to construct this panel:MyPanel(Container parent, MyObject object, int size)
{}On 2/15/06, Jesper Preuss [EMAIL PROTECTED] wrote:
I know I'm not an
This is what seems the safest to me...
- v1.2 : Stop adding features RC/Release it :-)
- v1.3 : v1.2 + Constructor Change + /maybe/ minimal other (ajax?)
changes... (Try *really* hard not to feature-creep!)
- v2.0 : Requies Java 1.5 (Try to release sometime before Java 1.6 ships!)
/Gwyn
On
we have considered both options when figuring out the solution. we called it init() instead of bind() but it was basically the same thing.here are some advantages of a constructor over an init() method:1) constructors are atomic
2) an exception thrown from a constructor will prevent the object
Yes, it uses concurrent-backport.On 2/14/06, Mark Derricutt [EMAIL PROTECTED] wrote:
On 2/15/06, Jesse Sightler [EMAIL PROTECTED] wrote:
Actually, the really nice thing about Retrotranslator (as opposed to Retroweaver) is that it does support quite a few of the new Java 1.5 APIs.
Replies below...
Igor Vaynberg wrote:
we have considered both options when figuring out the solution. we
called it init() instead of bind() but it was basically the same thing.
here are some advantages of a constructor over an init() method:
1) constructors are atomic
Wicket
1) constructors are atomic
Wicket components have always been thread-unsafe by design, so I fail
to see how this is relevant. Do you plan on sharing Wicket components
across threads anytime soon? Just define Component.isInit() and set it
to true if a component has been initialized,
first of all we have already decided that this is going to happen. there was a vote and it passed. this is what the original posting by martijn implied, he asked for /when/ not /how/.second of all i asked you to not post any discussion of this to this thread, i really dont understand why this is
We are starting a Wicket project, we use JDK 1.4 because our old
software can't run on 1.5.
It's a problem, to move to 1.5, but we will eventually do it. But will
take a few years.
So I vote for waiting with Java 1.5 until Wicket version 3.0.
On 2/14/06, wang lei [EMAIL PROTECTED] wrote:
Here
+1 for the Constructor refactoring to 1.3
+1 for Java 1.5 ASAP! I see more and more momentum for 1.5 out
amongst our customers and the switch is going on already as more and
more realise that it's really not such a scary move. And the fringing
faces of the few bound to 1.4 should be
are we sure we just one to package that in the wicket.jar?Why not release it as a seperate jar? What is wrong with that? Then people can choose to use it or not.(just like extentions)We just have to sync the release cycle.
On 2/14/06, Jonathan Locke [EMAIL PROTECTED] wrote:
+1 on Java 5 sooner.
having 1.3 with constructor change and fixes and maybe one or 2 things more (ajax related) looks fine to meand then 2.0 with java 5 support.I will then try to backport most wanted features and bug fixes if possible because i can't use
1.5 because manymany customers don't run 1.5 on there servers.
Java 5 support would be a really big plus
(esp. with tools like Retrotranslator and Retroweaver) for me as well.
We've tried Retroweaver with our desktop applications and it failed
completely for non-trivial stuff. A few days ago I've tried
Retrotranslator (did not know about it before) and
Martijn Dashorst schrieb:
- constructor refactor
Wow, that's a /major/ change and will probably effect every custom
component and every application written using Wicket.
I see the benefit of having a complete component hierarchy availably
right at the initialization of a class.
But
Here is my opinion:+1 for the Constructor refactoring to 1.3 for JDK5 it's better to split another wicket-jdk5.jar so we can benefit from it *now*.And merging both together when wicket 2.5 or 3 finished.
I hope future wicket can buddle all fundamentals in one single package, say,
download one
that would be very hard to maintain.For example if you have a panel that is rewritten by using only the new parent in constructor params.And you add that in youre own webpage/panel that doesn't use that parent in constructor param.
Then you get all kind of errors because the child panel expect to
another java5 jar that is an add on for the normal wicket.jar?If we introduce generics i think it will be ALL over the place throughout the complete code base of wicket.There is no real seperation.johan
On 2/14/06, Ingram Chen [EMAIL PROTECTED] wrote:
Here is my opinion:+1 for the Constructor
Johan Compagner schrieb:
that would be very hard to maintain.
For example if you have a panel that is rewritten by using only the new
parent in constructor params.
And you add that in youre own webpage/panel that doesn't use that parent in
constructor param.
Then you get all kind of errors
But wouldn't it suffice to just make the new constructors available, and
put a clear statement in the API docs? Then maybe deprecate the public
add() in the next major version, and drop it in 2.0 or something like that?
That's an option we discussed, and as usual is has opponents and
After reading everybody's posts and thinking what I myself would want to
have in future wicket releases:
JDK 1.5 support is here for too long not to have it in. I know it's
tough for the people who need to deploy on 1.4 in the future but Os is
supposed to drive innovation. How to do it if
Yeah. One of our most important use of generics would be IModel. It's
just not possible to seperate that from core without having to
maintain seperate code bases.
Eelco
On 2/14/06, Johan Compagner [EMAIL PROTECTED] wrote:
another java5 jar that is an add on for the normal wicket.jar?
If we
On Tuesday 14 Feb 2006 11:43, Eelco Hillenius wrote:
move. I am always in favor of clarity and breaking early in these
matters.
I would certainly rather see wicket become a better framework than be held
back by backwards compatibility. Those who are not willing to refactor their
ui code
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I'm +1 for the 1.5 change and the constructor change. I think upgrading
to 1.5 has many advantages and while it sucks for those left on 1.4 (or
god forbid 1.3!) we can't keep dragging our feet for stragglers.
Eelco Hillenius wrote:
Yeah. One
i think wicket starting out on 1.4 will need to stabilize properly on 1.4 before leaping to tiger. even though tiger has many tasty features like annotations and generics but since servers are still quite 1.4 friendly than
1.5, its important to consider that.
although if it has to change to
On Feb 13, 2006, at 4:53 PM, Martijn Dashorst wrote:
All,
- constructor refactor
we have reached a limit to the support we want to provide
for Ajax and javascript. In order to provide the best support
+1 on the constructor refactor, just means I'll have to convert a few
On Feb 13, 2006, at 5:53 PM, Martijn Dashorst wrote:
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
+1 on the upgrade to 1.5
+1 on adding parent to the constructor
1.2 will serve well for those who can't be bothered to
+1 for Jonathan Locke´s statement.
regardsOn 2/14/06, Jonathan Locke [EMAIL PROTECTED] wrote:
+1 on Java 5 sooner. for one thing, we can't fold the
authentication package into the core until we adopt it. for
another, the lack of typesafe models is something we ought to remedy as
soon as we
Please ensure, that wicket still can be used on old 1.4 platforms (e.g.
with retrotranslator). Not every provider has already switched to Java 1.5.
--
Cheers,
Tom
Tom S. wrote:
Java 5 support would be a really big plus
(esp. with tools like Retrotranslator and Retroweaver) for me as well.
Hi,
The main trunk of TestNG (http:/testng.org/) is JDK 1.5 source base. Still we are able to release it
for JDK1.4. The trick is simple: a compiler flag. There is still some small restriction: the code
should not use JDK1.5-only API. If you can avoid this, than I can definitely pass you the
Actually, the really nice thing about Retrotranslator (as opposed to Retroweaver) is that it does support quite a few of the new Java 1.5 APIs. java.util.concurrent and StringBuilder are both supported.-- Jess
http://www.jroller.com/page/jsight/On 2/14/06, Erik van Oosten
[EMAIL PROTECTED]
On 2/15/06, Jesse Sightler [EMAIL PROTECTED] wrote:
Actually, the really nice thing about Retrotranslator (as opposed to Retroweaver) is that it does support quite a few of the new Java 1.5 APIs. java.util.concurrent and StringBuilder are both supported.
Interesting - does it make use of the
Just curious, can you be more specific about problems with Retroweaver?
Thanks,
Gili
Tom S. wrote:
Java 5 support would be a really big plus
(esp. with tools like Retrotranslator and Retroweaver) for me as well.
We've tried Retroweaver with our desktop applications and it failed
Instead of introducing extra arguments to the constructor, why not
simply move all this logic into a new method?
That is, introduce Component.bind(Component parent). We'd benefit from
the fact that Wicket components could become JavaBeans and method-based
binding is more flexible than
All,
We are of course very busy finalizing Wicket 1.2, and we /really/ hope
to get it done soon. This will benefit everyone. So I want to take a
look beyond 1.2 and try to get some opinions on our roadmap, and
adjust where appropiate.
There are two very big things ahead of us:
- constructor
Here are mine:
The questions I'm seeking answers to are the following:
- should the post 1.2 version of Wicket involve both changes?
No. The constructor changes first, we can call it 1.3, and that
version should be primarily just that change and some minor ones
around it.
- should we make
I'm completely in favor of jumping to Wicket 2.0 and implementing both
of these changes with it. Java 5 support would be a really big plus
(esp. with tools like Retrotranslator and Retroweaver) for me as well.
I'm sure that won't be perfect for some people, but I think it is
reasonable to cut
Here is my opinions: - should the post 1.2 version of Wicket involve both changes?Absolutely not.I support the constructor change ,because it force the programmer to do in a right way.I don't want wicket support JDK1.5 soon.I know generics can bring many benefits.But there is a long time before
Seems to me you guys are quickly running out of things to work on.
Might I humbly suggest you schedule RFE #1228367 for the next release?
On a related note, I believe RFE #1167649 can be closed as fixed.
Thanks,
Gili
Martijn Dashorst wrote:
All,
We are of course very busy finalizing
Say what? Running out of things to work on? That's a joke, right? May
I remind you that we are doing this largely in our spare time, and
have been doing that for a long time already?
Eelco
On 2/13/06, Gili [EMAIL PROTECTED] wrote:
Seems to me you guys are quickly running out of things
We /will/ evaluate all bugs, issues and patches before we bring out
any final release. We can't make any guarantees on fixes and schedules
however.
On 2/13/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Say what? Running out of things to work on? That's a joke, right? May
I remind you that we are
may i humbly suggest you do not post off topic.-IgorOn 2/13/06, Gili [EMAIL PROTECTED]
wrote:Seems to me you guys are quickly running out of things to work on.
Might I humbly suggest you schedule RFE #1228367 for the next release?On a related note, I believe RFE #1167649 can be closed as
As Jesse referenced, once we move to Java 1.5 we can still release Java
1.4 versions via tools such as Retroweaver... assuming that the tool
works as advertised. Has anyone had more experience in these types of
tools?
- Jason B.
Jesse Sightler wrote:
I'm completely in favor of jumping to
Yes, you are correct, that is exactly what I meant. The pace of development seems to be quite nice. :)-- JessOn 2/14/06, Eelco Hillenius
[EMAIL PROTECTED] wrote:
I think you mean pace of releasing. The pace of development isactually very high, and is - unfortunately - the main reason why wedidn't
ourceforge.net Sent: Tuesday, February 14, 2006 1:17 PM Subject: Re: [Wicket-user] Post 1.2 roadmap On 2/13/06, wang lei [EMAIL PROTECTED] wrote: Here is my opinions: - should the post 1.2 version of Wicket involve both changes?Absolutely not.I s
upport
the constructor change ,because
All,
I am for 1.5. I am in the happy situation where I have complete control
over deployment of my apps. Not everyone is. I would rather have it
sooner than later, but if it's best for the community as a whole, I am
glad to wait until after the Constructor refactoring. Just not too much
63 matches
Mail list logo
