RE: using saml2 for authentication
We have to use SAML2 in wicket as well, but there are absolutely no libraries for java available. Let alone proper documentation... It seems this is a wheel to be invented... Hielke -Original Message- From: fachhoch [mailto:fachh...@gmail.com] Sent: woensdag 20 juli 2011 16:33 To: users@wicket.apache.org Subject: using saml2 for authentication my application uses wicket authentication which it turn uses spring acegi security, now we along with our partner decided to use single sign on for which saml2 is proposed, I have to implement saml2 in my wicket application we will the service provider and our partners will be identity provider, did anybody used saml2 with wicket? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/using-saml2-for-authenticatio n-tp3680988p3680988.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling futures
Hans: I hadn't looked at that project, thanks for mentioning it. Thank you all for your input. It seems the only viable solution is to keep track of Futures in another scope than the relevant components so I'll go with that. On 24/07/2011 1:21 AM, Rodolfo Hansen wrote: Have you thought about keeping your future in another scope? a conversation scope for example, or delegating it to the application / session ? On Sat, Jul 23, 2011 at 10:31 PM, Bertrand Guay-Paquet< ber...@step.polymtl.ca> wrote: Thanks for your answers Scott. I thought Wicket could essentially serialize a page any time it sees fit. Is that the case? If so, that would mean that even if the page containing the Future reference is still open in the browser window, the Future could be thrown away. Wouldn't that be a definite possibility if a user has multiple browser windows open in the same session and keeps browsing the site in another window while the "pending result" window is still open? On 23/07/2011 11:10 AM, Scott Swank wrote: Perhaps a transient Future would work for you after all. If the user navigates away the Page is serialized and the Future is thrown away. If you do put futures in a Map, perhaps in the Session, I'd wrap that in an AbstractReadonlyModel. Then you could use have a Map> (assuming your key is an Integer) if you're still concerned about memory usage getting out of hand. Scott On Sat, Jul 23, 2011 at 8:02 AM, Bertrand Guay-Paquet wrote: I haven't actually done it yet, but the 3 steps you list are what I have in mind. After these, I plan to use a javascript timer that polls the status of the request and updates a label (or icon). That ajax behavior would be the one polling the Future. What I can't wrap my head around is this: the ajax behavior can't directly hold a reference to the Future because it can be serialized with the page. On the other hand, if I store the Future in a map somewhere and keep a serializable handle in the behavior, there is a possibility that the user will navigate to another page before get() is called on the Future. To avoid running out of memory, this means that I would need to have a daemon that periodically nulls stale Futures from the map so they can be garbage collected. This kind of operation (submit + polling asynchronous result) seems rather common so I'm sure there's some (easy) way to handle it... On 23/07/2011 9:14 AM, Scott Swank wrote: What does your workflow look like? 1. submit form (or ajax event) 2. create Future 3. return response page (or ajax response) Now who checks the Future and what sort of UI result occurs? Scott On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet wrote: Hello, I can't find the correct way to handle java.util.concurrent.Future instances returned from asynchronous methods in Wicket. This interface does not extend Serializable so its instances can't be stored in components or pages. So what do you do with them? Do you store them in a map in the application and keep a handle (e.g. an int) in the Wicket component? I saw code on a github repository that implemented an ajax timer behavior that keeps a reference to a Future in a transient field to update a status. However, I can't understand how that would work. Wouldn't the transient field be nulled out if the behavior is serialized with the page and then deserialized? Essentially, my question is: what is the standard way to handle Futures in Wicket that run longer than the page rendering? (like processing an order or sending emails) I hope I'm not missing something obvious, but that might be the case... Regards, Bertrand --**--** - To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--** - To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--** - To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--** - To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org For additional commands, e-mail: users-h...@wicket.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@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: Loading wicket components from javascript
On Sun, Jul 24, 2011 at 6:18 PM, Michael Petritsch
wrote:
> I am using this behaviour because I found an example for this. I don't
> know if there is anything better. :)
>
> Ok, the problem is I have some javascript diagrams (from
> http://highcharts.com/, don't want to advertise, but since you've
> asked ;)) that I use in our wicket app.
see https://github.com/hielkehoeve/wiquery-highcharts . could be in help ...
>
> and when I click on a part of the diagramm I want to open a wicket
for events like click you better use AjaxEventBehavior
> panel that loads data for that specific part of the diagramm.
>
> so I got everything working except the panel replacement. I also tried
> the MyPanel.this.addOrReplacecomponent(myAjaxLoadedPanel) before with
> no effect, but maybe I've screwed something else up then. Gonna try it
> again, thanks.
>
>
> On Sun, Jul 24, 2011 at 5:06 PM, Martin Grigorov wrote:
>> On Sun, Jul 24, 2011 at 5:40 PM, Michael Petritsch
>> wrote:
>>> Yes, I removed the visibility related code and anything else for
>>> simplicity and to focus on the actual problem.
>>>
>>> What I actually want to achieve is something like:
>>>
>>> public class MyPanel extends Panel {
>>> Panel myAjaxLoadedPanel;
>>> public MyPanel() {
>>> add(new AbstractDefaultAjaxBehavior() {
>> Still not clear why you use directly this behavior but you know better :-)
>>> @Override
>>> protected void respond(AjaxRequestTarget target) {
>>> String someParameter =
>>> RequestCycle.get().getRequest().getParameter("someParameter");
>>> if(someParameter.equals("1") {
>> reverse the check here to avoid NPE
>>> myAjaxLoadedPanel = new Foo1Panel("myAjaxLoadedPanel");
>>> }
>>> ...
>>> else {
>>> myAjaxLoadedPanel = new FooXPanel("myAjaxLoadedPanel");
>>> }
>>> target.addComponent(myAjaxLoadedPanel);
>>> }
>>> }
>>> myAjaxLoadedPanel = new MyDefaultPanel("myAjaxLoadedPanel");
>>> myAjaxLoadedPanel.setOutputMarkupId(true);
>>> add(myAjaxLoadedPanel);
>>> }
>> The problem that I see is that you just re-assign the panel. Better
>> see org.apache.wicket.Component.replaceWith(Component) and
>> org.apache.wicket.MarkupContainer.replace(Component). These methods
>> preserve the component hierarchy, i.e. the new assignment will
>> inherits its parent (MyPanel.this) from the old assignment.
>>
>> What is the actual problem ? Sorry, but I didn't follow this thread before.
>>
>>>
>>> On Sun, Jul 24, 2011 at 4:16 PM, Martin Grigorov
>>> wrote:
On Sun, Jul 24, 2011 at 5:10 PM, Michael Petritsch
wrote:
> I am using wicket 1.4.16, the markupplaceholder is there (checked with
> firebug).
>
> I have also tried it with a simple visible label:
>
> public class MyPanel extends Panel {
> Label myUpdatedLabel;
> public MyPanel() {
> add(new AbstractDefaultAjaxBehavior() {
Why do you use this behavior but not a more specific one ? E.g.
AjaxEventBehavior.
> @Override
> protected void respond(AjaxRequestTarget target) {
> myUpdatedLabel.setDefaultModel("bar");
> target.addComponent(myUpdatedLabel);
> }
> }
> myUpdatedLabel = new Label("myLabel","foo");
> myUpdatedLabel.setOutputMarkupId(true);
> add(myUpdatedLabel);
> }
>
> This works, however what I actually have to do in the response()
> method is the following:
> myUpdatedLabel = new Label("myLabel","bar");
> myUpdatedLabel.setOuputMarkupId(true);
> target.addComponent(myUpdatedLabel);
What you really want is:
myUpdatedLabel.setDefaultModelObject("bar");
target.addComponent(myUpdatedLabel);
>
> But when I try this nothing happens. The html of the label remains
> untouched: foo
setOutputMarkupPlaceholderTag(true) is needed only if you change the
visibility of Ajax updated component. I don't see visibility related
logic in your code.
What exactly you want to achieve ?
>
> On Mon, Jul 18, 2011 at 4:59 AM, msj121 wrote:
>> I am not sure if it is still true, but if you have the label added, just
>> the
>> visibility is false from the beginning, then in older versions of wicket
>> it
>> would not actually put the component, even the placeholder. I dealt with
>> this before, but I think in newer versions presumably this was
>> changed
>> In theory a good way to check if this is an issue is to setvisible to
>> true
>> in the beginning and alternate.
>>
>>
>> If your trying to add a new markup that never existed in html to the
>> page,
>> it should throw an error, and then you will need to use ListViews etc...
>> as
>> described above.
>>
>> --
>> View this message in context:
>> http://apache-wicket.1842946.n4.
Re: IE 8: FileUpload#getClientFileName() returns full file path
What still baffles me is why IE upload works in 1.4.17 Wicket examples http://wicketstuff.org/wicket14/upload/single? On Sun, Jul 24, 2011 at 10:22 AM, Alec Swan wrote: > Looks like other people experienced the same problem with file upload > in IE. Is there a JIRA issue for this? > > Here are some related threads: > http://apache-wicket.1842946.n4.nabble.com/upload-in-IE-tp3045562p3045562.html > http://apache-wicket.1842946.n4.nabble.com/FileUpload-getClientFileName-1-4-9-vs-1-4-8-tp2306372p2306372.html > > Alec > > > On Sun, Jul 24, 2011 at 9:58 AM, Alec Swan wrote: >> Hello, >> >> I have an upload form in Wicket 1.4.17 and noticed that >> FileUpload#getClientFileName() returns just the file name in Firefox 4.0 and >> the entire absolute path in IE 8.0. >> My code is almost identical to the one in upload file Wicket example, which >> works in IE 8.0. >> Any ideas on what could cause this? Could it have anything to do with the >> servlet container on which the app is deployed? >> >> Thanks, >> >> Alec > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: IE 8: FileUpload#getClientFileName() returns full file path
Looks like other people experienced the same problem with file upload in IE. Is there a JIRA issue for this? Here are some related threads: http://apache-wicket.1842946.n4.nabble.com/upload-in-IE-tp3045562p3045562.html http://apache-wicket.1842946.n4.nabble.com/FileUpload-getClientFileName-1-4-9-vs-1-4-8-tp2306372p2306372.html Alec On Sun, Jul 24, 2011 at 9:58 AM, Alec Swan wrote: > Hello, > > I have an upload form in Wicket 1.4.17 and noticed that > FileUpload#getClientFileName() returns just the file name in Firefox 4.0 and > the entire absolute path in IE 8.0. > My code is almost identical to the one in upload file Wicket example, which > works in IE 8.0. > Any ideas on what could cause this? Could it have anything to do with the > servlet container on which the app is deployed? > > Thanks, > > Alec - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
IE 8: FileUpload#getClientFileName() returns full file path
Hello, I have an upload form in Wicket 1.4.17 and noticed that FileUpload#getClientFileName() returns just the file name in Firefox 4.0 and the entire absolute path in IE 8.0. My code is almost identical to the one in upload file Wicket example, which works in IE 8.0. Any ideas on what could cause this? Could it have anything to do with the servlet container on which the app is deployed? Thanks, Alec
Re: Loading wicket components from javascript
I am using this behaviour because I found an example for this. I don't
know if there is anything better. :)
Ok, the problem is I have some javascript diagrams (from
http://highcharts.com/, don't want to advertise, but since you've
asked ;)) that I use in our wicket app.
and when I click on a part of the diagramm I want to open a wicket
panel that loads data for that specific part of the diagramm.
so I got everything working except the panel replacement. I also tried
the MyPanel.this.addOrReplacecomponent(myAjaxLoadedPanel) before with
no effect, but maybe I've screwed something else up then. Gonna try it
again, thanks.
On Sun, Jul 24, 2011 at 5:06 PM, Martin Grigorov wrote:
> On Sun, Jul 24, 2011 at 5:40 PM, Michael Petritsch
> wrote:
>> Yes, I removed the visibility related code and anything else for
>> simplicity and to focus on the actual problem.
>>
>> What I actually want to achieve is something like:
>>
>> public class MyPanel extends Panel {
>> Panel myAjaxLoadedPanel;
>> public MyPanel() {
>> add(new AbstractDefaultAjaxBehavior() {
> Still not clear why you use directly this behavior but you know better :-)
>> @Override
>> protected void respond(AjaxRequestTarget target) {
>> String someParameter =
>> RequestCycle.get().getRequest().getParameter("someParameter");
>> if(someParameter.equals("1") {
> reverse the check here to avoid NPE
>> myAjaxLoadedPanel = new Foo1Panel("myAjaxLoadedPanel");
>> }
>> ...
>> else {
>> myAjaxLoadedPanel = new FooXPanel("myAjaxLoadedPanel");
>> }
>> target.addComponent(myAjaxLoadedPanel);
>> }
>> }
>> myAjaxLoadedPanel = new MyDefaultPanel("myAjaxLoadedPanel");
>> myAjaxLoadedPanel.setOutputMarkupId(true);
>> add(myAjaxLoadedPanel);
>> }
> The problem that I see is that you just re-assign the panel. Better
> see org.apache.wicket.Component.replaceWith(Component) and
> org.apache.wicket.MarkupContainer.replace(Component). These methods
> preserve the component hierarchy, i.e. the new assignment will
> inherits its parent (MyPanel.this) from the old assignment.
>
> What is the actual problem ? Sorry, but I didn't follow this thread before.
>
>>
>> On Sun, Jul 24, 2011 at 4:16 PM, Martin Grigorov
>> wrote:
>>> On Sun, Jul 24, 2011 at 5:10 PM, Michael Petritsch
>>> wrote:
I am using wicket 1.4.16, the markupplaceholder is there (checked with
firebug).
I have also tried it with a simple visible label:
public class MyPanel extends Panel {
Label myUpdatedLabel;
public MyPanel() {
add(new AbstractDefaultAjaxBehavior() {
>>> Why do you use this behavior but not a more specific one ? E.g.
>>> AjaxEventBehavior.
@Override
protected void respond(AjaxRequestTarget target) {
myUpdatedLabel.setDefaultModel("bar");
target.addComponent(myUpdatedLabel);
}
}
myUpdatedLabel = new Label("myLabel","foo");
myUpdatedLabel.setOutputMarkupId(true);
add(myUpdatedLabel);
}
This works, however what I actually have to do in the response()
method is the following:
myUpdatedLabel = new Label("myLabel","bar");
myUpdatedLabel.setOuputMarkupId(true);
target.addComponent(myUpdatedLabel);
>>> What you really want is:
>>> myUpdatedLabel.setDefaultModelObject("bar");
>>> target.addComponent(myUpdatedLabel);
But when I try this nothing happens. The html of the label remains
untouched: foo
>>> setOutputMarkupPlaceholderTag(true) is needed only if you change the
>>> visibility of Ajax updated component. I don't see visibility related
>>> logic in your code.
>>>
>>> What exactly you want to achieve ?
On Mon, Jul 18, 2011 at 4:59 AM, msj121 wrote:
> I am not sure if it is still true, but if you have the label added, just
> the
> visibility is false from the beginning, then in older versions of wicket
> it
> would not actually put the component, even the placeholder. I dealt with
> this before, but I think in newer versions presumably this was changed
> In theory a good way to check if this is an issue is to setvisible to true
> in the beginning and alternate.
>
>
> If your trying to add a new markup that never existed in html to the page,
> it should throw an error, and then you will need to use ListViews etc...
> as
> described above.
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Loading-wicket-components-from-javascript-tp3673381p3674372.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wick
Re: Loading wicket components from javascript
On Sun, Jul 24, 2011 at 5:40 PM, Michael Petritsch
wrote:
> Yes, I removed the visibility related code and anything else for
> simplicity and to focus on the actual problem.
>
> What I actually want to achieve is something like:
>
> public class MyPanel extends Panel {
> Panel myAjaxLoadedPanel;
> public MyPanel() {
> add(new AbstractDefaultAjaxBehavior() {
Still not clear why you use directly this behavior but you know better :-)
> @Override
> protected void respond(AjaxRequestTarget target) {
> String someParameter =
> RequestCycle.get().getRequest().getParameter("someParameter");
> if(someParameter.equals("1") {
reverse the check here to avoid NPE
> myAjaxLoadedPanel = new Foo1Panel("myAjaxLoadedPanel");
> }
> ...
> else {
> myAjaxLoadedPanel = new FooXPanel("myAjaxLoadedPanel");
> }
> target.addComponent(myAjaxLoadedPanel);
> }
> }
> myAjaxLoadedPanel = new MyDefaultPanel("myAjaxLoadedPanel");
> myAjaxLoadedPanel.setOutputMarkupId(true);
> add(myAjaxLoadedPanel);
> }
The problem that I see is that you just re-assign the panel. Better
see org.apache.wicket.Component.replaceWith(Component) and
org.apache.wicket.MarkupContainer.replace(Component). These methods
preserve the component hierarchy, i.e. the new assignment will
inherits its parent (MyPanel.this) from the old assignment.
What is the actual problem ? Sorry, but I didn't follow this thread before.
>
> On Sun, Jul 24, 2011 at 4:16 PM, Martin Grigorov wrote:
>> On Sun, Jul 24, 2011 at 5:10 PM, Michael Petritsch
>> wrote:
>>> I am using wicket 1.4.16, the markupplaceholder is there (checked with
>>> firebug).
>>>
>>> I have also tried it with a simple visible label:
>>>
>>> public class MyPanel extends Panel {
>>> Label myUpdatedLabel;
>>> public MyPanel() {
>>> add(new AbstractDefaultAjaxBehavior() {
>> Why do you use this behavior but not a more specific one ? E.g.
>> AjaxEventBehavior.
>>> @Override
>>> protected void respond(AjaxRequestTarget target) {
>>> myUpdatedLabel.setDefaultModel("bar");
>>> target.addComponent(myUpdatedLabel);
>>> }
>>> }
>>> myUpdatedLabel = new Label("myLabel","foo");
>>> myUpdatedLabel.setOutputMarkupId(true);
>>> add(myUpdatedLabel);
>>> }
>>>
>>> This works, however what I actually have to do in the response()
>>> method is the following:
>>> myUpdatedLabel = new Label("myLabel","bar");
>>> myUpdatedLabel.setOuputMarkupId(true);
>>> target.addComponent(myUpdatedLabel);
>> What you really want is:
>> myUpdatedLabel.setDefaultModelObject("bar");
>> target.addComponent(myUpdatedLabel);
>>>
>>> But when I try this nothing happens. The html of the label remains
>>> untouched: foo
>> setOutputMarkupPlaceholderTag(true) is needed only if you change the
>> visibility of Ajax updated component. I don't see visibility related
>> logic in your code.
>>
>> What exactly you want to achieve ?
>>>
>>> On Mon, Jul 18, 2011 at 4:59 AM, msj121 wrote:
I am not sure if it is still true, but if you have the label added, just
the
visibility is false from the beginning, then in older versions of wicket it
would not actually put the component, even the placeholder. I dealt with
this before, but I think in newer versions presumably this was changed
In theory a good way to check if this is an issue is to setvisible to true
in the beginning and alternate.
If your trying to add a new markup that never existed in html to the page,
it should throw an error, and then you will need to use ListViews etc... as
described above.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Loading-wicket-components-from-javascript-tp3673381p3674372.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Develop
Re: Loading wicket components from javascript
Yes, I removed the visibility related code and anything else for
simplicity and to focus on the actual problem.
What I actually want to achieve is something like:
public class MyPanel extends Panel {
Panel myAjaxLoadedPanel;
public MyPanel() {
add(new AbstractDefaultAjaxBehavior() {
@Override
protected void respond(AjaxRequestTarget target) {
String someParameter =
RequestCycle.get().getRequest().getParameter("someParameter");
if(someParameter.equals("1") {
myAjaxLoadedPanel = new Foo1Panel("myAjaxLoadedPanel");
}
...
else {
myAjaxLoadedPanel = new FooXPanel("myAjaxLoadedPanel");
}
target.addComponent(myAjaxLoadedPanel);
}
}
myAjaxLoadedPanel = new MyDefaultPanel("myAjaxLoadedPanel");
myAjaxLoadedPanel.setOutputMarkupId(true);
add(myAjaxLoadedPanel);
}
On Sun, Jul 24, 2011 at 4:16 PM, Martin Grigorov wrote:
> On Sun, Jul 24, 2011 at 5:10 PM, Michael Petritsch
> wrote:
>> I am using wicket 1.4.16, the markupplaceholder is there (checked with
>> firebug).
>>
>> I have also tried it with a simple visible label:
>>
>> public class MyPanel extends Panel {
>> Label myUpdatedLabel;
>> public MyPanel() {
>> add(new AbstractDefaultAjaxBehavior() {
> Why do you use this behavior but not a more specific one ? E.g.
> AjaxEventBehavior.
>> @Override
>> protected void respond(AjaxRequestTarget target) {
>> myUpdatedLabel.setDefaultModel("bar");
>> target.addComponent(myUpdatedLabel);
>> }
>> }
>> myUpdatedLabel = new Label("myLabel","foo");
>> myUpdatedLabel.setOutputMarkupId(true);
>> add(myUpdatedLabel);
>> }
>>
>> This works, however what I actually have to do in the response()
>> method is the following:
>> myUpdatedLabel = new Label("myLabel","bar");
>> myUpdatedLabel.setOuputMarkupId(true);
>> target.addComponent(myUpdatedLabel);
> What you really want is:
> myUpdatedLabel.setDefaultModelObject("bar");
> target.addComponent(myUpdatedLabel);
>>
>> But when I try this nothing happens. The html of the label remains
>> untouched: foo
> setOutputMarkupPlaceholderTag(true) is needed only if you change the
> visibility of Ajax updated component. I don't see visibility related
> logic in your code.
>
> What exactly you want to achieve ?
>>
>> On Mon, Jul 18, 2011 at 4:59 AM, msj121 wrote:
>>> I am not sure if it is still true, but if you have the label added, just the
>>> visibility is false from the beginning, then in older versions of wicket it
>>> would not actually put the component, even the placeholder. I dealt with
>>> this before, but I think in newer versions presumably this was changed
>>> In theory a good way to check if this is an issue is to setvisible to true
>>> in the beginning and alternate.
>>>
>>>
>>> If your trying to add a new markup that never existed in html to the page,
>>> it should throw an error, and then you will need to use ListViews etc... as
>>> described above.
>>>
>>> --
>>> View this message in context:
>>> http://apache-wicket.1842946.n4.nabble.com/Loading-wicket-components-from-javascript-tp3673381p3674372.html
>>> Sent from the Users forum mailing list archive at Nabble.com.
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Loading wicket components from javascript
On Sun, Jul 24, 2011 at 5:10 PM, Michael Petritsch
wrote:
> I am using wicket 1.4.16, the markupplaceholder is there (checked with
> firebug).
>
> I have also tried it with a simple visible label:
>
> public class MyPanel extends Panel {
> Label myUpdatedLabel;
> public MyPanel() {
> add(new AbstractDefaultAjaxBehavior() {
Why do you use this behavior but not a more specific one ? E.g.
AjaxEventBehavior.
> @Override
> protected void respond(AjaxRequestTarget target) {
> myUpdatedLabel.setDefaultModel("bar");
> target.addComponent(myUpdatedLabel);
> }
> }
> myUpdatedLabel = new Label("myLabel","foo");
> myUpdatedLabel.setOutputMarkupId(true);
> add(myUpdatedLabel);
> }
>
> This works, however what I actually have to do in the response()
> method is the following:
> myUpdatedLabel = new Label("myLabel","bar");
> myUpdatedLabel.setOuputMarkupId(true);
> target.addComponent(myUpdatedLabel);
What you really want is:
myUpdatedLabel.setDefaultModelObject("bar");
target.addComponent(myUpdatedLabel);
>
> But when I try this nothing happens. The html of the label remains
> untouched: foo
setOutputMarkupPlaceholderTag(true) is needed only if you change the
visibility of Ajax updated component. I don't see visibility related
logic in your code.
What exactly you want to achieve ?
>
> On Mon, Jul 18, 2011 at 4:59 AM, msj121 wrote:
>> I am not sure if it is still true, but if you have the label added, just the
>> visibility is false from the beginning, then in older versions of wicket it
>> would not actually put the component, even the placeholder. I dealt with
>> this before, but I think in newer versions presumably this was changed
>> In theory a good way to check if this is an issue is to setvisible to true
>> in the beginning and alternate.
>>
>>
>> If your trying to add a new markup that never existed in html to the page,
>> it should throw an error, and then you will need to use ListViews etc... as
>> described above.
>>
>> --
>> View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/Loading-wicket-components-from-javascript-tp3673381p3674372.html
>> Sent from the Users forum mailing list archive at Nabble.com.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Loading wicket components from javascript
I am using wicket 1.4.16, the markupplaceholder is there (checked with firebug).
I have also tried it with a simple visible label:
public class MyPanel extends Panel {
Label myUpdatedLabel;
public MyPanel() {
add(new AbstractDefaultAjaxBehavior() {
@Override
protected void respond(AjaxRequestTarget target) {
myUpdatedLabel.setDefaultModel("bar");
target.addComponent(myUpdatedLabel);
}
}
myUpdatedLabel = new Label("myLabel","foo");
myUpdatedLabel.setOutputMarkupId(true);
add(myUpdatedLabel);
}
This works, however what I actually have to do in the response()
method is the following:
myUpdatedLabel = new Label("myLabel","bar");
myUpdatedLabel.setOuputMarkupId(true);
target.addComponent(myUpdatedLabel);
But when I try this nothing happens. The html of the label remains
untouched: foo
On Mon, Jul 18, 2011 at 4:59 AM, msj121 wrote:
> I am not sure if it is still true, but if you have the label added, just the
> visibility is false from the beginning, then in older versions of wicket it
> would not actually put the component, even the placeholder. I dealt with
> this before, but I think in newer versions presumably this was changed
> In theory a good way to check if this is an issue is to setvisible to true
> in the beginning and alternate.
>
>
> If your trying to add a new markup that never existed in html to the page,
> it should throw an error, and then you will need to use ListViews etc... as
> described above.
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Loading-wicket-components-from-javascript-tp3673381p3674372.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling futures
Did you already take a look at wicketstuff-progressbar? Regards Hans Am 23.07.11 17:02 schrieb "Bertrand Guay-Paquet" unter : > I haven't actually done it yet, but the 3 steps you list are what I have > in mind. > > After these, I plan to use a javascript timer that polls the status of > the request and updates a label (or icon). That ajax behavior would be > the one polling the Future. > > What I can't wrap my head around is this: the ajax behavior can't > directly hold a reference to the Future because it can be serialized > with the page. On the other hand, if I store the Future in a map > somewhere and keep a serializable handle in the behavior, there is a > possibility that the user will navigate to another page before get() is > called on the Future. To avoid running out of memory, this means that I > would need to have a daemon that periodically nulls stale Futures from > the map so they can be garbage collected. > > This kind of operation (submit + polling asynchronous result) seems > rather common so I'm sure there's some (easy) way to handle it... > > On 23/07/2011 9:14 AM, Scott Swank wrote: >> What does your workflow look like? >> >> 1. submit form (or ajax event) >> 2. create Future >> 3. return response page (or ajax response) >> >> Now who checks the Future and what sort of UI result occurs? >> >> Scott >> >> On Fri, Jul 22, 2011 at 8:55 PM, Bertrand Guay-Paquet >> wrote: >>> Hello, >>> >>> I can't find the correct way to handle java.util.concurrent.Future instances >>> returned from asynchronous methods in Wicket. This interface does not extend >>> Serializable so its instances can't be stored in components or pages. So >>> what do you do with them? >>> >>> Do you store them in a map in the application and keep a handle (e.g. an >>> int) in the Wicket component? >>> >>> I saw code on a github repository that implemented an ajax timer behavior >>> that keeps a reference to a Future in a transient field to update a status. >>> However, I can't understand how that would work. Wouldn't the transient >>> field be nulled out if the behavior is serialized with the page and then >>> deserialized? >>> >>> Essentially, my question is: what is the standard way to handle Futures in >>> Wicket that run longer than the page rendering? (like processing an order or >>> sending emails) >>> >>> I hope I'm not missing something obvious, but that might be the case... >>> >>> Regards, >>> Bertrand >>> >>> - >>> 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 > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
