Re: AjaxFormSubmitBehavior, FileUploadField and nested forms.

2016-06-17 Thread Fabio Fioretti
Thanks Martin,

This is good news. Looking forward to 6.24.0.

Kind regards,
Fabio

On Fri, Jun 17, 2016 at 10:26 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi Fabio,
>
> I agree that the removal of the default message is not really needed.
> It has been done with https://issues.apache.org/jira/browse/WICKET-5735.
>
> I've reverted this with https://issues.apache.org/jira/browse/WICKET-6181
>
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, Jun 13, 2016 at 1:43 PM, Fabio Fioretti <
> windom.macroso...@gmail.com
> > wrote:
>
> > Hi all,
> > Does anybody have any feedback on this?
> >
> > Many thanks,
> > Fabio
> >
> > On Tue, May 31, 2016 at 12:46 PM, Fabio Fioretti <
> > windom.macroso...@gmail.com> wrote:
> >
> > > Hi Martin,
> > >
> > > You are right, the form id was already there in 6.17.0, but the default
> > > message was removed! That is what is breaking my app - I did not
> realize
> > it
> > > because my custom message was the same as the default.
> > >
> > > Why was it removed?
> > >
> > > In 6.17.0:
> > > final String defaultValue = "Upload must be less than " + getMaxSize();
> > > String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY,
> > > Model.ofMap(model), defaultValue)
> > >
> > > While in 6.23.0:
> > > String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY,
> > > Model.ofMap(model));
> > >
> > > Interestingly, the comment still says "Resource key should be
> > > .uploadTooLarge to override default message".
> > >
> > > IMHO, forcing to have the root (!) form id in the property key makes it
> > > impossible to create a reusable component for managing uploads, like an
> > > UploadPanel with its own form and FileUploadField . In fact, as soon as
> > you
> > > place it in a hierarchy that includes an outer form, it will break your
> > > app. The default value at least provided a safe fallback.
> > >
> > > What do you think?
> > >
> > > Many thanks,
> > > Fabio
> > >
> > >
> > > On Mon, May 30, 2016 at 4:31 PM, Martin Grigorov <mgrigo...@apache.org
> >
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> On Fri, May 27, 2016 at 12:42 PM, Fabio Fioretti <
> > >> windom.macroso...@gmail.com> wrote:
> > >>
> > >> > Hi Martin,
> > >> >
> > >> > Is this the ticket you refer to?
> > >> > https://issues.apache.org/jira/browse/WICKET-5190
> > >>
> > >>
> > >> Yes, this is the one!
> > >>
> > >>
> > >> >
> > >> >
> > >> > It has an explanation on why onFileUploadException() is called on
> the
> > >> root
> > >> > form that seems reasonable.
> > >> >
> > >> > In any case, if I don't specify the form id in the property key
> > (leaving
> > >> > just "uploadTooLarge") I get the following MissingResourceException
> > when
> > >> > FileUploadBase.SizeLimitExceededException is thrown:
> > >> >
> > >>
> > >> According to Git history the id was there even in 6.17:
> > >>
> > >>
> >
> https://github.com/apache/wicket/blob/wicket-6.17.0/wicket-core/src/main/java/org/apache/wicket/markup/html/form/Form.java#L1423
> > >>
> > >> The id is not in Wicket 7.x though!
> > >> It has been removed with
> > >> https://issues.apache.org/jira/browse/WICKET-5206
> > >> 3 years ago
> > >>
> > >>
> > >> >
> > >> > *java.util.MissingResourceException*: Unable to find property:
> > >> > 'form1.uploadTooLarge' for component: border:border_body:form1
> > >> > [class=org.apache.wicket.markup.html.form.Form].
> > >> > Locale: null, style: null
> > >> >
> > >> > As you can see, I do have a border complicating things (not sure if
> it
> > >> > might play a role here) but it worked just fine in Wicket 6.17.0. In
> > >> fact I
> > >> > had to add the form id ("form0.uploadTooLarge") to make it work in
> > >> 6.23.0,
> > >> > but then I ran into this other issue that, when form0 is nested in
>

Re: AjaxFormSubmitBehavior, FileUploadField and nested forms.

2016-06-13 Thread Fabio Fioretti
Hi all,
Does anybody have any feedback on this?

Many thanks,
Fabio

On Tue, May 31, 2016 at 12:46 PM, Fabio Fioretti <
windom.macroso...@gmail.com> wrote:

> Hi Martin,
>
> You are right, the form id was already there in 6.17.0, but the default
> message was removed! That is what is breaking my app - I did not realize it
> because my custom message was the same as the default.
>
> Why was it removed?
>
> In 6.17.0:
> final String defaultValue = "Upload must be less than " + getMaxSize();
> String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY,
> Model.ofMap(model), defaultValue)
>
> While in 6.23.0:
> String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY,
> Model.ofMap(model));
>
> Interestingly, the comment still says "Resource key should be
> .uploadTooLarge to override default message".
>
> IMHO, forcing to have the root (!) form id in the property key makes it
> impossible to create a reusable component for managing uploads, like an
> UploadPanel with its own form and FileUploadField . In fact, as soon as you
> place it in a hierarchy that includes an outer form, it will break your
> app. The default value at least provided a safe fallback.
>
> What do you think?
>
> Many thanks,
> Fabio
>
>
> On Mon, May 30, 2016 at 4:31 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
>> Hi,
>>
>> On Fri, May 27, 2016 at 12:42 PM, Fabio Fioretti <
>> windom.macroso...@gmail.com> wrote:
>>
>> > Hi Martin,
>> >
>> > Is this the ticket you refer to?
>> > https://issues.apache.org/jira/browse/WICKET-5190
>>
>>
>> Yes, this is the one!
>>
>>
>> >
>> >
>> > It has an explanation on why onFileUploadException() is called on the
>> root
>> > form that seems reasonable.
>> >
>> > In any case, if I don't specify the form id in the property key (leaving
>> > just "uploadTooLarge") I get the following MissingResourceException when
>> > FileUploadBase.SizeLimitExceededException is thrown:
>> >
>>
>> According to Git history the id was there even in 6.17:
>>
>> https://github.com/apache/wicket/blob/wicket-6.17.0/wicket-core/src/main/java/org/apache/wicket/markup/html/form/Form.java#L1423
>>
>> The id is not in Wicket 7.x though!
>> It has been removed with
>> https://issues.apache.org/jira/browse/WICKET-5206
>> 3 years ago
>>
>>
>> >
>> > *java.util.MissingResourceException*: Unable to find property:
>> > 'form1.uploadTooLarge' for component: border:border_body:form1
>> > [class=org.apache.wicket.markup.html.form.Form].
>> > Locale: null, style: null
>> >
>> > As you can see, I do have a border complicating things (not sure if it
>> > might play a role here) but it worked just fine in Wicket 6.17.0. In
>> fact I
>> > had to add the form id ("form0.uploadTooLarge") to make it work in
>> 6.23.0,
>> > but then I ran into this other issue that, when form0 is nested in
>> > form1, Wicket looks up for "form1.uploadTooLarge" instead.
>> >
>> > I also noticed that there is a new fileMaxSize property in Form that
>> wasn't
>> > there in 6.17.0. Should I use that one instead of maxSize? It has no
>> setter
>> > though...
>> >
>>
>> This is related to https://issues.apache.org/jira/browse/WICKET-5735
>>
>>
>> >
>> > Any clarification would be much appreciated.
>> >
>> > Many thanks,
>> > Fabio
>> >
>> > On Thu, May 26, 2016 at 7:18 PM, Martin Grigorov <mgrigo...@apache.org>
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > I believe there is/was another ticket describing exactly your problem
>> > but I
>> > > cannot find it now.
>> > >
>> > > The form id in the property key is not really needed.
>> > > You could use it to give Wicket a more specific message for particular
>> > > component.
>> > > You can remove it if this message should/could be used for any other
>> Form
>> > > in you application/package/page/panel (depending in which .properties
>> > file
>> > > you have it).
>> > >
>> > > Martin Grigorov
>> > > Wicket Training and Consulting
>> > > https://twitter.com/mtgrigorov
>> > >
>> > > On Thu, May 26, 2016 at 6:46 PM, Fabio Fioretti <
>> > > windom.macroso...@gmail.com
&

Re: AjaxFormSubmitBehavior, FileUploadField and nested forms.

2016-05-31 Thread Fabio Fioretti
Hi Martin,

You are right, the form id was already there in 6.17.0, but the default
message was removed! That is what is breaking my app - I did not realize it
because my custom message was the same as the default.

Why was it removed?

In 6.17.0:
final String defaultValue = "Upload must be less than " + getMaxSize();
String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY,
Model.ofMap(model), defaultValue)

While in 6.23.0:
String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY,
Model.ofMap(model));

Interestingly, the comment still says "Resource key should be
.uploadTooLarge to override default message".

IMHO, forcing to have the root (!) form id in the property key makes it
impossible to create a reusable component for managing uploads, like an
UploadPanel with its own form and FileUploadField . In fact, as soon as you
place it in a hierarchy that includes an outer form, it will break your
app. The default value at least provided a safe fallback.

What do you think?

Many thanks,
Fabio


On Mon, May 30, 2016 at 4:31 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> On Fri, May 27, 2016 at 12:42 PM, Fabio Fioretti <
> windom.macroso...@gmail.com> wrote:
>
> > Hi Martin,
> >
> > Is this the ticket you refer to?
> > https://issues.apache.org/jira/browse/WICKET-5190
>
>
> Yes, this is the one!
>
>
> >
> >
> > It has an explanation on why onFileUploadException() is called on the
> root
> > form that seems reasonable.
> >
> > In any case, if I don't specify the form id in the property key (leaving
> > just "uploadTooLarge") I get the following MissingResourceException when
> > FileUploadBase.SizeLimitExceededException is thrown:
> >
>
> According to Git history the id was there even in 6.17:
>
> https://github.com/apache/wicket/blob/wicket-6.17.0/wicket-core/src/main/java/org/apache/wicket/markup/html/form/Form.java#L1423
>
> The id is not in Wicket 7.x though!
> It has been removed with https://issues.apache.org/jira/browse/WICKET-5206
> 3 years ago
>
>
> >
> > *java.util.MissingResourceException*: Unable to find property:
> > 'form1.uploadTooLarge' for component: border:border_body:form1
> > [class=org.apache.wicket.markup.html.form.Form].
> > Locale: null, style: null
> >
> > As you can see, I do have a border complicating things (not sure if it
> > might play a role here) but it worked just fine in Wicket 6.17.0. In
> fact I
> > had to add the form id ("form0.uploadTooLarge") to make it work in
> 6.23.0,
> > but then I ran into this other issue that, when form0 is nested in
> > form1, Wicket looks up for "form1.uploadTooLarge" instead.
> >
> > I also noticed that there is a new fileMaxSize property in Form that
> wasn't
> > there in 6.17.0. Should I use that one instead of maxSize? It has no
> setter
> > though...
> >
>
> This is related to https://issues.apache.org/jira/browse/WICKET-5735
>
>
> >
> > Any clarification would be much appreciated.
> >
> > Many thanks,
> > Fabio
> >
> > On Thu, May 26, 2016 at 7:18 PM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > I believe there is/was another ticket describing exactly your problem
> > but I
> > > cannot find it now.
> > >
> > > The form id in the property key is not really needed.
> > > You could use it to give Wicket a more specific message for particular
> > > component.
> > > You can remove it if this message should/could be used for any other
> Form
> > > in you application/package/page/panel (depending in which .properties
> > file
> > > you have it).
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> > > On Thu, May 26, 2016 at 6:46 PM, Fabio Fioretti <
> > > windom.macroso...@gmail.com
> > > > wrote:
> > >
> > > > Hello everybody,
> > > >
> > > > I recently migrated an application from Wicket 6.17.0 to 6.23.0 and
> I'm
> > > > experiencing the following problem.
> > > >
> > > > I have 2 nested forms. The inner one, form0, contains a
> FileUploadField
> > > > with an AjaxFormSubmitBehavior(form0, "change") attached to it, while
> > the
> > > > external one, form1, wraps form0.
> > > >
> > > > form1
> > > > |__
> > > >  form0
> > > >   |__
> >

Re: AjaxFormSubmitBehavior, FileUploadField and nested forms.

2016-05-27 Thread Fabio Fioretti
As a side note: finalMaxSize does have a setter in Form, sorry for the
oversight. However, setting finalMaxSize on form0 has no effect... Only the
one on form1 (the outer form) is actually enforced, but then again,
properties must be defined at that level.

Thanks,
Fabio

On Fri, May 27, 2016 at 12:42 PM, Fabio Fioretti <
windom.macroso...@gmail.com> wrote:

> Hi Martin,
>
> Is this the ticket you refer to?
> https://issues.apache.org/jira/browse/WICKET-5190
>
> It has an explanation on why onFileUploadException() is called on the root
> form that seems reasonable.
>
> In any case, if I don't specify the form id in the property key (leaving
> just "uploadTooLarge") I get the following MissingResourceException when
> FileUploadBase.SizeLimitExceededException is thrown:
>
> *java.util.MissingResourceException*: Unable to find property:
> 'form1.uploadTooLarge' for component: border:border_body:form1 
> [class=org.apache.wicket.markup.html.form.Form].
> Locale: null, style: null
>
> As you can see, I do have a border complicating things (not sure if it
> might play a role here) but it worked just fine in Wicket 6.17.0. In fact I
> had to add the form id ("form0.uploadTooLarge") to make it work in 6.23.0,
> but then I ran into this other issue that, when form0 is nested in
> form1, Wicket looks up for "form1.uploadTooLarge" instead.
>
> I also noticed that there is a new fileMaxSize property in Form that
> wasn't there in 6.17.0. Should I use that one instead of maxSize? It has no
> setter though...
>
> Any clarification would be much appreciated.
>
> Many thanks,
> Fabio
>
> On Thu, May 26, 2016 at 7:18 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
>> Hi,
>>
>> I believe there is/was another ticket describing exactly your problem but
>> I
>> cannot find it now.
>>
>> The form id in the property key is not really needed.
>> You could use it to give Wicket a more specific message for particular
>> component.
>> You can remove it if this message should/could be used for any other Form
>> in you application/package/page/panel (depending in which .properties file
>> you have it).
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Thu, May 26, 2016 at 6:46 PM, Fabio Fioretti <
>> windom.macroso...@gmail.com
>> > wrote:
>>
>> > Hello everybody,
>> >
>> > I recently migrated an application from Wicket 6.17.0 to 6.23.0 and I'm
>> > experiencing the following problem.
>> >
>> > I have 2 nested forms. The inner one, form0, contains a FileUploadField
>> > with an AjaxFormSubmitBehavior(form0, "change") attached to it, while
>> the
>> > external one, form1, wraps form0.
>> >
>> > form1
>> > |__
>> >  form0
>> >   |__
>> >FileUploadField
>> >
>> > When the user selects a file and a file upload exception is thrown (e.g.
>> > FileSizeLimitExceededException), I would expect form0's
>> > onFileUploadException() method to be invoked. However, the one of form1
>> is
>> > invoked instead...
>> >
>> > As a result, Wicket starts looking for a property named
>> > "form1.uploadTooLarge" instead of "form0.uploadTooLarge", thus breaking
>> my
>> > app, which only defines the latter.
>> >
>> > Is this an intended behavior?
>> >
>> > Was it introduced by https://issues.apache.org/jira/browse/WICKET-5753?
>> >
>> > And, by the way, what is the rationale of having the form id in the
>> > property key?
>> >
>> > Many thanks in advance,
>> > Fabio
>> >
>>
>
>


Re: AjaxFormSubmitBehavior, FileUploadField and nested forms.

2016-05-27 Thread Fabio Fioretti
Hi Martin,

Is this the ticket you refer to?
https://issues.apache.org/jira/browse/WICKET-5190

It has an explanation on why onFileUploadException() is called on the root
form that seems reasonable.

In any case, if I don't specify the form id in the property key (leaving
just "uploadTooLarge") I get the following MissingResourceException when
FileUploadBase.SizeLimitExceededException is thrown:

*java.util.MissingResourceException*: Unable to find property:
'form1.uploadTooLarge' for component: border:border_body:form1
[class=org.apache.wicket.markup.html.form.Form].
Locale: null, style: null

As you can see, I do have a border complicating things (not sure if it
might play a role here) but it worked just fine in Wicket 6.17.0. In fact I
had to add the form id ("form0.uploadTooLarge") to make it work in 6.23.0,
but then I ran into this other issue that, when form0 is nested in
form1, Wicket looks up for "form1.uploadTooLarge" instead.

I also noticed that there is a new fileMaxSize property in Form that wasn't
there in 6.17.0. Should I use that one instead of maxSize? It has no setter
though...

Any clarification would be much appreciated.

Many thanks,
Fabio

On Thu, May 26, 2016 at 7:18 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> I believe there is/was another ticket describing exactly your problem but I
> cannot find it now.
>
> The form id in the property key is not really needed.
> You could use it to give Wicket a more specific message for particular
> component.
> You can remove it if this message should/could be used for any other Form
> in you application/package/page/panel (depending in which .properties file
> you have it).
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, May 26, 2016 at 6:46 PM, Fabio Fioretti <
> windom.macroso...@gmail.com
> > wrote:
>
> > Hello everybody,
> >
> > I recently migrated an application from Wicket 6.17.0 to 6.23.0 and I'm
> > experiencing the following problem.
> >
> > I have 2 nested forms. The inner one, form0, contains a FileUploadField
> > with an AjaxFormSubmitBehavior(form0, "change") attached to it, while the
> > external one, form1, wraps form0.
> >
> > form1
> > |__
> >  form0
> >   |__
> >FileUploadField
> >
> > When the user selects a file and a file upload exception is thrown (e.g.
> > FileSizeLimitExceededException), I would expect form0's
> > onFileUploadException() method to be invoked. However, the one of form1
> is
> > invoked instead...
> >
> > As a result, Wicket starts looking for a property named
> > "form1.uploadTooLarge" instead of "form0.uploadTooLarge", thus breaking
> my
> > app, which only defines the latter.
> >
> > Is this an intended behavior?
> >
> > Was it introduced by https://issues.apache.org/jira/browse/WICKET-5753?
> >
> > And, by the way, what is the rationale of having the form id in the
> > property key?
> >
> > Many thanks in advance,
> > Fabio
> >
>


AjaxFormSubmitBehavior, FileUploadField and nested forms.

2016-05-26 Thread Fabio Fioretti
Hello everybody,

I recently migrated an application from Wicket 6.17.0 to 6.23.0 and I'm
experiencing the following problem.

I have 2 nested forms. The inner one, form0, contains a FileUploadField
with an AjaxFormSubmitBehavior(form0, "change") attached to it, while the
external one, form1, wraps form0.

form1
|__
 form0
  |__
   FileUploadField

When the user selects a file and a file upload exception is thrown (e.g.
FileSizeLimitExceededException), I would expect form0's
onFileUploadException() method to be invoked. However, the one of form1 is
invoked instead...

As a result, Wicket starts looking for a property named
"form1.uploadTooLarge" instead of "form0.uploadTooLarge", thus breaking my
app, which only defines the latter.

Is this an intended behavior?

Was it introduced by https://issues.apache.org/jira/browse/WICKET-5753?

And, by the way, what is the rationale of having the form id in the
property key?

Many thanks in advance,
Fabio


Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.

2016-05-10 Thread Fabio Fioretti
I confirm version 6.23.0 fixed the problem.

Thank you for the great support!

Kind regards,
Fabio

On Thu, Apr 28, 2016 at 12:02 PM, Fabio Fioretti <
windom.macroso...@gmail.com> wrote:

> Thanks Andrea, that would be excellent!
>
> Keep up the great work,
> Fabio
>
> On Thu, Apr 28, 2016 at 11:52 AM, Andrea Del Bene <an.delb...@gmail.com>
> wrote:
>
>> Thank you for the issue! I think we can make it for next release 6.23.0
>> which should come quite soon (at the moment we are voting to release Wicket
>> 6.23.0).
>>
>> Andrea.
>>
>>
>> On 28/04/2016 11:34, Fabio Fioretti wrote:
>>
>>> Done: https://github.com/wicketstuff/core/issues/490
>>>
>>> Many thanks,
>>> Fabio
>>>
>>> On Thu, Apr 28, 2016 at 11:03 AM, Martin Grigorov <
>>> martin.grigo...@gmail.com
>>>
>>>> wrote:
>>>> Please file an issue at Wicketstuff GibHub.
>>>> On Apr 28, 2016 10:31 AM, "Fabio Fioretti" <windom.macroso...@gmail.com
>>>> >
>>>> wrote:
>>>>
>>>> Hi Martin,
>>>>>
>>>>> Thanks, I agree - findOffices() shouldn't be executed at all. In fact,
>>>>> handleMethodExecution() returns before invoking application code in all
>>>>> other cases (step 1 for unauthorized access, step 3 for validation
>>>>>
>>>> errors).
>>>>
>>>>> Any chance to have it fixed relatively soon? (maybe Andrea can answer
>>>>>
>>>> this)
>>>>
>>>>> Kind regards,
>>>>> Fabio
>>>>>
>>>>> On Thu, Apr 28, 2016 at 6:44 AM, Martin Grigorov <mgrigo...@apache.org
>>>>> >
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 27, 2016 at 12:07 PM, Fabio Fioretti <
>>>>>> windom.macroso...@gmail.com> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>>
>>>>>>> Please consider the following simple implementation of
>>>>>>>
>>>>>> AbstractRestResource
>>>>>>
>>>>>>> (6.22.0):
>>>>>>>
>>>>>>> @ResourcePath("/rest/api")
>>>>>>> public class MyRestResource extends
>>>>>>> AbstractRestResource
>>>>>>> {
>>>>>>>
>>>>>>>   public MyRestResource ()
>>>>>>>   {
>>>>>>>super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial()));
>>>>>>>   }
>>>>>>>
>>>>>>>   @MethodMapping(value = "/offices")
>>>>>>>   public List findOffices(
>>>>>>> @RequestParam(value = "region", required = false) Integer
>>>>>>>
>>>>>> regionId)
>>>>
>>>>>   {
>>>>>>>return findOfficesByRegion(regionId);
>>>>>>>   }
>>>>>>> }
>>>>>>>
>>>>>>> My question relates to the findOffices method and its filtering
>>>>>>>
>>>>>> regionId
>>>>>
>>>>>> parameter when the value is not a valid integer. For example,
>>>>>>>
>>>>>> consider
>>>>
>>>>> the
>>>>>>
>>>>>>> request 'GET /rest/api/offices?region=AA'.
>>>>>>>
>>>>>>> At the second step of AbstractRestResource.handleMethodExecution,
>>>>>>> extractMethodParameters is invoked, which in turn triggers the
>>>>>>>
>>>>>> conversion
>>>>>
>>>>>> of all parameters through the static method toObject.
>>>>>>>
>>>>>>> When the conversion goes wrong and ConversionException is thrown,
>>>>>>>
>>>>>> toObject
>>>>>>
>>>>>>> catches it, sets the response status to 400 and returns null!
>>>>>>>
>>>>>>> Now, when my findOffices is finally executed, I get a null regionId
>>>>>>>
>>>>>> but I
>>>>>
>>>>>> don't know whether it was not valid or the parameter was not present
>>>>>>>
>>>>>> at
>>>>
>>>>> all. Checking the response status downstream is also particularly
>>>>>>>
>>>>>> hard
>>>>
>>>>> because I have no getStatus (Tomcat 6 here, ouch!).
>>>>>>>
>>>>>>> To my mind, findOffices should return null instead of the unfiltered
>>>>>>>
>>>>>> list
>>>>>
>>>>>> of offices if the conversion went wrong, even because the response
>>>>>>> status is 400 (as set by toObject). However, how can I know it?
>>>>>>>
>>>>>>> Any suggestions?
>>>>>>>
>>>>>>> IMO this is a bug in the library.
>>>>>> #findOffices() should not be executed at all.
>>>>>> A response with status code 400 should be returned immediately after
>>>>>>
>>>>> the
>>>>
>>>>> unsuccessful convention without giving a chance to the application code
>>>>>>
>>>>> to
>>>>>
>>>>>> be executed.
>>>>>>
>>>>>> Many thanks,
>>>>>>> Fabio
>>>>>>>
>>>>>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>


Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.

2016-04-28 Thread Fabio Fioretti
Thanks Andrea, that would be excellent!

Keep up the great work,
Fabio

On Thu, Apr 28, 2016 at 11:52 AM, Andrea Del Bene <an.delb...@gmail.com>
wrote:

> Thank you for the issue! I think we can make it for next release 6.23.0
> which should come quite soon (at the moment we are voting to release Wicket
> 6.23.0).
>
> Andrea.
>
>
> On 28/04/2016 11:34, Fabio Fioretti wrote:
>
>> Done: https://github.com/wicketstuff/core/issues/490
>>
>> Many thanks,
>> Fabio
>>
>> On Thu, Apr 28, 2016 at 11:03 AM, Martin Grigorov <
>> martin.grigo...@gmail.com
>>
>>> wrote:
>>> Please file an issue at Wicketstuff GibHub.
>>> On Apr 28, 2016 10:31 AM, "Fabio Fioretti" <windom.macroso...@gmail.com>
>>> wrote:
>>>
>>> Hi Martin,
>>>>
>>>> Thanks, I agree - findOffices() shouldn't be executed at all. In fact,
>>>> handleMethodExecution() returns before invoking application code in all
>>>> other cases (step 1 for unauthorized access, step 3 for validation
>>>>
>>> errors).
>>>
>>>> Any chance to have it fixed relatively soon? (maybe Andrea can answer
>>>>
>>> this)
>>>
>>>> Kind regards,
>>>> Fabio
>>>>
>>>> On Thu, Apr 28, 2016 at 6:44 AM, Martin Grigorov <mgrigo...@apache.org>
>>>> wrote:
>>>>
>>>> Hi,
>>>>>
>>>>>
>>>>> On Wed, Apr 27, 2016 at 12:07 PM, Fabio Fioretti <
>>>>> windom.macroso...@gmail.com> wrote:
>>>>>
>>>>> Hi all,
>>>>>>
>>>>>> Please consider the following simple implementation of
>>>>>>
>>>>> AbstractRestResource
>>>>>
>>>>>> (6.22.0):
>>>>>>
>>>>>> @ResourcePath("/rest/api")
>>>>>> public class MyRestResource extends
>>>>>> AbstractRestResource
>>>>>> {
>>>>>>
>>>>>>   public MyRestResource ()
>>>>>>   {
>>>>>>super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial()));
>>>>>>   }
>>>>>>
>>>>>>   @MethodMapping(value = "/offices")
>>>>>>   public List findOffices(
>>>>>> @RequestParam(value = "region", required = false) Integer
>>>>>>
>>>>> regionId)
>>>
>>>>   {
>>>>>>return findOfficesByRegion(regionId);
>>>>>>   }
>>>>>> }
>>>>>>
>>>>>> My question relates to the findOffices method and its filtering
>>>>>>
>>>>> regionId
>>>>
>>>>> parameter when the value is not a valid integer. For example,
>>>>>>
>>>>> consider
>>>
>>>> the
>>>>>
>>>>>> request 'GET /rest/api/offices?region=AA'.
>>>>>>
>>>>>> At the second step of AbstractRestResource.handleMethodExecution,
>>>>>> extractMethodParameters is invoked, which in turn triggers the
>>>>>>
>>>>> conversion
>>>>
>>>>> of all parameters through the static method toObject.
>>>>>>
>>>>>> When the conversion goes wrong and ConversionException is thrown,
>>>>>>
>>>>> toObject
>>>>>
>>>>>> catches it, sets the response status to 400 and returns null!
>>>>>>
>>>>>> Now, when my findOffices is finally executed, I get a null regionId
>>>>>>
>>>>> but I
>>>>
>>>>> don't know whether it was not valid or the parameter was not present
>>>>>>
>>>>> at
>>>
>>>> all. Checking the response status downstream is also particularly
>>>>>>
>>>>> hard
>>>
>>>> because I have no getStatus (Tomcat 6 here, ouch!).
>>>>>>
>>>>>> To my mind, findOffices should return null instead of the unfiltered
>>>>>>
>>>>> list
>>>>
>>>>> of offices if the conversion went wrong, even because the response
>>>>>> status is 400 (as set by toObject). However, how can I know it?
>>>>>>
>>>>>> Any suggestions?
>>>>>>
>>>>>> IMO this is a bug in the library.
>>>>> #findOffices() should not be executed at all.
>>>>> A response with status code 400 should be returned immediately after
>>>>>
>>>> the
>>>
>>>> unsuccessful convention without giving a chance to the application code
>>>>>
>>>> to
>>>>
>>>>> be executed.
>>>>>
>>>>> Many thanks,
>>>>>> Fabio
>>>>>>
>>>>>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.

2016-04-28 Thread Fabio Fioretti
Done: https://github.com/wicketstuff/core/issues/490

Many thanks,
Fabio

On Thu, Apr 28, 2016 at 11:03 AM, Martin Grigorov <martin.grigo...@gmail.com
> wrote:

> Please file an issue at Wicketstuff GibHub.
> On Apr 28, 2016 10:31 AM, "Fabio Fioretti" <windom.macroso...@gmail.com>
> wrote:
>
> > Hi Martin,
> >
> > Thanks, I agree - findOffices() shouldn't be executed at all. In fact,
> > handleMethodExecution() returns before invoking application code in all
> > other cases (step 1 for unauthorized access, step 3 for validation
> errors).
> >
> > Any chance to have it fixed relatively soon? (maybe Andrea can answer
> this)
> >
> > Kind regards,
> > Fabio
> >
> > On Thu, Apr 28, 2016 at 6:44 AM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > >
> > > On Wed, Apr 27, 2016 at 12:07 PM, Fabio Fioretti <
> > > windom.macroso...@gmail.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > Please consider the following simple implementation of
> > > AbstractRestResource
> > > > (6.22.0):
> > > >
> > > > @ResourcePath("/rest/api")
> > > > public class MyRestResource extends
> > > > AbstractRestResource
> > > > {
> > > >
> > > >  public MyRestResource ()
> > > >  {
> > > >   super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial()));
> > > >  }
> > > >
> > > >  @MethodMapping(value = "/offices")
> > > >  public List findOffices(
> > > >@RequestParam(value = "region", required = false) Integer
> regionId)
> > > >  {
> > > >   return findOfficesByRegion(regionId);
> > > >  }
> > > > }
> > > >
> > > > My question relates to the findOffices method and its filtering
> > regionId
> > > > parameter when the value is not a valid integer. For example,
> consider
> > > the
> > > > request 'GET /rest/api/offices?region=AA'.
> > > >
> > > > At the second step of AbstractRestResource.handleMethodExecution,
> > > > extractMethodParameters is invoked, which in turn triggers the
> > conversion
> > > > of all parameters through the static method toObject.
> > > >
> > > > When the conversion goes wrong and ConversionException is thrown,
> > > toObject
> > > > catches it, sets the response status to 400 and returns null!
> > > >
> > > > Now, when my findOffices is finally executed, I get a null regionId
> > but I
> > > > don't know whether it was not valid or the parameter was not present
> at
> > > > all. Checking the response status downstream is also particularly
> hard
> > > > because I have no getStatus (Tomcat 6 here, ouch!).
> > > >
> > > > To my mind, findOffices should return null instead of the unfiltered
> > list
> > > > of offices if the conversion went wrong, even because the response
> > > > status is 400 (as set by toObject). However, how can I know it?
> > > >
> > > > Any suggestions?
> > > >
> > >
> > > IMO this is a bug in the library.
> > > #findOffices() should not be executed at all.
> > > A response with status code 400 should be returned immediately after
> the
> > > unsuccessful convention without giving a chance to the application code
> > to
> > > be executed.
> > >
> > > >
> > > > Many thanks,
> > > > Fabio
> > > >
> > >
> >
>


Re: [wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.

2016-04-28 Thread Fabio Fioretti
Hi Martin,

Thanks, I agree - findOffices() shouldn't be executed at all. In fact,
handleMethodExecution() returns before invoking application code in all
other cases (step 1 for unauthorized access, step 3 for validation errors).

Any chance to have it fixed relatively soon? (maybe Andrea can answer this)

Kind regards,
Fabio

On Thu, Apr 28, 2016 at 6:44 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
>
> On Wed, Apr 27, 2016 at 12:07 PM, Fabio Fioretti <
> windom.macroso...@gmail.com> wrote:
>
> > Hi all,
> >
> > Please consider the following simple implementation of
> AbstractRestResource
> > (6.22.0):
> >
> > @ResourcePath("/rest/api")
> > public class MyRestResource extends
> > AbstractRestResource
> > {
> >
> >  public MyRestResource ()
> >  {
> >   super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial()));
> >  }
> >
> >  @MethodMapping(value = "/offices")
> >  public List findOffices(
> >@RequestParam(value = "region", required = false) Integer regionId)
> >  {
> >   return findOfficesByRegion(regionId);
> >  }
> > }
> >
> > My question relates to the findOffices method and its filtering regionId
> > parameter when the value is not a valid integer. For example, consider
> the
> > request 'GET /rest/api/offices?region=AA'.
> >
> > At the second step of AbstractRestResource.handleMethodExecution,
> > extractMethodParameters is invoked, which in turn triggers the conversion
> > of all parameters through the static method toObject.
> >
> > When the conversion goes wrong and ConversionException is thrown,
> toObject
> > catches it, sets the response status to 400 and returns null!
> >
> > Now, when my findOffices is finally executed, I get a null regionId but I
> > don't know whether it was not valid or the parameter was not present at
> > all. Checking the response status downstream is also particularly hard
> > because I have no getStatus (Tomcat 6 here, ouch!).
> >
> > To my mind, findOffices should return null instead of the unfiltered list
> > of offices if the conversion went wrong, even because the response
> > status is 400 (as set by toObject). However, how can I know it?
> >
> > Any suggestions?
> >
>
> IMO this is a bug in the library.
> #findOffices() should not be executed at all.
> A response with status code 400 should be returned immediately after the
> unsuccessful convention without giving a chance to the application code to
> be executed.
>
> >
> > Many thanks,
> > Fabio
> >
>


[wicketstuff-restannotations] AbstractRestResource.toObject makes it impossible for mapped methods to know a parameter conversion went wrong.

2016-04-27 Thread Fabio Fioretti
Hi all,

Please consider the following simple implementation of AbstractRestResource
(6.22.0):

@ResourcePath("/rest/api")
public class MyRestResource extends
AbstractRestResource
{

 public MyRestResource ()
 {
  super(new JsonWebSerialDeserial(new GsonObjectSerialDeserial()));
 }

 @MethodMapping(value = "/offices")
 public List findOffices(
   @RequestParam(value = "region", required = false) Integer regionId)
 {
  return findOfficesByRegion(regionId);
 }
}

My question relates to the findOffices method and its filtering regionId
parameter when the value is not a valid integer. For example, consider the
request 'GET /rest/api/offices?region=AA'.

At the second step of AbstractRestResource.handleMethodExecution,
extractMethodParameters is invoked, which in turn triggers the conversion
of all parameters through the static method toObject.

When the conversion goes wrong and ConversionException is thrown, toObject
catches it, sets the response status to 400 and returns null!

Now, when my findOffices is finally executed, I get a null regionId but I
don't know whether it was not valid or the parameter was not present at
all. Checking the response status downstream is also particularly hard
because I have no getStatus (Tomcat 6 here, ouch!).

To my mind, findOffices should return null instead of the unfiltered list
of offices if the conversion went wrong, even because the response
status is 400 (as set by toObject). However, how can I know it?

Any suggestions?

Many thanks,
Fabio


Re: [wicketstuff-restannotations] How to automatically generate Swagger definitions.

2016-04-27 Thread Fabio Fioretti
Hi Andrea,

Thanks anyway. No big deal in doing it manually with the Swagger editor for
me, but having some kind of built-in automation would be great for large
APIs.

By the way, I have another question more strictly related to
restannotations, for which I am going to start another thread.

Kind regards,
Fabio

On Tue, Apr 26, 2016 at 10:19 PM, Andrea Del Bene <an.delb...@gmail.com>
wrote:

> Hi,
>
> at the moment we don't have such kind of integration with Swagger. You may
> obtain some results if you use Spring in your application:
> https://dzone.com/articles/swagger-make-developers-love.
> However I've never tried this kind of solution.
>
>
> On 25/04/2016 16:08, Fabio Fioretti wrote:
>
>> Hi all,
>>
>> I have been successfully using wicketstuff-restannotations to create some
>> REST web services in my Wicket 6.22.0 application - thanks for that, very
>> straightforward.
>>
>> Now that my REST resources and methods are complete and correctly
>> annotated, I would need to generate the related Swagger definitions.
>>
>> Is there an easy way to do so?
>>
>> Many thanks,
>> Fabio
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


[wicketstuff-restannotations] How to automatically generate Swagger definitions.

2016-04-25 Thread Fabio Fioretti
Hi all,

I have been successfully using wicketstuff-restannotations to create some
REST web services in my Wicket 6.22.0 application - thanks for that, very
straightforward.

Now that my REST resources and methods are complete and correctly
annotated, I would need to generate the related Swagger definitions.

Is there an easy way to do so?

Many thanks,
Fabio


Re: Backward compatibility with URLs generated by HybridUrlCodingStrategy.

2014-06-12 Thread Fabio Fioretti
Many thanks Martin,

I followed your advice and ended up overriding SystemMapper's mapRequest. I
decided to simply strip away the page instance instead of moving it to the
query string. It's just noise for me, after all. Quite rough probably, but
it seems to do the job in all the cases I tried.

Do you foresee any problem with this piece of code? I'm not really
confident the way to identify the page instance is correct, and I'm afraid
it could add too much overhead (note: isNumber is implemented using
Character.isDigit, as suggested here:
http://jdevelopment.nl/efficient-determine-string-number/).

setRootRequestMapper(*new* SystemMapper(*this*) {

@Override

 *public* IRequestHandler mapRequest(Request request) {

*final* Url url = request.getUrl();

*final* String lastSegment = !url.getSegments().isEmpty() ?
url.getSegments().get(url.getSegments().size() - 1) : *null*;

*if* (lastSegment != *null*  lastSegment.contains(.)) {

*final* String presumedPageInstance =
lastSegment.substring(lastSegment.lastIndexOf(.) + 1);

*if* (isNumber(presumedPageInstance)) {

// If it's a number, assume it's the page Id and strip it from the request
URL.

*final* String cleanedUpLastSegment = lastSegment.substring(0,
lastSegment.lastIndexOf(.));

url.getSegments().set(url.getSegments().size() - 1, cleanedUpLastSegment);

*return* *super*.mapRequest(request.cloneWithUrl(url));

}

 }

*return* *super*.mapRequest(request);

 }

});


Many thanks,
Fabio


On Wed, Jun 11, 2014 at 2:12 PM, Martin Grigorov mgrigo...@apache.org
wrote:

 Hi Fabio,

 You can create your own root request mapper that when detecting an old url
 can either :
 1) return a redirect with code 301 (Moved permanently)
 2) just move the page id from the last segment to the query string
 silently

 Martin Grigorov
 Wicket Training and Consulting


 On Wed, Jun 11, 2014 at 1:00 PM, Fabio Fioretti 
 windom.macroso...@gmail.com
  wrote:

  Hi all,
 
  I am migrating an application from Wicket 1.4 to 6.15. This app makes use
  of HybridUrlCodingStrategy, that I replaced with a MountedMapped using
  UrlPathPageParametersEncoder.
 
  The problem is that many users have old bookmarks of URLs generated by
  HybridUrlCodingStrategy, in which the page instance number comes after a
  dot, like in the following example:
 
  http://myapp.com/mount/path/param/value.4
 
  Now, with MountedMapper and UrlPathPageParametersEncoder, the same URL
  looks like this (mind the ? replacing the .):
 
  http://myapp.com/mount/path/param/value?4
 
  The result is that the old dotted bookmarks do not work anymore (HTTP
 404).
 
  Any suggestion on the best approach to guarantee backward compatibility
  with old URLs?
 
  Thanks very much in advance,
  Fabio Fioretti
 



Re: Backward compatibility with URLs generated by HybridUrlCodingStrategy.

2014-06-12 Thread Fabio Fioretti
Hi Martin,

Thanks for your time and help.

Even though my 1.4 URLs contain pageIds, in the moment they were bookmarked
they were basically made stateless to my application, as the pageId lost
meaning. It is now just noise that gets misinterpreted by the migrated app
because of the dotted notation. All I wanted to achieve is to make them
work in Wicket 6.x and, to do that, it is sufficient to strip the
bookmarked pageId away and let Wicket reassign a new one with the proper
encoding (? instead of .).

Kind regards,
Fabio


On Thu, Jun 12, 2014 at 2:54 PM, Martin Grigorov mgrigo...@apache.org
wrote:

 Hi Fabio,

 The code looks OK!

 Indeed it is not very easy to create really bookmarkable url!
 The page has to be stateless to have url that will produce the same result
 every time.
 With stateful pages (pages with pageId in their url) there is a chance to
 load something different than what you expect ... but all this is known.
 You can search the mail archives for NoVersionRequestMapper to workaround
 this. But it will lead to different kind of problems.

 Martin Grigorov
 Wicket Training and Consulting


 On Thu, Jun 12, 2014 at 2:19 PM, Fabio Fioretti 
 windom.macroso...@gmail.com
  wrote:

  Many thanks Martin,
 
  I followed your advice and ended up overriding SystemMapper's
 mapRequest. I
  decided to simply strip away the page instance instead of moving it to
 the
  query string. It's just noise for me, after all. Quite rough probably,
 but
  it seems to do the job in all the cases I tried.
 
  Do you foresee any problem with this piece of code? I'm not really
  confident the way to identify the page instance is correct, and I'm
 afraid
  it could add too much overhead (note: isNumber is implemented using
  Character.isDigit, as suggested here:
  http://jdevelopment.nl/efficient-determine-string-number/).
 
  setRootRequestMapper(*new* SystemMapper(*this*) {
 
  @Override
 
   *public* IRequestHandler mapRequest(Request request) {
 
  *final* Url url = request.getUrl();
 
  *final* String lastSegment = !url.getSegments().isEmpty() ?
  url.getSegments().get(url.getSegments().size() - 1) : *null*;
 
  *if* (lastSegment != *null*  lastSegment.contains(.)) {
 
  *final* String presumedPageInstance =
  lastSegment.substring(lastSegment.lastIndexOf(.) + 1);
 
  *if* (isNumber(presumedPageInstance)) {
 
  // If it's a number, assume it's the page Id and strip it from the
 request
  URL.
 
  *final* String cleanedUpLastSegment = lastSegment.substring(0,
  lastSegment.lastIndexOf(.));
 
  url.getSegments().set(url.getSegments().size() - 1,
 cleanedUpLastSegment);
 
  *return* *super*.mapRequest(request.cloneWithUrl(url));
 
  }
 
   }
 
  *return* *super*.mapRequest(request);
 
   }
 
  });
 
 
  Many thanks,
  Fabio
 
 
  On Wed, Jun 11, 2014 at 2:12 PM, Martin Grigorov mgrigo...@apache.org
  wrote:
 
   Hi Fabio,
  
   You can create your own root request mapper that when detecting an old
  url
   can either :
   1) return a redirect with code 301 (Moved permanently)
   2) just move the page id from the last segment to the query string
   silently
  
   Martin Grigorov
   Wicket Training and Consulting
  
  
   On Wed, Jun 11, 2014 at 1:00 PM, Fabio Fioretti 
   windom.macroso...@gmail.com
wrote:
  
Hi all,
   
I am migrating an application from Wicket 1.4 to 6.15. This app makes
  use
of HybridUrlCodingStrategy, that I replaced with a MountedMapped
 using
UrlPathPageParametersEncoder.
   
The problem is that many users have old bookmarks of URLs generated
 by
HybridUrlCodingStrategy, in which the page instance number comes
 after
  a
dot, like in the following example:
   
http://myapp.com/mount/path/param/value.4
   
Now, with MountedMapper and UrlPathPageParametersEncoder, the same
 URL
looks like this (mind the ? replacing the .):
   
http://myapp.com/mount/path/param/value?4
   
The result is that the old dotted bookmarks do not work anymore (HTTP
   404).
   
Any suggestion on the best approach to guarantee backward
 compatibility
with old URLs?
   
Thanks very much in advance,
Fabio Fioretti
   
  
 



Backward compatibility with URLs generated by HybridUrlCodingStrategy.

2014-06-11 Thread Fabio Fioretti
Hi all,

I am migrating an application from Wicket 1.4 to 6.15. This app makes use
of HybridUrlCodingStrategy, that I replaced with a MountedMapped using
UrlPathPageParametersEncoder.

The problem is that many users have old bookmarks of URLs generated by
HybridUrlCodingStrategy, in which the page instance number comes after a
dot, like in the following example:

http://myapp.com/mount/path/param/value.4

Now, with MountedMapper and UrlPathPageParametersEncoder, the same URL
looks like this (mind the ? replacing the .):

http://myapp.com/mount/path/param/value?4

The result is that the old dotted bookmarks do not work anymore (HTTP 404).

Any suggestion on the best approach to guarantee backward compatibility
with old URLs?

Thanks very much in advance,
Fabio Fioretti


CachingResourceStreamLocator is not extension-aware.

2014-05-06 Thread Fabio Fioretti
Hi all,

I have a Wicket 6 application that integrates with Apache FOP in a way
that, by overriding Page's getMarkupType(), I can have a component render
its .fo markup (to generate a PDF) instead of the usual html, depending on
whether it is added to a Page with the fo MarkupType or the standard html
one.

This means my typical Panel has two markup files, an html one and a fo one:
Panel.fo and Panel.html.

Now, the default CashingResourceStreamLocator makes use of
ResourceReference#Key for the cache. That Key completely ignores the
extension of the file or, better, assumes it is part of the name, while for
markup files this is apparently not the case. Basically, Panel.html and
Panel.fo have the same Key, the name of which is simply Panel.

Therefore, when a Panel is first rendered in html, its html markup
reference is cached and there is no way to make it render again in fo,
because the cache will always return the html markup reference.

The solution is not dramatic but makes me feel uncomfortable: I had to
write a custom CashingResourceStreamLocator clone, using a custom Key that
is basically a ResourceReference#Key with an added extension property.

What am I missing here?

Thanks very much for you help and keep up the excellent work,
Fabio Fioretti


Re: CachingResourceStreamLocator is not extension-aware.

2014-05-06 Thread Fabio Fioretti
Hi Martin,

I have just created a ticket:
https://issues.apache.org/jira/browse/WICKET-5581
Thanks for taking it into consideration.

Overriding #getVariation() works well but it is, as you say, a workaround.

I look forward to having CachingRes​ourceStrea​mLocator improved.

Thanks again,
Fabio



On Tue, May 6, 2014 at 12:51 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 Hi,

 Please file a ticket at https://issues.apache.org/jira/browse/WICKET and
 we
 will improve it.
 As a workaround you can override #getVariation() for the pages and return
 html and fo respectively.

 Martin Grigorov
 Wicket Training and Consulting


 On Tue, May 6, 2014 at 11:39 AM, Fabio Fioretti 
 windom.macroso...@gmail.com
  wrote:

  Hi all,
 
  I have a Wicket 6 application that integrates with Apache FOP in a way
  that, by overriding Page's getMarkupType(), I can have a component render
  its .fo markup (to generate a PDF) instead of the usual html, depending
 on
  whether it is added to a Page with the fo MarkupType or the standard html
  one.
 
  This means my typical Panel has two markup files, an html one and a fo
 one:
  Panel.fo and Panel.html.
 
  Now, the default CashingResourceStreamLocator makes use of
  ResourceReference#Key for the cache. That Key completely ignores the
  extension of the file or, better, assumes it is part of the name, while
 for
  markup files this is apparently not the case. Basically, Panel.html and
  Panel.fo have the same Key, the name of which is simply Panel.
 
  Therefore, when a Panel is first rendered in html, its html markup
  reference is cached and there is no way to make it render again in fo,
  because the cache will always return the html markup reference.
 
  The solution is not dramatic but makes me feel uncomfortable: I had to
  write a custom CashingResourceStreamLocator clone, using a custom Key
 that
  is basically a ResourceReference#Key with an added extension property.
 
  What am I missing here?
 
  Thanks very much for you help and keep up the excellent work,
  Fabio Fioretti
 



Re: wicket and ext-js

2010-10-08 Thread Fabio Fioretti
Hi Frank,

Sorry for the late reply. We are currently migrating our main
application from Wicket 1.3 to 1.4 and contextually upgrading
ext-wicket. This might eventually be the right occasion to update the
project, though we are still targetting Ext 2.2.

With regard to behaviors and components, we felt it was useful to keep
them separate in spite of a small overhead, as it is always easy to
merge them but much more complicated to extract a behavior from a
component. Anyway, ext-wicket was born to help up support Ext-JS
components we found interesting for our applications, and not to
provide a clean and complete mapping of Ext features into Wicket.
Therefore, its architecture is far from perfect!

Is your integration effort moving forward?

Kind regards,
Fabio


On Wed, Sep 29, 2010 at 4:43 PM, Frank van Lankvelt
f.vanlankv...@onehippo.com wrote:
 hi Fabio,

 good to hear it is in active use and development!  There might be more users
 than you think; perhaps you can get them to voice their enthousiasm.  Might
 help to find the time to publish the changes?

 Concerning your example, some behaviors are definitively offered best as
 actual wicket behaviors.  Tooltips, data stores, other services you need
 from the client.  But I still wonder whether that justifies the overhead,
 considering the large number of components.  Are there other motivations
 like, I could imagine, needing to subclass the FormComponent to be able to
 participate in form processing?

 thanks, Frank

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



Re: wicket and ext-js

2010-09-29 Thread Fabio Fioretti
Hi,

I am one of the developers behind wicket-ext.

The project hasn't been updated lately even though it is still used,
maintained and developed behind closed doors. We stopped updating it
both because of lack of public interest (we have received only few
external contributions) and because of the fact that the Ext-JS
components we found most useful for our applications are already
supported (i.e. we currently have no real interest in driving the
endeavour further). In addition, we had no time to clean-up the latest
code to the extent of releasing it publicly.

I can say that the integration was quite straightforward and Wicket
proved to work very well with Ext-JS; in particular, we found grid
components (GridPanel, GroupingView, etc.) extremely useful.

The separation of Behaviors and Components hierarchies was a design
decision rooted in flexibility and actually inspired by Wicket: we
wanted to allow the application of Ext behaviors to standard Wicket
components. Just to give an example, think of a PersistentTip applied
to a Wicket TextField through a simple textField.add(new
ExtBaloonBehavior(model)). Why would you need a custom TextField for
that?

Good luck for your integration effort and, should you decide to build
on top of wicket-ext, feel free to ask.


Cheers,

Fabio Fioretti


On Wed, Sep 29, 2010 at 12:09 PM, Frank van Lankvelt
f.vanlankv...@onehippo.com wrote:
 I'm in the process of integrating Ext-JS into our Wicket application.   So
 there are a number of questions, such as:
 What are your experiences of using wicket and ext together?
 Do these projects help at all, or do you rather roll a custom behavior each
 time?
 Is there some project that is not indexed by Google (see below)?
 Are there some fundamental problems one runs into when building more complex
 UIs?

 I found two projects that provide an integration;
 - wicket-ext at http://code.google.com/p/wicket-ext/
 - wicket-extjs-integration
 http://code.google.com/p/wicket-extjs-integration/
 Neither of these is very active, but I'm hoping that some of you have
 experience with them.

 The wicket-ext project has lots of widgets already integrated, but I don't
 really understand the reason for creating two hierarchies; one of Components
 and one of Behaviors.  It seems to me that mapping ext components onto
 wicket components should be sufficient; behaviors can then be added to
 provide services to the client-side code.

 The wicket-extjs-integration project is in its infancy, but has a lot of
 potential; it maps ext components directly onto wicket components, has been
 explicitly designed to do composition and even has a nice way of invoking
 ext client-side methods from server-side code.  I also like the
 annotation-based configuration of the client-side components.

 I would like to continue work on the second approach, but would like to get
 some feeling for the task at hand first ;-)

 thanks, Frank


 --
 Hippo
 Europe  •  Amsterdam  Oosteinde 11  •  1017 WT Amsterdam  •  +31 (0)20 522
 4466
 USA  • San Francisco  185 H Street Suite B  •  Petaluma CA 94952-5100 •  +1
 (707) 773 4646
 Canada    •   Montréal  5369 Boulevard St-Laurent #430 •  Montréal QC H2T
 1S5  •  +1 (514) 316 8966
 www.onehippo.com  •  www.onehippo.org  •  i...@onehippo.com


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



Re: [OT] Wicket changed my life !

2010-02-19 Thread Fabio Fioretti
Peter, I completely agree with you. :-) Thanks Wicket!

Fabio

On Fri, Feb 19, 2010 at 9:37 AM, Peter Ertl pe...@gmx.org wrote:
 Wicket put the suck out of web development for me :-)

 Am 19.02.2010 um 08:14 schrieb Josh Kamau:

 Me too!!

 On Fri, Feb 19, 2010 at 9:57 AM, Ashika Umanga Umagiliya 
 auma...@biggjapan.com wrote:

 I love Wicket !

 -
 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: Switch tab only if user doesn't want to save changes.

2009-03-15 Thread Fabio Fioretti
On Wed, Mar 11, 2009 at 6:30 PM, jchappelle jchappe...@4redi.com wrote:

 Could you post how you are detecting unsaved changes? I am trying to
 implement something similar.

Hi Josh,
it depends on the kind of data you are dealing with, but basically it
is just a matter of keeping the initial model object values somewhere
and comparing them with the new ones resulting from form updating by
the user.

Regards,

Fabio Fioretti - WindoM

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



Re: [OT] wicket users around the world

2008-12-11 Thread Fabio Fioretti
Rome, Italy! :)

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



Re: Switch tab only if user doesn't want to save changes.

2008-07-15 Thread Fabio Fioretti
Thank you Maurice,

what you suggested matched the way I was trying to solve the problem,
but I had to add a bit of client-side logic to decide whether to
display the confirm dialog or not, basing the decision on the
enabled/disabled status of the save button inside the first tab, which
already implemented the logic to detect unsaved changes.

I paste the relevant bits to share my solution with you all. Probably
it's not optimal at all, so please do feel free to
comment/correct/laugh. :)

@Override
protected IAjaxCallDecorator getAjaxCallDecorator() {
// Add custom decorator for tabs other than the one containing 
detailsPanel
if ( index != 0 ) {
return new AjaxCallDecorator() {
@Override
public CharSequence decorateScript( CharSequence script 
) {
// Ask for user confirmation, as tab-switching 
discards unsaved changes.
final String saveButton = detailsPanel != null ?
detailsPanel.getSaveButtonMarkupId() : ;
final StringBuffer decoration = new 
StringBuffer();
return decoration.append(String.format(if(
document.getElementById('%s')!= null , saveButton))
  .append(String.format(
!document.getElementById('%s').disabled , saveButton))
  .append( !confirm('Please note that 
unsaved changes will be
lost.\\n\\nDo you want to switch tab?')) )
  .append({ return false; })
  .append(script);
}
};
}
return super.getAjaxCallDecorator();
}


Cheers,

Fabio Fioretti - WindoM


On Sun, Jul 13, 2008 at 9:43 PM, Maurice Marrink [EMAIL PROTECTED] wrote:
 Override newLink to return an ajaxfallbacklink where you have
 overridden the getAjaxCallDecorator method to return a custom
 IAjaxCallDecorator.
 Use that to insert a javascript confirm dialog.

 Maurice

 On Fri, Jul 11, 2008 at 7:28 PM, Fabio Fioretti
 [EMAIL PROTECTED] wrote:
 Hi all,

 thanks in advance for your precious support.

 I have an AjaxTabbedPanel with two tabs. In the first tab there is a
 panel with a form, some input fields and a save button; the content of
 the second tab is irrelevant.

 Use-case:

 1 - user selects first tab;
 2 - user makes some changes in the input fields but doesn't click the
 save button;
 3 - user selects second tab.

 On step 3, users loses all his updates without being warned.

 I would like to add a javascript confirm dialog to be triggered only
 when some changes have been performed but not saved (no ModalWindow,
 just javascript). I mean something like: There are some unsaved
 changes that will be lost, do you really want to switch tab? OK
 Cancel. OK brings the user to the second tab, Cancel makes him stay
 in the first tab.

 The panel inside the first tab has a handy boolean hasUnsavedChanges()
 method, but I don't know where I could call it and how to inject an
 if (!confirm('...')) return false;.

 Maybe in the onClick(AjaxRequestTarget target) method of the
 AjaxFallbackLink returned by AjaxTabbedPanel's newLink() method?

 What's the best way to do it?


 Thank you very much,

 Fabio Fioretti - WindoM

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Switch tab only if user doesn't want to save changes.

2008-07-11 Thread Fabio Fioretti
Hi all,

thanks in advance for your precious support.

I have an AjaxTabbedPanel with two tabs. In the first tab there is a
panel with a form, some input fields and a save button; the content of
the second tab is irrelevant.

Use-case:

1 - user selects first tab;
2 - user makes some changes in the input fields but doesn't click the
save button;
3 - user selects second tab.

On step 3, users loses all his updates without being warned.

I would like to add a javascript confirm dialog to be triggered only
when some changes have been performed but not saved (no ModalWindow,
just javascript). I mean something like: There are some unsaved
changes that will be lost, do you really want to switch tab? OK
Cancel. OK brings the user to the second tab, Cancel makes him stay
in the first tab.

The panel inside the first tab has a handy boolean hasUnsavedChanges()
method, but I don't know where I could call it and how to inject an
if (!confirm('...')) return false;.

Maybe in the onClick(AjaxRequestTarget target) method of the
AjaxFallbackLink returned by AjaxTabbedPanel's newLink() method?

What's the best way to do it?


Thank you very much,

Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[Wicket 1.3.3] Possible wicket:enclosure regression.

2008-04-03 Thread Fabio Fioretti
Hi All,

I'm experiencing a possible regression for wicket:enclosure in Wicket
1.3.3 (maybe related to the couple of patches that involved enclosures
for 1.3.3). It thought of a regression because the following code
works just fine in 1.3.1, even if I haven't tested it in 1.3.2.

Basically, I have a RadioGroup with a couple of options. When the user
selects the second option, a text field and link (wrapped in an
enclosure) should appear next to the option. If she/he selects the
first option, they should disappear again. Their visibility management
is based on the enclosure.

wicket:extend
form wicket:id=form
span wicket:id=radioGroup

input wicket:id=radioOne type=radio value=U
span onclick=event.cancelBubble = true;Set OPTION ONE
br/
/span

   input wicket:id=radioTwo type=radio value=P/
   span onclick=event.cancelBubble = true;Set OPTION TWO
   wicket:enclosure child=textField
   input wicket:id=textField type=text/
   a wicket:id=linklink/a
   /wicket:enclosure
   br/
/span

/span
input type=button wicket:id=submitButton/
/form
/wicket:extend


On the Java side, the relevant code looks like this (feel free to ask
for further details):

radioGroup.add(new AjaxFormRadioUpdatingBehavior(onclick){
@Override
protected void onUpdate(AjaxRequestTarget target) {
if (OPTION_ONE.equals(getSelectedOption())) {
textField.setVisible(true);
} else {
textField.setVisible(false);
}
   target.addComponent(radioGroup);
}
});

As you can see, I set the visibility of the textField depending on the
selected option and then update the container (the radioGroup). Again,
it worked fine in 1.3.1.

Is anybody aware of this or has anyone else experienced the same
change in enclosure functioning from Wicket 1.3.1 to 1.3.3?


Thank you very much and keep up the good work!

Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [vote] Release 1.4 with only generics and stop support for 1.3

2008-03-18 Thread Fabio Fioretti
+1.

Best regards,

Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Trigger ajax-form submit when changing tabs

2008-01-17 Thread Fabio Fioretti
If I understand your problem correctly, you could override the
newLink() method of the AjaxTabbedPanel to return an AjaxSubmitLink
instead. Something like the following:

tabPanel = new AjaxTabbedPanel(tabs, tabs){
@Override
protected WebMarkupContainer newLink(String linkId, final int index) {
return new AjaxSubmitLink(linkId, yourForm) {
@Override
protected void onSubmit(AjaxRequestTarget target, Form form) {
setSelectedTab(index);
if (target != null) {
target.addComponent(tabPanel);
}
onAjaxUpdate(target);
}

@Override
protected void onError(AjaxRequestTarget target, Form form){
AjaxUtils.error(form);
}
};
}
};


Disclaimer: the code above is based on Wicket 1.2.6.


Cheers,

Fabio Fioretti - WindoM


On Jan 17, 2008 1:21 PM, Steffen Fritzsche [EMAIL PROTECTED] wrote:
 Hi,

 I have the following problem. I created a three individual forms each
 within its own Tab (implementing AbstractTab). Each is submitted via
 ajax according to the Ajax-FormPage example. All forms are backed by the
 same Model-Object representing a simple Product wrapped in a
 BoundCompoundPropertyModel.

 On the surrounding page I have a forth form just with a submit button.
 This form refers to the same Product-Object and when the button is
 clicked it performs some action cleans up my Product Object and persists
 it via JPA.

 This is working so far, but currently I have to hit my ajax-submit
 button always before switching between each of the three real forms
 using the tabs.

 Is there an elagant solution to trigger this ajax submit and validating
 the form elements of the currently active form when the user clicks on
 one of the other form-tabs. So that I do not need a visible ajax-submit
 button anymore ...

 Steffen


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: the flow of wicket

2008-01-14 Thread Fabio Fioretti
On Jan 14, 2008 1:35 AM, Eelco Hillenius [EMAIL PROTECTED] wrote:
   Documenting Wicket's inner implementations and strategies, beyond its
   API, is desirable and a huge plus for hardcore developers.
 
  i wouldnt think hardcore developers would be afraid of setting a
  breakpoint and walking the code. maybe one of them could even create a
  wiki page - open source and all that.

 Yup. Please anyone, take the initiative and write a WIKI page. That's
 more constructive than complaining about it here :-) Good if it is
 done by someone outside anyway, because that someone won't make the
 assumptions we probably would make. We'll be happy to review.

Fine, this can be a good compromise: documentation written by the
skilled community and reviewed by the developers themselves. I'm not
that hardcore now, but the more I get into Wicket, the more I'll try
to help out as much as I can.


Thanks,

Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: the flow of wicket

2008-01-14 Thread Fabio Fioretti
On Jan 14, 2008 1:00 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
 easy to say when its not you who has to put in the huge effort :)

I'm just a humble junior developer. :)


Regards,

Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: the flow of wicket

2008-01-13 Thread Fabio Fioretti
On Jan 12, 2008 8:56 PM, Dmitry Kandalov [EMAIL PROTECTED] wrote:
 On the whole I think it's the matter of knowing the big picture and not using
 framework as a black box.

Exactly. For knowledge's sake.

Documenting Wicket's inner implementations and strategies, beyond its
API, is desirable and a huge plus for hardcore developers. Sure, we
could study the code, but it can lead to bad assumptions if it's not
coupled with some sort of high-level, even gross-grained,
documentation.

So, +1 for Paolo, even if I understand that the documentation effort
can become huge.


Cheers,

Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Wicket 1.2.6] How to get Wizard's form from inside a WizardStep?

2008-01-07 Thread Fabio Fioretti
Thanks everybody for the precious help, a custom lazy
AjaxFormSubmitBehavior was the way to go.


Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[Wicket 1.2.6] How to get Wizard's form from inside a WizardStep?

2008-01-04 Thread Fabio Fioretti
First of all, many compliments for the great Wicket 1.3 release: we're
looking forward to port our application to the new cool version!

How can I get the Wizard's form from inside a WizardStep? I need it to
trigger an AjaxSubmitLink which should update a part of my model while
remaining inside that step. What leaves me clueless is the fact that
WizardStep instances are added to the WizardModel instead of the
Wizard, so doing something like this from inside the WizardStep:

Form form = (Form)WizardStep.this.findParent(Form.class);

seems to return null; moreover, this makes me wonder how the same
instruction inside WizardStep.AddFormValidatorAction.execute() can
succeed.

I'm sure I'm missing something really stupid. Please forgive me. :-)


Thanks a lot,

Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Keep inserted data on AjaxTabbedPanel tab switching.

2007-11-14 Thread Fabio Fioretti
Hi,
this is how I implemented it:

tabPanel = new AjaxTabbedPanel(tabs, tabs){
@Override
protected WebMarkupContainer newLink(String linkId, final int index) {
return new AjaxSubmitLink(linkId, candidateForm) {
private static final long serialVersionUID = 1L;

@Override
protected void onSubmit(AjaxRequestTarget target, Form form) {
setSelectedTab(index);
if (target != null) {
target.addComponent(tabPanel);
}
onAjaxUpdate(target);
}

@Override
protected void onError(AjaxRequestTarget target, Form form){
AjaxUtils.error(form);
}
};
}
};


Kindest regards,

Fabio Fioretti - WindoM


On Nov 14, 2007 1:18 PM, lizz [EMAIL PROTECTED] wrote:

 Hi,
 I tried implementing the submitLink but dont really understand what I do
 wrong as I still loose the data.
 Could you provide me with your code in the newlink metthod please...
 I am new to web development so I might have forgotten some obvious stuff ...
 Thanks :-)



 Fabio Fioretti wrote:
 
  On 9/21/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
  you have to override newlink on the tabbedpanel and return a submitlink
  instead
 
  Nice, this worked just fine!
 
  also, really, for situations like this it doesnt make sense to use a
  server-side panel. use client side tabs like what jquery provides instead
  -
  it works much better with forms.
 
  I agree, but this is not the case: I simplified the situation to frame
  the question more easily, but it's more complex in reality.
 
 
  Thanks a lot for your precious help,
 
  Fabio Fioretti - WindoM
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

 --
 View this message in context: 
 http://www.nabble.com/Keep-inserted-data-on-AjaxTabbedPanel-tab-switching.-tf4493055.html#a13745653
 Sent from the Wicket - User mailing list archive at Nabble.com.



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Weird Ajax non-English characters encoding problem.

2007-10-22 Thread Fabio Fioretti
Hi Matej and Johan,

thanks for your replies.

I'm using Latin1 because the page I'm talking about is part of a
legacy web application fully encoded in ISO-8859-1. The application
server it runs on is Tomcat 5.5, which defaults to Latin1, so it
shouldn't be a problem.

I tried to set the request/response encoding in the application main
class using:

getRequestCycleSettings().setResponseRequestEncoding(ISO-8859-1);

but nothing changed, except that Wicket Ajax Debug now prints:

INFO:
?xml version=1.0 encoding=ISO-8859-1?ajax-response/ajax-response

The problem I'm facing seems the same Stefan Lindner faced last year,
whithout apparently finding a solution. I tried everything he tried.
See link:

http://www.nabble.com/AjaxSubmitButton-and-Umlauts-with-ISO-8859-1-%28Wicket-2%29-tf2622064.html

I could migrate the whole application to UTF-8, but I would't do that
for a single textarea in a single page... :-) It's the only page that
needs non-English input.


Any suggestion?


Thanks a lot,

Fabio Fioretti - WindoM


On 10/21/07, Matej Knopp [EMAIL PROTECTED] wrote:
 I don't know tbh. I believe the request body is encoded in UTF-8.
 People usually use UTF-8, so no-one was complaining before. Can't you
 just use UTF-8? It's much safer than latin1.

 -Matej

 On 10/20/07, Johan Compagner [EMAIL PROTECTED] wrote:
  are you configuring wicket and you appserver correctly?
  in wicket you have to set the encoding you want to use
  why not just use utf8?
  else matej?
  How does the ajax submit work with encoding?
  It is still a normal post and how do we interpret it?
 
 
  On 10/19/07, Fabio Fioretti [EMAIL PROTECTED] wrote:
   Hi all,
  
   thanks in advance for your time and suggestions.
  
   I'm building a really simple page made up of a form with a text area
   and a submit button (instance of Button). An AjaxFormSubmitBehavior
   that performs the save operation is added to the button. The page is
   encoded as follows:
  
   meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1
  
   Everything works fine until a user submits a non-English text (French
   or Spanish, with characters like íéñ, still supported by the
   ISO-8859-1 encoding): all non-English characters are scrambled.
  
   What appears weird to me is that the problem doesn't happen if I use,
   for example, a SubmitLink instead of an Ajax-enabled Button.
  
   This makes me point to Ajax as the responsible, and to the fact that
   Wicket uses UTF-8 for requests... but I really have no clue about how
   to fix it.
  
   Any idea?
  
  
   Thank you very much and have a nice week-end.
  
   Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Weird Ajax non-English characters encoding problem.

2007-10-19 Thread Fabio Fioretti
PS: I'm using Wicket 1.2.6.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Weird Ajax non-English characters encoding problem.

2007-10-19 Thread Fabio Fioretti
Hi all,

thanks in advance for your time and suggestions.

I'm building a really simple page made up of a form with a text area
and a submit button (instance of Button). An AjaxFormSubmitBehavior
that performs the save operation is added to the button. The page is
encoded as follows:

meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1

Everything works fine until a user submits a non-English text (French
or Spanish, with characters like íéñ, still supported by the
ISO-8859-1 encoding): all non-English characters are scrambled.

What appears weird to me is that the problem doesn't happen if I use,
for example, a SubmitLink instead of an Ajax-enabled Button.

This makes me point to Ajax as the responsible, and to the fact that
Wicket uses UTF-8 for requests... but I really have no clue about how
to fix it.

Any idea?


Thank you very much and have a nice week-end.

Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: CompoundPropertyModel stops working when form validation fails.

2007-10-08 Thread Fabio Fioretti
On 10/6/07, Kent Tong [EMAIL PROTECTED] wrote:
 Even though you're not using wantOnSelectionChangedNotifications(),
 what I said applies: you need to call clearInput() like:
[CUT]
 recommendationForm.clearInput(); //THIS LINE IS WHAT YOU NEED

You were right Kent, thanks a lot! Calling clearInput() in the
updating behavior really fixes the problem.

What I miss now is why the CompoundPropertyModel breaks if the form is
not manually reset by calling clearInput(). Is it a bug or a feature?
:)


Thank you for your time and precious help.


Kindest regards,

Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: CompoundPropertyModel stops working when form validation fails.

2007-10-08 Thread Fabio Fioretti
On 10/5/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
  *BUT*, when the user edits one of the recommendations making errors,
  tries to save it and form validation fails, the panel's
  CompoundPropertyModel seems to detach from the underlying
  AbstractModel and, if the user selects another choice on the
  ListChoice, the form is refreshed but it keeps showing data of the
  recommendation instance that failed validation.

 Not sure what this could be. Would you be able to create a test case
 or quickstart project that shows the bug?

Given that calling form.clearInput() inside ListChoice's updating
behavior solves the problem, is it still useful to create a test case
to show CompoundPropertyModel's detachment or is it explainable now?
I'm still missing an explanation, but probably you are not (and in
this case, please share :-).


Thanks a lot,

Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: TabbedPanel with image tabs

2007-10-07 Thread Fabio Fioretti
On 10/7/07, Erik van Oosten [EMAIL PROTECTED] wrote:
 You can override a method on TabbedPanel to create the component that is
 put in the tab.
 I can not look it up now, but can do so later if you want.

The method you are talking about is newLink.


Kindest regards,

Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: CompoundPropertyModel stops working when form validation fails.

2007-10-05 Thread Fabio Fioretti
On 10/5/07, Kent Tong [EMAIL PROTECTED] wrote:

Hello, thanks for your reply.

 I suppose you're using wantOnSelectionChangedNotifications() to trigger
 the refresh?

No, I'm not.

The ListChoice uses the same AbstractModel on which the panel inside
the form builds its CompoundPropertyModel (see my previous posts):
when user's selection changes, the AbstractModel correctly replaces
its object with the newly selected instance and the form gets
refreshed by an AjaxFormComponentUpdatingBehavior (attached to
ListChoice's onclick event) to display the new instance (read from
the same AbstractModel).

Everything works really smooth: the user selects a recommendation from
the list, he edits it, saves it, then he clicks on another
recommendation from the list and edits this other one, and so on.

*BUT*, when the user edits one of the recommendations making errors,
tries to save it and form validation fails, the panel's
CompoundPropertyModel seems to detach from the underlying
AbstractModel and, if the user selects another choice on the
ListChoice, the form is refreshed but it keeps showing data of the
recommendation instance that failed validation.

Any suggestion would be really appreciated, because maybe I'm missing
something about the inner mechanisms of Wicket.


Thank you all for any help,

Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: CompoundPropertyModel stops working when form validation fails.

2007-10-04 Thread Fabio Fioretti
P.S.: I'm using Wicket 1.2.6.


Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



CompoundPropertyModel stops working when form validation fails.

2007-10-03 Thread Fabio Fioretti
Hi all,

thanks for your time and for keeping up this precious users' list.

I have a page with a page-global currentRecommendation variable. The
instance of this variable is updated by selecting one of the entries
of a ListChoice; basically, the ListChoice deals with a list of
recommendations instances and sets currentRecommendation to the
one selected by the user.

When a recommendation is selected, its data are loaded and displayed
in a recommendationForm (contained in the same page) defined like
this:

recommendationForm = new Form(recommendationForm);

The form contains a custom recommendationPanel which is linked to the
currentRecommendation instance by a CompoundPropertyModel built on
an AbstractReadOnlyModel, just like this:

IModel recommendationModel = new AbstractReadOnlyModel() {
@Override
public Object getObject(Component component) {
return currentRecommendation;
}
};

recommendationPanel = new CustomPanel(recommendationPanel, new
CompoundPropertyModel(recommendationModel));

The problem is that when the form is submitted and validation *fails*,
the CompoundPropertyModel of the recommendationPanel seems to
disconnect from the currentRecommendation instance, because clicking
on a different entry of the ListChoice mentioned above still refreshes
the form but doesn't update the data contained in it anymore.
In other words, the underlying currentRecommendation instance keeps
changing correctly on ListChoice selection change (and the
AbstractReadOnlyModel correctly picks up the selected instance), but
the form (i.e. the panel contained in it) keeps displaying the
instance that failed validation and doesn't show the newly selected
recommendation instance anymore.
The whole thing happens only when form validation fails.

What am I missing?


Thanks a lot for your help,

Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: CompoundPropertyModel stops working when form validation fails.

2007-10-03 Thread Fabio Fioretti
On 10/3/07, Martin-2 [EMAIL PROTECTED] wrote:

 Hi,

Hi, thanks for the quick reply.

 if I understand correctly, the page variable and the panel model should
 always point to the same thing.

Right.

 I suggest you give your page a model with
 currentRecommendation as model object. Then construct your panel with the
 same model instance as the page (or wrap it with an IChainingModel) and get
 rid of the page wide variable.

I can't do that because my page is rather complex and it deals with at
least two different kinds of objects. That's why I choose to have the
currentRecommendation page variable instead, and a panel inside the
related form that deals with the variable through the
CompoundPropertyModel.

 The form's onSubmit() would be like:

 selectedValue = obtainSelectedValue();
 getPage().getModel().setObject(selectedValue);
 setResponsePage(getPage());

 so setting the page's model object to the choice the user selected, and only
 setting it if validation succeeds.

I don't think this could solve my problem because:
1) I don't want the whole page to be refreshed or reloaded but only
the panel that deals with currentRecommendation;
2) more important, I don't want the panel to be refreshed only if
validation succeeds; I want it to always reflect user's selection from
the ListChoice, i.e. the currentRecommendation which is the model
object of the panel.

The problem here is that, when form validation fails, the panel (which
is contained in the form) stops responding to user's selections on the
ListChoice as if its model loses the pointer to currentRecommendation.

I hope I've been clear enough, 'cause it's not so easy to explain...


Thanks a lot for your help!

Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Keep inserted data on AjaxTabbedPanel tab switching.

2007-09-25 Thread Fabio Fioretti
On 9/21/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
 you have to override newlink on the tabbedpanel and return a submitlink
 instead

Nice, this worked just fine!

 also, really, for situations like this it doesnt make sense to use a
 server-side panel. use client side tabs like what jquery provides instead -
 it works much better with forms.

I agree, but this is not the case: I simplified the situation to frame
the question more easily, but it's more complex in reality.


Thanks a lot for your precious help,

Fabio Fioretti - WindoM

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]