Re: Handling futures
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 > > -- Rodolfo Hansen CTO, KindleIT Software Development Email: rhan...@kitsd.com M
Re: Handling futures
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-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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Avoid doing lot of Ajax request
I'm not sure I understood your response. Are you saying you don't want to set the throttle for every link you do? If so, sub-class it and reuse your special subclass that always throttles. On Sat, Jul 23, 2011 at 2:06 AM, coincoinfou wrote: > But I have to throttle delay for a set of same type links not only one > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Avoid-doing-lot-of-Ajax-request-tp3687472p3688488.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: "Select" Component with Blank Choice at the Top
new SelectOption(id, Model.of("")) ?!
On Fri, Jul 22, 2011 at 10:24 PM, eugenebalt wrote:
> I am using the Select component to represent the HTML OptionGroup with
> Options.
>
> The Select must have a blank choice displayed at the top.
>
> With DropDowns, I would have been able to do "setNullValid", but Select
> doesn't have this method. Any ideas? Thanks a lot.
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Select-Component-with-Blank-Choice-at-the-Top-tp3687589p3687589.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
>
>
--
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: Getting Post DATA
mountPage() uses MountedMapper behind the scenes. MountedMapper replaces QueryStringUrlCodingStrategy and several other url coding strategies from 1.4. Read http://wicketinaction.com/2011/07/wicket-1-5-mounting-pages/ for more information. Pages' PageParameters extract only GET parameters, i.e. the ones from the URL (indexed, named indexed and query string). POST data can be read with getRequest().getPostParameters(). This method is used for example in form submit processing code. I'd use plain Servlet for your needs. If you need Wicket application/session/request cycle then you can also use Wicket's resources (org.apache.wicket.request.resource.IResource). I'll talk about them in my next blog (in few days). On Fri, Jul 22, 2011 at 9:05 PM, Niranjan Rao wrote: > I am very new user of wicket, so please be gentle with me if this is > obvious question or RTFM. I tried searching for docs but no luck. > > Using Wicket 1.5. > > I have bunch of pages mounted using mountPage(url, page class). This > works fine and pages do get parameters so long as the request is GET. > > If you do post on the same url, pages don't see the same parameters. I > tried searching google for the solution and came across one solution at > http://apache-wicket.1842946.n4.nabble.com/Manually-handle-post-data-td1853028.html > > However seems like I can not resolve QueryStringUrlCodingStrategy class > in wicket 1.5. Tried looking for replacement calls, but no luck so far. > > These are services and there is no UI for this. A script will typically > post the data to the service. > > Regards, > > Niranjan > > > - > 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: Re-Captcha with WiQuery ButtonBehavior causes "Channel busy - postponing"
Dan,
Thanks for the pointer. It turned out that our webapp is using jQuery
already and adding WiQuery behavior caused a duplicate WiQuery's
jQuery reference possibly causing problems with handling Ajax
requests.
Thanks,
Alec
On Fri, Jul 22, 2011 at 6:16 PM, Dan Retzlaff wrote:
> Alec,
>
> Have you checked that no JavaScript errors are being encountered on the
> client? We're not using WiQuery, but we encountered your channel busy
> symptom dealing with https://issues.apache.org/jira/browse/WICKET-3820. The
> client-side AJAX processing was choking before the channel was marked
> available.
>
> Dan
>
> On Fri, Jul 22, 2011 at 4:04 PM, Alec Swan wrote:
>
>> I didn't get any feedback on this and was thinking about posting this
>> on WiQuery forum but it didn't look very active. Does anybody have any
>> thoughts on why we are getting "Channel busy - postponing" message?
>>
>> Thanks
>>
>> On Tue, Jul 19, 2011 at 3:42 PM, Alec Swan wrote:
>> > Hello,
>> >
>> > We have a re-captcha button which refreshes captcha password image. It
>> > works fine until we add WiQuery ButtonBehavior to the button. With
>> > this behavior the captcha image is no longer refreshed and Wicked Ajax
>> > Debugger displays "INFO: "Channel busy - postponing". The following is
>> > a code snippet which describes the problem. Uncommenting add(new
>> > ButtonBehavior()) breaks re-captcha functionality.
>> >
>> > Please help,
>> >
>> > Thanks
>> >
>> > new AjaxLink("reCaptcha")
>> > {
>> > @Override
>> > public void onClick(AjaxRequestTarget target) {
>> > password = newPassword();
>> > CaptchaImageResource captchaImageResource = new
>> > CaptchaImageResource(password);
>> > NonCachingImage imgCaptcha = new
>> > NonCachingImage("captchaImage", captchaImageResource);
>> > imgCaptcha.setOutputMarkupId(true);
>> > SignUpForm.this.addOrReplace(imgCaptcha);
>> > if (target != null) {
>> > target.addComponent(imgCaptcha);
>> > }
>> > }
>> > }//.add(new ButtonBehavior())
>> >
>>
>> -
>> 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: dynamic DataTable
Thanks for the tip Bertrand, I understand SQLResultRow better now. I will
try that
Regards,
On Saturday, 23 July 2011, Bertrand Guay-Paquet
wrote:
> Hi,
>
> SQLResultRow is a type I made up. I didn't know what type you received
from your SQL query, so I used that. I assumed that your result set is
composed of rows where each row can be used as a "map" with key=column name
and value=column value.
>
> With that in hand, you could iterate over the keys to build the list of
datatable columns. Each column would hold its key value and would use it to
access the proper column value from a result row.
>
>
> On 23/07/2011 10:12 AM, davut uysal wrote:
>>
>> Hi Bertrand,
>>
>> What is SQLResultRow, is it a Wicket Type? Or should I create a custom
class
>> named "SQLResultRow"?
>>
>> The problem is, I can't create a custom "SQLResultRow" because I can't be
>> sure of its member fields.
>>
>> User can run any SQL, so the type must be compatible with any result. For
>> example:
>> 1) select firstname, lastname from employees; => Returns
>> 2) select locationcode, locationname from locations; =>
Returns
>> ... (any SQL can return any unpredictable object)
>> So it is impossible to create a custom "SQLResultRow"
>>
>> Anyway, I have solved the problem in the complex, hard way which is about
to
>> use 2 nested repeaters (ListView). 1 for table column names loop, 1 for
>> table rows loop.
>>
>> And, I got the answer: There is no easy way in wicket to do that kind of
>> dynamic thing.
>>
>> Thanks,
>>
>>
>> On 22 July 2011 18:03, Bertrand Guay-Paquet
wrote:
>>
>>> Hi,
>>>
>>> Here is the outline of a possible implementation :
>>>
>>> Execute SQL String
>>> Create a List>
>>> for each SQL result column:
>>>add a column to the list that displays one column of a SQLResultRow
>>> Create a very simple ISortableDataProvider that returns the SQL result
from
>>> above
>>> (make it more complex to implement sorting)
>>> Create a DataTable using the column list and the data provider
>>>
>>>
>>> On 22/07/2011 2:05 AM, davut uysal wrote:
>>>
Someone in another forum advised me this:
***
Maybe in latest Wicket something changed but in 1.4.16 you can't change
Columns in DataTable. So it's immutable in some sense.
But you may replace whole DataTable component instead when your sql
statement changes:
form.add(new Button("sqlSubmit") {
void onSubmit() {
String sql = ...;
form.replace(createDataTable("**myDataTable", sql));
}
})
form.add(createDataTable("**myDataTable", null));
Where createDataTable() creates DataTable using provided id and sql
string.
Also there is a convenient method Component.replaceWith(). Maybe it'll
fit
better to your coding style.
***
I think this is what I need, but I dont know how to do. Can someone
please
help me to create below method?
*createDataTable("wicketId", "SQL")*
Thanks,
On 21 July 2011 21:05, Andrew Fielden
>
> wrote:
I see your problem Davut, but I really don't think Wicket can solve it
in
>
> the
> way you want it to. As Martin said, you need an to populate
the
> models used by the various Wicket components.
> Could you somehow parse the SQL statement to extract the table name,
and
> find its meta data?
>
>
> --
> View this message in context:
> http://apache-wicket.1842946. **
n4.nabble.com/dynamic-**
> DataTable-tp3683514p3684513.**html<
http://apache-wicket.1842946.n4.nabble.com/dynamic-DataTable-tp3683514p3684513.html
>
> Sent from the Users forum mailing list archive at Nabble.com.
>
> --**--**
> -
> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<
users-unsubscr...@wicket.apache.org>
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
>>>
--**--**-
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<
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
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-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
Re: dynamic DataTable
Hi,
SQLResultRow is a type I made up. I didn't know what type you received
from your SQL query, so I used that. I assumed that your result set is
composed of rows where each row can be used as a "map" with key=column
name and value=column value.
With that in hand, you could iterate over the keys to build the list of
datatable columns. Each column would hold its key value and would use it
to access the proper column value from a result row.
On 23/07/2011 10:12 AM, davut uysal wrote:
Hi Bertrand,
What is SQLResultRow, is it a Wicket Type? Or should I create a custom class
named "SQLResultRow"?
The problem is, I can't create a custom "SQLResultRow" because I can't be
sure of its member fields.
User can run any SQL, so the type must be compatible with any result. For
example:
1) select firstname, lastname from employees; => Returns
2) select locationcode, locationname from locations; => Returns
... (any SQL can return any unpredictable object)
So it is impossible to create a custom "SQLResultRow"
Anyway, I have solved the problem in the complex, hard way which is about to
use 2 nested repeaters (ListView). 1 for table column names loop, 1 for
table rows loop.
And, I got the answer: There is no easy way in wicket to do that kind of
dynamic thing.
Thanks,
On 22 July 2011 18:03, Bertrand Guay-Paquet wrote:
Hi,
Here is the outline of a possible implementation :
Execute SQL String
Create a List>
for each SQL result column:
add a column to the list that displays one column of a SQLResultRow
Create a very simple ISortableDataProvider that returns the SQL result from
above
(make it more complex to implement sorting)
Create a DataTable using the column list and the data provider
On 22/07/2011 2:05 AM, davut uysal wrote:
Someone in another forum advised me this:
***
Maybe in latest Wicket something changed but in 1.4.16 you can't change
Columns in DataTable. So it's immutable in some sense.
But you may replace whole DataTable component instead when your sql
statement changes:
form.add(new Button("sqlSubmit") {
void onSubmit() {
String sql = ...;
form.replace(createDataTable("**myDataTable", sql));
}
})
form.add(createDataTable("**myDataTable", null));
Where createDataTable() creates DataTable using provided id and sql
string.
Also there is a convenient method Component.replaceWith(). Maybe it'll fit
better to your coding style.
***
I think this is what I need, but I dont know how to do. Can someone please
help me to create below method?
*createDataTable("wicketId", "SQL")*
Thanks,
On 21 July 2011 21:05, Andrew
Fielden
wrote:
I see your problem Davut, but I really don't think Wicket can solve it in
the
way you want it to. As Martin said, you need an to populate the
models used by the various Wicket components.
Could you somehow parse the SQL statement to extract the table name, and
find its meta data?
--
View this message in context:
http://apache-wicket.1842946.**n4.nabble.com/dynamic-**
DataTable-tp3683514p3684513.**html
Sent from the Users forum mailing list archive at Nabble.com.
--**--**
-
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: Handling futures
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
Re: dynamic DataTable
Hi Bertrand,
What is SQLResultRow, is it a Wicket Type? Or should I create a custom class
named "SQLResultRow"?
The problem is, I can't create a custom "SQLResultRow" because I can't be
sure of its member fields.
User can run any SQL, so the type must be compatible with any result. For
example:
1) select firstname, lastname from employees; => Returns
2) select locationcode, locationname from locations; => Returns
... (any SQL can return any unpredictable object)
So it is impossible to create a custom "SQLResultRow"
Anyway, I have solved the problem in the complex, hard way which is about to
use 2 nested repeaters (ListView). 1 for table column names loop, 1 for
table rows loop.
And, I got the answer: There is no easy way in wicket to do that kind of
dynamic thing.
Thanks,
On 22 July 2011 18:03, Bertrand Guay-Paquet wrote:
> Hi,
>
> Here is the outline of a possible implementation :
>
> Execute SQL String
> Create a List>
> for each SQL result column:
>add a column to the list that displays one column of a SQLResultRow
> Create a very simple ISortableDataProvider that returns the SQL result from
> above
> (make it more complex to implement sorting)
> Create a DataTable using the column list and the data provider
>
>
> On 22/07/2011 2:05 AM, davut uysal wrote:
>
>> Someone in another forum advised me this:
>>
>> ***
>> Maybe in latest Wicket something changed but in 1.4.16 you can't change
>> Columns in DataTable. So it's immutable in some sense.
>>
>> But you may replace whole DataTable component instead when your sql
>> statement changes:
>>
>> form.add(new Button("sqlSubmit") {
>>void onSubmit() {
>> String sql = ...;
>> form.replace(createDataTable("**myDataTable", sql));
>>}
>> })
>> form.add(createDataTable("**myDataTable", null));
>>
>> Where createDataTable() creates DataTable using provided id and sql
>> string.
>> Also there is a convenient method Component.replaceWith(). Maybe it'll fit
>> better to your coding style.
>>
>> ***
>>
>> I think this is what I need, but I dont know how to do. Can someone please
>> help me to create below method?
>>
>> *createDataTable("wicketId", "SQL")*
>>
>> Thanks,
>>
>> On 21 July 2011 21:05, Andrew
>> Fielden
>> >wrote:
>>
>> I see your problem Davut, but I really don't think Wicket can solve it in
>>> the
>>> way you want it to. As Martin said, you need an to populate the
>>> models used by the various Wicket components.
>>> Could you somehow parse the SQL statement to extract the table name, and
>>> find its meta data?
>>>
>>>
>>> --
>>> View this message in context:
>>> http://apache-wicket.1842946.**n4.nabble.com/dynamic-**
>>> DataTable-tp3683514p3684513.**html
>>> Sent from the Users forum mailing list archive at Nabble.com.
>>>
>>> --**--**
>>> -
>>> 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
>
>
Re: Handling futures
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
Re: Avoid doing lot of Ajax request
But I have to throttle delay for a set of same type links not only one -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Avoid-doing-lot-of-Ajax-request-tp3687472p3688488.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
