Kent Tong wrote:
>
> So, please vote:
> [ ] setRequired(true) means the Checkbox is checked.
> [ ] setRequired(true) means the Checkbox has a value (always the case).
>
[x] setRequired(true) means the Checkbox has a value (always the case).
-----
--
Kent Tong
Wicket t
https://issues.apache.org/jira/browse/WICKET-1221 for some
previous discussion.
So, please vote:
[ ] setRequired(true) means the Checkbox is checked.
[ ] setRequired(true) means the Checkbox has a value (always the case).
-
--
Kent Tong
Wicket tutorials freely available at http
gt;
If Igor agrees that it is covering 2) and 3), then this point is settled.
Obviously
now it is found that ZeroPaddingConverter needs extensibility and thus
belong
to 1), but then what is the supporting that *all* converters need
extensibility
and thus belong to 1)?
-
--
Kent Tong
Wicke
and 3), but what you said
is that it will be made final only for 2).
> Why are so many classes and methods in Wicket final?
>
> Classes and methods in Wicket are generally declared as final until the
> need for
> extensibility is well understood.
>
-
--
Kent Tong
Wicke
ntion is the opposite: marking them as final by default. Now what is
being suggested
seems to be contradictory to your project convention. In that case I must
say that is a
bad thing.
-----
--
Kent Tong
Wicket tutorials freely available at http://www.agileskills2.org/EWDW
--
View this message in co
My non-binding vote:
[x] 1) Keep the change. It provides friendlier HTML id's by
eliminating '.' characters and it's perfectly safe.
[ ] 2) Revert the change. It's not a bug and the "magic" behavior is
unnecessary and/or dangerous.
I would reverse my vote if the change had not been made as th
Matt Jensen-2 wrote:
>
> I have a use case where I would like to be able to splice wizard
> sequences together, possibly injecting one wizard into another under
> certain conditions.
>
Try using the attached RecursiveWizardModel. You give it a wizard model and
it
is prepared to handle a st
Eelco Hillenius wrote:
>
> It's been in there for a while though, and the impact on the Wicket
> core project should be nill. The only thing that we have to take into
> account with the Wicket core project is that we shouldn't break Ate's
> rules, but I think that could only happen when we would
Matej Knopp-2 wrote:
>
> I think it would be shame not to have portlet support in trunk if we
> can (and if it won't cause too many issues).
>
I think the issue is how much extra time is needed to wait until the
merged result can be proven in the wild to be stable enough.
It may not affect on
JohnSmith333 wrote:
>
> Form uploadForm = new Form("uploadform",new CompoundPropertyModel(new
> TestTO())){
>
This is the problem. You only add a single TestTO obj to it at constructor
time. It means the page
will keep updating this object and adding the same object to the list. To
fix it qu
Eelco Hillenius wrote:
>
> It would perform slightly better when debugging is on, but a bit worse
> if it is off. That single isDebugEnabled would still be cheaper than
> letting log.debug demine whether the log level is on *and*
> constructing the string and getting the request cycle.
>
If ju
Matej Knopp <[EMAIL PROTECTED]> writes:
>
> We never override isRequired in Wicket. So we keep the contract of
> setRequired. But we shouldn't prevent users to override it. If user
> wants to break the set contract, it's ok. I don't see anything bad
> about it.
Personally I also don't see anythi
Johan Compagner <[EMAIL PROTECTED]> writes:
> the problem is that is* should just be overridable, because can we do
> setvisible in onattach? dont think so because that makes a new
> version. isVis and isEnabled can change between request of a
> component, thats why we have to be able to override
Eelco Hillenius <[EMAIL PROTECTED]> writes:
> > Can't you have an onSetRequired() callback? Or would that be even nastier?
I thought you had gone through this issue? If a child class provides
a onSetRequired() but a grand child wants to override it, it still
has to override it. Then why not just
Eelco Hillenius <[EMAIL PROTECTED]> writes:
> Well nevermind. I'm actually ok with doing this in onAttach. I rolled
> back the change.
For what it's worth, I think having isRequired() returns a value that
is different from the REQUIRED flag is a serious design flaw. It
simply means the REQUIRED
15 matches
Mail list logo
