Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)

[gnul]

>> On 02 Apr 2011, at 00:13, Bruno Borges wrote:
>>
>> [    ] Please, check this box if you agree with EULA
>> [ x ] Please, uncheck this box if you don't want to receive notifications
>>
>>
>> In this case, I would set the first checkbox as required, and leave the
>> later as optional.
>>
>> Vote for (1) +1

>On Fri, Apr 1, 2011 at 5:01 PM, Maarten Billemont  wrote:
>
> Please don't pretend a checkbox is a Radio component.  This is irrelevant to 
> this discussion.
>

I don't see how radio choices could represent these options as
elegantly as checkboxes. It seems you would need four radio choices,
two for each selection, possibly each pair in a radio group.

With respect to the larger discussion, I don't think it matters. If
you wish to setRequired(true) on a checkbox, it means it must be
checked. If we're not allowed to setRequired(), then a validator can
require checked.

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

Re: Frustrating behavior ... same browser, same war, same tomcat version - different behavior!!!

[gnul]

>
> Essentially, part of the process generates dynamic web forms based on xml
> configuration files. We noticed that on one of our servers when we deployed
> the war file that the fields would not hold their values, and as soon as you
> tabbed out, the entry would disappear. Taking the same war file and
> deploying it to another server the form acts as expected.
>

If it works on one server, but not the other, and they are configured
the same (meaning same appserver/tomcat version, same jvm, same
user/group/perms, etc.), the first thing I do is "clean" the appserver
and do a fresh deploy.

For example, say you are deploying to /var/lib/tomcat/webapps/, I
would shutdown both tomcats, remove the exploded directories (e.g.
myapp.war => myapp/ ) and re-deploy the war files to each server.  I
would also clean out tomcat's temp directory (e.g.
/var/cache/tomcat5/temp), then restart them both.

 -gnul

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

Re: Very interesting question... my boss complain about one of my implementations...

[gnul]

On Thu, May 27, 2010 at 5:16 PM, Jeremy Thomerson
 wrote:
> On Thu, May 27, 2010 at 5:46 PM, Victor_Trapiello wrote:
>
>>
>> Hello guys!
>>
>> I had a terrible day because one of my bosses complain about how I have
>> done
>> one task of a project, we had to implement "something" that updates a field
>> in the database, my brilliant idea was to create a thread inside the wicket
>> init method that makes a query to the database every 3 hours and updates
>> the
>> fields.
>>
>> My boss said that it is not a good practice and he recomended  to use
>> something like in Struts called "Timers", do we have something like that in
>> wickets¿?
>>
>> how can I implement this behaviour without  a thread¿? I mean something
>> that
>> is executing since my application is deployed and executing a method every
>> N
>> time!!
>>
>> thank you very much guys, I go to sleep in Spain it is 1.00 AM and tomorrow
>> I have to go to work!!
>>
>> Waiting some feedback
>>
>> Cheers!!
>> --
>> View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/Very-interesting-question-my-boss-complain-about-one-of-my-implementations-tp2233874p2233874.html
>> Sent from the Wicket - User 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
>>
>>
> Does the "update" to the database have anything to do with the webapp?  Or
> is it something totally unrelated?  You don't really give us enough
> information to go on.
>
> Struts timers (at least the ones I know of) are for timing how long a
> webpage takes to render.  Perhaps he's confused with TimerTasks, which are
> in Java, not Struts.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>

I also do not understand how the "timer" is related to the web application.

If you are using some logic to update the database "every N time",
then I suggest using Quartz:
  https://quartz.dev.java.net/
  http://www.quartz-scheduler.org/overview/index.html

We implement a quartz task that runs every 15 minutes to pull data
over a third party API and update our database.  Wicket, like any web
application, displays the updated information on the next
[LoadableDetachableModel] data refresh which satisfies our
requirements. (If you use an ApplicationContext (e.g. Spring) you
could even update a local cache / cache cluster (e.g ehcache).)

The only tricky part of Quartz has been deploying it properly on an
application cluster -- to avoid having the same scheduled tasks run
simultaneously.  If you have a "backend" app server you can purpose
running scheduled tasks on, then it is simple.

 -gnul

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