Hi Jonathan,
What is the result of the vote then? Or was it just a poll?
Seems like many users expressed the wish to remove that feature.
Is there a JIRA issue for that?
Thanks,
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
-
wicket:container is available for 2.x.
Juergen
On 2/14/07, Rüdiger Schulz <[EMAIL PROTECTED]> wrote:
> Jonathan Locke schrieb:
>
> > [X] Delete this unimportant and generally unsupported feature
> > [ ] Keep , but define its limits, document it on the wiki
> > as fully supported and commit to s
Jonathan Locke schrieb:
> [X] Delete this unimportant and generally unsupported feature
> [ ] Keep , but define its limits, document it on the wiki
> as fully supported and commit to supporting it in the future
and a +1 for wicket:pseudo / wicket:container as well ;)
Greetings,
Rüdiger
-
Hi,
I vote either:
[X] Keep , but define its limits, document it on the wiki
as fully supported and commit to supporting it in the future
or
[X] Delete this unimportant and generally unsupported feature
with the amendment that the case below is supported in some other way
Like Timo I am using
[X] Delete this unimportant and generally unsupported feature
On 2/13/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
Our Wiki describes the wicket:component tag as follows:
" - Creates a Wicket component on the fly. Needs a class
attribute. Though this has been in wicket for a long time, it i
yep. yep. yep. could not have said it better. it takes real effort
to restrain a maturing project from collapsing under its own weight.
*less is more*
Ryan Holmes wrote:
>
> As a long-time Tapestry user (but very new Wicket user), I have a few
> thoughts about in-line component declar
Stability and consistency is paramount in a good framework - delete.
Jonathan Locke wrote:
>
>
> Our Wiki describes the wicket:component tag as follows:
>
> " - Creates a Wicket component on the fly. Needs a class
> attribute. Though this has been in wicket for a long time, it is still
> kind
Didn't know about it before, so can't see a possible use case where it is
necessary
+1 remove.
On 2/14/07, Frank Bille <[EMAIL PROTECTED]> wrote:
On 2/14/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> On 2/14/07, Ryan Holmes <[EMAIL PROTECTED]> wrote:
> > As a long-time Tapestry user (
On 2/14/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
On 2/14/07, Ryan Holmes <[EMAIL PROTECTED]> wrote:
> As a long-time Tapestry user (but very new Wicket user), I have a few
> thoughts about in-line component declaration.
>
> 1.) Even in a framework like Tapestry where the idiom is fully
> s
On 2/14/07, Ryan Holmes <[EMAIL PROTECTED]> wrote:
> As a long-time Tapestry user (but very new Wicket user), I have a few
> thoughts about in-line component declaration.
>
> 1.) Even in a framework like Tapestry where the idiom is fully
> supported, it can lead to complex and difficult to maintain
As a long-time Tapestry user (but very new Wicket user), I have a few
thoughts about in-line component declaration.
1.) Even in a framework like Tapestry where the idiom is fully
supported, it can lead to complex and difficult to maintain
templates. In fact, it's generally discouraged in Tap
I've havent used this feature.. And currently see no use for it.
As long as one of the options are done, im happy:)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Locke
Sent: 13. februar 2007 17:48
To: wicket-user@lists.sourceforge.net
Subject:
If wicket:component goes, please add wicket:pseudo
http://www.nabble.com/%3Cwicket%3Apseudo%3E-tf2881952.html#a8052462
to be able to keep e.g. this kind of repeater markup valid
when producing HTML tables with repeaters.
- Timo
--
Timo Rantalaiho
Reaktor Innovations Oyhttp://www.r
I don't mind keeping it. We just ought to restrict/define its usage
precisely and advertise that we support that usage. Personally, I think the
only reasonable usage is to instantiate a component that (a) takes no
parameters and (b) is never referenced in the Java code. That would make
sense.
> [ ] Delete this unimportant and generally unsupported feature
> [ ] Keep , but define its limits, document it on the wiki
> as fully supported and commit to supporting it in the future
-0.
I don't care much about this feature, but it's not in my way either.
It's been in the project for over 2
[X] Delete this unimportant and generally unsupported feature
--
Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket
Wicket 1.2.5 is as easy as 1-2-5. Download Wicket now!
http://wicketframework.org
---
i don't care to much, but i don't plan on supporting it at this time
(personally)
But maybe some comes up with a GREAT usecase?
so +0
I do agree a bit that we maybe should say, it is really supported if we keep
it.
johan
On 2/13/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
Our Wiki descr
[X] Delete this unimportant and generally unsupported feature
Juergen
On 2/13/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>
>
> Our Wiki describes the wicket:component tag as follows:
>
> " - Creates a Wicket component on the fly. Needs a class
> attribute. Though this has been in wicket for a
With those names I am changing my vote to +1.
Erik.
Jonathan Locke wrote:
> what do you think of gustav and eelco's IModelLocator / get/setModel idea?
>
>
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
-
On 1/23/07, James McLaughlin <[EMAIL PROTECTED]> wrote:
>
> On 1/23/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > getModelValue would have been better than getModelObject yeah. That
> > said, imo (and I have stated this before), I think having those
> > methods in the first place is distractin
On 1/23/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
getModelValue would have been better than getModelObject yeah. That
said, imo (and I have stated this before), I think having those
methods in the first place is distracting, as it doesn't push people
in the direction of just letting the com
r IModelWrapper are not ambiguous (as is
"ModelObject"), and avoids overloading the word "Model".
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan
Locke
Sent: Tuesday, January 23, 2007 11:55 AM
To: wicket-user@lists.source
e that process is understood, multiple levels of
> wrapping should not be too difficult to understand.)
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan
> Locke
> Sent: Tuesday, January 23, 2007 11:35 AM
> To: wicke
Yeah, the only real argument for that method other than brevity is that you
could override it.
It would be unreliable outside the core though and I can't think of a reason
to do that offhand.
Eelco Hillenius wrote:
>
> getModelValue would have been better than getModelObject yeah. That
> said,
n Behalf Of Jonathan
Locke
Sent: Tuesday, January 23, 2007 11:35 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] VOTE: IModel and 'model object' name change
yeah. i agree. if we did anything it would be better to change IModel
as i said, but then just depreca
geez, this makes so much sense like this! ;-)
Eelco Hillenius wrote:
>
> Agreed. We have been discussing that in the past as well.
> IModelLocator for instance might have been a better name. And
> IModelLocator could then have get/setModel, as that's the real model
> value you're looking at.
getModelValue would have been better than getModelObject yeah. That
said, imo (and I have stated this before), I think having those
methods in the first place is distracting, as it doesn't push people
in the direction of just letting the components and models work
directly for them.
Eelco
On 1/23
yes. that is the major concern.
for now, eelco could put a callout box in the book with a warning about
this ambiguity. we could also do the same in the javadoc for getModel()
and getModelObject() so any rare people who actually read the docs
won't be lost.
igor.vaynberg wrote:
>
> it woul
You make a good point. Something like IModelLocator would be a
clearer name for IModel. then its methods could be called get/setModel.
As you point out, IModel is only the model from the framework's
perspective. From the user's it is a model locator and the actual
model is the object returne
Agreed. We have been discussing that in the past as well.
IModelLocator for instance might have been a better name. And
IModelLocator could then have get/setModel, as that's the real model
value you're looking at.
Eelco
On 1/23/07, Gustavo Hexsel <[EMAIL PROTECTED]> wrote:
> +0 for changing, exc
it would be Component.getModelValue() not Component.getModelObject() i
think. what this disambiguates is what object you are referring to. the
problem is that IModel impl itself is an object, so when you say
component.getModelObject() what do you really want? the model object or the
object inside
yeah. i agree. if we did anything it would be better to change IModel as i
said,
but then just deprecate getModelObject() and add a preferred version as
getModelValue() as johan suggested. this would only break code that
directly
uses IModel (a more limited number of users).
Eelco Hillenius
I voted -1, but here is my opinion about the change proper.
> public interface IModel extends IDetachable
> {
> V getValue();
> void setValue(V value);
> }
This would be for the better imo, though I don't hate the original
getObject *that* much. It's just what you are used to and I think
docu
+0 for changing, except not sure it's what Johnathan suggested.
My problem is with using the word Model at all for the objects that
access model properties (maybe they should be ModelAccessors,
ModelExposer, ModelAdaptor, ModelBridge, ModelConnector, or something
along the lines... then Reflection
+1 Don't know if my vote counts or not, but anyway.
I'm one of those users that had trouble with the ambiguity between model
object (as in the IModel instance) and modelObject (the object contained
by the model). Worse, In my project's team all the modelObjects were
classes with the naming conv
-1 for changing the method signature
+1 for more model examples particularly contextual ones, i.e. with a form
you often use the form component itself as the model (I can work on this if
things go as I hope with our web ui proofs of concept -- otherwise I'll be
off learning JSF)
On 1/23/07, Eelco
-1. Regardless of whether the change is for the better, it will break
way too much existing code not to mention the tutorials on the
internet etc.
Eelco
On 1/22/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>
>
> i'd like us to vote on changing IModel to this in 2.0 (i know it's very
> late, but
If it is user opinion wanted, for what I am it is -1.
I would be please with the change if I used wicket for a home hobby of
making something easy. But the problem is that I'm working in a production
environment. Every thing that will make 2.0 migration harder will make
sure that it will not g
On 23/01/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
... in fact, that term is actually ambiguous since the object
implementing IModel might be informally understood to be the model object
(which is not what we mean)...
You're very right. This is the major contributor to my confusion abou
Im -1.
As most of my models holds objects and not "value", I've had no problem
understanding this part of the IModel.
I must admit that I may be blind to this because im used to the current naming,
and have been working with it for so long. I guess the new users would be the
ones best to tell
We already have a getValue on formcomponent
that is the input value from the request or the model object as a string
(just the latest value)
So then that also has to be renamed. (and relearned)
I think getModelObject() is just what it says. (besides the getModel() call
we also have!)
else it shou
-1
I'm sorry, although I totally understand your argument, and how it may help
new users, but this will break already written code, will not add additional
level of functionality, and really it's just a matter of reading to
understand how IModel works, I did have difficulties when I started to
un
But this:i really don't like.That is worsed of both worlds. You still don't have default/preview but you do have an
extra input attribute to parse. Ok knowing that something must be i18n is easier.But you are right about that it looks neather when with multiply attributes.But this should also work
1 [ ]
2 [X]
>
If you want to express it without a default value, that would be
written as:
And if Wicket is going to support multiple attributes:
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
--
1 [X]
Btw.
We are using ${key} everywhere (customized markup parsing) and it's much
more convenient than wicket:message :-)
-Matej
Eelco Hillenius wrote:
> For localized attributes - so that you don't have to attach attribute
> modifiers all over the place for that sole reason - we have two
>
On Fri, 2006-08-04 at 08:50 +0200, Korbinian Bachl wrote:
> thus im quite new,
>
> 2[x]
>
> be ** up (hopefully...) by your next designer who changed the text so it
> looks better...
This a good point, with option 1 it is likely that designers touch the
value-attribute. In option 2, it doe
thus im quite new,
2[x]
as its the only way to have a preview wich works in WYSIWYG editors and wont
be ** up (hopefully...) by your next designer who changed the text so it
looks better...
> On 8/3/06, Dirk Markert <[EMAIL PROTECTED]> wrote:
> > 2 [x]
> >
> > 2006/8/3, Eelco Hillenius <
he is a witch! throw him in the lake! if he floats that will prove he is a witch and then we burn him. if he drowns he wasnt a witch, we let him go.-IgorOn 8/3/06, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:
Hey, you cheat! You voted twice! :)Eelco
--
Hey, you cheat! You voted twice! :)
Eelco
On 8/3/06, Nick Heudecker <[EMAIL PROTECTED]> wrote:
> 2 [X]
>
>
> On 8/3/06, MK Tan <[EMAIL PROTECTED]> wrote:
> > 2 [X]
> >
> > --- Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> >
> > > For localized attributes - so that you don't have to
> > > attach a
1 [X]
as in this case every attribute would be assignable from java
Imran
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & bus
2
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com
2
- Original Message -
From:
Dirk
Markert
To: wicket-user@lists.sourceforge.net
Sent: Friday, August 04, 2006 12:32
PM
Subject: Re: [Wicket-user] VOTE: how
should localized attributes work?
2 [x]
2006/8/3, Eelco Hillenius <[EM
2 [x]
On 8/3/06, Dirk Markert <[EMAIL PROTECTED]> wrote:
> 2 [x]
>
> 2006/8/3, Eelco Hillenius <[EMAIL PROTECTED]>:
> > For localized attributes - so that you don't have to attach attribute
> > modifiers all over the place for that sole reason - we have two
> > alternative approaches in mind. For
2 [x]2006/8/3, Eelco Hillenius <[EMAIL PROTECTED]>:
For localized attributes - so that you don't have to attach attributemodifiers all over the place for that sole reason - we have twoalternative approaches in mind. For end-users this would either looklike:
1) which is compact, or2)
which works be
2 [X]On 8/3/06, MK Tan <[EMAIL PROTECTED]> wrote:
2 [X]--- Eelco Hillenius <[EMAIL PROTECTED]> wrote:> For localized attributes - so that you don't have to> attach attribute> modifiers all over the place for that sole reason -
> we have two> alternative approaches in mind. For end-users this> would
2 [X]
--- Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> For localized attributes - so that you don't have to
> attach attribute
> modifiers all over the place for that sole reason -
> we have two
> alternative approaches in mind. For end-users this
> would either look
> like:
>
> 1)
>
> which i
2[x]
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.
2 [x]
On 8/3/06, Frank Bille <[EMAIL PROTECTED]> wrote:
> 2 [x]
>
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & busi
2 [x]
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay
2
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com
> 2 [ X ]
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.te
2 [x]
Wilko
--
View this message in context:
http://www.nabble.com/VOTE%3A-how-should-localized-attributes-work--tf2047179.html#a5639800
Sent from the Wicket - User forum at Nabble.com.
-
Take Surveys. Earn Cash. Influenc
All votes count for this thread as far as I am concerned.
Eelco
On 8/3/06, Scott Sauyet <[EMAIL PROTECTED]> wrote:
> If you want the opinion of non-committers, here's a strong preference for
>
> 2 [X]
>
> The thought of seeing the "wicket..." text in preview mode really goes
> against the grain t
If you want the opinion of non-committers, here's a strong preference for
2 [X]
The thought of seeing the "wicket..." text in preview mode really goes
against the grain to me.
-- Scott
Eelco Hillenius wrote:
> For localized attributes - so that you don't have to attach attribute
> modifiers
Yeah, but we have to choose a default here. Unless you want to support
those two options at the same time.
Eelco
On 8/3/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> if we have to choose for one then 2
> but i think we can support both, i think it can just be a
> markupfilter/parser implement
if we have to choose for one then 2but i think we can support both, i think it can just be a markupfilter/parser implementation per option.johanOn 8/3/06,
Eelco Hillenius <[EMAIL PROTECTED]> wrote:
For localized attributes - so that you don't have to attach attributemodifiers all over the place fo
1 [x]-IgorOn 8/3/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
For localized attributes - so that you don't have to attach attributemodifiers all over the place for that sole reason - we have twoalternative approaches in mind. For end-users this would either looklike:
1) which is compact, or2)
wh
2 [x]
Eelco Hillenius a écrit :
> For localized attributes - so that you don't have to attach attribute
> modifiers all over the place for that sole reason - we have two
> alternative approaches in mind. For end-users this would either look
> like:
>
> 1)
>
> which is compact, or
>
> 2)
>
>
2
previewability is one of wicket's strong features
Joni
On Thu, 2006-08-03 at 11:10 -0700, Eelco Hillenius wrote:
> For localized attributes - so that you don't have to attach attribute
> modifiers all over the place for that sole reason - we have two
> alternative approaches in mind. For end-u
I'm not sure setReuseItems is the best name, but I not a friend of
setUseOptimizedItemRemoval.
Eelco
On 4/21/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> +1
>
> we can deprecate the existing one and have it forward to the new one as not
> to break the api. then remove the deprecated method once
doneOn 4/22/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
+1 depricate the oldOn 4/21/06, Juergen Donnerstag
<[EMAIL PROTECTED]> wrote:
+1On 4/21/06, Martijn Dashorst <
[EMAIL PROTECTED]
> wrote:> +1>>> On 4/21/06, Vincent Jenks <[EMAIL PROTECTED]
> wrote:> > +1 - it's certainly easier on the eye
+1 depricate the oldOn 4/21/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
+1On 4/21/06, Martijn Dashorst <[EMAIL PROTECTED]
> wrote:> +1>>> On 4/21/06, Vincent Jenks <[EMAIL PROTECTED]> wrote:> > +1 - it's certainly easier on the eyes.> >
> > On 4/21/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
+1
On 4/21/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> +1
>
>
> On 4/21/06, Vincent Jenks <[EMAIL PROTECTED]> wrote:
> > +1 - it's certainly easier on the eyes.
> >
> > On 4/21/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > +1
> > >
> > > we can deprecate the existing one and have it for
+1On 4/21/06, Vincent Jenks <[EMAIL PROTECTED]> wrote:
+1 - it's certainly easier on the eyes.On 4/21/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:> +1>> we can deprecate the existing one and have it forward to the new one as not
> to break the api. then remove the deprecated method once 1.2 is out
+1 - it's certainly easier on the eyes.
On 4/21/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> +1
>
> we can deprecate the existing one and have it forward to the new one as not
> to break the api. then remove the deprecated method once 1.2 is out of the
> door.
>
> -Igor
>
>
>
> On 4/21/06, coww
+1we can deprecate the existing one and have it forward to the new one as not to break the api. then remove the deprecated method once 1.2 is out of the door.-Igor
On 4/21/06, cowwoc <[EMAIL PROTECTED]> wrote:
I vote in favor of renaming setUseOptimizedItemRemoval() tosetReuseItems() becaus
I think i have it all in now.There isn't much outside used api touched because if i just look what lines i needed to change over all the contrib libs (didn't check those in yet)it where only a very few and it was just adding toString() or changing String to CharSequence.
And also another project ir
+1, not breaking existing 1.1 api's.MartijnOn 4/1/06, Eelco Hillenius <[EMAIL PROTECTED]
> wrote:+1 for now.EelcoOn 4/1/06, Johan Compagner <
[EMAIL PROTECTED]> wrote:> Currently almost all our interfaces that makes the output or Response> writing code are using Strings> as parameters or return typ
+1 for now.
Eelco
On 4/1/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> Currently almost all our interfaces that makes the output or Response
> writing code are using Strings
> as parameters or return types
>
> I would like to change all those methods to use Charsequence because this
> would m
+1 for now. For all new 1.2 interfaces and methods and for internal
methods (incl. pre 1.2).
Did we add replaceComponentTagBody in 1.2? If not, that should not
(yet) be changed. Especially as I can imagine that this function is
used by some users.
Juergen
On 4/1/06, Igor Vaynberg <[EMAIL PROTECTE
if it is it is a final methodso it doesn't matter it can only be called onso calling it with the same code that is a string just compiles fineand you can't override it (that would be a problem because then they also need to change the signature)
johanOn 4/1/06, Juergen Donnerstag <[EMAIL PROTECTED]
+1 to do it now. if this does affect 1.2 only interfaces a lot then we
should do this before we actually release those interfaces into the
wild.
-Igor
On 4/1/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
Currently almost all our interfaces that makes the output or Response writing code are using
i havent thought about it /that/ much. but for example if you have a factory, the factory will need to be refactored.also situations where you are creating components but not yet adding them to the parent will have to be refactored to work differently. although i think this is an edge case.
-IgorOn
Which ones? Do we have a list?
Eelco
On 2/22/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> an easy fix in /most/ cases. there will be situations that are harder to fix
> then others.
>
> -Igor
>
>
>
> On 2/22/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote:
> >
> > > assuming that the constructo
an easy fix in /most/ cases. there will be situations that are harder to fix then others.-IgorOn 2/22/06, Eelco Hillenius <
[EMAIL PROTECTED]> wrote:> assuming that the constructor changes are an unusually severe break in
> the API.It's a severe break indeed. BUT to the upside, with a very easy fix
> assuming that the constructor changes are an unusually severe break in
> the API.
It's a severe break indeed. BUT to the upside, with a very easy fix.
It's just big because it'll break most of your code instead of just a
few areas.
Eelco
---
changes are an unusually severe break in
the API.
/Frank
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eelco
Hillenius
Sent: Wednesday, February 22, 2006 10:15 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: Results so far (was Re: [Wicket-user]
I agree with Johan here. I want to start discussing it on the admin
list shortly. But it looks like there are enough for 2 - not the
majority, but enough - to make seperate releases. We should decide on
whether 1.2. (we might call that version differently actually, but
that's another question) or 1
and yeah more expected to come in :)
On 2/22/06, karthik Guru <[EMAIL PROTECTED]> wrote:
> Ok for the benefit of others, the summary of vote that actually matters - .
>
> Igor - 1
> Johan - 2
> Eelco - 1
>
> So ,
>
> 2 votes for both at once (constructor and JDK5)
> 1 vote for split releases
>
-
Ok for the benefit of others, the summary of vote that actually matters - .
Igor - 1
Johan - 2
Eelco - 1
So ,
2 votes for both at once (constructor and JDK5)
1 vote for split releases
---
This SF.net email is sponsored by: Splunk Inc. Do you
and we could interpreted the results this way that there are still quite a number of persons that can't use 1.5 yet.So it is not a pure democratic vote but just the get a feeling how many people would be really set backed by directly
1.5I still believe that you can live without it, but you can't l
The vote isn't officially closed. We didn't set a time limit at beforehand. It is probably dead though :)In this case, the vote was NON-binding. That basically means that the core team can do whatever we want, ignoring everything and build Wicket 2 on dolphin (Java 7). Surpise!
We haven't started d
Is the voting officially closed ? :)
and does that mean 'constructor and JDK5' will come packaged as one release
wicket 2.0?
On 2/21/06, Al Maw <[EMAIL PROTECTED]> wrote:
> Alexandru Popescu wrote:
> > I know that this might be early considering the lenght of the thread,
> > but what is the voting
It's not about not wanting to go for Java 1.5. But more a I can't or
my company can't. I have no choice here.
On 2/21/06, Christian Hvid <[EMAIL PROTECTED]> wrote:
> I am one for a move to Java 5 as fast as possible.
>
> From my perspective Wicket is a young framework and if we are
> adventurousl
+1 1. Give me the constructor change and the Java 5 functionality in one
pass (Wicket 2.0)
My vote goes to 1.
>
> 1. Give me the constructor change and the Java 5 functionality in one
> pass (Wicket 2.0)
> 2. Do the constructor change in a seperate release (Wicket 1.3) and
> put Java 5 in the next (Wicket 2.0)
> 3. I don't want either one and I want to stay on Wicket 1.2.
>
---
I am one for a move to Java 5 as fast as possible.
From my perspective Wicket is a young framework and if we are
adventurously enough to choose Wicket, we are adventurously enough to
be on Java 5.
On 21 Feb 2006, at 00:27, Al Maw wrote:
Alexandru Popescu wrote:
I know that this might be
Alexandru Popescu wrote:
I know that this might be early considering the lenght of the thread,
but what is the voting result? :-).
So far I count:
40 votes for both at once (constructor and JDK5)
17 votes for split releases (16 plus me, I'm voting now. :-) )
Al
--
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Good news. We've just decided you're not trolls. bahrahrhum.
Alexandru Popescu wrote:
> I know that this might be early considering the lenght of the thread,
> but what is the voting result? :-).
>
> BR,
>
> ./alex
> --
> .w( the_mindstorm )p
I know that this might be early considering the lenght of the thread,
but what is the voting result? :-).
BR,
./alex
--
.w( the_mindstorm )p.
On 2/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> This is a non-binding (the developers ultimately decide) call votes
> concerning whe
1 - 100 of 191 matches
Mail list logo
