*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]
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 PROTEC
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, ju
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 1
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 a
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 to
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: RIPEMD16
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
-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
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
Eelco Hillenius wrote:
>
> 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 committe
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
f
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 h
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 d
Igor Vaynberg schrieb:
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/.
Martijns post started with the following sentence (emphasis mine):
| We are of course
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 so
> > 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 initial
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 compo
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. java.util.co
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 from
+1 For both changes.
The constructor refactor would make my code neater and easier to read.
Java 1.5 support would be fantastic, it's been a while since I came
across any company that didn't support 1.5, even the large ones that are
akin to an ocean liners. There must be very few companies lef
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 14/
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 wick
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 thi
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 p
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 pa
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
or
Indeed. Looks like I need to give a spin.
Regards,
Erik.
Jesse Sightler schreef:
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.
--
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 cons
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
com
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 con
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]> wrot
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 de
+1 on java1.5 = Wicket3.0
/Flemming
Martijn Dashorst wrote:
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.
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.
W
+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 pos
I've been using only 1.5 for over a year, so thats where I stand.
Typing with wicket will definitely help out the new users.
On 2/14/06, Ayodeji Aladejebi <[EMAIL PROTECTED]> wrote:
> i think wicket starting out on 1.4 will need to stabilize properly on 1.4
> before leaping to tiger. even though
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
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
thi
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 1.5
-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 o
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
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
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 wick
> 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
propone
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 becaus
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 ref
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 h
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 wicke
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 would
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 so
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.
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.
+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 weighted
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:
> Her
Thanks for all the great work and fantastic support!!
Here are my preferences, but whatever you decide, I'm behind you.
> The questions I'm seeking answers to are the following:
>
> - should the post 1.2 version of Wicket involve both changes?
Personally, I prefer the idea of smaller steps...
+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 possibly can. so i like the idea of doing
1.3 VERY quickly (JUST the constructor change and associ
I have no personal experience with retrowaever. However, there are many
success stories on the internet. I have at least one colleague that used
it without problems.
If I understand correctly, there is one slight drawback: you can not use
the new java 5 APIs (like StringBuilder and java.util.c
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
after.
r@lists.sourceforge.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 cha
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
I think you mean pace of releasing. The pace of development is
actually very high, and is - unfortunately - the main reason why we
didn't bring out a release yet :)
Eelco
> Based on the current pace of development, a 2.0 release would probably not
> land until late this year at the earliest, I wo
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 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 brin
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
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
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
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 thi
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 Wicke
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 m
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 ove
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 m
71 matches
Mail list logo
