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 wicket:component, but define its limits, document it on the wiki
as fully supported and
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
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
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
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 (but very
Stability and consistency is paramount in a good framework - delete.
Jonathan Locke wrote:
Our Wiki describes the wicket:component tag as follows:
wicket:component - Creates a Wicket component on the fly. Needs a class
attribute. Though this has been in wicket for a long time, it is
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
[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:
wicket:component - Creates a Wicket component on the fly. Needs a class
attribute. Though this has been in wicket for a
Hi,
I vote either:
[X] Keep wicket:component, 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
Jonathan Locke schrieb:
[X] Delete this unimportant and generally unsupported feature
[ ] Keep wicket:component, 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,
Our Wiki describes the wicket:component tag as follows:
wicket:component - 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
of an unsupported feature, as most of the core developers believe that this
may lead to
[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:
wicket:component - Creates a Wicket component on the fly. Needs a class
attribute. Though this has been in
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
[ ] Delete this unimportant and generally unsupported feature
[ ] Keep wicket:component, 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
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.
wicket:component wicket:id=dataView
wicket:component
: [Wicket-user] VOTE on wicket:component
Our Wiki describes the wicket:component tag as follows:
wicket:component - 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
of an unsupported feature, as most of the core
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
-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Locke
Sent: 23. januar 2007 07:51
To: wicket-user@lists.sourceforge.net
Subject: [Wicket-user] VOTE: IModel and 'model object' name change
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late
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 about
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
-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
-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,
+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
+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
I voted -1, but here is my opinion about the change proper.
public interface IModelV 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
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
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
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,
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
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 would
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
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.
, 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 deprecate getModelObject() and add a preferred
version as
getModelValue
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,
.)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On 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
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.sourceforge.net
Subject: Re: [Wicket-user] VOTE: IModel and 'model object' name change
what do you
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
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 distracting, as it
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/
-
i'd like us to vote on changing IModel to this in 2.0 (i know it's very
late, but please at least read my argument below and think about it for a
moment):
public interface IModelV extends IDetachable
{
V getValue();
void setValue(V value);
}
we would also change getModelObject() to
-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
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 [EMAIL
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 doesn't
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
1 [ ]
2 [X]
input type=submit value=Default Value wicket:message=value:my_key/
If you want to express it without a default value, that would be
written as:
input type=submit value=my_key wicket:message=value/
And if Wicket is going to support multiple attributes:
input type=submit
But this:input type=submit value=my_key wicket:message=value/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
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) input type=submit value=wicket:i18n:my_key/
which is compact, or
2) input
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
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) input type=submit value=wicket:i18n:my_key/
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) input type=submit
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 for
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
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
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 to me.
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.
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
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
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
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 business
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
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) input type=submit
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 either
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) input type=submit
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 end-users
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 [EMAIL PROTECTED
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
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
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 attribute
modifiers
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
+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 we can
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 eyes.
On
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 1.2
I vote in favor of renaming setUseOptimizedItemRemoval() to
setReuseItems() because I feel it is more descriptive of what it
actually does. What do the rest of you think?
Thanks,
Gili
signature.asc
Description: OpenPGP digital signature
+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() because I feel
+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 of the
+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
Currently almost all our interfaces that makes the output or Response writing code are using Stringsas parameters or return typesI would like to change all those methods to use Charsequence because this would mean that
we don't have to do toString() every where and just passing directly the buffer
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 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
+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 mean
+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 types I
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
Wicket has made it to the finals for the SourceForge Open Source Community Choice Awards 2006!Show your support by voting for Wicket on this page:
http://www.wilsonresearch.com/2006/ostgawards06/ostgawards4.phpVoting ends at March 23.Thank you all for getting us this far! Now we need to go the
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
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
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
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
--
--
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
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] VOTE)
I agree
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
---
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
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 constructor changes are an
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.
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
adventurously
1. Give me the constructor change and the Java 5 functionality in one pass (Wicket 2.0)+1
-- The more life's risk you take, the more life's reward you get - Me
#QuoteI vote for 2. 2. Do the constructor change in a seperate release (Wicket 1.3) andput Java 5 in the next (Wicket 2.0)On 2/16/06,
Eelco Hillenius [EMAIL PROTECTED] wrote:
Hi all,This is a non-binding (the developers ultimately decide) call votesconcerning whether we should fold the upcomming
I vote for #1. I want the latest and greatest -- thats why I'm into wicket!
/Fredrik
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
Eelco Hillenius wrote:
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 vote for #2
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 whether
1 - 100 of 177 matches
Mail list logo
