I'm not proposing to ease up on final in general, though I think using
finals aggressively makes more sense when the project is taking shape
and less so when things got more stabilized. Components like Link,
TextField, CheckBox, ImageButton are components people regularly ask
about why they can't
A lot of people have asked in the past for a component interface and
we said no (until OSGi came with a good reason, and even then). Just
only asking for opening up is not a good reason to do so IMO.
A good reason I can come up with for removing final from the
onComponentTag method is to reduce
Hi experts,
I am using Wicket with Tomcat Server.
How to tested manually without using tomcat. because if change wicket java
file, i should re start the tomcat. so i want check the design view of
wicket page manually without using tomcat. Is it possible?
Thanks for replying.
Edward
--
View
usually your IDE checks the java files for correctness (at least does
netbeans and eclipse so), the HTML templates can only be tested by wicket
but when you have dev mode and turn of caching these are rereloaded as soon
as you put a new one in... furthermore, i dont see a problem in sending a
Please vote:
[ x ] yes, make all onComponentTag and onComponentTagBody methods of
the standard components in core non-final. This does leave the door
open for specific components to not adhere to that - I'm not proposing
a new standard - but if this wins we would remove final for most of em
+1
BTW I just created the issue in JIRA, so that we won't forget:
https://issues.apache.org/jira/browse/WICKET-150
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
On 12/7/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Another example is Link with a label inside. I'm starting to get
irritated with the fact that even though a label rendering was
requested as part of it's default behavior, and at least some people
were pro that, it ended in a stale mate again,
On 12/7/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 12/7/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Another example is Link with a label inside. I'm starting to get
irritated with the fact that even though a label rendering was
requested as part of it's default behavior, and at least
can i vote 0.7 for and 0.3 against? my brain cant do
floating point math!
simple, thats 0.4 for it!
:)
johan
From:
+0: 'I don't feel strongly about it, but I'm okey with this.'
-0: 'I won't get in the way, but I'd rather we didn't do this.'
-0.5: 'I don't like this idea, but I can't find any rational
justification for my feelings.'
++1: 'Wow! I like this! Let's do it!'
-0.9: 'I really don't like this,
that has got to be one of the most idiotic things i have ever seen.
so what does this mean?
+1 -0.5 -0.5 -0.5 ? does that mean the vote doesnt pass? cause when you add
them up you get a -0.5
can i vote?
-
Just doing it as the manual says :) If you get 3 times -0.5 votes,
that may be a strong indicator that it is not the way to go. IIUC part
of voting is the ability to disagree, either mildly, strongly, or even
unresolvable. This is reflected by the analog votes.
In this case, I don't want to
and that can easily be expressed with a
+0 i dont like it but not enough to block
-igor
On 12/7/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
Just doing it as the manual says :) If you get 3 times -0.5 votes,
that may be a strong indicator that it is not the way to go. IIUC part
of voting
Hi Martijn,
Nice excercise. As a user of Wicket, I'd say:
Which one gets precedent? The modifier or onComponentTag?
either modifier or neither (an exception).
The modifier is added later and provides a one-time way to adapt an
existing component.
Letting the component have precedence is weird
After deleting some heated, unsent messages (never post when angry, a
very wise blogger told me), taking some time thinking about other
stuff, I see that I misinterpreted your message. I'm sorry I misread
you, I'm sorry I accused you of mal-intent. My sincerest apologies,
the whiskey is on me
define reliably. markupid should never be used by anything other then
wicket - we have never guaranteed its stability. did you ever create the rfe
to have the id migrated when components are replaced? that is the only
usecase i can think of where we need to worry about the id being stable so
that
* Igor Vaynberg:
define reliably. markupid should never be used by anything
other then wicket - we have never guaranteed its stability. did
you ever create the rfe to have the id migrated when components
are replaced? that is the only usecase i can think of where we
need to worry
On 12/7/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
After deleting some heated, unsent messages (never post when angry, a
very wise blogger told me), taking some time thinking about other
stuff, I see that I misinterpreted your message. I'm sorry I misread
you, I'm sorry I accused you of
hrm, i dont see how this can happen.
once an id is created for a component that component keeps it for its entire
lifetime - it is cached in the component's metadata.
the counter is also nontransient so it keeps its value as long as the page
is alive.
can you recreate it using wicket tester?
All,
Woudn't it be great if we could release our current progress as a
development build into the wild, and validate our progress on
licensing issues?
I think we could best address this by performing a milestone release,
which doesn't promise API stability, or bug-free operation, but will
be
i think we can release an alpha1 of 2.0
i dont know about 1.3
we need to create a roadmap for 1.3 on the wiki and mark what features are
already in and what are not
-igor
On 12/7/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
All,
Woudn't it be great if we could release our current
On 12/8/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i think we can release an alpha1 of 2.0
Fair enough, though the DatePicker needs to be moved out of extensions.
we need to create a roadmap for 1.3 on the wiki and mark what features are
already in and what are not
JIRA can do this for us
On 12/7/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 12/8/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i think we can release an alpha1 of 2.0
Fair enough, though the DatePicker needs to be moved out of extensions.
we havent already? was that only in 1.x?
we need to create a roadmap for
23 matches
Mail list logo
