Re: Image based on external url model object
Hi,
maybe we can extend the normal image and add a constructor Image(String id,
IModel model, String url) so that the url is used in the src attribute (like in
MediaComponents)
WDYT?
kind regards
Tobias
> Am 23.11.2015 um 03:45 schrieb Maxim Solodovnik :
>
> Actually I'm using "hacky" way:
>
> if (absolute) {
> profile.add(new
> WebMarkupContainer("img").add(AttributeModifier.append("alt",
> Application.getString(5L)), AttributeModifier.append("src", uri)));
> } else {
> profile.add(new Image("img", new ByteArrayResource("image/jpeg") {
> ..
>
> Would love to know if is there any better way
>
>> On Mon, Nov 23, 2015 at 4:34 AM, Sebastien wrote:
>>
>> Forgot to mention I've read the following wiki, but as it was a little bit
>> old I was wondering if there was nothing newer...
>>
>> https://cwiki.apache.org/confluence/display/WICKET/How+to+load+an+external+image
>>
>>
>>> On Sun, Nov 22, 2015 at 11:31 PM, Sebastien wrote:
>>>
>>> Hi all,
>>>
>>> I cannot find an Image component that could display an image from an
>>> *external* url, supplied by the model object. My use-case is that I have
>> a
>>> user object, which have a gravatarUrl property, and I would like to do
>>> something like "this.add(new ExternalImage("gravatarUrl"));"...
>>>
>>> Isn't there any component that actually exists which could do this?
>>>
>>> Many thanks in advance,
>>> Sebastien
>
>
>
> --
> WBR
> Maxim aka solomax
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Image based on external url model object
Actually I'm using "hacky" way:
if (absolute) {
profile.add(new
WebMarkupContainer("img").add(AttributeModifier.append("alt",
Application.getString(5L)), AttributeModifier.append("src", uri)));
} else {
profile.add(new Image("img", new ByteArrayResource("image/jpeg") {
..
Would love to know if is there any better way
On Mon, Nov 23, 2015 at 4:34 AM, Sebastien wrote:
> Forgot to mention I've read the following wiki, but as it was a little bit
> old I was wondering if there was nothing newer...
>
> https://cwiki.apache.org/confluence/display/WICKET/How+to+load+an+external+image
>
>
> On Sun, Nov 22, 2015 at 11:31 PM, Sebastien wrote:
>
> > Hi all,
> >
> > I cannot find an Image component that could display an image from an
> > *external* url, supplied by the model object. My use-case is that I have
> a
> > user object, which have a gravatarUrl property, and I would like to do
> > something like "this.add(new ExternalImage("gravatarUrl"));"...
> >
> > Isn't there any component that actually exists which could do this?
> >
> > Many thanks in advance,
> > Sebastien
> >
> >
>
--
WBR
Maxim aka solomax
Re: Image based on external url model object
Forgot to mention I've read the following wiki, but as it was a little bit
old I was wondering if there was nothing newer...
https://cwiki.apache.org/confluence/display/WICKET/How+to+load+an+external+image
On Sun, Nov 22, 2015 at 11:31 PM, Sebastien wrote:
> Hi all,
>
> I cannot find an Image component that could display an image from an
> *external* url, supplied by the model object. My use-case is that I have a
> user object, which have a gravatarUrl property, and I would like to do
> something like "this.add(new ExternalImage("gravatarUrl"));"...
>
> Isn't there any component that actually exists which could do this?
>
> Many thanks in advance,
> Sebastien
>
>
Image based on external url model object
Hi all,
I cannot find an Image component that could display an image from an
*external* url, supplied by the model object. My use-case is that I have a
user object, which have a gravatarUrl property, and I would like to do
something like "this.add(new ExternalImage("gravatarUrl"));"...
Isn't there any component that actually exists which could do this?
Many thanks in advance,
Sebastien
Re: Quetsion to nesting Forms and reflecting states of FormComponents after ajax refreshs
Hi Andrea, Thanks for this investigation, this is very interesting that nothing breaks! > I don't understand why the onFormSubmitted is called on the root form and not on the actually submitted one The question is "what form is really submitted/posted"? We know that only a real form - the root form - can/will be submitted (using #submit()). So from my understanding, .getRootForm().onFormSubmitted() had the purpose to match the real submitted form, not an inner - fake - form... But IIRC, wicket is smart enough to recognize an inner-form as the form being submitted. I don't have deeply tested like you did, but if we can remove the call to getRootForm(), I'm +1! :) Best regards, Sebastien On Sun, Nov 22, 2015 at 7:37 PM, Andrea Del Bene wrote: > Hi, > > playing with the quickstart I've noticed something strange that might help > to solve this issue. Before rendering phase both the inner and outer form > are marked as submitted (Form#isSubmitted returns true). This is quite > strange as I would expect that only the inner form would be marked as > submitted. It turned out that the cause of this strange behavior is > AjaxFormSubmitBehavior#onEvent which just contains: > > getForm().getRootForm().onFormSubmitted(new AjaxFormSubmitter(this, > target)); > > I don't understand why the onFormSubmitted is called on the root form and > not on the actually submitted one. If we remove getRootForm() the issue is > resolved and no test gets broken. The call to getRootForm() was introduced > ages ago for WICKET-1282 but the issue doesn't provide much details about > it. > > Andrea. > > Hi, >> >> > 2) if the application needs to repaint any form which is not >> > processed then the application has to call #inputChanged() for >> > this form / form component >> >> this will break current applications. >> >> We can argue which approach is more consistent, but I don't think we >> should change this just because of a single user request: >> His solution is to not using nested forms. >> >> Regards >> Sven >> >> >> >> >> On 20.11.2015 17:13, Martin Grigorov wrote: >> >>> On Fri, Nov 20, 2015 at 5:02 PM, Sven Meier wrote: >>> >>> When a nested form is submitted Wicket calls the processing methods > only for the nested form. > I don't see a reason why #inputChanged() should be an exception. > The outer form is not processed, because we don't want validation errors to appear. #inputChanged() is called, so that on a possible render of the whole page the input of the user is preserved. >>> >>> >>> This is what I said in my mail earlier. >>> >>> I suggest: >>> 1) call form processing methods only for the submitted form (and the ones >>> which requests processing explicitly, i.e. >>> #wantSubmitOnNestedFormSubmit() >>> and #wantSubmitOnParentFormSubmit()) >>> 2) if the application needs to repaint any form which is not processed >>> then >>> the application has to call #inputChanged() for this form / form >>> component >>> >>> The current way is: >>> 1) call #inputChanged() for *all* >>> 2) call other processing methods only for the submitted one and the extra >>> ones which explicitly want to participate >>> 3) the application should call #clearInput() for any non-processed >>> >>> For me the approach I suggest is more consistent and expected. >>> >>> >>> it is very common to reuse components in Wicket > I'm shocked ;) So a Panel with a Form could appear as a nested anywhere. > That is the main reason to support nested forms. > Yes, and it comes with a price. In most cases it's not necessary to include a form in panels - generally I would advice against it: - because "it's not supported in HTML" - again, it comes with a price (see above) Have fun Sven On 20.11.2015 16:47, Martin Grigorov wrote: On Fri, Nov 20, 2015 at 4:37 PM, Sven Meier wrote: > > IMO the current behavior is wrong. > >> >>> >> I don't see anything wrong with the current nested form handling. >> Care to >> elaborate? >> >> >> The problem I see is that Wicket treats #inputChanged() differently > than > all other Form processing methods (like #validate(), #on[In]Valid(), > #updateModel()). > When a nested form is submitted Wicket calls the processing methods > only > for the nested form. > I don't see a reason why #inputChanged() should be an exception. > > > > It's rather unusual to have to formComponents for the same model on a >> single page. >> >> IMHO Patrick shouldn't use nested forms in the first place, I consider >> them an advanced feature. >> >> >> Advanced or not, it is very common to reuse components in Wicket. > So a Panel with a Form could appear as a nested anywhere. That is the > main > reason to support nested forms. > > > > Regards >> Sven >
Re: Quetsion to nesting Forms and reflecting states of FormComponents after ajax refreshs
Hi, playing with the quickstart I've noticed something strange that might help to solve this issue. Before rendering phase both the inner and outer form are marked as submitted (Form#isSubmitted returns true). This is quite strange as I would expect that only the inner form would be marked as submitted. It turned out that the cause of this strange behavior is AjaxFormSubmitBehavior#onEvent which just contains: getForm().getRootForm().onFormSubmitted(new AjaxFormSubmitter(this, target)); I don't understand why the onFormSubmitted is called on the root form and not on the actually submitted one. If we remove getRootForm() the issue is resolved and no test gets broken. The call to getRootForm() was introduced ages ago for WICKET-1282 but the issue doesn't provide much details about it. Andrea. Hi, > 2) if the application needs to repaint any form which is not > processed then the application has to call #inputChanged() for > this form / form component this will break current applications. We can argue which approach is more consistent, but I don't think we should change this just because of a single user request: His solution is to not using nested forms. Regards Sven On 20.11.2015 17:13, Martin Grigorov wrote: On Fri, Nov 20, 2015 at 5:02 PM, Sven Meier wrote: When a nested form is submitted Wicket calls the processing methods only for the nested form. I don't see a reason why #inputChanged() should be an exception. The outer form is not processed, because we don't want validation errors to appear. #inputChanged() is called, so that on a possible render of the whole page the input of the user is preserved. This is what I said in my mail earlier. I suggest: 1) call form processing methods only for the submitted form (and the ones which requests processing explicitly, i.e. #wantSubmitOnNestedFormSubmit() and #wantSubmitOnParentFormSubmit()) 2) if the application needs to repaint any form which is not processed then the application has to call #inputChanged() for this form / form component The current way is: 1) call #inputChanged() for *all* 2) call other processing methods only for the submitted one and the extra ones which explicitly want to participate 3) the application should call #clearInput() for any non-processed For me the approach I suggest is more consistent and expected. it is very common to reuse components in Wicket I'm shocked ;) So a Panel with a Form could appear as a nested anywhere. That is the main reason to support nested forms. Yes, and it comes with a price. In most cases it's not necessary to include a form in panels - generally I would advice against it: - because "it's not supported in HTML" - again, it comes with a price (see above) Have fun Sven On 20.11.2015 16:47, Martin Grigorov wrote: On Fri, Nov 20, 2015 at 4:37 PM, Sven Meier wrote: IMO the current behavior is wrong. I don't see anything wrong with the current nested form handling. Care to elaborate? The problem I see is that Wicket treats #inputChanged() differently than all other Form processing methods (like #validate(), #on[In]Valid(), #updateModel()). When a nested form is submitted Wicket calls the processing methods only for the nested form. I don't see a reason why #inputChanged() should be an exception. It's rather unusual to have to formComponents for the same model on a single page. IMHO Patrick shouldn't use nested forms in the first place, I consider them an advanced feature. Advanced or not, it is very common to reuse components in Wicket. So a Panel with a Form could appear as a nested anywhere. That is the main reason to support nested forms. Regards Sven On 20.11.2015 16:06, Martin Grigorov wrote: OK. I see what happens. At org.apache.wicket.markup.html.form.Form#onFormSubmitted(org.apache.wicket.markup.html.form.IFormSubmitter) Wicket calls #inputChanged() for the root form, so this calls #inputChanged() on *all* FormComponents (including nested ones). My first reaction is: this is a bug! But then ... the purpose of the rawInput is to preserve the data entered by the user. So if your #onSubmit() logic in the nested form / submitter repaints the form components in the root/parent form then their data would be lost and the user will have to re-type it again. It seems in both cases the application developer will have to do something: 1) either clear the input manually (as now) 2) or update it manually when needed (by calling #inputChanged() only on the FormComponents in the rootForm). IMO the current behavior is wrong. Please create a bug with a quickstart. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Nov 20, 2015 at 3:51 PM, Patrick Davids < patrick.dav...@nubologic.com> wrote: Hi Martin, this is true for my DropDownChoice2. But DropDownChoice1 does not get validated. So, this could be the reason why it is not cleared. Now... I'm getting more and
Re: Testing for an IEvent
Hi, you can override BaseWicketTester#createPage(), returning your own page (might be a subclass of StartComponentInPage) which records all events handed to Component#onEvent(). Regards Sven On 22.11.2015 12:37, calle sollander wrote: Hello!I have a question about how to test that an IEvent has been sent. Say that I have a Panel with a AjaxLink on it and depending on something or other diffrentevents are sent when the user clicks the link.Is there a way to set up a unit test using the Wickettester that can detect which events are sent? Regards Calle S - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Testing for an IEvent
Hello!I have a question about how to test that an IEvent has been sent. Say that I have a Panel with a AjaxLink on it and depending on something or other diffrentevents are sent when the user clicks the link.Is there a way to set up a unit test using the Wickettester that can detect which events are sent? Regards Calle S
