Re: Incorrect error message?

[Martin Grigorov]

Hi Thies,

Please create a quickstart and attach it to Jira.
Maybe we can improve the exception message to have the component path when
available.

Martin Grigorov
Wicket Training and Consulting


On Tue, Jan 7, 2014 at 10:55 PM, Thies Edeling  wrote:

> Hi
>
> With 6.12.0 I have:
>
> val border = new Border("border")
> val l = new Label("l", "label")
> l.setOutputMarkupId(true)
> border.add(l)
>
> and when handling an ajax call, I'm add/replacing it in the wrong spot in
> the hierarchy:
>
> val replacement = new Label("l", "labe2l")
> replacement.setOutputMarkupId(true)
> addOrReplace(replacement)
> target.add(replacement)
>
> Wicket gives me a MarkupNotFoundException which is a little odd and least
> put me in the complete wrong direction. It doesn't seem like the correct
> exception, right?
>
> org.apache.wicket.markup.MarkupNotFoundException: Markup not found for
> Component: [Component id = l]
> at org.apache.wicket.Component.internalRender(Component.java:2347)
> at org.apache.wicket.Component.render(Component.java:2307)
>
>
> gr,
> Thies
>

Re: Incorrect error message?

[Paul Bors]

Well, is actually correct.

Let me draw your component tree for you:

Page
- Border "border"
-- Label "l"
- Label "l"

So thus, did you add the "l" label to the Page?

If not, shouldn't the markup error rise?
If you would have defined a wicket:id="l" in the Page's HTML then you'd get
a missing component by ID 'l".

At least if I remember how those 2 exception work. I haven't gotten them in
a while since we have tools in our IDEs to ensure that Java's and HTML's
component tree match. See the Eclipse market place or IntelliJ IDEA's
plugin market places and search for "Wicket" :)


On Tue, Jan 7, 2014 at 3:55 PM, Thies Edeling  wrote:

> Hi
>
> With 6.12.0 I have:
>
> val border = new Border("border")
> val l = new Label("l", "label")
> l.setOutputMarkupId(true)
> border.add(l)
>
> and when handling an ajax call, I'm add/replacing it in the wrong spot in
> the hierarchy:
>
> val replacement = new Label("l", "labe2l")
> replacement.setOutputMarkupId(true)
> addOrReplace(replacement)
> target.add(replacement)
>
> Wicket gives me a MarkupNotFoundException which is a little odd and least
> put me in the complete wrong direction. It doesn't seem like the correct
> exception, right?
>
> org.apache.wicket.markup.MarkupNotFoundException: Markup not found for
> Component: [Component id = l]
> at org.apache.wicket.Component.internalRender(Component.java:2347)
> at org.apache.wicket.Component.render(Component.java:2307)
>
>
> gr,
> Thies
>

Incorrect error message?

[Thies Edeling]

Hi

With 6.12.0 I have:

val border = new Border("border")
val l = new Label("l", "label")
l.setOutputMarkupId(true)
border.add(l)

and when handling an ajax call, I'm add/replacing it in the wrong spot in
the hierarchy:

val replacement = new Label("l", "labe2l")
replacement.setOutputMarkupId(true)
addOrReplace(replacement)
target.add(replacement)

Wicket gives me a MarkupNotFoundException which is a little odd and least
put me in the complete wrong direction. It doesn't seem like the correct
exception, right?

org.apache.wicket.markup.MarkupNotFoundException: Markup not found for
Component: [Component id = l]
at org.apache.wicket.Component.internalRender(Component.java:2347)
at org.apache.wicket.Component.render(Component.java:2307)


gr,
Thies

Re: Auto-save feature

[Paul Bors]

This is a bizarre use-case to some extent.

You want the user's input to be saved prior to the user's session expiring.



Wouldn't it be easier to run validation and save the user's input as the
field level?

This way as the user leaves a form field, the validation kicks in and if
correct the new input is saved.



Granted you would have to work some other flows, you might want different
states of saving the user input. One committed to the storage tier, the
other committed to the user's name space as one can navigate through your
UI and leave from one page to another. Should you still show the
"auto-saved" form fields which override the actual state of the
application? Probably not, so you'll have to reset the auto-saved data each
time the page is rendered.



Is a cool idea duh, persist the user's input between sessions (although not
right as you'll hide the actual state).

ie: What happens when it takes me 1 hr to time out my session, I come back
tomorrow and see my old input instead of what's really in the database?



~ Thank you,

Paul Bors

On Tue, Jan 7, 2014 at 2:52 PM, Marios Skounakis  wrote:

> In a similar case I've used a wrapper around validators which controls
> whether they run or not. This way you can automatically parse the form
> component tree, find all validators and wrap them in a new Validator that
> runs them only if needed.
>
> I've done this because I wanted to be able to have the standard wicket
> validators run in onValidateModelObjects(). I.e. I wanted my model to be
> updated even if some validations did not pass.
>
> So here's the basic idea (this is slightly modified from my actual code so
> it may have small errors).
>
> public abstract class ValidatorWrapper implements IValidator {
> IValidator validator;
>  public DelayedValidator(IValidator validator) {
> super();
> this.validator = validator;
> }
>
> protected abstract boolean shouldRun();
>
> @Override
> public void validate(IValidatable validatable) {
> if (!shouldRun())
> return;
> if (validatable.getValue() == null) {
> if (!(validator instanceof INullAcceptingValidator)) {
> return;
> }
> }
> validator.validate(validatable);
> }
> }
>
> It is reasonably easy to extend this for FormValidators as well.
>
> This does not handle the case of conversion errors, i.e. in an Integer
> TextField if the user input is not a valid integer, it won't update the
> model object. So if you auto-save and the reload, such fields will be
> empty. This is something that would actually be a lot of work to handle
> because you would need a custom model that would actually store string
> values.
>
> Cheers
> Marios
>
>
> On Tue, Jan 7, 2014 at 9:32 PM, gmparker2000  >wrote:
>
> > Interesting but unfortunately our form is very complex with repeaters,
> etc.
> > So I don't think this would work for us.
> >
> > --
> > View this message in context:
> >
> http://apache-wicket.1842946.n4.nabble.com/Auto-save-feature-tp4663517p4663522.html
> > Sent from the Users forum mailing list archive at Nabble.com.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>

Re: Auto-save feature

[Marios Skounakis]

In a similar case I've used a wrapper around validators which controls
whether they run or not. This way you can automatically parse the form
component tree, find all validators and wrap them in a new Validator that
runs them only if needed.

I've done this because I wanted to be able to have the standard wicket
validators run in onValidateModelObjects(). I.e. I wanted my model to be
updated even if some validations did not pass.

So here's the basic idea (this is slightly modified from my actual code so
it may have small errors).

public abstract class ValidatorWrapper implements IValidator {
IValidator validator;
 public DelayedValidator(IValidator validator) {
super();
this.validator = validator;
}

protected abstract boolean shouldRun();

@Override
public void validate(IValidatable validatable) {
if (!shouldRun())
return;
if (validatable.getValue() == null) {
if (!(validator instanceof INullAcceptingValidator)) {
return;
}
}
validator.validate(validatable);
}
}

It is reasonably easy to extend this for FormValidators as well.

This does not handle the case of conversion errors, i.e. in an Integer
TextField if the user input is not a valid integer, it won't update the
model object. So if you auto-save and the reload, such fields will be
empty. This is something that would actually be a lot of work to handle
because you would need a custom model that would actually store string
values.

Cheers
Marios


On Tue, Jan 7, 2014 at 9:32 PM, gmparker2000 wrote:

> Interesting but unfortunately our form is very complex with repeaters, etc.
> So I don't think this would work for us.
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Auto-save-feature-tp4663517p4663522.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Auto-save feature

[gmparker2000]

Interesting but unfortunately our form is very complex with repeaters, etc. 
So I don't think this would work for us.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Auto-save-feature-tp4663517p4663522.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Auto-save feature

[Gabriel Landon]

I don't know if that is what you are looking for but there is a JS script
that can do it for your.
Data are store locally.

http://garlicjs.org/

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Auto-save-feature-tp4663517p4663521.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: TinyMce disappears with CryptoMapper

[jchappelle]

Sorry I thought I posted it. 

Another thing I'll mention is when I turn on request logging I see these two
lines logged out in the console when the problem occurs. It looks like the
last couple of segments aren't being encrypted.

http://localhost:8080/L7ExSNbPC4sb6TPJDblCAkN0baRJxw3qBR0wyJEtP3uLmhnUUFEbeu7SFNM9wrlMrHBtoodlQMAPr5CCP9g2aproPDfvon2O/L7E59/TPJfd//langs/en.js
http://localhost:8080/L7ExSNbPC4sb6TPJDblCAkN0baRJxw3qBR0wyJEtP3uLmhnUUFEbeu7SFNM9wrlMrHBtoodlQMAPr5CCP9g2aproPDfvon2O/L7E59/TPJfd//themes/simple/editor_template.js

Here is the quickstart
tinymce-crypto-quickstart.zip

  

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/TinyMce-disappears-with-CryptoMapper-tp4663499p4663520.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: TinyMce disappears with CryptoMapper

[Sven Meier]

Where's the quickstart?

Sven

On 01/07/2014 07:28 PM, jchappelle wrote:

I have a quickstart now. The setResponsePage(new TinyMcePage()) seems to
cause the issue. On the HomePage I have a tinymce and it displays fine.
However if you click a link that does the setResponsePage and transition to
a new page it does not display.

Any ideas?

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/TinyMce-disappears-with-CryptoMapper-tp4663499p4663518.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: TinyMce disappears with CryptoMapper

[jchappelle]

I have a quickstart now. The setResponsePage(new TinyMcePage()) seems to
cause the issue. On the HomePage I have a tinymce and it displays fine.
However if you click a link that does the setResponsePage and transition to
a new page it does not display.

Any ideas?

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/TinyMce-disappears-with-CryptoMapper-tp4663499p4663518.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Auto-save feature

[gmparker2000]

I am looking at implementing an auto save feature on a form I have created. 
This would save the data that the user had entered prior to their session
timing out.  The form has various validations that would have to be disabled
before this could work.  I have seen numerous posts around disabling
validation based on which button was used to submit the form, etc.  However,
none of the answers seemed satisfactory.  The only thing I can think to do
is set a flag on the form that each validator would check to see if it
should proceed.  This is going to be a lot more work than if I could just
call updateFormComponentModels myself (I tried this but it didn't work).

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Auto-save-feature-tp4663517.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Rationale for Converting to AngularJS/Spring MVC

[Ernesto Reinaldo Barreiro]

Hi,


On Tue, Jan 7, 2014 at 4:48 PM, Dan Simko  wrote:

> Hi,
>
> I didn't read whole conversation but you don't need to choose between
> Wicket and AngularJS. We are using both technologies together and it works
> great. AngularJS has no global state so you can use many Angular ("island"
>

That's exactly what the demo mentioned does: it creates a page where all
logic/AJAX is done via Angular and Wicket page just acts as a script
generating the page.


> single page) apps in one Wicket page. For some use-cases is better Wicket

so you use Wicket and for some (not so many) is better Angular, so you
> embed Angular app to Wicket page.
>
> Best regards,
> Dan Simko
>
>
> On Tue, Jan 7, 2014 at 8:37 AM, Martin Grigorov  >wrote:
>
> > Make some noise about this (stupid) decision and when the higher
> management
> > realize the mistake they made they will ask you ;-)
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> >
> >
> > On Mon, Jan 6, 2014 at 3:11 PM, Richard W. Adams 
> wrote:
> >
> > > Whether the reasons are valid or not irrelevant. I only passed along
> what
> > > I have heard; don't necessarily agree with the rationales. As I said, I
> > > was not consulted (and probably never will be).
> > >
> > >
> > >
> > >
> > > From:   Paul Bors 
> > > To: "users@wicket.apache.org" 
> > > Date:   01/03/2014 12:16 PM
> > > Subject:Re: Rationale for Converting to AngularJS/Spring MVC
> > >
> > >
> > >
> > > Both reasons provided don't carry much wight.
> > >
> > > 1) Dificulty of maintanance/upgrading between major releases
> > > Our webapp was our reporting tool which morphed into a system
> > > administative tool currently with 54k lines of code in well over 1k
> > public
> > > classes (conform Sonar). I migrated the webapp from Wicket 1.3.x to 6.x
> > by
> > > myself in under 2 weeks simply by following the migration tutorials one
> > by
> > > one.
> > >
> > > 2) Cost of tranning new developers
> > > Wicket itself is model much after the Java's Swing and it promotes
> > > fast
> > > adaptation for new developers (they teach Swing in college). Perhaps
> the
> > > new staff should consider spending 1 to 2 weeks reading one of the many
> > > books avaialble on Wicket, see:
> > > http://wicket.apache.org/learn/books/
> > >
> > > I spent a good 3-4 weeks reading over Andreas' free guide whcih took so
> > > long because I was reading it a chpater a day on the subway ride to
> work
> > > while at the same time proof reading his new material. You can print
> the
> > > free guide via:
> > > http://wicket.apache.org/start/userguide.html
> > >
> > > I don't know AngualrJS too much as I never worked with it. To me it
> looks
> > > like another JS framework out there in the mixture of many that can
> very
> > > easily be integrated with Wicket. Perhaps you should suggest that to
> your
> > > upper management.
> > >
> > > Anyhow, that's my two cents.
> > >
> > >
> > > On Fri, Jan 3, 2014 at 12:12 PM, Richard W. Adams 
> > wrote:
> > >
> > > > I don't have first hand knowledge of the decision making process,
> but I
> > > > understand there were two main factors:
> > > >
> > > > 1.  Difficulty in changing/maintaining the intermediate corporate
> > > > libraries, especially when considering whether to make the leap from
> > > > Wicket 1.4.17 to 6.x.
> > > >
> > > > 2. A perception of excessive cost in training new developers to use
> > > > Wicket. I myself am fairly comfortable with Wicket now (after 2 years
> > > > experience), but have to admit  the leaning curve was pretty steep.
> > > >
> > > >
> > > >
> > > >
> > > > From:   Ernesto Reinaldo Barreiro 
> > > > To: users@wicket.apache.org
> > > > Date:   01/03/2014 10:58 AM
> > > > Subject:Re: Converting Wicket to AngularJS/Spring MVC
> > > >
> > > >
> > > >
> > > > May I ask what was the rationale of choosing Angular JS + Spring MVC
> > > over
> > > > Wicket? I have been using Backbone + Spring MVC in a project, imposed
> > by
> > > > client, for the last month and to be honest I'm not impressed with
> > > > productivity you achieve using the combination: not to mention that
> > > > developers need to know both JavaScript + Java server side to be
> > > > completely
> > > > productive. IMHO this will impact your productivity in a negative
> way.
> > > The
> > > > only "reason" I could see to make that move is if scalability is an
> > > issue.
> > > >
> > > > Best regards,
> > > >
> > > > Ernesto
> > > >
> > > >
> > > >
> > > > **
> > > >
> > > > This email and any attachments may contain information that is
> > > > confidential and/or privileged for the sole use of the intended
> > > recipient.
> > > >  Any use, review, disclosure, copying, distribution or reliance by
> > > others,
> > > > and any forwarding of this email or its contents, without the express
> > > > permission of the sender is strictly prohibited by law.  If you are
> not
> > > the
> > > > intended recipient, please contact the sender immediately, delete the
> > >

Re: Why is getDisplayValue in getDisplayValue final?

[Martin Grigorov]

http://wicket.sourceforge.net/faqs.html#why-final
this is the explanation of the designers of Wicket

I agree with both sides
I don't think that there are too many finals in the code
usually if you explain why you need to remove the final we either remove it
for the next release or explain a better way
Sven asked for the reason already

Martin Grigorov
Wicket Training and Consulting


On Tue, Jan 7, 2014 at 5:21 PM, Steve  wrote:

> Have to agree with this.  I've come across the 'final' issues many times
> in wicket and other libraries. It appears from my own experience with
> Wicket is that classes/methods are marked final if the developer can't
> think of a reason someone might want to extend it (Martin, I'm not
> actually referring to RawMarkup here, there's many other cases I've
> encountered both in wicket-el and completely unrelated coding
> adventures).   IMHO this is an artificial limitation and they should
> only be marked final if the expected results of that method form part of
> a contract that could be broken if the behaviour of the implementing
> method differs from the original.  In that case it is the responsibility
> of the overrider to deal with the implications ultimately but if can be
> dealt with explaining the contract clearly in the javadoc.  That way if
> a downstream developer mucks it up it's on their own head and the wicket
> devs don't have to deal with the fallout of buggered up design.
>
> Again IMHO there are very few legitimate use cases for marking methods
> or classes final in an OS library.  Closed source I can understand.
>
> On 08/01/14 00:53, Oliver B. Fischer wrote:
> > There are to much final methods in Wicket. This leads to copying code
> > instead of overriding only the methods you would like to change.
> >
> > Oliver
> >
> > Am 07.01.14 15:44, schrieb Martin Grigorov:
> >> On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> It is no more final in 7.x.
> >>>
> >>
> >> Actually it is still final.
> >> I have been confused with another method.
> >>
> >>
> >>> I don't mind removing final in 6.x too.
> >>>
> >>> Martin Grigorov
> >>> Wicket Training and Consulting
> >>>
> >>>
> >>> On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer
> >>> wrote:
> >>>
>  Hi,
> 
>  I just tried to customize EnumChoiceRenderer and to override
>  getDisplayValue, but is final. Why?
> 
>  Can I submit a patch to remove final?
> 
>  Bye,
> 
>  Oliver
> 
>  -
>  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>  For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> >>>
> >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Rationale for Converting to AngularJS/Spring MVC

[Dan Simko]

Hi,

I didn't read whole conversation but you don't need to choose between
Wicket and AngularJS. We are using both technologies together and it works
great. AngularJS has no global state so you can use many Angular ("island"
single page) apps in one Wicket page. For some use-cases is better Wicket
so you use Wicket and for some (not so many) is better Angular, so you
embed Angular app to Wicket page.

Best regards,
Dan Simko


On Tue, Jan 7, 2014 at 8:37 AM, Martin Grigorov wrote:

> Make some noise about this (stupid) decision and when the higher management
> realize the mistake they made they will ask you ;-)
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Mon, Jan 6, 2014 at 3:11 PM, Richard W. Adams  wrote:
>
> > Whether the reasons are valid or not irrelevant. I only passed along what
> > I have heard; don't necessarily agree with the rationales. As I said, I
> > was not consulted (and probably never will be).
> >
> >
> >
> >
> > From:   Paul Bors 
> > To: "users@wicket.apache.org" 
> > Date:   01/03/2014 12:16 PM
> > Subject:Re: Rationale for Converting to AngularJS/Spring MVC
> >
> >
> >
> > Both reasons provided don't carry much wight.
> >
> > 1) Dificulty of maintanance/upgrading between major releases
> > Our webapp was our reporting tool which morphed into a system
> > administative tool currently with 54k lines of code in well over 1k
> public
> > classes (conform Sonar). I migrated the webapp from Wicket 1.3.x to 6.x
> by
> > myself in under 2 weeks simply by following the migration tutorials one
> by
> > one.
> >
> > 2) Cost of tranning new developers
> > Wicket itself is model much after the Java's Swing and it promotes
> > fast
> > adaptation for new developers (they teach Swing in college). Perhaps the
> > new staff should consider spending 1 to 2 weeks reading one of the many
> > books avaialble on Wicket, see:
> > http://wicket.apache.org/learn/books/
> >
> > I spent a good 3-4 weeks reading over Andreas' free guide whcih took so
> > long because I was reading it a chpater a day on the subway ride to work
> > while at the same time proof reading his new material. You can print the
> > free guide via:
> > http://wicket.apache.org/start/userguide.html
> >
> > I don't know AngualrJS too much as I never worked with it. To me it looks
> > like another JS framework out there in the mixture of many that can very
> > easily be integrated with Wicket. Perhaps you should suggest that to your
> > upper management.
> >
> > Anyhow, that's my two cents.
> >
> >
> > On Fri, Jan 3, 2014 at 12:12 PM, Richard W. Adams 
> wrote:
> >
> > > I don't have first hand knowledge of the decision making process, but I
> > > understand there were two main factors:
> > >
> > > 1.  Difficulty in changing/maintaining the intermediate corporate
> > > libraries, especially when considering whether to make the leap from
> > > Wicket 1.4.17 to 6.x.
> > >
> > > 2. A perception of excessive cost in training new developers to use
> > > Wicket. I myself am fairly comfortable with Wicket now (after 2 years
> > > experience), but have to admit  the leaning curve was pretty steep.
> > >
> > >
> > >
> > >
> > > From:   Ernesto Reinaldo Barreiro 
> > > To: users@wicket.apache.org
> > > Date:   01/03/2014 10:58 AM
> > > Subject:Re: Converting Wicket to AngularJS/Spring MVC
> > >
> > >
> > >
> > > May I ask what was the rationale of choosing Angular JS + Spring MVC
> > over
> > > Wicket? I have been using Backbone + Spring MVC in a project, imposed
> by
> > > client, for the last month and to be honest I'm not impressed with
> > > productivity you achieve using the combination: not to mention that
> > > developers need to know both JavaScript + Java server side to be
> > > completely
> > > productive. IMHO this will impact your productivity in a negative way.
> > The
> > > only "reason" I could see to make that move is if scalability is an
> > issue.
> > >
> > > Best regards,
> > >
> > > Ernesto
> > >
> > >
> > >
> > > **
> > >
> > > This email and any attachments may contain information that is
> > > confidential and/or privileged for the sole use of the intended
> > recipient.
> > >  Any use, review, disclosure, copying, distribution or reliance by
> > others,
> > > and any forwarding of this email or its contents, without the express
> > > permission of the sender is strictly prohibited by law.  If you are not
> > the
> > > intended recipient, please contact the sender immediately, delete the
> > > e-mail and destroy all copies.
> > > **
> > >
> >
> >
> >
> > **
> >
> > This email and any attachments may contain information that is
> > confidential and/or privileged for the sole use of the intended
> recipient.
> >  Any use, review, disclosure, copying, distribution or reliance by
> others,
> > and any forwarding of this email or its contents, without the express
> > permission of the sender is strictly prohibited by law.  If you are not
> the
> > intended recipient, please contact the

Re: Why is getDisplayValue in getDisplayValue final?

[Steve]

Have to agree with this.  I've come across the 'final' issues many times
in wicket and other libraries. It appears from my own experience with
Wicket is that classes/methods are marked final if the developer can't
think of a reason someone might want to extend it (Martin, I'm not
actually referring to RawMarkup here, there's many other cases I've
encountered both in wicket-el and completely unrelated coding
adventures).   IMHO this is an artificial limitation and they should
only be marked final if the expected results of that method form part of
a contract that could be broken if the behaviour of the implementing
method differs from the original.  In that case it is the responsibility
of the overrider to deal with the implications ultimately but if can be
dealt with explaining the contract clearly in the javadoc.  That way if
a downstream developer mucks it up it's on their own head and the wicket
devs don't have to deal with the fallout of buggered up design.

Again IMHO there are very few legitimate use cases for marking methods
or classes final in an OS library.  Closed source I can understand.

On 08/01/14 00:53, Oliver B. Fischer wrote:
> There are to much final methods in Wicket. This leads to copying code
> instead of overriding only the methods you would like to change.
>
> Oliver
>
> Am 07.01.14 15:44, schrieb Martin Grigorov:
>> On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov
>> wrote:
>>
>>> Hi,
>>>
>>> It is no more final in 7.x.
>>>
>>
>> Actually it is still final.
>> I have been confused with another method.
>>
>>
>>> I don't mind removing final in 6.x too.
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>>
>>>
>>> On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer
>>> wrote:
>>>
 Hi,

 I just tried to customize EnumChoiceRenderer and to override
 getDisplayValue, but is final. Why?

 Can I submit a patch to remove final?

 Bye,

 Oliver

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


>>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Why is getDisplayValue in getDisplayValue final?

[Oliver B. Fischer]

There are to much final methods in Wicket. This leads to copying code 
instead of overriding only the methods you would like to change.


Oliver

Am 07.01.14 15:44, schrieb Martin Grigorov:

On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov wrote:


Hi,

It is no more final in 7.x.



Actually it is still final.
I have been confused with another method.



I don't mind removing final in 6.x too.

Martin Grigorov
Wicket Training and Consulting


On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer wrote:


Hi,

I just tried to customize EnumChoiceRenderer and to override
getDisplayValue, but is final. Why?

Can I submit a patch to remove final?

Bye,

Oliver

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org








-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Why is getDisplayValue in getDisplayValue final?

[Martin Grigorov]

On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov wrote:

> Hi,
>
> It is no more final in 7.x.
>

Actually it is still final.
I have been confused with another method.


> I don't mind removing final in 6.x too.
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer 
> wrote:
>
>> Hi,
>>
>> I just tried to customize EnumChoiceRenderer and to override
>> getDisplayValue, but is final. Why?
>>
>> Can I submit a patch to remove final?
>>
>> Bye,
>>
>> Oliver
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>

Re: Why is getDisplayValue in getDisplayValue final?

[Martin Grigorov]

Hi,

It is no more final in 7.x.
I don't mind removing final in 6.x too.

Martin Grigorov
Wicket Training and Consulting


On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer wrote:

> Hi,
>
> I just tried to customize EnumChoiceRenderer and to override
> getDisplayValue, but is final. Why?
>
> Can I submit a patch to remove final?
>
> Bye,
>
> Oliver
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Why is getDisplayValue in getDisplayValue final?

[Sven Meier]

You have #resourceKey() and #postprocess() to override - what do you 
need more?


Sven

On 01/07/2014 03:37 PM, Oliver B. Fischer wrote:

Hi,

I just tried to customize EnumChoiceRenderer and to override 
getDisplayValue, but is final. Why?


Can I submit a patch to remove final?

Bye,

Oliver

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Why is getDisplayValue in getDisplayValue final?

[Oliver B. Fischer]

Hi,

I just tried to customize EnumChoiceRenderer and to override 
getDisplayValue, but is final. Why?


Can I submit a patch to remove final?

Bye,

Oliver

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org