Re: Storing user entity in session?
I already told that in this thread: move your entity storage to your custom request cycle, and just keep the entity identifier in your custom session. then always access the entity either directly from the request cycle, or through delegates from your session. There's no rocket science here. Martijn On Fri, Mar 6, 2009 at 7:27 AM, Tauren Mills wrote: > Martijn, > > I see your point about users clicking fast and causing an exception if > I keep a User in the session (transient or otherwise). I too would be > curious to see some example code of how you handle the situation. > > Thanks, > Tauren > > > On Mon, Feb 23, 2009 at 11:47 PM, Alexander Lohse wrote: >> Hi Martijn, >> >> could you paste some short example code to point out how to load and access >> a UserModel in the requestcycle? >> >> Regards, >> >> Alex >> >> Am 23.02.2009 um 08:42 schrieb Martijn Dashorst: >> - Show quoted text - >> >>> Storing the user in a field of Session is wrong. Didn't you read the >>> concurrency caveats I posted earlier? >>> >>> When users click fast enough, you'll get Hibernate exceptions pretty >>> soon. Entity instances can't be shared between multiple threads. >>> Putting them in the Session exposes them to that threat. Putting >>> transient before the field doesn't mitigate that, neither does >>> synchronized. >>> >>> Martijn >>> >>> On Fri, Feb 20, 2009 at 11:25 PM, Tauren Mills wrote: Nino and Martijn, Thanks for the help. Last night I was looking through the elephas code and found a solution that I think will work for me. It doesn't store an LDM in the session, but stores an identifier and a *transient* instance of User. This seems like an effective solution to me. I tried it out and haven't had problems yet. Here's the elephas session so you can see for yourself: http://code.google.com/p/elephas/source/browse/trunk/src/main/java/org/elephas/webapp/application/ElephasSession.java?r=87 Then on my page, I just do something like this: setDefaultModel(new DetachableUserModel(getSession().getUser(),userDao)); Please let me know your thoughts on this. Thanks, Tauren On Fri, Feb 20, 2009 at 2:05 AM, nino martinez wael wrote: > > Hi Tauren > > I've done something similar.. Have no trouble with.. > > Disclaimer, below code are really ugly and I need to clean it up... > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >>> >>> -- >>> Become a Wicket expert, learn from the best: http://wicketinaction.com >>> Apache Wicket 1.3.5 is released >>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >> >> __ >> >> "A designer knows he has achieved perfection not when there is nothing left >> to add, >> but when there is nothing left to take away." >> (Antoine de Saint Exupéry) >> . >> >> Alexander Lohse • Entwicklungsleitung & Projektmanagement >> Tel +49 38374 752 11 • Fax +49 38374 752 23 >> http://www.humantouch.de >> >> Human Touch Medienproduktion GmbH >> Am See 1 • 17440 Klein Jasedow • Deutschland >> >> Geschäftsführung: >> Lara Mallien, Nele Hybsier, Alexander Lohse, Johannes Heimrath (Senior) >> Handelsregister Stralsund • HRB 4192 • USt-IdNr. DE128367684 >> - Show quoted text - >> >> >> - >> 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 > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: localization and session expiration
May be cookie? On Fri, Mar 6, 2009 at 12:20 PM, ElSe wrote: > > Hello! > > I have a question: in my application there are several locales and the user > can choose locale on the fly. Locale is stored in the session and all is ok > while the session exists. But! When the session is expired the application > must say user about this and it does - using default locale. It is > unpleasant - from the user's point of view the application changes locale > by > its own will. Is there any workaraound for such situation? The only thought > that I have is to add locale parameter to every url but it is so ugly... > > Best regards, > Elena. > -- > View this message in context: > http://www.nabble.com/localization-and-session-expiration-tp22366384p22366384.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 > >
page expiration of main application when using iframe
Hello, I have a main application and in a page i put an iframe. the source of that iframe is another wicket application. now when navigate to the application in the iframe and then click other menus in main application the page expired. what could go wrong? there is no stacktrace displayed. Thanks a lot. Cheers. -- View this message in context: http://www.nabble.com/page-expiration-of-main-application-when-using-iframe-tp22367009p22367009.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
Re: Storing user entity in session?
Martijn, I see your point about users clicking fast and causing an exception if I keep a User in the session (transient or otherwise). I too would be curious to see some example code of how you handle the situation. Thanks, Tauren On Mon, Feb 23, 2009 at 11:47 PM, Alexander Lohse wrote: > Hi Martijn, > > could you paste some short example code to point out how to load and access > a UserModel in the requestcycle? > > Regards, > > Alex > > Am 23.02.2009 um 08:42 schrieb Martijn Dashorst: > - Show quoted text - > >> Storing the user in a field of Session is wrong. Didn't you read the >> concurrency caveats I posted earlier? >> >> When users click fast enough, you'll get Hibernate exceptions pretty >> soon. Entity instances can't be shared between multiple threads. >> Putting them in the Session exposes them to that threat. Putting >> transient before the field doesn't mitigate that, neither does >> synchronized. >> >> Martijn >> >> On Fri, Feb 20, 2009 at 11:25 PM, Tauren Mills wrote: >>> >>> Nino and Martijn, >>> >>> Thanks for the help. Last night I was looking through the elephas >>> code and found a solution that I think will work for me. It doesn't >>> store an LDM in the session, but stores an identifier and a >>> *transient* instance of User. This seems like an effective solution >>> to me. I tried it out and haven't had problems yet. Here's the >>> elephas session so you can see for yourself: >>> >>> http://code.google.com/p/elephas/source/browse/trunk/src/main/java/org/elephas/webapp/application/ElephasSession.java?r=87 >>> >>> Then on my page, I just do something like this: >>> setDefaultModel(new DetachableUserModel(getSession().getUser(),userDao)); >>> >>> Please let me know your thoughts on this. >>> >>> Thanks, >>> Tauren >>> >>> >>> On Fri, Feb 20, 2009 at 2:05 AM, nino martinez wael >>> wrote: Hi Tauren I've done something similar.. Have no trouble with.. Disclaimer, below code are really ugly and I need to clean it up... >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> >> >> -- >> Become a Wicket expert, learn from the best: http://wicketinaction.com >> Apache Wicket 1.3.5 is released >> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> > > __ > > "A designer knows he has achieved perfection not when there is nothing left > to add, > but when there is nothing left to take away." > (Antoine de Saint Exupéry) > . > > Alexander Lohse • Entwicklungsleitung & Projektmanagement > Tel +49 38374 752 11 • Fax +49 38374 752 23 > http://www.humantouch.de > > Human Touch Medienproduktion GmbH > Am See 1 • 17440 Klein Jasedow • Deutschland > > Geschäftsführung: > Lara Mallien, Nele Hybsier, Alexander Lohse, Johannes Heimrath (Senior) > Handelsregister Stralsund • HRB 4192 • USt-IdNr. DE128367684 > - Show quoted text - > > > - > 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
Equal InputValidator
Hi, How to use Equal InputValidator in wicket can any one give small example on it. Regards, Srinviasa Raju CH. Get your world in your inbox! Mail, widgets, documents, spreadsheets, organizer and much more with your Sifymail WIYI id! Log on to http://www.sify.com ** DISCLAIMER ** Information contained and transmitted by this E-MAIL is proprietary to Sify Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at ad...@sifycorp.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
localization and session expiration
Hello! I have a question: in my application there are several locales and the user can choose locale on the fly. Locale is stored in the session and all is ok while the session exists. But! When the session is expired the application must say user about this and it does - using default locale. It is unpleasant - from the user's point of view the application changes locale by its own will. Is there any workaraound for such situation? The only thought that I have is to add locale parameter to every url but it is so ugly... Best regards, Elena. -- View this message in context: http://www.nabble.com/localization-and-session-expiration-tp22366384p22366384.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
Re: AjaxEditableLabel in 1.3.0
Dear all, How can you solve the problem? I used wicket1.3.5, also have the problem: can not save with the error: java.lang.IllegalAccessError: tried to access method org.apache.wicket.Component.onModelChanging()V from class org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel$1 any suggestion? thanks a lot -- View this message in context: http://www.nabble.com/AjaxEditableLabel-in-1.3.0-tp14675483p22365003.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
Re: Is this a bug in Wicket?
Where is the 'conditionChoice' in the markup?
On Thu, Mar 5, 2009 at 2:15 PM, rjilani wrote:
>
> Hi: Gurus, I am trying to render a form and looks like wicket is not
> rendering the form elements in right sequence, here is my markup that is
> having the issues
>
>
>Search feed by name:
>
>
>
>
>
> Match all
> conditions
> Match any
> conditions
> Match all news
>
>
>
>
> here is the java code
>
> add(new TextField("feedName", new Model()));
>
>add(new RadioChoice("conditionChoice", new
> Model(),conditionChoices ).setSuffix(""));
>
> when I run the code I see the radio button choices before the text field;
> any suggestions?
>
> Thanks,
> RJ.
> --
> View this message in context:
> http://www.nabble.com/Is-this-a-bug-in-Wicket--tp22356116p22356116.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
>
>
Re: Appropriate tool for time series
Jurek, http://wicketstuff.org/grid-examples/data-grid/editable.1 This is quite nice. Regads - Cemal http://jWeekend.com jWeekend Jurek Piasek wrote: > > Hi, > > I would like to create a table/grid in wicket for presenting multiple time > series in one table. I have three time series to present in one table. > Each > time series is stored as a map with date as key and value as double > (Map). The table/grid would consist of four columns; the > date, > time series 1, time series 2, time series 3. > > What would be the best approach to create an editable and pageable > table/grid to present these three time series? > > Many thanks! > Jurek. > > -- View this message in context: http://www.nabble.com/Appropriate-tool-for-time-series-tp22362156p22362724.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
Appropriate tool for time series
Hi, I would like to create a table/grid in wicket for presenting multiple time series in one table. I have three time series to present in one table. Each time series is stored as a map with date as key and value as double (Map). The table/grid would consist of four columns; the date, time series 1, time series 2, time series 3. What would be the best approach to create an editable and pageable table/grid to present these three time series? Many thanks! Jurek.
Re: Uppercasing inputs
Igor, You made it very clear why a converter isn't appropriate. And also why you shouldn't use a Validator when you don't want to force the user to enter uppercase. But what's your opinion about using an UpperCasingModel ? Downside of overriding getInput is that you'd have to do it on TextField, PasswordTextFiled, RequiredTextField, AutoCompleteTextField, ... Or am I missing something ? Maarten On Thu, Mar 5, 2009 at 7:19 PM, Igor Vaynberg wrote: > if you want the users to have to enter the uppercase then use a > validator, if you want to uppercase for them then override getinput() > on the textfield and perform the uppercasing there. > > -igor > > On Thu, Mar 5, 2009 at 9:46 AM, Peter Ertl wrote: > > So what's the result o this? > > > > "My dear customer, actually it is not possible to upper-case your input > > because type conversion doesn't fit, validation is the wrong place,too, > and > > javascript uppercasing is not reliable if javascript is disabled. However > we > > can compute the 100.000.000 digit of pi but uppercase is too > complicated..." > > > > *g* > > > > > > Am 05.03.2009 um 17:46 schrieb jWeekend: > > > >> > >> Igor, > >> > >>> anyways, just letting you know the intention behind the converters in > >>> wicket. > >> > >> OK - that's exactly the thing that needs to be crystal clear. > >> So the bottom line is that the if in your scenario the user entering > lower > >> case strings is acceptable then, in Wicket, the conversion to upper-case > >> is > >> not a job for IConverter and something downstream should take care of a > >> the > >> transformation to upper case (within Wicket or further down). > >> > >> If the user input should not even be submitted unless it is in upper > case, > >> then use http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html > >> Adriano's solution or something that has a similar effect. > >> > >> Is that summary correct? > >> > >> Regards - Cemal > >> http://jWeekend.om jWeekend > >> > >> > >> igor.vaynberg wrote: > >>> > >>> On Thu, Mar 5, 2009 at 8:12 AM, jWeekend > >>> wrote: > > Igor, > > If there was a Java type called UpperCaseString that's what the > developer > would use as the underlying object and you would not have this > objection. > What's the difference between a converter translating 2009-04-04 to a > java.util.Date or even to a LunchDate which always sets the time part > to > midday? > >>> > >>> there isnt an UpperCaseString for a good reason :) if you went as far > >>> as creating an uppercasestring type, then i would say that it is a > >>> fair conversion. but then again, creating a type just to uppercase > >>> something seems broken, so its not a valid argument. > >>> > >>> if you had a lunchdate that sets the time to noon it would be a fair > >>> conversion because you would be converting the string date portion to > >>> a proper type. but then again, why would you have a lunchdate and not > >>> just use date if you already know the time is always noon? > >>> > >>> the point of converters is to take a type-agnostic input in a form of > >>> a string and convert it to a proper type. if your expected type is > >>> also a string then really no conversion should happen. there are > >>> *type* converters, thats is why they have tostring(object) and > >>> toobject(string), not a single object convert(object). anyways, just > >>> letting you know the intention behind the converters in wicket. i > >>> would say what you are doing is abusing the system and it is not > >>> guaranteed to keep working in 1.5. just my two cents. > >>> > I agree clearly that the translation should not be done by the > validator. > >>> > >>> my point was not that the conversion should not be done by the > >>> validator, my point was that the validator should not check the > >>> uppercase requirement. entering something in uppercase is not a > >>> requirement on the user its a requirement on the system that stores > >>> the input, validators deal with user-related requirements. > >>> > >>> -igor > >>> > > Regards - Cemal > http;//jWeekend.com > > > igor.vaynberg wrote: > > > > using conversion and validation for this is wrong. > > > > converters in wicket are meant to convert from type<->string because > > the web is type-agnostic. a string<->string conversion is not a > > conversion from wicket's point of view. yes, the code is somewhat > > unclear, we are going to address this in 1.5 where we can change some > > api and better name things. > > > > validation is also wrong. validation checks user input. the > > requirement to have this entered in uppercase is not on the user, it > > is on the system. so a validator should not fail because something > was > > entered in non-uppercase. > > > > -igor > > > > > > On Thu, Mar 5, 2009 at 1:26 AM, jWeekend < > jweekend_for...@cabouge.com> > > wrote: > >>
Re: Expected close tag for ??
You will also get this error when you accidentally use a WebComponent instead of a WebMarkupContainer. The first does not allow embedded content and will therefor issue this error. Regards, Erik. Edwin Ansicodd wrote: I find this error in my log file when a wicket page loads. Would anyone know what causes this error? ERROR org.apache.wicket.RequestCycle - unexpected exception when handling another exception: Expected close tag for -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Is this a bug in Wicket?
you have two tds in your first tr, but 3 in your next one.
also wicket just generates the html, how the browser renders it is not
dependent on wicket.
-igor
On Thu, Mar 5, 2009 at 9:15 AM, rjilani wrote:
>
> Hi: Gurus, I am trying to render a form and looks like wicket is not
> rendering the form elements in right sequence, here is my markup that is
> having the issues
>
>
> Search feed by name:
>
>
>
>
>
> Match all
> conditions
> Match any
> conditions
> Match all news
>
>
>
>
> here is the java code
>
> add(new TextField("feedName", new Model()));
>
> add(new RadioChoice("conditionChoice", new
> Model(),conditionChoices ).setSuffix(""));
>
> when I run the code I see the radio button choices before the text field;
> any suggestions?
>
> Thanks,
> RJ.
> --
> View this message in context:
> http://www.nabble.com/Is-this-a-bug-in-Wicket--tp22356116p22356116.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
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Is this a bug in Wicket?
I understand what Mr. Mattler said but is it correct from the HTML
point of view? Anybody knows what the HTML specification says about
it?
On Thu, Mar 5, 2009 at 2:49 PM, rjilani wrote:
>
> Mattler thanks for the tip, It did work like a charm, but I am bit confuse
> about this behavior.
>
> Regards,
> RJ.
>
>
> rmattler wrote:
>>
>> Don't put the in a .
>>
>> Should be:
>>
>>
>>
>>
>> Search feed by name:
>>
>>
>>
>>
>>
>>
>> Match all
>> conditions>
>> Match any
>> conditions>
>> Match all news
>>
>>
>>
>>
>>
>>
>>
>> rjilani wrote:
>>>
>>> Hi: Gurus, I am trying to render a form and looks like wicket is not
>>> rendering the form elements in right sequence, here is my markup that is
>>> having the issues
>>>
>>>
>>> Search feed by name:
>>> >> wicket:id="feedName"/>
>>>
>>>
>>>
>>>
>>> Match all
>>> conditions
>>> Match any
>>> conditions
>>> Match all news
>>>
>>>
>>>
>>>
>>> here is the java code
>>>
>>> add(new TextField("feedName", new Model()));
>>>
>>> add(new RadioChoice("conditionChoice", new
>>> Model(),conditionChoices ).setSuffix(""));
>>>
>>> when I run the code I see the radio button choices before the text field;
>>> any suggestions?
>>>
>>> Thanks,
>>> RJ.
>>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Is-this-a-bug-in-Wicket--tp22356116p22356811.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
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: null lastPage at restoreAfterSerialization
I'm not sure I can provide any additional information as we just started
looking into it (though we've been seeing it for a while). For the time
being, I'm just going to set up a cron job to remove old pagemap files.
Perhaps we could make the restore block allow a null lastPage? Btw - what
happens if the only request a client ever makes is for a resource? Will
lastPage ever be set?
Thanks!
Meetesh
On Thu, Mar 5, 2009 at 1:51 PM, Matej Knopp wrote:
> Unfortunately I wasn't able to reproduce this so I don't think this
> got resolved.
>
> -Matej
>
> On Thu, Mar 5, 2009 at 8:47 PM, Meetesh Karia
> wrote:
> > I know this has been a while, but was this ever resolved? We're seeing
> the
> > same problem. And, because of this problem, Wicket is never cleaning up
> old
> > session pagemap files which leads to oodles of files in our tomcat work
> > directory.
> > Thanks,
> > Meetesh
> >
> > On Sat, Nov 22, 2008 at 5:55 AM, Carlos Pita >wrote:
> >
> >> Matej,
> >>
> >> forget what I said yesterday about session lastAccessedDate, I've
> >> debugged it in detail and tomcat is doing its part fine, I was
> >> confused by a sequence of logs that implied that the session was
> >> swapped out before a page was added to its pagemap. But later I found
> >> out that this wasn't the usual pattern so I included more log output
> >> here and there. And now it seems as if the pagemap instance that is
> >> swapped out isn't the same one where the page was first put. Below I
> >> copied the pertinent fragments of code and one example of output
> >> showing the anomaly:
> >>
> >> 1) What follows is in order to identify each pagemap instance (with
> >> thisNum):
> >>
> >> private static final class SecondLevelCachePageMap extends PageMap
> >> {
> >>
> >>
> >> private static int pageMapNum = 0;
> >> private int thisNum;
> >>
> >> private SecondLevelCachePageMap(String sessionId, Application
> >> application, String name)
> >> {
> >>
> >> synchronized (SecondLevelCachePageMap.class)
> >> {
> >> thisNum = pageMapNum++;
> >> }
> >>
> >> }
> >>
> >> 2) Now for the logging part
> >>
> >> a) First when a page is put into the pagemap
> >>
> >> public void put(Page page)
> >> {
> >> if (!page.isPageStateless())
> >> {
> >> Session session = getSession();
> >> String sessionId = session.getId();
> >> if (sessionId != null && !session.isSessionInvalidated())
> >> {
> >> // the id could have changed from null during request
> >> this.sessionId = sessionId;
> >> > log.error("put " + sessionId + " " + thisNum); <
> >> getStore().storePage(sessionId, page);
> >> setLastPage(page);
> >> dirty();
> >> }
> >> }
> >> }
> >>
> >> b) Then when a pagemap is swapped out (writeObject):
> >>
> >> private void writeObject(java.io.ObjectOutputStream s) throws
> IOException
> >> {
> >> s.defaultWriteObject();
> >> IPageStore store = getPageStore();
> >> if (sessionId != null && store instanceof IClusteredPageStore == false)
> >> {
> >> --> if (lastPage == null) log.error("writeObject1 " + sessionId + " "
> >> + thisNum); <--
> >> Object page = lastPage;
> >> if (store instanceof ISerializationAwarePageStore)
> >> {
> >> page =
> (ISerializationAwarePageStore)store).prepareForSerialization(...
> >> --> if (page == null) log.error("writeObject2 " + sessionId + " " +
> >> thisNum); <--
> >> }
> >> }
> >> .
> >> }
> >>
> >> Finally, the output looks like:
> >>
> >> 2008-11-22 04:43:58,841 PAGE 19ACC6B64E22346D494E742A0E859B52 29
> >>
> >>
> >> other pages in other sessions follows
> >>
> >> 2008-11-22 04:44:00,486 put 33932E31AE77206B5E556266170B4827 33
> >> 2008-11-22 04:44:00,201 put C6423FDD58C4B31C080700E4455F158C
> >>
> >>
> >> and about 120 secs later:
> >>
> >> 2008-11-22 04:46:36,432 writeObject1 19ACC6B64E22346D494E742A0E859B52 30
> >> 2008-11-22 04:46:36,432 writeObject2 19ACC6B64E22346D494E742A0E859B52 30
> >>
> >>
> >> In every case I've seen the instance num for the writeObject1/2 logs
> >> was one plus the num for the put log in the same session. I think that
> >> here the second pagemap (30) is created with a default lastPage = null
> >> that never is assigned a non null page, because put is being called on
> >> the first pagemap (29) instead.
> >>
> >> I still don't know where the second pagemap is created, but I'm getting
> >> closer.
> >>
> >> HIH
> >> -Carlos
> >>
> >> On Thu, Nov 20, 2008 at 3:05 AM, Carlos Pita
> >> wrote:
> >> > Hi Matej,
> >> >
> >> > I'm browsing your changes. Please notice that according to my own
> >> > debugging it's lastPage itself that is null and not only the result of
> >> > prepareForSerialization. So I don't think the warning "PageStore
> >> > prepared non-null page as null for serialization" will ever be
> >> > reached. Anyway, I will add other warnings and keep you informed of
> >> > the output as soon as I can. This is really tricky to debug because up
> >> > til today I'm only able to reproduce it at full scale in a production
> >> >
Re: null lastPage at restoreAfterSerialization
Unfortunately I wasn't able to reproduce this so I don't think this
got resolved.
-Matej
On Thu, Mar 5, 2009 at 8:47 PM, Meetesh Karia wrote:
> I know this has been a while, but was this ever resolved? We're seeing the
> same problem. And, because of this problem, Wicket is never cleaning up old
> session pagemap files which leads to oodles of files in our tomcat work
> directory.
> Thanks,
> Meetesh
>
> On Sat, Nov 22, 2008 at 5:55 AM, Carlos Pita wrote:
>
>> Matej,
>>
>> forget what I said yesterday about session lastAccessedDate, I've
>> debugged it in detail and tomcat is doing its part fine, I was
>> confused by a sequence of logs that implied that the session was
>> swapped out before a page was added to its pagemap. But later I found
>> out that this wasn't the usual pattern so I included more log output
>> here and there. And now it seems as if the pagemap instance that is
>> swapped out isn't the same one where the page was first put. Below I
>> copied the pertinent fragments of code and one example of output
>> showing the anomaly:
>>
>> 1) What follows is in order to identify each pagemap instance (with
>> thisNum):
>>
>> private static final class SecondLevelCachePageMap extends PageMap
>> {
>>
>>
>> private static int pageMapNum = 0;
>> private int thisNum;
>>
>> private SecondLevelCachePageMap(String sessionId, Application
>> application, String name)
>> {
>>
>> synchronized (SecondLevelCachePageMap.class)
>> {
>> thisNum = pageMapNum++;
>> }
>>
>> }
>>
>> 2) Now for the logging part
>>
>> a) First when a page is put into the pagemap
>>
>> public void put(Page page)
>> {
>> if (!page.isPageStateless())
>> {
>> Session session = getSession();
>> String sessionId = session.getId();
>> if (sessionId != null && !session.isSessionInvalidated())
>> {
>> // the id could have changed from null during request
>> this.sessionId = sessionId;
>> > log.error("put " + sessionId + " " + thisNum); <
>> getStore().storePage(sessionId, page);
>> setLastPage(page);
>> dirty();
>> }
>> }
>> }
>>
>> b) Then when a pagemap is swapped out (writeObject):
>>
>> private void writeObject(java.io.ObjectOutputStream s) throws IOException
>> {
>> s.defaultWriteObject();
>> IPageStore store = getPageStore();
>> if (sessionId != null && store instanceof IClusteredPageStore == false)
>> {
>> --> if (lastPage == null) log.error("writeObject1 " + sessionId + " "
>> + thisNum); <--
>> Object page = lastPage;
>> if (store instanceof ISerializationAwarePageStore)
>> {
>> page = (ISerializationAwarePageStore)store).prepareForSerialization(...
>> --> if (page == null) log.error("writeObject2 " + sessionId + " " +
>> thisNum); <--
>> }
>> }
>> .
>> }
>>
>> Finally, the output looks like:
>>
>> 2008-11-22 04:43:58,841 PAGE 19ACC6B64E22346D494E742A0E859B52 29
>>
>>
>> other pages in other sessions follows
>>
>> 2008-11-22 04:44:00,486 put 33932E31AE77206B5E556266170B4827 33
>> 2008-11-22 04:44:00,201 put C6423FDD58C4B31C080700E4455F158C
>>
>>
>> and about 120 secs later:
>>
>> 2008-11-22 04:46:36,432 writeObject1 19ACC6B64E22346D494E742A0E859B52 30
>> 2008-11-22 04:46:36,432 writeObject2 19ACC6B64E22346D494E742A0E859B52 30
>>
>>
>> In every case I've seen the instance num for the writeObject1/2 logs
>> was one plus the num for the put log in the same session. I think that
>> here the second pagemap (30) is created with a default lastPage = null
>> that never is assigned a non null page, because put is being called on
>> the first pagemap (29) instead.
>>
>> I still don't know where the second pagemap is created, but I'm getting
>> closer.
>>
>> HIH
>> -Carlos
>>
>> On Thu, Nov 20, 2008 at 3:05 AM, Carlos Pita
>> wrote:
>> > Hi Matej,
>> >
>> > I'm browsing your changes. Please notice that according to my own
>> > debugging it's lastPage itself that is null and not only the result of
>> > prepareForSerialization. So I don't think the warning "PageStore
>> > prepared non-null page as null for serialization" will ever be
>> > reached. Anyway, I will add other warnings and keep you informed of
>> > the output as soon as I can. This is really tricky to debug because up
>> > til today I'm only able to reproduce it at full scale in a production
>> > environment.
>> >
>> > Do you have any idea why a lastPage would be null after 120 secs of
>> > the request that created the session? Specially for sessions that
>> > don't survive that first request. An exception that could avoid
>> > request cycle to detach the session maybe?
>> >
>> > Thanks!
>> > -Carlos
>> >
>> >
>> > On Wed, Nov 19, 2008 at 7:18 PM, Matej Knopp
>> wrote:
>> >> This really is weird. I added couple of warnings and null check to 1.4
>> >> trunk. I wonder if that helps it though.
>> >>
>> >> -Matej
>> >>
>> >> On Wed, Nov 19, 2008 at 12:44 PM, Carlos Pita
>> wrote:
>> >>> The last one of the saga for now, I badly need to sleep.
>> >>>
>> >>> I've been sampling tomcat work dir every second:
>> >>>
>> >>
Re: null lastPage at restoreAfterSerialization
I know this has been a while, but was this ever resolved? We're seeing the
same problem. And, because of this problem, Wicket is never cleaning up old
session pagemap files which leads to oodles of files in our tomcat work
directory.
Thanks,
Meetesh
On Sat, Nov 22, 2008 at 5:55 AM, Carlos Pita wrote:
> Matej,
>
> forget what I said yesterday about session lastAccessedDate, I've
> debugged it in detail and tomcat is doing its part fine, I was
> confused by a sequence of logs that implied that the session was
> swapped out before a page was added to its pagemap. But later I found
> out that this wasn't the usual pattern so I included more log output
> here and there. And now it seems as if the pagemap instance that is
> swapped out isn't the same one where the page was first put. Below I
> copied the pertinent fragments of code and one example of output
> showing the anomaly:
>
> 1) What follows is in order to identify each pagemap instance (with
> thisNum):
>
> private static final class SecondLevelCachePageMap extends PageMap
> {
>
>
> private static int pageMapNum = 0;
> private int thisNum;
>
> private SecondLevelCachePageMap(String sessionId, Application
> application, String name)
> {
>
> synchronized (SecondLevelCachePageMap.class)
> {
> thisNum = pageMapNum++;
> }
>
> }
>
> 2) Now for the logging part
>
> a) First when a page is put into the pagemap
>
> public void put(Page page)
> {
> if (!page.isPageStateless())
> {
> Session session = getSession();
> String sessionId = session.getId();
> if (sessionId != null && !session.isSessionInvalidated())
> {
> // the id could have changed from null during request
> this.sessionId = sessionId;
> > log.error("put " + sessionId + " " + thisNum); <
> getStore().storePage(sessionId, page);
> setLastPage(page);
> dirty();
> }
> }
> }
>
> b) Then when a pagemap is swapped out (writeObject):
>
> private void writeObject(java.io.ObjectOutputStream s) throws IOException
> {
> s.defaultWriteObject();
> IPageStore store = getPageStore();
> if (sessionId != null && store instanceof IClusteredPageStore == false)
> {
> --> if (lastPage == null) log.error("writeObject1 " + sessionId + " "
> + thisNum); <--
> Object page = lastPage;
> if (store instanceof ISerializationAwarePageStore)
> {
> page = (ISerializationAwarePageStore)store).prepareForSerialization(...
> --> if (page == null) log.error("writeObject2 " + sessionId + " " +
> thisNum); <--
> }
> }
> .
> }
>
> Finally, the output looks like:
>
> 2008-11-22 04:43:58,841 PAGE 19ACC6B64E22346D494E742A0E859B52 29
>
>
> other pages in other sessions follows
>
> 2008-11-22 04:44:00,486 put 33932E31AE77206B5E556266170B4827 33
> 2008-11-22 04:44:00,201 put C6423FDD58C4B31C080700E4455F158C
>
>
> and about 120 secs later:
>
> 2008-11-22 04:46:36,432 writeObject1 19ACC6B64E22346D494E742A0E859B52 30
> 2008-11-22 04:46:36,432 writeObject2 19ACC6B64E22346D494E742A0E859B52 30
>
>
> In every case I've seen the instance num for the writeObject1/2 logs
> was one plus the num for the put log in the same session. I think that
> here the second pagemap (30) is created with a default lastPage = null
> that never is assigned a non null page, because put is being called on
> the first pagemap (29) instead.
>
> I still don't know where the second pagemap is created, but I'm getting
> closer.
>
> HIH
> -Carlos
>
> On Thu, Nov 20, 2008 at 3:05 AM, Carlos Pita
> wrote:
> > Hi Matej,
> >
> > I'm browsing your changes. Please notice that according to my own
> > debugging it's lastPage itself that is null and not only the result of
> > prepareForSerialization. So I don't think the warning "PageStore
> > prepared non-null page as null for serialization" will ever be
> > reached. Anyway, I will add other warnings and keep you informed of
> > the output as soon as I can. This is really tricky to debug because up
> > til today I'm only able to reproduce it at full scale in a production
> > environment.
> >
> > Do you have any idea why a lastPage would be null after 120 secs of
> > the request that created the session? Specially for sessions that
> > don't survive that first request. An exception that could avoid
> > request cycle to detach the session maybe?
> >
> > Thanks!
> > -Carlos
> >
> >
> > On Wed, Nov 19, 2008 at 7:18 PM, Matej Knopp
> wrote:
> >> This really is weird. I added couple of warnings and null check to 1.4
> >> trunk. I wonder if that helps it though.
> >>
> >> -Matej
> >>
> >> On Wed, Nov 19, 2008 at 12:44 PM, Carlos Pita
> wrote:
> >>> The last one of the saga for now, I badly need to sleep.
> >>>
> >>> I've been sampling tomcat work dir every second:
> >>>
> >>> i=0; while [[ i -le 300 ]]; do echo $i; ls -lt /u01/tomcatWork/_ >
> >>> /tmp/work$i; sleep 1; i=$((i + 1)); done
> >>>
> >>> Then I greped a number of session ids corresponding to
> >>> restoreAfterSerialization errors and every one of them appears in zero
> >>> or one samples at most. With maxIdle
Re: a bit of topic but i couldnt resist ....
Yes, I understand your point. It is also eloquently formulated in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4730113.
Maybe try to submit a patch via http://openjdk.java.net/ ?
Regards,
Dave
Johan Compagner wrote:
But now you are completely breaking My contact
My object is an database object
MyObject
{
id
name
}
MyObject is only equals if the id is the same
But now i want a TreeSet that orders by name (sometimes case is
important,sometimes not)
Those things are not the same!
I cant make my object equals on name.. That would break everything else!
And that is just not true
I know TreeSet is a special case, but thats the whole point it should always
just use the comparator with everything.
Then it is jus always clear.
if we revert it
HashSet.removeAll(TreeSet)
now suddenly the comparator of the TreeSet is used to remove things from the
HashSet
That is just plain weird and stupid.
johan
On Thu, Mar 5, 2009 at 18:41, Dave Schoorl wrote:
Sorry Pointbreak, I did not change the Comparators. They are identical to
Johan's example. All I did was to add the equals() and hascode() methods,
aligning the equals with the Comparator, as described by the specs.
Indeed, maybe I am missing Johan's point. But early in this thread Johan
described his point as "we have to know the implementations" and illustrated
that with the Set-example. My point is that you don't have to know the
implementations when all contracts are fulfilled correctly. And I tried to
point out in his example, that the contracts are not fulfilled correctly.
But now I think Johan tries to make the point that the TreeSet is useless
given the contracts, because the Comparator and equals() method must be
compatible. Or he tries to make the point that the TreeSet implementation is
broken and the specification must be changed. I'm not sure. I can sympathize
with both. But I am glad he pointed out the problems with TreeSet, because I
wasn't aware of them.
Pointbreak wrote:
Dave, you are missing the point completely. The issue raised by Johan is
that if you call TreeSet.removeAll(otherSet), then in some cases the
comperator/equals contract of otherSet is used, in other cases the
comperator/equals contract of the treeset. Which is a bit strange, and
even by Sun considered a bug (although low priority). You are just
making both comperators the same, which of course will not demonstrate
this problem. Make the comperator of the TreeSet use str.compareTo
instead of compareToIgnoreCase, while keeping your implementation of
MyObject the same, and you will have the same problem that Johan
illustrated.
On Thu, 05 Mar 2009 16:51 +0100, "Dave Schoorl"
wrote:
I do understand your point. However you are dealing with multiple
contracts and not all of them are satisfied. And sometimes contracts are
conflicting and it is impossible to meet all contracts, but I believe this
is not the case in your scenario.
A TreeSet is an implementation of a Set and must obey the Set contract.
Adding order to the Set should not break the Set contract, because if I have
a Set, I should not be concerned with the implementation details (is it a
TreeSet or a HashSet or whatever). I believe the Set contract takes
precedence over the Comparator contract, but in your case, by providing an
equals method to MyObject that is in line with the Comparator, there still
is no problem. See the code below, where MyObject implements the equals
method with by comparing case insensitive:
-
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: Uppercasing inputs
Could there be any unexpected consequences when just up-casing the
string in the model's setter (setObject(...)) ?
like this...
void setObject(String input)
{
this.value = (input != null) ? input.toUpperCase() : null;
}
Am 05.03.2009 um 19:39 schrieb jWeekend:
Leszek,
Thank you asking such a deep question ;-)
We may not all agree, but in the end, at least you have been offered
around
87 well-intentioned solutions you can ask your customer to choose
from; that
will teach them to request such complex features and fuctionality!
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data should
be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22357806.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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Leszek,
Thank you asking such a deep question ;-)
We may not all agree, but in the end, at least you have been offered around
87 well-intentioned solutions you can ask your customer to choose from; that
will teach them to request such complex features and fuctionality!
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
>
> Hello,
>
> one of my customers has this weird requirement that all data should be
> input/shown uppercase. I can easily add
>
> input {
>text-transform: uppercase;
> }
>
> to my css rules, but this does not change the fact that data written
> into database will still be case sensitive.
>
> How can I create a behavior for TextField so that the dat is uppercased
> before being written to the model?
>
> my regards
>
> --
> Leszek Gawron
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22357806.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
Re: a bit of topic but i couldnt resist ....
But now you are completely breaking My contact
My object is an database object
MyObject
{
id
name
}
MyObject is only equals if the id is the same
But now i want a TreeSet that orders by name (sometimes case is
important,sometimes not)
Those things are not the same!
I cant make my object equals on name.. That would break everything else!
And that is just not true
I know TreeSet is a special case, but thats the whole point it should always
just use the comparator with everything.
Then it is jus always clear.
if we revert it
HashSet.removeAll(TreeSet)
now suddenly the comparator of the TreeSet is used to remove things from the
HashSet
That is just plain weird and stupid.
johan
On Thu, Mar 5, 2009 at 18:41, Dave Schoorl wrote:
> Sorry Pointbreak, I did not change the Comparators. They are identical to
> Johan's example. All I did was to add the equals() and hascode() methods,
> aligning the equals with the Comparator, as described by the specs.
>
> Indeed, maybe I am missing Johan's point. But early in this thread Johan
> described his point as "we have to know the implementations" and illustrated
> that with the Set-example. My point is that you don't have to know the
> implementations when all contracts are fulfilled correctly. And I tried to
> point out in his example, that the contracts are not fulfilled correctly.
>
> But now I think Johan tries to make the point that the TreeSet is useless
> given the contracts, because the Comparator and equals() method must be
> compatible. Or he tries to make the point that the TreeSet implementation is
> broken and the specification must be changed. I'm not sure. I can sympathize
> with both. But I am glad he pointed out the problems with TreeSet, because I
> wasn't aware of them.
>
>
>
> Pointbreak wrote:
>
>> Dave, you are missing the point completely. The issue raised by Johan is
>> that if you call TreeSet.removeAll(otherSet), then in some cases the
>> comperator/equals contract of otherSet is used, in other cases the
>> comperator/equals contract of the treeset. Which is a bit strange, and
>> even by Sun considered a bug (although low priority). You are just
>> making both comperators the same, which of course will not demonstrate
>> this problem. Make the comperator of the TreeSet use str.compareTo
>> instead of compareToIgnoreCase, while keeping your implementation of
>> MyObject the same, and you will have the same problem that Johan
>> illustrated.
>>
>> On Thu, 05 Mar 2009 16:51 +0100, "Dave Schoorl"
>> wrote:
>>
>>
>>> I do understand your point. However you are dealing with multiple
>>> contracts and not all of them are satisfied. And sometimes contracts are
>>> conflicting and it is impossible to meet all contracts, but I believe this
>>> is not the case in your scenario.
>>>
>>> A TreeSet is an implementation of a Set and must obey the Set contract.
>>> Adding order to the Set should not break the Set contract, because if I have
>>> a Set, I should not be concerned with the implementation details (is it a
>>> TreeSet or a HashSet or whatever). I believe the Set contract takes
>>> precedence over the Comparator contract, but in your case, by providing an
>>> equals method to MyObject that is in line with the Comparator, there still
>>> is no problem. See the code below, where MyObject implements the equals
>>> method with by comparing case insensitive:
>>>
>>>
>>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Uppercasing inputs
Due to the mind-boggling complexity of this issue I wrote an open source library 'upstring.jar' which provides plenty of useful stuff... example classes and methods... - class UpperCaseString - class LowerCaseString - class InitialUpperCaseWithRemainingLowerCaseString - class CamelCaseString - class UpperCaseAtPositionString(int firstIndex, int lastIndex) - UpperCaseDecorator(String original) - UpperCaseProvider.getUpperCaseInstance(Locale locale) - UpperCaseUtil.countUpperCaseChars(Object arg) Am 05.03.2009 um 19:01 schrieb jWeekend: Dear Software House, We realise that our requirement is very demanding and challenging but we are not used to such honestly; we usually have to pay for several man years of a team of top software experts before they discover that they cannot deliver a solution to our problem. As a sign of our gratitude and respect for your expert foresight, we would like to engage your services for the next 12 months to provide us with the value of PI, accurate to 3 decimal places, as long as you are willing to explain the algorithm to our president who has been wondering why this is not the same as 22/7 since he was kicked out of school at the age of 15 for beating up his Ethics teacher, despite being quite good at mathematics. Your Grateful Customer Peter Ertl-3 wrote: So what's the result o this? "My dear customer, actually it is not possible to upper-case your input because type conversion doesn't fit, validation is the wrong place,too, and javascript uppercasing is not reliable if javascript is disabled. However we can compute the 100.000.000 digit of pi but uppercase is too complicated..." *g* Am 05.03.2009 um 17:46 schrieb jWeekend: Igor, anyways, just letting you know the intention behind the converters in wicket. OK - that's exactly the thing that needs to be crystal clear. So the bottom line is that the if in your scenario the user entering lower case strings is acceptable then, in Wicket, the conversion to upper- case is not a job for IConverter and something downstream should take care of a the transformation to upper case (within Wicket or further down). If the user input should not even be submitted unless it is in upper case, then use http://www.nabble.com/Re%3A-Uppercasing-inputs- p22332471.html Adriano's solution or something that has a similar effect. Is that summary correct? Regards - Cemal http://jWeekend.om jWeekend igor.vaynberg wrote: On Thu, Mar 5, 2009 at 8:12 AM, jWeekend wrote: Igor, If there was a Java type called UpperCaseString that's what the developer would use as the underlying object and you would not have this objection. What's the difference between a converter translating 2009-04-04 to a java.util.Date or even to a LunchDate which always sets the time part to midday? there isnt an UpperCaseString for a good reason :) if you went as far as creating an uppercasestring type, then i would say that it is a fair conversion. but then again, creating a type just to uppercase something seems broken, so its not a valid argument. if you had a lunchdate that sets the time to noon it would be a fair conversion because you would be converting the string date portion to a proper type. but then again, why would you have a lunchdate and not just use date if you already know the time is always noon? the point of converters is to take a type-agnostic input in a form of a string and convert it to a proper type. if your expected type is also a string then really no conversion should happen. there are *type* converters, thats is why they have tostring(object) and toobject(string), not a single object convert(object). anyways, just letting you know the intention behind the converters in wicket. i would say what you are doing is abusing the system and it is not guaranteed to keep working in 1.5. just my two cents. I agree clearly that the translation should not be done by the validator. my point was not that the conversion should not be done by the validator, my point was that the validator should not check the uppercase requirement. entering something in uppercase is not a requirement on the user its a requirement on the system that stores the input, validators deal with user-related requirements. -igor Regards - Cemal http;//jWeekend.com igor.vaynberg wrote: using conversion and validation for this is wrong. converters in wicket are meant to convert from type<->string because the web is type-agnostic. a string<->string conversion is not a conversion from wicket's point of view. yes, the code is somewhat unclear, we are going to address this in 1.5 where we can change some api and better name things. validation is also wrong. validation checks user input. the requirement to have this entered in uppercase is not on the user, it is on the system. so a validator should not fail because something was entered in non-uppercase. -igor On Thu, Mar 5, 2009 at 1:26 AM, jWeekend wrote
Re: Uppercasing inputs
if you want the users to have to enter the uppercase then use a validator, if you want to uppercase for them then override getinput() on the textfield and perform the uppercasing there. -igor On Thu, Mar 5, 2009 at 9:46 AM, Peter Ertl wrote: > So what's the result o this? > > "My dear customer, actually it is not possible to upper-case your input > because type conversion doesn't fit, validation is the wrong place,too, and > javascript uppercasing is not reliable if javascript is disabled. However we > can compute the 100.000.000 digit of pi but uppercase is too complicated..." > > *g* > > > Am 05.03.2009 um 17:46 schrieb jWeekend: > >> >> Igor, >> >>> anyways, just letting you know the intention behind the converters in >>> wicket. >> >> OK - that's exactly the thing that needs to be crystal clear. >> So the bottom line is that the if in your scenario the user entering lower >> case strings is acceptable then, in Wicket, the conversion to upper-case >> is >> not a job for IConverter and something downstream should take care of a >> the >> transformation to upper case (within Wicket or further down). >> >> If the user input should not even be submitted unless it is in upper case, >> then use http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html >> Adriano's solution or something that has a similar effect. >> >> Is that summary correct? >> >> Regards - Cemal >> http://jWeekend.om jWeekend >> >> >> igor.vaynberg wrote: >>> >>> On Thu, Mar 5, 2009 at 8:12 AM, jWeekend >>> wrote: Igor, If there was a Java type called UpperCaseString that's what the developer would use as the underlying object and you would not have this objection. What's the difference between a converter translating 2009-04-04 to a java.util.Date or even to a LunchDate which always sets the time part to midday? >>> >>> there isnt an UpperCaseString for a good reason :) if you went as far >>> as creating an uppercasestring type, then i would say that it is a >>> fair conversion. but then again, creating a type just to uppercase >>> something seems broken, so its not a valid argument. >>> >>> if you had a lunchdate that sets the time to noon it would be a fair >>> conversion because you would be converting the string date portion to >>> a proper type. but then again, why would you have a lunchdate and not >>> just use date if you already know the time is always noon? >>> >>> the point of converters is to take a type-agnostic input in a form of >>> a string and convert it to a proper type. if your expected type is >>> also a string then really no conversion should happen. there are >>> *type* converters, thats is why they have tostring(object) and >>> toobject(string), not a single object convert(object). anyways, just >>> letting you know the intention behind the converters in wicket. i >>> would say what you are doing is abusing the system and it is not >>> guaranteed to keep working in 1.5. just my two cents. >>> I agree clearly that the translation should not be done by the validator. >>> >>> my point was not that the conversion should not be done by the >>> validator, my point was that the validator should not check the >>> uppercase requirement. entering something in uppercase is not a >>> requirement on the user its a requirement on the system that stores >>> the input, validators deal with user-related requirements. >>> >>> -igor >>> Regards - Cemal http;//jWeekend.com igor.vaynberg wrote: > > using conversion and validation for this is wrong. > > converters in wicket are meant to convert from type<->string because > the web is type-agnostic. a string<->string conversion is not a > conversion from wicket's point of view. yes, the code is somewhat > unclear, we are going to address this in 1.5 where we can change some > api and better name things. > > validation is also wrong. validation checks user input. the > requirement to have this entered in uppercase is not on the user, it > is on the system. so a validator should not fail because something was > entered in non-uppercase. > > -igor > > > On Thu, Mar 5, 2009 at 1:26 AM, jWeekend > wrote: >> >> Martijn, >> >> Is there not already an EasyUpperCaseRUs.com web service you can >> subscribe >> to for unlimited conversions at an annual fee of under 30,000USD (or >> 100USD/conversion) who also have a "5 free conversions" trial >> subscription? >> >> Ether way, I would suggest this be done at conversion time so >> validation >> can >> do its job properly and you're not handing off conversion >> responsibilities >> where they don't belong. Some solutions leaving this transformation of >> the >> text input by the user until after conversion in the form processing >> life-cycle may be less lines of code (or less classes), but IMO, are >> bend
Re: Button onSubmit not called, instead page reloads
Here's the culprit:
# Home
{above is an html link}
Don't know why I used
--
View this message in context:
http://www.nabble.com/Button-onSubmit-not-called%2C-instead-page-reloads-tp22350921p22357126.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
Re: Uppercasing inputs
Dear Software House, We realise that our requirement is very demanding and challenging but we are not used to such honestly; we usually have to pay for several man years of a team of top software experts before they discover that they cannot deliver a solution to our problem. As a sign of our gratitude and respect for your expert foresight, we would like to engage your services for the next 12 months to provide us with the value of PI, accurate to 3 decimal places, as long as you are willing to explain the algorithm to our president who has been wondering why this is not the same as 22/7 since he was kicked out of school at the age of 15 for beating up his Ethics teacher, despite being quite good at mathematics. Your Grateful Customer Peter Ertl-3 wrote: > > So what's the result o this? > > "My dear customer, actually it is not possible to upper-case your > input because type conversion doesn't fit, validation is the wrong > place,too, and javascript uppercasing is not reliable if javascript is > disabled. However we can compute the 100.000.000 digit of pi but > uppercase is too complicated..." > > *g* > > > Am 05.03.2009 um 17:46 schrieb jWeekend: > >> >> Igor, >> >>> anyways, just letting you know the intention behind the converters in >>> wicket. >> >> OK - that's exactly the thing that needs to be crystal clear. >> So the bottom line is that the if in your scenario the user entering >> lower >> case strings is acceptable then, in Wicket, the conversion to upper- >> case is >> not a job for IConverter and something downstream should take care >> of a the >> transformation to upper case (within Wicket or further down). >> >> If the user input should not even be submitted unless it is in upper >> case, >> then use http://www.nabble.com/Re%3A-Uppercasing-inputs- >> p22332471.html >> Adriano's solution or something that has a similar effect. >> >> Is that summary correct? >> >> Regards - Cemal >> http://jWeekend.om jWeekend >> >> >> igor.vaynberg wrote: >>> >>> On Thu, Mar 5, 2009 at 8:12 AM, jWeekend >>> >>> wrote: Igor, If there was a Java type called UpperCaseString that's what the developer would use as the underlying object and you would not have this objection. What's the difference between a converter translating 2009-04-04 to a java.util.Date or even to a LunchDate which always sets the time part to midday? >>> >>> there isnt an UpperCaseString for a good reason :) if you went as far >>> as creating an uppercasestring type, then i would say that it is a >>> fair conversion. but then again, creating a type just to uppercase >>> something seems broken, so its not a valid argument. >>> >>> if you had a lunchdate that sets the time to noon it would be a fair >>> conversion because you would be converting the string date portion to >>> a proper type. but then again, why would you have a lunchdate and not >>> just use date if you already know the time is always noon? >>> >>> the point of converters is to take a type-agnostic input in a form of >>> a string and convert it to a proper type. if your expected type is >>> also a string then really no conversion should happen. there are >>> *type* converters, thats is why they have tostring(object) and >>> toobject(string), not a single object convert(object). anyways, just >>> letting you know the intention behind the converters in wicket. i >>> would say what you are doing is abusing the system and it is not >>> guaranteed to keep working in 1.5. just my two cents. >>> I agree clearly that the translation should not be done by the validator. >>> >>> my point was not that the conversion should not be done by the >>> validator, my point was that the validator should not check the >>> uppercase requirement. entering something in uppercase is not a >>> requirement on the user its a requirement on the system that stores >>> the input, validators deal with user-related requirements. >>> >>> -igor >>> Regards - Cemal http;//jWeekend.com igor.vaynberg wrote: > > using conversion and validation for this is wrong. > > converters in wicket are meant to convert from type<->string > because > the web is type-agnostic. a string<->string conversion is not a > conversion from wicket's point of view. yes, the code is somewhat > unclear, we are going to address this in 1.5 where we can change > some > api and better name things. > > validation is also wrong. validation checks user input. the > requirement to have this entered in uppercase is not on the user, > it > is on the system. so a validator should not fail because > something was > entered in non-uppercase. > > -igor > > > On Thu, Mar 5, 2009 at 1:26 AM, jWeekend > > wrote: >> >> Martijn, >> >> Is there not already an EasyUpperCaseRUs.com web service you can
Re: Button onSubmit not called, instead page reloads
Thank you for checking it out!! I'm going through the html now. Michael Sparer wrote: > > i just tested your code and it worked for me. maybe there's something > wrong in the basepage? or in the markup? > > -- View this message in context: http://www.nabble.com/Button-onSubmit-not-called%2C-instead-page-reloads-tp22350921p22356928.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
Re: Is this a bug in Wicket?
Mattler thanks for the tip, It did work like a charm, but I am bit confuse
about this behavior.
Regards,
RJ.
rmattler wrote:
>
> Don't put the in a .
>
> Should be:
>
>
>
>
> Search feed by name:
>
>
>
>
>
>
> Match all
> conditions>
> Match any
> conditions>
> Match all news
>
>
>
>
>
>
>
>
> rjilani wrote:
>>
>> Hi: Gurus, I am trying to render a form and looks like wicket is not
>> rendering the form elements in right sequence, here is my markup that is
>> having the issues
>>
>>
>> Search feed by name:
>> > wicket:id="feedName"/>
>>
>>
>>
>>
>> Match all
>> conditions
>> Match any
>> conditions
>> Match all news
>>
>>
>>
>>
>> here is the java code
>>
>> add(new TextField("feedName", new Model()));
>>
>> add(new RadioChoice("conditionChoice", new
>> Model(),conditionChoices ).setSuffix(""));
>>
>> when I run the code I see the radio button choices before the text field;
>> any suggestions?
>>
>> Thanks,
>> RJ.
>>
>
>
--
View this message in context:
http://www.nabble.com/Is-this-a-bug-in-Wicket--tp22356116p22356811.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
Re: Uppercasing inputs
So what's the result o this? "My dear customer, actually it is not possible to upper-case your input because type conversion doesn't fit, validation is the wrong place,too, and javascript uppercasing is not reliable if javascript is disabled. However we can compute the 100.000.000 digit of pi but uppercase is too complicated..." *g* Am 05.03.2009 um 17:46 schrieb jWeekend: Igor, anyways, just letting you know the intention behind the converters in wicket. OK - that's exactly the thing that needs to be crystal clear. So the bottom line is that the if in your scenario the user entering lower case strings is acceptable then, in Wicket, the conversion to upper- case is not a job for IConverter and something downstream should take care of a the transformation to upper case (within Wicket or further down). If the user input should not even be submitted unless it is in upper case, then use http://www.nabble.com/Re%3A-Uppercasing-inputs- p22332471.html Adriano's solution or something that has a similar effect. Is that summary correct? Regards - Cemal http://jWeekend.om jWeekend igor.vaynberg wrote: On Thu, Mar 5, 2009 at 8:12 AM, jWeekend wrote: Igor, If there was a Java type called UpperCaseString that's what the developer would use as the underlying object and you would not have this objection. What's the difference between a converter translating 2009-04-04 to a java.util.Date or even to a LunchDate which always sets the time part to midday? there isnt an UpperCaseString for a good reason :) if you went as far as creating an uppercasestring type, then i would say that it is a fair conversion. but then again, creating a type just to uppercase something seems broken, so its not a valid argument. if you had a lunchdate that sets the time to noon it would be a fair conversion because you would be converting the string date portion to a proper type. but then again, why would you have a lunchdate and not just use date if you already know the time is always noon? the point of converters is to take a type-agnostic input in a form of a string and convert it to a proper type. if your expected type is also a string then really no conversion should happen. there are *type* converters, thats is why they have tostring(object) and toobject(string), not a single object convert(object). anyways, just letting you know the intention behind the converters in wicket. i would say what you are doing is abusing the system and it is not guaranteed to keep working in 1.5. just my two cents. I agree clearly that the translation should not be done by the validator. my point was not that the conversion should not be done by the validator, my point was that the validator should not check the uppercase requirement. entering something in uppercase is not a requirement on the user its a requirement on the system that stores the input, validators deal with user-related requirements. -igor Regards - Cemal http;//jWeekend.com igor.vaynberg wrote: using conversion and validation for this is wrong. converters in wicket are meant to convert from type<->string because the web is type-agnostic. a string<->string conversion is not a conversion from wicket's point of view. yes, the code is somewhat unclear, we are going to address this in 1.5 where we can change some api and better name things. validation is also wrong. validation checks user input. the requirement to have this entered in uppercase is not on the user, it is on the system. so a validator should not fail because something was entered in non-uppercase. -igor On Thu, Mar 5, 2009 at 1:26 AM, jWeekend > wrote: Martijn, Is there not already an EasyUpperCaseRUs.com web service you can subscribe to for unlimited conversions at an annual fee of under 30,000USD (or 100USD/conversion) who also have a "5 free conversions" trial subscription? Ether way, I would suggest this be done at conversion time so validation can do its job properly and you're not handing off conversion responsibilities where they don't belong. Some solutions leaving this transformation of the text input by the user until after conversion in the form processing life-cycle may be less lines of code (or less classes), but IMO, are bending rules and ignoring good design principles. Of course, others may disagree and come up with all sorts of "neat" solutions that still manage to upper-case a string; how about "just cut out the middle-man altogether and do it in a stored-procedure triggered on INSERT and UPDATE" - that would work too, but wouldn't be my choice. There's also a degree of "it depends" here, but generally, the form-processing life-cycle should be respected or explicitly overridden for a good design reason (to meet user requirements). Regards - Cemal http://jWeekend.com jWeekend Martijn Dashorst wrote: I suggest setting up an ESB with a UppercaseService that is available through EJB/SOAP/JAX-RS a
Re: a bit of topic but i couldnt resist ....
Sorry Pointbreak, I did not change the Comparators. They are identical to Johan's example. All I did was to add the equals() and hascode() methods, aligning the equals with the Comparator, as described by the specs. Indeed, maybe I am missing Johan's point. But early in this thread Johan described his point as "we have to know the implementations" and illustrated that with the Set-example. My point is that you don't have to know the implementations when all contracts are fulfilled correctly. And I tried to point out in his example, that the contracts are not fulfilled correctly. But now I think Johan tries to make the point that the TreeSet is useless given the contracts, because the Comparator and equals() method must be compatible. Or he tries to make the point that the TreeSet implementation is broken and the specification must be changed. I'm not sure. I can sympathize with both. But I am glad he pointed out the problems with TreeSet, because I wasn't aware of them. Pointbreak wrote: Dave, you are missing the point completely. The issue raised by Johan is that if you call TreeSet.removeAll(otherSet), then in some cases the comperator/equals contract of otherSet is used, in other cases the comperator/equals contract of the treeset. Which is a bit strange, and even by Sun considered a bug (although low priority). You are just making both comperators the same, which of course will not demonstrate this problem. Make the comperator of the TreeSet use str.compareTo instead of compareToIgnoreCase, while keeping your implementation of MyObject the same, and you will have the same problem that Johan illustrated. On Thu, 05 Mar 2009 16:51 +0100, "Dave Schoorl" wrote: I do understand your point. However you are dealing with multiple contracts and not all of them are satisfied. And sometimes contracts are conflicting and it is impossible to meet all contracts, but I believe this is not the case in your scenario. A TreeSet is an implementation of a Set and must obey the Set contract. Adding order to the Set should not break the Set contract, because if I have a Set, I should not be concerned with the implementation details (is it a TreeSet or a HashSet or whatever). I believe the Set contract takes precedence over the Comparator contract, but in your case, by providing an equals method to MyObject that is in line with the Comparator, there still is no problem. See the code below, where MyObject implements the equals method with by comparing case insensitive: - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Is this a bug in Wicket?
Don't put the in a .
Should be:
Search feed by name:
Match all
conditions>
Match any
conditions>
Match all news
rjilani wrote:
>
> Hi: Gurus, I am trying to render a form and looks like wicket is not
> rendering the form elements in right sequence, here is my markup that is
> having the issues
>
>
> Search feed by name:
>
>
>
>
>
> Match all
> conditions
> Match any
> conditions
> Match all news
>
>
>
>
> here is the java code
>
> add(new TextField("feedName", new Model()));
>
> add(new RadioChoice("conditionChoice", new
> Model(),conditionChoices ).setSuffix(""));
>
> when I run the code I see the radio button choices before the text field;
> any suggestions?
>
> Thanks,
> RJ.
>
--
View this message in context:
http://www.nabble.com/Is-this-a-bug-in-Wicket--tp22356116p22356561.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
Place Button or Link in w_content_3 of ModalWindow
Hallo, how can i place components (buttons, links etc) in a ModalWindow which is displayed by div class w_content_3??? Is there an possibility to structure the modalwindow analog the css-classes. Thanks for help... -- View this message in context: http://www.nabble.com/Place-Button-or-Link-in-w_content_3-of-ModalWindow-tp22356556p22356556.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
Re: Turn off form validation
On 19.01.2009, at 20:22, jWeekend wrote: Kaspar, Will either of getInput() or getVaue() allow you to do what you want? Dear Cemal, getInput() did it: even with default form processing disabled, getInput() gives me the form input. Thanks a lot. Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Is this a bug in Wicket?
Hi: Gurus, I am trying to render a form and looks like wicket is not
rendering the form elements in right sequence, here is my markup that is
having the issues
Search feed by name:
Match all
conditions
Match any
conditions
Match all news
here is the java code
add(new TextField("feedName", new Model()));
add(new RadioChoice("conditionChoice", new
Model(),conditionChoices ).setSuffix(""));
when I run the code I see the radio button choices before the text field;
any suggestions?
Thanks,
RJ.
--
View this message in context:
http://www.nabble.com/Is-this-a-bug-in-Wicket--tp22356116p22356116.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
Re: Uppercasing inputs
Igor, > anyways, just letting you know the intention behind the converters in > wicket. OK - that's exactly the thing that needs to be crystal clear. So the bottom line is that the if in your scenario the user entering lower case strings is acceptable then, in Wicket, the conversion to upper-case is not a job for IConverter and something downstream should take care of a the transformation to upper case (within Wicket or further down). If the user input should not even be submitted unless it is in upper case, then use http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html Adriano's solution or something that has a similar effect. Is that summary correct? Regards - Cemal http://jWeekend.om jWeekend igor.vaynberg wrote: > > On Thu, Mar 5, 2009 at 8:12 AM, jWeekend > wrote: >> >> Igor, >> >> If there was a Java type called UpperCaseString that's what the developer >> would use as the underlying object and you would not have this objection. >> What's the difference between a converter translating 2009-04-04 to a >> java.util.Date or even to a LunchDate which always sets the time part to >> midday? > > there isnt an UpperCaseString for a good reason :) if you went as far > as creating an uppercasestring type, then i would say that it is a > fair conversion. but then again, creating a type just to uppercase > something seems broken, so its not a valid argument. > > if you had a lunchdate that sets the time to noon it would be a fair > conversion because you would be converting the string date portion to > a proper type. but then again, why would you have a lunchdate and not > just use date if you already know the time is always noon? > > the point of converters is to take a type-agnostic input in a form of > a string and convert it to a proper type. if your expected type is > also a string then really no conversion should happen. there are > *type* converters, thats is why they have tostring(object) and > toobject(string), not a single object convert(object). anyways, just > letting you know the intention behind the converters in wicket. i > would say what you are doing is abusing the system and it is not > guaranteed to keep working in 1.5. just my two cents. > >> I agree clearly that the translation should not be done by the validator. > > my point was not that the conversion should not be done by the > validator, my point was that the validator should not check the > uppercase requirement. entering something in uppercase is not a > requirement on the user its a requirement on the system that stores > the input, validators deal with user-related requirements. > > -igor > >> >> Regards - Cemal >> http;//jWeekend.com >> >> >> igor.vaynberg wrote: >>> >>> using conversion and validation for this is wrong. >>> >>> converters in wicket are meant to convert from type<->string because >>> the web is type-agnostic. a string<->string conversion is not a >>> conversion from wicket's point of view. yes, the code is somewhat >>> unclear, we are going to address this in 1.5 where we can change some >>> api and better name things. >>> >>> validation is also wrong. validation checks user input. the >>> requirement to have this entered in uppercase is not on the user, it >>> is on the system. so a validator should not fail because something was >>> entered in non-uppercase. >>> >>> -igor >>> >>> >>> On Thu, Mar 5, 2009 at 1:26 AM, jWeekend >>> wrote: Martijn, Is there not already an EasyUpperCaseRUs.com web service you can subscribe to for unlimited conversions at an annual fee of under 30,000USD (or 100USD/conversion) who also have a "5 free conversions" trial subscription? Ether way, I would suggest this be done at conversion time so validation can do its job properly and you're not handing off conversion responsibilities where they don't belong. Some solutions leaving this transformation of the text input by the user until after conversion in the form processing life-cycle may be less lines of code (or less classes), but IMO, are bending rules and ignoring good design principles. Of course, others may disagree and come up with all sorts of "neat" solutions that still manage to upper-case a string; how about "just cut out the middle-man altogether and do it in a stored-procedure triggered on INSERT and UPDATE" - that would work too, but wouldn't be my choice. There's also a degree of "it depends" here, but generally, the form-processing life-cycle should be respected or explicitly overridden for a good design reason (to meet user requirements). Regards - Cemal http://jWeekend.com jWeekend Martijn Dashorst wrote: > > I suggest setting up an ESB with a UppercaseService that is available > through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access > that UppercaseService to make the value upperc
Re: Uppercasing inputs
On Thu, Mar 5, 2009 at 8:12 AM, jWeekend wrote:
>
> Igor,
>
> If there was a Java type called UpperCaseString that's what the developer
> would use as the underlying object and you would not have this objection.
> What's the difference between a converter translating 2009-04-04 to a
> java.util.Date or even to a LunchDate which always sets the time part to
> midday?
there isnt an UpperCaseString for a good reason :) if you went as far
as creating an uppercasestring type, then i would say that it is a
fair conversion. but then again, creating a type just to uppercase
something seems broken, so its not a valid argument.
if you had a lunchdate that sets the time to noon it would be a fair
conversion because you would be converting the string date portion to
a proper type. but then again, why would you have a lunchdate and not
just use date if you already know the time is always noon?
the point of converters is to take a type-agnostic input in a form of
a string and convert it to a proper type. if your expected type is
also a string then really no conversion should happen. there are
*type* converters, thats is why they have tostring(object) and
toobject(string), not a single object convert(object). anyways, just
letting you know the intention behind the converters in wicket. i
would say what you are doing is abusing the system and it is not
guaranteed to keep working in 1.5. just my two cents.
> I agree clearly that the translation should not be done by the validator.
my point was not that the conversion should not be done by the
validator, my point was that the validator should not check the
uppercase requirement. entering something in uppercase is not a
requirement on the user its a requirement on the system that stores
the input, validators deal with user-related requirements.
-igor
>
> Regards - Cemal
> http;//jWeekend.com
>
>
> igor.vaynberg wrote:
>>
>> using conversion and validation for this is wrong.
>>
>> converters in wicket are meant to convert from type<->string because
>> the web is type-agnostic. a string<->string conversion is not a
>> conversion from wicket's point of view. yes, the code is somewhat
>> unclear, we are going to address this in 1.5 where we can change some
>> api and better name things.
>>
>> validation is also wrong. validation checks user input. the
>> requirement to have this entered in uppercase is not on the user, it
>> is on the system. so a validator should not fail because something was
>> entered in non-uppercase.
>>
>> -igor
>>
>>
>> On Thu, Mar 5, 2009 at 1:26 AM, jWeekend
>> wrote:
>>>
>>> Martijn,
>>>
>>> Is there not already an EasyUpperCaseRUs.com web service you can
>>> subscribe
>>> to for unlimited conversions at an annual fee of under 30,000USD (or
>>> 100USD/conversion) who also have a "5 free conversions" trial
>>> subscription?
>>>
>>> Ether way, I would suggest this be done at conversion time so validation
>>> can
>>> do its job properly and you're not handing off conversion
>>> responsibilities
>>> where they don't belong. Some solutions leaving this transformation of
>>> the
>>> text input by the user until after conversion in the form processing
>>> life-cycle may be less lines of code (or less classes), but IMO, are
>>> bending
>>> rules and ignoring good design principles.
>>>
>>> Of course, others may disagree and come up with all sorts of "neat"
>>> solutions that still manage to upper-case a string; how about "just cut
>>> out
>>> the middle-man altogether and do it in a stored-procedure triggered on
>>> INSERT and UPDATE" - that would work too, but wouldn't be my choice.
>>>
>>> There's also a degree of "it depends" here, but generally, the
>>> form-processing life-cycle should be respected or explicitly overridden
>>> for
>>> a good design reason (to meet user requirements).
>>>
>>> Regards - Cemal
>>> http://jWeekend.com jWeekend
>>>
>>>
>>> Martijn Dashorst wrote:
I suggest setting up an ESB with a UppercaseService that is available
through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
that UppercaseService to make the value uppercase.
Martijn
On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg
wrote:
> you can create a convertermodel that takes an instance of iconverter
> and uses that to convert the values, then you can subclass textfield,
> override initmodel() and wrap any model the textfield had with this
> one.
>
> that way everyone is happy!
>
> -igor
>
> On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
> wrote:
>> LOL! Nah - I would just change all the setters on every domain object
>> to
>> be:
>>
>> public void setFoo(String foo) {
>> this.foo = foo == null ? null : foo.toUpperCase();
>> }
>>
>> Or, maybe I'd use AOP and build an aspect that could automatically
>> intercept
>> calls to com.mydomain setters that take a single string argument and
>> do
>> the
>> upper-casin
Re: Uppercasing inputs
I've solved this same requirement on the backend (architecture was
two-layered). Wicket on the front layer had no relation to the
uppercasing.
On java.util.String there are two methods: toUpperCase() and
toUpperCase(Locale locale). I've used the parametrized one with the
user's locale. I am not sure if it is good practice, or even if it has
different results, but I did it just in case.
Regards
On Thu, Mar 5, 2009 at 12:12 PM, jWeekend wrote:
>
> Igor,
>
> If there was a Java type called UpperCaseString that's what the developer
> would use as the underlying object and you would not have this objection.
> What's the difference between a converter translating 2009-04-04 to a
> java.util.Date or even to a LunchDate which always sets the time part to
> midday?
>
> I agree clearly that the translation should not be done by the validator.
>
> Regards - Cemal
> http;//jWeekend.com
>
>
> igor.vaynberg wrote:
>>
>> using conversion and validation for this is wrong.
>>
>> converters in wicket are meant to convert from type<->string because
>> the web is type-agnostic. a string<->string conversion is not a
>> conversion from wicket's point of view. yes, the code is somewhat
>> unclear, we are going to address this in 1.5 where we can change some
>> api and better name things.
>>
>> validation is also wrong. validation checks user input. the
>> requirement to have this entered in uppercase is not on the user, it
>> is on the system. so a validator should not fail because something was
>> entered in non-uppercase.
>>
>> -igor
>>
>>
>> On Thu, Mar 5, 2009 at 1:26 AM, jWeekend
>> wrote:
>>>
>>> Martijn,
>>>
>>> Is there not already an EasyUpperCaseRUs.com web service you can
>>> subscribe
>>> to for unlimited conversions at an annual fee of under 30,000USD (or
>>> 100USD/conversion) who also have a "5 free conversions" trial
>>> subscription?
>>>
>>> Ether way, I would suggest this be done at conversion time so validation
>>> can
>>> do its job properly and you're not handing off conversion
>>> responsibilities
>>> where they don't belong. Some solutions leaving this transformation of
>>> the
>>> text input by the user until after conversion in the form processing
>>> life-cycle may be less lines of code (or less classes), but IMO, are
>>> bending
>>> rules and ignoring good design principles.
>>>
>>> Of course, others may disagree and come up with all sorts of "neat"
>>> solutions that still manage to upper-case a string; how about "just cut
>>> out
>>> the middle-man altogether and do it in a stored-procedure triggered on
>>> INSERT and UPDATE" - that would work too, but wouldn't be my choice.
>>>
>>> There's also a degree of "it depends" here, but generally, the
>>> form-processing life-cycle should be respected or explicitly overridden
>>> for
>>> a good design reason (to meet user requirements).
>>>
>>> Regards - Cemal
>>> http://jWeekend.com jWeekend
>>>
>>>
>>> Martijn Dashorst wrote:
I suggest setting up an ESB with a UppercaseService that is available
through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
that UppercaseService to make the value uppercase.
Martijn
On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg
wrote:
> you can create a convertermodel that takes an instance of iconverter
> and uses that to convert the values, then you can subclass textfield,
> override initmodel() and wrap any model the textfield had with this
> one.
>
> that way everyone is happy!
>
> -igor
>
> On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
> wrote:
>> LOL! Nah - I would just change all the setters on every domain object
>> to
>> be:
>>
>> public void setFoo(String foo) {
>> this.foo = foo == null ? null : foo.toUpperCase();
>> }
>>
>> Or, maybe I'd use AOP and build an aspect that could automatically
>> intercept
>> calls to com.mydomain setters that take a single string argument and
>> do
>> the
>> upper-casing there!
>>
>> It's makes me smile to think of how many ways a single thing can be
>> done.
>>
>> Leszek - you should now definitely have plenty of choices. Pick which
>> feels
>> best / most comfortable for you!
>>
>> On Wed, Mar 4, 2009 at 5:22 PM, jWeekend
>> wrote:
>>
>>>
>>> Igor,
>>>
>>> Nope, not for me (this time).
>>> Here's the Javadoc for updateModel:
>>> * Updates this components model from the request, it expects
>>> that
>>> the
>>> object is already
>>> * converted through the convertInput() call that is called by
>>> the
>>> validate() method when a form
>>> * is being processed.
>>>
>>> Regards - Cemal
>>> http://jWeekend.com jWeekend
>>>
>>>
>>> igor.vaynberg wrote:
>>> >
>>> > pft, you guys!
>>> >
>>> > i would go with the simplest!
>>> >
>>> > class uppercasetextfield exte
Re: a bit of topic but i couldnt resist ....
I agree that it's weird that the behavior of the removeAll depends on
the size of the other collection.
On Thu, Mar 5, 2009 at 11:11 AM, Pointbreak
wrote:
> Dave, you are missing the point completely. The issue raised by Johan is
> that if you call TreeSet.removeAll(otherSet), then in some cases the
> comperator/equals contract of otherSet is used, in other cases the
> comperator/equals contract of the treeset. Which is a bit strange, and
> even by Sun considered a bug (although low priority). You are just
> making both comperators the same, which of course will not demonstrate
> this problem. Make the comperator of the TreeSet use str.compareTo
> instead of compareToIgnoreCase, while keeping your implementation of
> MyObject the same, and you will have the same problem that Johan
> illustrated.
>
> On Thu, 05 Mar 2009 16:51 +0100, "Dave Schoorl"
> wrote:
>> I do understand your point. However you are dealing with multiple
>> contracts and not all of them are satisfied. And sometimes contracts are
>> conflicting and it is impossible to meet all contracts, but I believe
>> this is not the case in your scenario.
>>
>> A TreeSet is an implementation of a Set and must obey the Set contract.
>> Adding order to the Set should not break the Set contract, because if I
>> have a Set, I should not be concerned with the implementation details
>> (is it a TreeSet or a HashSet or whatever). I believe the Set contract
>> takes precedence over the Comparator contract, but in your case, by
>> providing an equals method to MyObject that is in line with the
>> Comparator, there still is no problem. See the code below, where
>> MyObject implements the equals method with by comparing case insensitive:
>>
>> import java.util.ArrayList;
>> import java.util.Collection;
>> import java.util.Comparator;
>> import java.util.HashSet;
>> import java.util.Iterator;
>> import java.util.TreeSet;
>>
>> public class CorrectedMyObjectTest {
>>
>> public static class MyObject {
>> private final String aString;
>>
>> MyObject(String str) {
>> aString = str;
>> }
>>
>> @Override
>> public String toString() {
>> return aString;
>> }
>>
>> @Override
>> public int hashCode() {
>> final int prime = 31;
>> int result = 1;
>> result = prime * result + ((aString == null) ? 0 :
>> aString.toLowerCase().hashCode());
>> return result;
>> }
>>
>> @Override
>> public boolean equals(Object obj) {
>> if (this == obj)
>> return true;
>> if (obj == null)
>> return false;
>> if (!(obj instanceof MyObject))
>> return false;
>> MyObject other = (MyObject) obj;
>> if (aString == null) {
>> if (other.aString != null) {
>> return false;
>> }
>> } else if (other.aString == null) {
>> return false;
>> }
>> return aString.compareToIgnoreCase(other.aString) == 0;
>> }
>>
>> }
>>
>> public static void main(String[] args) {
>> TreeSet set1 = getCleanSet();
>>
>> HashSet set2 = new HashSet();
>> set2.add(new MyObject("johan"));
>>
>> set1.removeAll(set2);
>>
>> System.err.println("this works: " + set1.size() + " == 1, and
>> remaining object is " + set1.iterator().next() + " == rob");
>>
>> // add removed back in
>> set1 = getCleanSet();
>>
>> // increase the size of set2 with some other random others
>> set2.add(new MyObject("random1"));
>> set2.add(new MyObject("random2"));
>>
>> // now size is bigger then set1, call removeall again:
>> set1.removeAll(set2);
>>
>> System.err.println("this doesnt work: " + set1.size() + " != 1,
>> so now both objects stil remain! This is because "
>> + "removeAll isnt overwritten by TreeSet and AbstractSet
>> walks over the smallest set but then compare fails");
>>
>> // same for retainAll that also compares wrong.
>> set1 = getCleanSet();
>> set1.retainAll(set2);
>>
>> System.err.println("set1 is now completely empty, but it should
>> have 1 left: " + set1);
>>
>> // so both methods should always iterator through the colleciton
>> they get and do the compare on its self
>>
>> set1 = getCleanFixedSet();
>> set1.removeAll(set2);
>>
>> System.err
>> .println("now this works: " + set1.size() + " == 1, and
>> remainng object is " + set1.iterator().next() + " == rob");
>>
>> // add removed back in
>> set1 = getCleanFixedSet();
>>
>> set1.retainAll(set2);
>>
>> System.err.println("set1 is now correct, it has 1 left: " +
>> set1);
>>
>> }
>>
>> public static TreeSet getCleanSet() {
>> TreeSet set1 = new Tr
Re: Uppercasing inputs
Igor,
If there was a Java type called UpperCaseString that's what the developer
would use as the underlying object and you would not have this objection.
What's the difference between a converter translating 2009-04-04 to a
java.util.Date or even to a LunchDate which always sets the time part to
midday?
I agree clearly that the translation should not be done by the validator.
Regards - Cemal
http;//jWeekend.com
igor.vaynberg wrote:
>
> using conversion and validation for this is wrong.
>
> converters in wicket are meant to convert from type<->string because
> the web is type-agnostic. a string<->string conversion is not a
> conversion from wicket's point of view. yes, the code is somewhat
> unclear, we are going to address this in 1.5 where we can change some
> api and better name things.
>
> validation is also wrong. validation checks user input. the
> requirement to have this entered in uppercase is not on the user, it
> is on the system. so a validator should not fail because something was
> entered in non-uppercase.
>
> -igor
>
>
> On Thu, Mar 5, 2009 at 1:26 AM, jWeekend
> wrote:
>>
>> Martijn,
>>
>> Is there not already an EasyUpperCaseRUs.com web service you can
>> subscribe
>> to for unlimited conversions at an annual fee of under 30,000USD (or
>> 100USD/conversion) who also have a "5 free conversions" trial
>> subscription?
>>
>> Ether way, I would suggest this be done at conversion time so validation
>> can
>> do its job properly and you're not handing off conversion
>> responsibilities
>> where they don't belong. Some solutions leaving this transformation of
>> the
>> text input by the user until after conversion in the form processing
>> life-cycle may be less lines of code (or less classes), but IMO, are
>> bending
>> rules and ignoring good design principles.
>>
>> Of course, others may disagree and come up with all sorts of "neat"
>> solutions that still manage to upper-case a string; how about "just cut
>> out
>> the middle-man altogether and do it in a stored-procedure triggered on
>> INSERT and UPDATE" - that would work too, but wouldn't be my choice.
>>
>> There's also a degree of "it depends" here, but generally, the
>> form-processing life-cycle should be respected or explicitly overridden
>> for
>> a good design reason (to meet user requirements).
>>
>> Regards - Cemal
>> http://jWeekend.com jWeekend
>>
>>
>> Martijn Dashorst wrote:
>>>
>>> I suggest setting up an ESB with a UppercaseService that is available
>>> through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
>>> that UppercaseService to make the value uppercase.
>>>
>>> Martijn
>>>
>>> On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg
>>> wrote:
you can create a convertermodel that takes an instance of iconverter
and uses that to convert the values, then you can subclass textfield,
override initmodel() and wrap any model the textfield had with this
one.
that way everyone is happy!
-igor
On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
wrote:
> LOL! Nah - I would just change all the setters on every domain object
> to
> be:
>
> public void setFoo(String foo) {
> this.foo = foo == null ? null : foo.toUpperCase();
> }
>
> Or, maybe I'd use AOP and build an aspect that could automatically
> intercept
> calls to com.mydomain setters that take a single string argument and
> do
> the
> upper-casing there!
>
> It's makes me smile to think of how many ways a single thing can be
> done.
>
> Leszek - you should now definitely have plenty of choices. Pick which
> feels
> best / most comfortable for you!
>
> On Wed, Mar 4, 2009 at 5:22 PM, jWeekend
> wrote:
>
>>
>> Igor,
>>
>> Nope, not for me (this time).
>> Here's the Javadoc for updateModel:
>> * Updates this components model from the request, it expects
>> that
>> the
>> object is already
>> * converted through the convertInput() call that is called by
>> the
>> validate() method when a form
>> * is being processed.
>>
>> Regards - Cemal
>> http://jWeekend.com jWeekend
>>
>>
>> igor.vaynberg wrote:
>> >
>> > pft, you guys!
>> >
>> > i would go with the simplest!
>> >
>> > class uppercasetextfield extends textfield {
>> > public void updatemodel()
>> > {
>> > final String str=getconvertedinput();
>> >
>> setdefaultmodelobject((str==null)?null:str.touppercase());
>> > }
>> > }
>> >
>> > done!
>> >
>> > -igor
>> >
>> > On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
>>
>> > wrote:
>> >>
>> >> Jeremy,
>> >>
>> >> I sensed you were uncomfortable with my "most Wicket-way"
>> suggestion
>> when
>> >> I
>> >> read
>> http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338
Re: a bit of topic but i couldnt resist ....
Dave, you are missing the point completely. The issue raised by Johan is
that if you call TreeSet.removeAll(otherSet), then in some cases the
comperator/equals contract of otherSet is used, in other cases the
comperator/equals contract of the treeset. Which is a bit strange, and
even by Sun considered a bug (although low priority). You are just
making both comperators the same, which of course will not demonstrate
this problem. Make the comperator of the TreeSet use str.compareTo
instead of compareToIgnoreCase, while keeping your implementation of
MyObject the same, and you will have the same problem that Johan
illustrated.
On Thu, 05 Mar 2009 16:51 +0100, "Dave Schoorl"
wrote:
> I do understand your point. However you are dealing with multiple
> contracts and not all of them are satisfied. And sometimes contracts are
> conflicting and it is impossible to meet all contracts, but I believe
> this is not the case in your scenario.
>
> A TreeSet is an implementation of a Set and must obey the Set contract.
> Adding order to the Set should not break the Set contract, because if I
> have a Set, I should not be concerned with the implementation details
> (is it a TreeSet or a HashSet or whatever). I believe the Set contract
> takes precedence over the Comparator contract, but in your case, by
> providing an equals method to MyObject that is in line with the
> Comparator, there still is no problem. See the code below, where
> MyObject implements the equals method with by comparing case insensitive:
>
> import java.util.ArrayList;
> import java.util.Collection;
> import java.util.Comparator;
> import java.util.HashSet;
> import java.util.Iterator;
> import java.util.TreeSet;
>
> public class CorrectedMyObjectTest {
>
> public static class MyObject {
> private final String aString;
>
> MyObject(String str) {
> aString = str;
> }
>
> @Override
> public String toString() {
> return aString;
> }
>
> @Override
> public int hashCode() {
> final int prime = 31;
> int result = 1;
> result = prime * result + ((aString == null) ? 0 :
> aString.toLowerCase().hashCode());
> return result;
> }
>
> @Override
> public boolean equals(Object obj) {
> if (this == obj)
> return true;
> if (obj == null)
> return false;
> if (!(obj instanceof MyObject))
> return false;
> MyObject other = (MyObject) obj;
> if (aString == null) {
> if (other.aString != null) {
> return false;
> }
> } else if (other.aString == null) {
> return false;
> }
> return aString.compareToIgnoreCase(other.aString) == 0;
> }
>
> }
>
> public static void main(String[] args) {
> TreeSet set1 = getCleanSet();
>
> HashSet set2 = new HashSet();
> set2.add(new MyObject("johan"));
>
> set1.removeAll(set2);
>
> System.err.println("this works: " + set1.size() + " == 1, and
> remaining object is " + set1.iterator().next() + " == rob");
>
> // add removed back in
> set1 = getCleanSet();
>
> // increase the size of set2 with some other random others
> set2.add(new MyObject("random1"));
> set2.add(new MyObject("random2"));
>
> // now size is bigger then set1, call removeall again:
> set1.removeAll(set2);
>
> System.err.println("this doesnt work: " + set1.size() + " != 1,
> so now both objects stil remain! This is because "
> + "removeAll isnt overwritten by TreeSet and AbstractSet
> walks over the smallest set but then compare fails");
>
> // same for retainAll that also compares wrong.
> set1 = getCleanSet();
> set1.retainAll(set2);
>
> System.err.println("set1 is now completely empty, but it should
> have 1 left: " + set1);
>
> // so both methods should always iterator through the colleciton
> they get and do the compare on its self
>
> set1 = getCleanFixedSet();
> set1.removeAll(set2);
>
> System.err
> .println("now this works: " + set1.size() + " == 1, and
> remainng object is " + set1.iterator().next() + " == rob");
>
> // add removed back in
> set1 = getCleanFixedSet();
>
> set1.retainAll(set2);
>
> System.err.println("set1 is now correct, it has 1 left: " +
> set1);
>
> }
>
> public static TreeSet getCleanSet() {
> TreeSet set1 = new TreeSet(new
> Comparator() {
>
> public int compare(MyObject o1, MyObject o2) {
> return o1.aString.compareToIgnoreCase(o2.aString);
> }
> });
>
> set1.add(new MyObject("johan"));
> set1.add
Re: Uppercasing inputs
using conversion and validation for this is wrong.
converters in wicket are meant to convert from type<->string because
the web is type-agnostic. a string<->string conversion is not a
conversion from wicket's point of view. yes, the code is somewhat
unclear, we are going to address this in 1.5 where we can change some
api and better name things.
validation is also wrong. validation checks user input. the
requirement to have this entered in uppercase is not on the user, it
is on the system. so a validator should not fail because something was
entered in non-uppercase.
-igor
On Thu, Mar 5, 2009 at 1:26 AM, jWeekend wrote:
>
> Martijn,
>
> Is there not already an EasyUpperCaseRUs.com web service you can subscribe
> to for unlimited conversions at an annual fee of under 30,000USD (or
> 100USD/conversion) who also have a "5 free conversions" trial subscription?
>
> Ether way, I would suggest this be done at conversion time so validation can
> do its job properly and you're not handing off conversion responsibilities
> where they don't belong. Some solutions leaving this transformation of the
> text input by the user until after conversion in the form processing
> life-cycle may be less lines of code (or less classes), but IMO, are bending
> rules and ignoring good design principles.
>
> Of course, others may disagree and come up with all sorts of "neat"
> solutions that still manage to upper-case a string; how about "just cut out
> the middle-man altogether and do it in a stored-procedure triggered on
> INSERT and UPDATE" - that would work too, but wouldn't be my choice.
>
> There's also a degree of "it depends" here, but generally, the
> form-processing life-cycle should be respected or explicitly overridden for
> a good design reason (to meet user requirements).
>
> Regards - Cemal
> http://jWeekend.com jWeekend
>
>
> Martijn Dashorst wrote:
>>
>> I suggest setting up an ESB with a UppercaseService that is available
>> through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
>> that UppercaseService to make the value uppercase.
>>
>> Martijn
>>
>> On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg
>> wrote:
>>> you can create a convertermodel that takes an instance of iconverter
>>> and uses that to convert the values, then you can subclass textfield,
>>> override initmodel() and wrap any model the textfield had with this
>>> one.
>>>
>>> that way everyone is happy!
>>>
>>> -igor
>>>
>>> On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
>>> wrote:
LOL! Nah - I would just change all the setters on every domain object
to
be:
public void setFoo(String foo) {
this.foo = foo == null ? null : foo.toUpperCase();
}
Or, maybe I'd use AOP and build an aspect that could automatically
intercept
calls to com.mydomain setters that take a single string argument and do
the
upper-casing there!
It's makes me smile to think of how many ways a single thing can be
done.
Leszek - you should now definitely have plenty of choices. Pick which
feels
best / most comfortable for you!
On Wed, Mar 4, 2009 at 5:22 PM, jWeekend
wrote:
>
> Igor,
>
> Nope, not for me (this time).
> Here's the Javadoc for updateModel:
> * Updates this components model from the request, it expects
> that
> the
> object is already
> * converted through the convertInput() call that is called by
> the
> validate() method when a form
> * is being processed.
>
> Regards - Cemal
> http://jWeekend.com jWeekend
>
>
> igor.vaynberg wrote:
> >
> > pft, you guys!
> >
> > i would go with the simplest!
> >
> > class uppercasetextfield extends textfield {
> > public void updatemodel()
> > {
> > final String str=getconvertedinput();
> >
> setdefaultmodelobject((str==null)?null:str.touppercase());
> > }
> > }
> >
> > done!
> >
> > -igor
> >
> > On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
>
> > wrote:
> >>
> >> Jeremy,
> >>
> >> I sensed you were uncomfortable with my "most Wicket-way" suggestion
> when
> >> I
> >> read
> http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
> >> previous post on this thread stating that the model doing the
> >> transformation work was on the "right track"; it is not unusual that
> more
> >> than one design can satisfy a given requirement.
> >>
> >> Do you like the idea of a model being responsible for conversion of
> >> users'
> >> textual input?
> >>
> >> Your article illustrates the use of nested models nicely but on this
> >> occasion I would probably go with
> >> http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html
> Adriano's
> >> idea
> >> for a client side, instant gratification
Re: ResourceLink, IE and https
Looking at ResourceLink#onResourceRequested, I see the resource is
delivered before
#onClick is called, so whatever you're doing in onClick is too late to
have any influence
on the report generation.
On Thu, Mar 5, 2009 at 4:52 PM, Luca Provenzani wrote:
> sorry i wrote a wrong thing...
> the result is NOT ever the same, but is the report with the previous
> parameters.
> I try to explain better:
> i've a form that determines the report's prameters. On ResourceLink, i added
> a "onmousedown" AjaxFormSubmitBehavior to submit the parameter and calculate
> other. Then into the onclick of ResourceLink i update th resource parameter.
>
> the source:
>
> * rXlsLnk = new ResourceLink("lnkReport", xlsResource){
> private static final long serialVersionUID = 1L;
>
> �...@override
> public void onClick() {
> HashMap par = new HashMap();
> par.put("myWhere", myWhere);
>
> xlsResource.setReportParameters(par);
>
> super.onClick();
> }
>
>
>
> };
>
>
>
> rXlsLnk.add(new AjaxFormSubmitBehavior("onmousedown") {
> private static final long serialVersionUID = 1L;
>
> �...@override
> protected void onSubmit(AjaxRequestTarget target) {
> myWhere = "WHERE
> iscr.SISSIONE_COD_SCUOLA='"+MySession.getSessesion().getOperatore().getSissioneScuole().getCodMec()+"'"
> +
> " AND iscr.FS_ISCR_AS='"+iscrFilter.getAnnoScolastico()+"'
> ";
>
> if(iscrFilter.getPlessoId()!=null &&
> !iscrFilter.getPlessoId().equals("-1"))
> ...
> etc etc
>
> }
> else
> {
> }
> }
> }
>
> �...@override
> protected void onError(AjaxRequestTarget target) {
> myWhere = "WHERE 1=0";
> target.addComponent(feedbackPanel);
> }
> });*
>
> The first time i download the report i obtain an empty report, because empty
> parameters. The second time i obtained the report with th first submit
> parameter end then and then...
>
> can you help?
>
> thanks a lot
>
> Luca
>
>
> 2009/3/5 Jonas
>
>> If it is the browser that caches the report, you can work around this
>> by adding something random to the url generated
>> by ResourceLink#getUrl, similar to what's done in NonCachingImage.
>>
>> urlFor(IResourceListener.INTERFACE) + "&wicket:antiCache=" +
>> System.currentTimeMillis()
>>
>> Unfortunatly, ResourceLink#getUrl is final, so you'll probably have to
>> create
>> your own Link subclass similar to ResourceLink
>>
>> On Thu, Mar 5, 2009 at 4:33 PM, Luca Provenzani
>> wrote:
>> > in this way it works, but how can i refresh the report when parameter is
>> > changed?
>> >
>> > Until now i change parameter into the onclick of the ResourceLink, but
>> now
>> > the resource is cached...and then the result report is ever the same..
>> >
>> > thanks
>> > Luca
>> >
>> > 2009/3/5 Jonas
>> >
>> >> Does it work if you set your Resource setCacheable(true)?
>> >>
>> >> On Thu, Mar 5, 2009 at 3:21 PM, Luca Provenzani
>> >> wrote:
>> >> > Hi all
>> >> >
>> >> > This is my situation:
>> >> > i've a ResourceLink based on a JasperReport
>> Resource(DynamicWebResource
>> >> )
>> >> > and all is ok until i use http.
>> >> > But if the web server uses https IE can't download the file.
>> >> >
>> >> > i searched in the web but i 've found only an e-mail with similar
>> problem
>> >> (
>> >> > http://www.nabble.com/Download-Link-Problem-td14693760.html#a14693760
>> ),
>> >> > but no answer!
>> >> >
>> >> > Someone can help?
>> >> >
>> >> > Regards
>> >> >
>> >> > Luca
>> >> >
>> >>
>> >> -
>> >> 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: ResourceLink, IE and https
OK it's all ok
i just move the code from the onclick to "onmousedown"
AjaxFormSubmitBehavior.
and now all work fine!
a big thank Jonas!
Luca
2009/3/5 Luca Provenzani
> sorry i wrote a wrong thing...
> the result is NOT ever the same, but is the report with the previous
> parameters.
> I try to explain better:
> i've a form that determines the report's prameters. On ResourceLink, i
> added a "onmousedown" AjaxFormSubmitBehavior to submit the parameter and
> calculate other. Then into the onclick of ResourceLink i update th resource
> parameter.
>
> the source:
>
> *rXlsLnk = new ResourceLink("lnkReport", xlsResource){
> private static final long serialVersionUID = 1L;
>
> @Override
> public void onClick() {
> HashMap par = new HashMap String>();
> par.put("myWhere", myWhere);
>
> xlsResource.setReportParameters(par);
>
> super.onClick();
> }
>
>
>
> };
>
>
>
> rXlsLnk.add(new AjaxFormSubmitBehavior("onmousedown") {
> private static final long serialVersionUID = 1L;
>
> @Override
> protected void onSubmit(AjaxRequestTarget target) {
> myWhere = "WHERE
> iscr.SISSIONE_COD_SCUOLA='"+MySession.getSessesion().getOperatore().getSissioneScuole().getCodMec()+"'"
> +
> " AND iscr.FS_ISCR_AS='"+iscrFilter.getAnnoScolastico()+"'
> ";
>
> if(iscrFilter.getPlessoId()!=null &&
> !iscrFilter.getPlessoId().equals("-1"))
> ...
> etc etc
>
>}
> else
> {
> }
> }
> }
>
> @Override
> protected void onError(AjaxRequestTarget target) {
> myWhere = "WHERE 1=0";
> target.addComponent(feedbackPanel);
> }
> });*
>
> The first time i download the report i obtain an empty report, because
> empty parameters. The second time i obtained the report with th first submit
> parameter end then and then...
>
> can you help?
>
> thanks a lot
>
>
> Luca
>
>
> 2009/3/5 Jonas
>
>> If it is the browser that caches the report, you can work around this
>> by adding something random to the url generated
>> by ResourceLink#getUrl, similar to what's done in NonCachingImage.
>>
>> urlFor(IResourceListener.INTERFACE) + "&wicket:antiCache=" +
>> System.currentTimeMillis()
>>
>> Unfortunatly, ResourceLink#getUrl is final, so you'll probably have to
>> create
>> your own Link subclass similar to ResourceLink
>>
>> On Thu, Mar 5, 2009 at 4:33 PM, Luca Provenzani
>> wrote:
>> > in this way it works, but how can i refresh the report when parameter is
>> > changed?
>> >
>> > Until now i change parameter into the onclick of the ResourceLink, but
>> now
>> > the resource is cached...and then the result report is ever the same..
>> >
>> > thanks
>> > Luca
>> >
>> > 2009/3/5 Jonas
>> >
>> >> Does it work if you set your Resource setCacheable(true)?
>> >>
>> >> On Thu, Mar 5, 2009 at 3:21 PM, Luca Provenzani
>> >> wrote:
>> >> > Hi all
>> >> >
>> >> > This is my situation:
>> >> > i've a ResourceLink based on a JasperReport
>> Resource(DynamicWebResource
>> >> )
>> >> > and all is ok until i use http.
>> >> > But if the web server uses https IE can't download the file.
>> >> >
>> >> > i searched in the web but i 've found only an e-mail with similar
>> problem
>> >> (
>> >> >
>> http://www.nabble.com/Download-Link-Problem-td14693760.html#a14693760),
>> >> > but no answer!
>> >> >
>> >> > Someone can help?
>> >> >
>> >> > Regards
>> >> >
>> >> > Luca
>> >> >
>> >>
>> >> -
>> >> 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: a bit of topic but i couldnt resist ....
I think it is a bug in the Eclipse plugin. Thankfully, it's Eclipse and
not Sun, so this bug can be solved very fast ;)
Dave Schoorl wrote:
I do understand your point. However you are dealing with multiple
contracts and not all of them are satisfied. And sometimes contracts
are conflicting and it is impossible to meet all contracts, but I
believe this is not the case in your scenario.
A TreeSet is an implementation of a Set and must obey the Set
contract. Adding order to the Set should not break the Set contract,
because if I have a Set, I should not be concerned with the
implementation details (is it a TreeSet or a HashSet or whatever). I
believe the Set contract takes precedence over the Comparator
contract, but in your case, by providing an equals method to MyObject
that is in line with the Comparator, there still is no problem. See
the code below, where MyObject implements the equals method with by
comparing case insensitive:
import java.util.ArrayList;
import java.util.Collection;
import java.util.Comparator;
import java.util.HashSet;
import java.util.Iterator;
import java.util.TreeSet;
public class CorrectedMyObjectTest {
public static class MyObject {
private final String aString;
MyObject(String str) {
aString = str;
}
@Override
public String toString() {
return aString;
}
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((aString == null) ? 0 :
aString.toLowerCase().hashCode());
return result;
}
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (!(obj instanceof MyObject))
return false;
MyObject other = (MyObject) obj;
if (aString == null) {
if (other.aString != null) {
return false;
}
} else if (other.aString == null) {
return false;
}
return aString.compareToIgnoreCase(other.aString) == 0;
}
}
public static void main(String[] args) {
TreeSet set1 = getCleanSet();
HashSet set2 = new HashSet();
set2.add(new MyObject("johan"));
set1.removeAll(set2);
System.err.println("this works: " + set1.size() + " == 1, and
remaining object is " + set1.iterator().next() + " == rob");
// add removed back in
set1 = getCleanSet();
// increase the size of set2 with some other random others
set2.add(new MyObject("random1"));
set2.add(new MyObject("random2"));
// now size is bigger then set1, call removeall again:
set1.removeAll(set2);
System.err.println("this doesnt work: " + set1.size() + " != 1,
so now both objects stil remain! This is because "
+ "removeAll isnt overwritten by TreeSet and
AbstractSet walks over the smallest set but then compare fails");
// same for retainAll that also compares wrong.
set1 = getCleanSet();
set1.retainAll(set2);
System.err.println("set1 is now completely empty, but it should
have 1 left: " + set1);
// so both methods should always iterator through the
colleciton they get and do the compare on its self
set1 = getCleanFixedSet();
set1.removeAll(set2);
System.err
.println("now this works: " + set1.size() + " == 1, and
remainng object is " + set1.iterator().next() + " == rob");
// add removed back in
set1 = getCleanFixedSet();
set1.retainAll(set2);
System.err.println("set1 is now correct, it has 1 left: " + set1);
}
public static TreeSet getCleanSet() {
TreeSet set1 = new TreeSet(new
Comparator() {
public int compare(MyObject o1, MyObject o2) {
return o1.aString.compareToIgnoreCase(o2.aString);
}
});
set1.add(new MyObject("johan"));
set1.add(new MyObject("rob"));
return set1;
}
public static TreeSet getCleanFixedSet() {
TreeSet set1 = new MyFixedTreeSet(new
Comparator() {
public int compare(MyObject o1, MyObject o2) {
return o1.aString.compareToIgnoreCase(o2.aString);
}
});
set1.add(new MyObject("johan"));
set1.add(new MyObject("rob"));
return set1;
}
public static class MyFixedTreeSet extends TreeSet {
public MyFixedTreeSet(Comparator comparator) {
super(comparator);
}
@Override
public boolean retainAll(Collection c) {
ArrayList list = new ArrayList();
Iterator e = c.iterator();
while (e.hasNext()) {
Object next = e.next();
if (contains(next)) {
list.add((E) next);
}
Re: ResourceLink, IE and https
sorry i wrote a wrong thing...
the result is NOT ever the same, but is the report with the previous
parameters.
I try to explain better:
i've a form that determines the report's prameters. On ResourceLink, i added
a "onmousedown" AjaxFormSubmitBehavior to submit the parameter and calculate
other. Then into the onclick of ResourceLink i update th resource parameter.
the source:
*rXlsLnk = new ResourceLink("lnkReport", xlsResource){
private static final long serialVersionUID = 1L;
@Override
public void onClick() {
HashMap par = new HashMap();
par.put("myWhere", myWhere);
xlsResource.setReportParameters(par);
super.onClick();
}
};
rXlsLnk.add(new AjaxFormSubmitBehavior("onmousedown") {
private static final long serialVersionUID = 1L;
@Override
protected void onSubmit(AjaxRequestTarget target) {
myWhere = "WHERE
iscr.SISSIONE_COD_SCUOLA='"+MySession.getSessesion().getOperatore().getSissioneScuole().getCodMec()+"'"
+
" AND iscr.FS_ISCR_AS='"+iscrFilter.getAnnoScolastico()+"'
";
if(iscrFilter.getPlessoId()!=null &&
!iscrFilter.getPlessoId().equals("-1"))
...
etc etc
}
else
{
}
}
}
@Override
protected void onError(AjaxRequestTarget target) {
myWhere = "WHERE 1=0";
target.addComponent(feedbackPanel);
}
});*
The first time i download the report i obtain an empty report, because empty
parameters. The second time i obtained the report with th first submit
parameter end then and then...
can you help?
thanks a lot
Luca
2009/3/5 Jonas
> If it is the browser that caches the report, you can work around this
> by adding something random to the url generated
> by ResourceLink#getUrl, similar to what's done in NonCachingImage.
>
> urlFor(IResourceListener.INTERFACE) + "&wicket:antiCache=" +
> System.currentTimeMillis()
>
> Unfortunatly, ResourceLink#getUrl is final, so you'll probably have to
> create
> your own Link subclass similar to ResourceLink
>
> On Thu, Mar 5, 2009 at 4:33 PM, Luca Provenzani
> wrote:
> > in this way it works, but how can i refresh the report when parameter is
> > changed?
> >
> > Until now i change parameter into the onclick of the ResourceLink, but
> now
> > the resource is cached...and then the result report is ever the same..
> >
> > thanks
> > Luca
> >
> > 2009/3/5 Jonas
> >
> >> Does it work if you set your Resource setCacheable(true)?
> >>
> >> On Thu, Mar 5, 2009 at 3:21 PM, Luca Provenzani
> >> wrote:
> >> > Hi all
> >> >
> >> > This is my situation:
> >> > i've a ResourceLink based on a JasperReport
> Resource(DynamicWebResource
> >> )
> >> > and all is ok until i use http.
> >> > But if the web server uses https IE can't download the file.
> >> >
> >> > i searched in the web but i 've found only an e-mail with similar
> problem
> >> (
> >> > http://www.nabble.com/Download-Link-Problem-td14693760.html#a14693760
> ),
> >> > but no answer!
> >> >
> >> > Someone can help?
> >> >
> >> > Regards
> >> >
> >> > Luca
> >> >
> >>
> >> -
> >> 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: Button onSubmit not called, instead page reloads
i just tested your code and it worked for me. maybe there's something wrong
in the basepage? or in the markup?
Edwin Ansicodd wrote:
>
> Some more code:
>
> public class SearchPage extends BasePage {
>
> private String name = "";
>
> public SearchPage(PageParameters parameters) {
> super(parameters);
> // TODO Auto-generated constructor stub
> init();
>
> }
>
> private void init() {
> Form form = new SearchForm("searchForm");
> getContentContainer().addOrReplace(form);
> getContentContainer().addOrReplace(new
> Label("result","").setVisible(false));
>}
>
> class SearchForm extends Form{
>
> public SearchForm(String id){
> super(id);
> TextField Name = new TextField("search.tf.name", new
> PropertyModel(SearchPage.this, "name"));
>
> add(Name);
> Button searchButton = new Button("searchButton"){
> @Override
> public void onSubmit() {
>
> super.onSubmit();
> System.out.println("in searchButton");
> SearchPage.this.updateList();
> }
> };
> add( searchButton );
>}
>
> public void onSubmit(){
> //do nothing extra
>
> }
>
>
> @Override
> public boolean isVersioned() {
> return false;
> }
> }
>
> ´ public String getPageTitleKey() {
> return "searchpage.pagetitle";
> }
>
>
> public String getPageContextKey() {
> return "searchpage";
> }
>
> @Override
> public String getContentWidth() {
> return "850px";
> }
>
> public String getname() {
> return name;
> }
>
> public void setname(String name) {
> this.name = name;
> }
>
> }
>
>
>
> Michael Sparer wrote:
>>
>> the page reloading itself is expected behaviour as the form gets
>> submitted, the onSubmit() method should however be called. if you
>> provided us some more code (and the wicket version you're using)?
>>
>> regards,
>> Michael
>>
>>
>
>
-
Michael Sparer
http://techblog.molindo.at
--
View this message in context:
http://www.nabble.com/Button-onSubmit-not-called%2C-instead-page-reloads-tp22350921p22354350.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
Re: a bit of topic but i couldnt resist ....
I do understand your point. However you are dealing with multiple
contracts and not all of them are satisfied. And sometimes contracts are
conflicting and it is impossible to meet all contracts, but I believe
this is not the case in your scenario.
A TreeSet is an implementation of a Set and must obey the Set contract.
Adding order to the Set should not break the Set contract, because if I
have a Set, I should not be concerned with the implementation details
(is it a TreeSet or a HashSet or whatever). I believe the Set contract
takes precedence over the Comparator contract, but in your case, by
providing an equals method to MyObject that is in line with the
Comparator, there still is no problem. See the code below, where
MyObject implements the equals method with by comparing case insensitive:
import java.util.ArrayList;
import java.util.Collection;
import java.util.Comparator;
import java.util.HashSet;
import java.util.Iterator;
import java.util.TreeSet;
public class CorrectedMyObjectTest {
public static class MyObject {
private final String aString;
MyObject(String str) {
aString = str;
}
@Override
public String toString() {
return aString;
}
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((aString == null) ? 0 :
aString.toLowerCase().hashCode());
return result;
}
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (!(obj instanceof MyObject))
return false;
MyObject other = (MyObject) obj;
if (aString == null) {
if (other.aString != null) {
return false;
}
} else if (other.aString == null) {
return false;
}
return aString.compareToIgnoreCase(other.aString) == 0;
}
}
public static void main(String[] args) {
TreeSet set1 = getCleanSet();
HashSet set2 = new HashSet();
set2.add(new MyObject("johan"));
set1.removeAll(set2);
System.err.println("this works: " + set1.size() + " == 1, and
remaining object is " + set1.iterator().next() + " == rob");
// add removed back in
set1 = getCleanSet();
// increase the size of set2 with some other random others
set2.add(new MyObject("random1"));
set2.add(new MyObject("random2"));
// now size is bigger then set1, call removeall again:
set1.removeAll(set2);
System.err.println("this doesnt work: " + set1.size() + " != 1,
so now both objects stil remain! This is because "
+ "removeAll isnt overwritten by TreeSet and AbstractSet
walks over the smallest set but then compare fails");
// same for retainAll that also compares wrong.
set1 = getCleanSet();
set1.retainAll(set2);
System.err.println("set1 is now completely empty, but it should
have 1 left: " + set1);
// so both methods should always iterator through the colleciton
they get and do the compare on its self
set1 = getCleanFixedSet();
set1.removeAll(set2);
System.err
.println("now this works: " + set1.size() + " == 1, and
remainng object is " + set1.iterator().next() + " == rob");
// add removed back in
set1 = getCleanFixedSet();
set1.retainAll(set2);
System.err.println("set1 is now correct, it has 1 left: " + set1);
}
public static TreeSet getCleanSet() {
TreeSet set1 = new TreeSet(new
Comparator() {
public int compare(MyObject o1, MyObject o2) {
return o1.aString.compareToIgnoreCase(o2.aString);
}
});
set1.add(new MyObject("johan"));
set1.add(new MyObject("rob"));
return set1;
}
public static TreeSet getCleanFixedSet() {
TreeSet set1 = new MyFixedTreeSet(new
Comparator() {
public int compare(MyObject o1, MyObject o2) {
return o1.aString.compareToIgnoreCase(o2.aString);
}
});
set1.add(new MyObject("johan"));
set1.add(new MyObject("rob"));
return set1;
}
public static class MyFixedTreeSet extends TreeSet {
public MyFixedTreeSet(Comparator comparator) {
super(comparator);
}
@Override
public boolean retainAll(Collection c) {
ArrayList list = new ArrayList();
Iterator e = c.iterator();
while (e.hasNext()) {
Object next = e.next();
if (contains(next)) {
list.add((E) next);
}
}
boolean modified = list.size() < size();
if (modified) {
clear();
for (E item :
Re: XML localization
create a quickstart and attach it to a jira issue -igor On Thu, Mar 5, 2009 at 3:52 AM, Mathias P.W Nilsson wrote: > > I've tried search the forum and googled but no answer so I'll give it a try. > > A while ago we needed to implement a new language to our wicket site. We > changed from .properties to .xml to get this to work. > > The problem is that some things has stopped working. Consider the following > > We have a textfield in a form that needs to be required. In our .properties > file I added > > form.email.Required=Please fill in email > > when doing this is a .xml it does not work. > > form.email.Required ( not working ) > email.Required ( not working ) > Required ( working ) > > Any comments? > -- > View this message in context: > http://www.nabble.com/XML-localization-tp22349788p22349788.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 > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ResourceLink, IE and https
If it is the browser that caches the report, you can work around this by adding something random to the url generated by ResourceLink#getUrl, similar to what's done in NonCachingImage. urlFor(IResourceListener.INTERFACE) + "&wicket:antiCache=" + System.currentTimeMillis() Unfortunatly, ResourceLink#getUrl is final, so you'll probably have to create your own Link subclass similar to ResourceLink On Thu, Mar 5, 2009 at 4:33 PM, Luca Provenzani wrote: > in this way it works, but how can i refresh the report when parameter is > changed? > > Until now i change parameter into the onclick of the ResourceLink, but now > the resource is cached...and then the result report is ever the same.. > > thanks > Luca > > 2009/3/5 Jonas > >> Does it work if you set your Resource setCacheable(true)? >> >> On Thu, Mar 5, 2009 at 3:21 PM, Luca Provenzani >> wrote: >> > Hi all >> > >> > This is my situation: >> > i've a ResourceLink based on a JasperReport Resource(DynamicWebResource >> ) >> > and all is ok until i use http. >> > But if the web server uses https IE can't download the file. >> > >> > i searched in the web but i 've found only an e-mail with similar problem >> ( >> > http://www.nabble.com/Download-Link-Problem-td14693760.html#a14693760), >> > but no answer! >> > >> > Someone can help? >> > >> > Regards >> > >> > Luca >> > >> >> - >> 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: ResourceLink, IE and https
in this way it works, but how can i refresh the report when parameter is changed? Until now i change parameter into the onclick of the ResourceLink, but now the resource is cached...and then the result report is ever the same.. thanks Luca 2009/3/5 Jonas > Does it work if you set your Resource setCacheable(true)? > > On Thu, Mar 5, 2009 at 3:21 PM, Luca Provenzani > wrote: > > Hi all > > > > This is my situation: > > i've a ResourceLink based on a JasperReport Resource(DynamicWebResource > ) > > and all is ok until i use http. > > But if the web server uses https IE can't download the file. > > > > i searched in the web but i 've found only an e-mail with similar problem > ( > > http://www.nabble.com/Download-Link-Problem-td14693760.html#a14693760), > > but no answer! > > > > Someone can help? > > > > Regards > > > > Luca > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: a bit of topic but i couldnt resist ....
No that isnt the issue here
Because i dont ask in my point of view anything of the hashset!
Why would this result in something asking the hashset (asking like that it
has to use the hash or equals things on things that are in the TreeSet)?
TreeSet.removeAll(HashSet)
why?
It should just iterate over all what is in the HashSet and call remove on
the TreeSet with every element that is in the iterator of the HashSet
The workaround i do now in the code is doing that my self (iterating of the
HashSet and calling remove() on the TreeSet)
johan
On Thu, Mar 5, 2009 at 15:50, James Carman wrote:
> When you ask the hashset if it contains that object (checking whether or
> not
> to remove) it will say that it doesn't contain it because it's not the same
> object (you didn't override equals and hashCode). That's the whole issue
> here.
>
> On Mar 5, 2009 8:06 AM, "Johan Compagner" wrote:
>
> yes i know but the TreeSet does also say that in the javadoc that it is an
> exception because of the Comparator
>
> And they could really just make it a black box. The only things they just
> need to fix then is the removeAll and retainAll methods
>
> Why the removeAll iterates by default over itself and ask for a contains on
> the other and then removes itself again is beyond me
> I wouldnt never implement it that way. Why would you do that in the first
> place?
> It wouldnt come into my mind to do it like that
>
> besides that AbstractSet.removeAll makes it even worse:
>
> public boolean removeAll(Collection c) { boolean modified = false;
> if (size() > c.size()) {
>
> for (Iterator i = c.iterator(); i.hasNext(); ) modified |= remove(i.n...
>} else {
> for (Iterator i = iterator(); i.hasNext(); ) {
> if (c.contains(i.next())) {
> i.remove();
> modified = true;
> }
> }
> }
> return modified;
> }
>
> see partly it does what i expect to happen (the if)
> but what sun wants to happen is the else..
>
> So now we just have 2 behaviors depending on what size the collection
> has...
> nice..
>
>
>
> On Thu, Mar 5, 2009 at 13:58, Maarten Bosteels >wrote:
>
> > It is in the javadoc for Comparator > > "Caution should be exercised when
> using a comparator capa...
> > pointbreak%252bwicketst...@ml1.net<
> pointbreak%25252bwicketst...@ml1.net
> ><
> pointbreak%25252bwicketst...@ml1.net
>
> >
> >
>
> > >> > > > > wrote: > > > > > >> Sorry, I have to correct myself. According
> to the API-docs, the > c...
> > pointbreak%252bwicketst...@ml1.net<
> pointbreak%25252bwicketst...@ml1.net
> ><
> pointbreak%25252bwicketst...@ml1.net
>
> >
> >
>
> > >>> > > >> wrote: > > >> > You are missing the point. With a string it
> will work, because the > > ...
>
Re: setRequired() final?
On 05.03.2009, at 15:11, jWeekend wrote: Kaspar, +1 :-) Thanks for the feedback. Good to know I'm on the right track. Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: a bit of topic but i couldnt resist ....
When you ask the hashset if it contains that object (checking whether or not
to remove) it will say that it doesn't contain it because it's not the same
object (you didn't override equals and hashCode). That's the whole issue
here.
On Mar 5, 2009 8:06 AM, "Johan Compagner" wrote:
yes i know but the TreeSet does also say that in the javadoc that it is an
exception because of the Comparator
And they could really just make it a black box. The only things they just
need to fix then is the removeAll and retainAll methods
Why the removeAll iterates by default over itself and ask for a contains on
the other and then removes itself again is beyond me
I wouldnt never implement it that way. Why would you do that in the first
place?
It wouldnt come into my mind to do it like that
besides that AbstractSet.removeAll makes it even worse:
public boolean removeAll(Collection c) { boolean modified = false;
if (size() > c.size()) {
for (Iterator i = c.iterator(); i.hasNext(); ) modified |= remove(i.n...
} else {
for (Iterator i = iterator(); i.hasNext(); ) {
if (c.contains(i.next())) {
i.remove();
modified = true;
}
}
}
return modified;
}
see partly it does what i expect to happen (the if)
but what sun wants to happen is the else..
So now we just have 2 behaviors depending on what size the collection has...
nice..
On Thu, Mar 5, 2009 at 13:58, Maarten Bosteels wrote:
> It is in the javadoc for Comparator > > "Caution should be exercised when
using a comparator capa...
> pointbreak%252bwicketst...@ml1.net <
pointbreak%25252bwicketst...@ml1.net
>
> >> > > > > wrote: > > > > > >> Sorry, I have to correct myself. According
to the API-docs, the > c...
> pointbreak%252bwicketst...@ml1.net <
pointbreak%25252bwicketst...@ml1.net
>
> >>> > > >> wrote: > > >> > You are missing the point. With a string it
will work, because the > > ...
Re: ResourceLink, IE and https
Does it work if you set your Resource setCacheable(true)? On Thu, Mar 5, 2009 at 3:21 PM, Luca Provenzani wrote: > Hi all > > This is my situation: > i've a ResourceLink based on a JasperReport Resource(DynamicWebResource ) > and all is ok until i use http. > But if the web server uses https IE can't download the file. > > i searched in the web but i 've found only an e-mail with similar problem ( > http://www.nabble.com/Download-Link-Problem-td14693760.html#a14693760), > but no answer! > > Someone can help? > > Regards > > Luca > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
ResourceLink, IE and https
Hi all This is my situation: i've a ResourceLink based on a JasperReport Resource(DynamicWebResource ) and all is ok until i use http. But if the web server uses https IE can't download the file. i searched in the web but i 've found only an e-mail with similar problem ( http://www.nabble.com/Download-Link-Problem-td14693760.html#a14693760), but no answer! Someone can help? Regards Luca
Re: Uppercasing inputs
Yes, I love that mailing list :-)
Am 05.03.2009 um 10:26 schrieb jWeekend:
Martijn,
Is there not already an EasyUpperCaseRUs.com web service you can
subscribe
to for unlimited conversions at an annual fee of under 30,000USD (or
100USD/conversion) who also have a "5 free conversions" trial
subscription?
Ether way, I would suggest this be done at conversion time so
validation can
do its job properly and you're not handing off conversion
responsibilities
where they don't belong. Some solutions leaving this transformation
of the
text input by the user until after conversion in the form processing
life-cycle may be less lines of code (or less classes), but IMO, are
bending
rules and ignoring good design principles.
Of course, others may disagree and come up with all sorts of "neat"
solutions that still manage to upper-case a string; how about "just
cut out
the middle-man altogether and do it in a stored-procedure triggered on
INSERT and UPDATE" - that would work too, but wouldn't be my choice.
There's also a degree of "it depends" here, but generally, the
form-processing life-cycle should be respected or explicitly
overridden for
a good design reason (to meet user requirements).
Regards - Cemal
http://jWeekend.com jWeekend
Martijn Dashorst wrote:
I suggest setting up an ESB with a UppercaseService that is available
through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
that UppercaseService to make the value uppercase.
Martijn
On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg >
wrote:
you can create a convertermodel that takes an instance of iconverter
and uses that to convert the values, then you can subclass
textfield,
override initmodel() and wrap any model the textfield had with this
one.
that way everyone is happy!
-igor
On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
wrote:
LOL! Nah - I would just change all the setters on every domain
object
to
be:
public void setFoo(String foo) {
this.foo = foo == null ? null : foo.toUpperCase();
}
Or, maybe I'd use AOP and build an aspect that could automatically
intercept
calls to com.mydomain setters that take a single string argument
and do
the
upper-casing there!
It's makes me smile to think of how many ways a single thing can be
done.
Leszek - you should now definitely have plenty of choices. Pick
which
feels
best / most comfortable for you!
On Wed, Mar 4, 2009 at 5:22 PM, jWeekend
wrote:
Igor,
Nope, not for me (this time).
Here's the Javadoc for updateModel:
* Updates this components model from the request, it
expects
that
the
object is already
* converted through the convertInput() call that is
called by
the
validate() method when a form
* is being processed.
Regards - Cemal
http://jWeekend.com jWeekend
igor.vaynberg wrote:
pft, you guys!
i would go with the simplest!
class uppercasetextfield extends textfield {
public void updatemodel()
{
final String str=getconvertedinput();
setdefaultmodelobject((str==null)?null:str.touppercase());
}
}
done!
-igor
On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
wrote:
Jeremy,
I sensed you were uncomfortable with my "most Wicket-way"
suggestion
when
I
read
http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
previous post on this thread stating that the model doing the
transformation work was on the "right track"; it is not
unusual that
more
than one design can satisfy a given requirement.
Do you like the idea of a model being responsible for
conversion of
users'
textual input?
Your article illustrates the use of nested models nicely but
on this
occasion I would probably go with
http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html
Adriano's
idea
for a client side, instant gratification, solution, and a custom
text
field
with a converter if the conversion can happen later, on the
server.
Regards - Cemal
http://jWeekend.com jWeekend
Jeremy Thomerson-5 wrote:
Cemal,
I think I have to respectfully disagree with you here. I
describe
what
I
feel is a better solution, and a little bit of why in this blog
post
from
a
few months ago:
http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
Basically, doing it the way you suggested isn't reusable
across
many
components - you have to create overridden variants of each
type of
input.
Also, a converter (or more specifically, an implementation of
IConverter)
is
supposed to be for transforming a type of object to a string
usable
in
the
browser / form post / etc, as it's javadoc mentions.
Anyway, as the saying goes "there are many ways to skin a
cat" -
although
the saying isn't that great, I think it applies - there are
multiple
ways
of
accomplishing the same thing.
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Mar 4, 2009 at 12:04 PM, jWeekend
wrote:
Leszek,
... or, probably the most "Wicket-way" of doing this
Re: Button onSubmit not called, instead page reloads
more code continued. . .
import org.apache.wicket.markup.html.WebPage;
public abstract class BasePage extends WebPage {
private CustomFeedbackPanel feedback;
public BasePage() {
super();
init();
}
private void init() {
add(new BookmarkablePageLink("PageLink", InfoPage.class));
ContentBorder c = new ContentBorder("content");
c.add( feedback = new CustomFeedbackPanel("feedback") );
add( c );
}
protected ContentBorder getContentContainer(){
return (ContentBorder)get("content");
}
@Override
protected void onBeforeRender() {
super.onBeforeRender();
boolean showfeedback =
getSession().getFeedbackMessages().size() != 0;
this.feedback.setVisible(showfeedback);
}
public abstract String getPageTitleKey();
public abstract String getPageContextKey();
protected HttpServletRequest getHttpRequest(){
return ((WebRequest)getRequest()).getHttpServletRequest();
}
public abstract String getContentWidth();
@Override
public boolean isVersioned() {
return false;
}
protected class ContentBorder extends Border{
public ContentBorder(String id) {
super(id);
WebMarkupContainer wmc = new
WebMarkupContainer("contentBorder");
wmc.add( new AttributeModifier("style", true, new
Model("width:" +
getContentWidth() + ";") ) );
add( wmc );
wmc.add(getBodyContainer());
}
}
}
--
View this message in context:
http://www.nabble.com/Button-onSubmit-not-called%2C-instead-page-reloads-tp22350921p22352467.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
Re: Button onSubmit not called, instead page reloads
more code continued. . .
import org.apache.wicket.markup.html.WebPage;
public abstract class BasePage extends WebPage {
private CustomFeedbackPanel feedback;
public BasePage() {
super();
init();
}
private void init() {
add(new BookmarkablePageLink("PageLink", InfoPage.class));
ContentBorder c = new ContentBorder("content");
c.add( feedback = new CustomFeedbackPanel("feedback") );
add( c );
}
protected ContentBorder getContentContainer(){
return (ContentBorder)get("content");
}
@Override
protected void onBeforeRender() {
super.onBeforeRender();
boolean showfeedback =
getSession().getFeedbackMessages().size() != 0;
this.feedback.setVisible(showfeedback);
}
public abstract String getPageTitleKey();
public abstract String getPageContextKey();
protected HttpServletRequest getHttpRequest(){
return ((WebRequest)getRequest()).getHttpServletRequest();
}
public abstract String getContentWidth();
@Override
public boolean isVersioned() {
return false;
}
protected class ContentBorder extends Border{
public ContentBorder(String id) {
super(id);
WebMarkupContainer wmc = new
WebMarkupContainer("contentBorder");
wmc.add( new AttributeModifier("style", true, new
Model("width:" +
getContentWidth() + ";") ) );
add( wmc );
wmc.add(getBodyContainer());
}
}
}
--
View this message in context:
http://www.nabble.com/Button-onSubmit-not-called%2C-instead-page-reloads-tp22350921p22352441.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
Re: setRequired() final?
Kaspar, +1 Regards - Cemal http://jWeekend.com jWeekend hbf wrote: > > On 05.03.2009, at 10:49, Kaspar Fischer wrote: > >> I have a form component to select items and would like to add lower >> and upper constraints on the number of items that need to be set by >> the user. I added setMin() and setMax() methods and would like to >> override setRequired() to call setMin(1). However, >> FormComponent.setRequired is final. Is there a particular reason for >> this? > > On second thoughts I think I am mixing two concerns her: requiring > input and validation. I guess in my case, "required" is meaningless > (the list of selected items should not be null). And the constraint on > the number of items should be added via a validator. > > Kaspar > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://www.nabble.com/setRequired%28%29-final--tp22348364p22352383.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
Re: setRequired() final?
On 05.03.2009, at 10:49, Kaspar Fischer wrote: I have a form component to select items and would like to add lower and upper constraints on the number of items that need to be set by the user. I added setMin() and setMax() methods and would like to override setRequired() to call setMin(1). However, FormComponent.setRequired is final. Is there a particular reason for this? On second thoughts I think I am mixing two concerns her: requiring input and validation. I guess in my case, "required" is meaningless (the list of selected items should not be null). And the constraint on the number of items should be added via a validator. Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: DropDownChoice with disabled items
Adriano, Take a look at a mini-presentation I gave at one of our London Wicket Events sometime in last couple of years on "Select and SelectOption" at http://jweekend.com/dev/ArticlesPage/ . Regards - Cemal http://jWeekend.com jWeekend Adriano dos Santos Fernandes-3 wrote: > > Is there an easy way to do it? Output would be: > > > Enabled item > Disabled item > ... > > > > Adriano > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://www.nabble.com/DropDownChoice-with-disabled-items-tp22351308p22352276.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
Re: Button onSubmit not called, instead page reloads
Added a feedback panel to the page, but no additional information appears. jWeekend wrote: > > Edwin, > > Put a feedback panel on your page - you may have validation errors. > > Regards - Cemal > http://jWeekend.com jWeekend > > > -- View this message in context: http://www.nabble.com/Button-onSubmit-not-called%2C-instead-page-reloads-tp22350921p22352004.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
Re: a bit of topic but i couldnt resist ....
http://bugs.sun.com/bugdatabase/search.do?process=1&category=&bugStatus=1%2C2%2C3%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11&subcategory=&type=&keyword=TreeSet+removeAll
first 1 is from 2001; "not a bug thats the spec" (i think that is still
wrong and if i read the javadoc a bit different for removeAll then i still
think that it is a bug)
the second : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6394757
is a low prio bug already know for years..
Its just what i already know for a long time and why i dont report really
anything anymore to sun.
Its a slow moving organization where i dont really want to spend any time on
reporting bugs that are not really taken serious anyway.
Compare that for example to eclipse... such a big difference, there i have a
lot of feedback and bugs are solved very fast.
johan
On Thu, Mar 5, 2009 at 14:26, Pointbreak
> wrote:
> I actually think the specs in the api doc are just worded very badly.
> They just mean to say that if the comparator is not consistent with
> equals, the Set-contract is broken, just because that contract is based
> on (and worded in terms of) equals. This may lead to odd behavior for
> other code that assumes the Set-contract on such collections.
> The removeAll/retainAll oddities you demonstrated are bugs. Somebody
> should file a bug report with sun...
>
> On Thu, 05 Mar 2009 14:05 +0100, "Johan Compagner"
> wrote:
> > yes i know but the TreeSet does also say that in the javadoc that it is
> > an
> > exception because of the Comparator
> >
> > And they could really just make it a black box. The only things they just
> > need to fix then is the removeAll and retainAll methods
> >
> > Why the removeAll iterates by default over itself and ask for a contains
> > on
> > the other and then removes itself again is beyond me
> > I wouldnt never implement it that way. Why would you do that in the first
> > place?
> > It wouldnt come into my mind to do it like that
> >
> > besides that AbstractSet.removeAll makes it even worse:
> >
> > public boolean removeAll(Collection c) {
> > boolean modified = false;
> >
> > if (size() > c.size()) {
> > for (Iterator i = c.iterator(); i.hasNext(); )
> > modified |= remove(i.next());
> > } else {
> > for (Iterator i = iterator(); i.hasNext(); ) {
> > if (c.contains(i.next())) {
> > i.remove();
> > modified = true;
> > }
> > }
> > }
> > return modified;
> > }
> >
> > see partly it does what i expect to happen (the if)
> > but what sun wants to happen is the else..
> >
> > So now we just have 2 behaviors depending on what size the collection
> > has...
> > nice..
> >
> >
> >
> > On Thu, Mar 5, 2009 at 13:58, Maarten Bosteels
> > wrote:
> >
> > > It is in the javadoc for Comparator
> > >
> > > "Caution should be exercised when using a comparator capable of
> imposing an
> > > ordering inconsistent with equals to order a sorted set (or sorted
> map).
> > > Suppose a sorted set (or sorted map) with an explicit comparator c is
> used
> > > with elements (or keys) drawn from a set S. If the ordering imposed by
> c on
> > > S is inconsistent with equals, the sorted set (or sorted map) will
> behave
> > > "strangely." In particular the sorted set (or sorted map) will violate
> the
> > > general contract for set (or map), which is defined in terms of
> equals."
> > >
> > >
> > > http://java.sun.com/javase/6/docs/api/java/util/Comparator.html
> > >
> > > On Thu, Mar 5, 2009 at 1:50 PM, Johan Compagner > > >wrote:
> > >
> > > > For example.
> > > >
> > > > You want a tree set with a case insensitive comparator.. Because you
> want
> > > > to
> > > > order case insensitive..
> > > > That breaks the equals contract.
> > > >
> > > > So that "note" in the doc just makes the TreeSet completely worthless
> > > >
> > > > johan
> > > >
> > > >
> > > > On Thu, Mar 5, 2009 at 13:46, Johan Compagner
> > > > wrote:
> > > >
> > > > > that is then the wrong spec that i talk about
> > > > > That is completely stupid
> > > > >
> > > > > With a comparator you just OVERRIDE the equals, thats the whole
> point!
> > > > >
> > > > > johan
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Mar 5, 2009 at 13:44, Pointbreak <
> > > pointbreak+wicketst...@ml1.net <
> pointbreak%2bwicketst...@ml1.net ><
> > > pointbreak%2bwicketst...@ml1.net <
> pointbreak%252bwicketst...@ml1.net
> >>
> > > > <
> pointbreak%252bwicketst...@ml1.net >
> <
> > > pointbreak%252bwicketst...@ml1.net<
> pointbreak%25252bwicketst...@ml1.net
> >
> > > >>
> > > > > > wrote:
> > > > >
> > > > >> Sorry, I have to correct myself. According to the API-docs, the
> > > compare
> > > > >> method in a TreeSet must be consistent with equals. In Johan's
> example
> > > > >> it is not.
> > > > >>
> > > > >> On Thu, 05 Mar 2009 13:36 +0100, "Pointbreak"
> > > > >> <
> pointbreak%2bwicketst...@ml1.net > <
> > > pointbreak%2bwicke
Re: Button onSubmit not called, instead page reloads
Edwin,
Put a feedback panel on your page - you may have validation errors.
Regards - Cemal
http://jWeekend.com jWeekend
Edwin Ansicodd wrote:
>
> Have a page that extends another page that in turn extends
> org.apache.wicket.markup.html.WebPage. Have added a form that extends
> org.apache.wicket.markup.html.form.Form to this page. In this form, I
> have a org.apache.wicket.markup.html.form.Button
>
> Button searchButton = new Button("searchButton"){
> @Override
> public void onSubmit() {
>super.onSubmit();
>System.out.println("in searchButton");
>SearchPage.this.updateList();
> }
>
> in the html for the button:
>
>
>
> but when I click the button, instead of calling the onSubmit(), the page
> itself is reloaded.
>
> Would anyone have any ideas what might be wrong?
>
>
>
--
View this message in context:
http://www.nabble.com/Button-onSubmit-not-called%2C-instead-page-reloads-tp22350921p22351673.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
Re: a bit of topic but i couldnt resist ....
I actually think the specs in the api doc are just worded very badly.
They just mean to say that if the comparator is not consistent with
equals, the Set-contract is broken, just because that contract is based
on (and worded in terms of) equals. This may lead to odd behavior for
other code that assumes the Set-contract on such collections.
The removeAll/retainAll oddities you demonstrated are bugs. Somebody
should file a bug report with sun...
On Thu, 05 Mar 2009 14:05 +0100, "Johan Compagner"
wrote:
> yes i know but the TreeSet does also say that in the javadoc that it is
> an
> exception because of the Comparator
>
> And they could really just make it a black box. The only things they just
> need to fix then is the removeAll and retainAll methods
>
> Why the removeAll iterates by default over itself and ask for a contains
> on
> the other and then removes itself again is beyond me
> I wouldnt never implement it that way. Why would you do that in the first
> place?
> It wouldnt come into my mind to do it like that
>
> besides that AbstractSet.removeAll makes it even worse:
>
> public boolean removeAll(Collection c) {
> boolean modified = false;
>
> if (size() > c.size()) {
> for (Iterator i = c.iterator(); i.hasNext(); )
> modified |= remove(i.next());
> } else {
> for (Iterator i = iterator(); i.hasNext(); ) {
> if (c.contains(i.next())) {
> i.remove();
> modified = true;
> }
> }
> }
> return modified;
> }
>
> see partly it does what i expect to happen (the if)
> but what sun wants to happen is the else..
>
> So now we just have 2 behaviors depending on what size the collection
> has...
> nice..
>
>
>
> On Thu, Mar 5, 2009 at 13:58, Maarten Bosteels
> wrote:
>
> > It is in the javadoc for Comparator
> >
> > "Caution should be exercised when using a comparator capable of imposing an
> > ordering inconsistent with equals to order a sorted set (or sorted map).
> > Suppose a sorted set (or sorted map) with an explicit comparator c is used
> > with elements (or keys) drawn from a set S. If the ordering imposed by c on
> > S is inconsistent with equals, the sorted set (or sorted map) will behave
> > "strangely." In particular the sorted set (or sorted map) will violate the
> > general contract for set (or map), which is defined in terms of equals."
> >
> >
> > http://java.sun.com/javase/6/docs/api/java/util/Comparator.html
> >
> > On Thu, Mar 5, 2009 at 1:50 PM, Johan Compagner > >wrote:
> >
> > > For example.
> > >
> > > You want a tree set with a case insensitive comparator.. Because you want
> > > to
> > > order case insensitive..
> > > That breaks the equals contract.
> > >
> > > So that "note" in the doc just makes the TreeSet completely worthless
> > >
> > > johan
> > >
> > >
> > > On Thu, Mar 5, 2009 at 13:46, Johan Compagner
> > > wrote:
> > >
> > > > that is then the wrong spec that i talk about
> > > > That is completely stupid
> > > >
> > > > With a comparator you just OVERRIDE the equals, thats the whole point!
> > > >
> > > > johan
> > > >
> > > >
> > > >
> > > > On Thu, Mar 5, 2009 at 13:44, Pointbreak <
> > pointbreak+wicketst...@ml1.net <
> > pointbreak%2bwicketst...@ml1.net >
> > > <
> > pointbreak%252bwicketst...@ml1.net
> > >>
> > > > > wrote:
> > > >
> > > >> Sorry, I have to correct myself. According to the API-docs, the
> > compare
> > > >> method in a TreeSet must be consistent with equals. In Johan's example
> > > >> it is not.
> > > >>
> > > >> On Thu, 05 Mar 2009 13:36 +0100, "Pointbreak"
> > > >> <
> > pointbreak%2bwicketst...@ml1.net > <
> > > pointbreak%2bwicketst...@ml1.net <
> > pointbreak%252bwicketst...@ml1.net
> > >>>
> > > >> wrote:
> > > >> > You are missing the point. With a string it will work, because the
> > > >> > elements will actually be the same string objects, so the
> > > String.equals
> > > >> > and the overridden compare method will give the same results in the
> > > >> > example. Johan's point is that while set1.removeAll() is called, it
> > is
> > > >> > not the compare method of set1 that is used, which seems
> > > >> > counterintuitive.
> > > >> >
> > > >> > On Thu, 05 Mar 2009 13:13 +0100, "Dave Schoorl" <
> > > mailli...@cyber-d.com>
> > > >> > wrote:
> > > >> > > If I change every MyObject in a String, everything is fine.
> > Perhaps
> > > >> the
> > > >> > > MyObject is not obeying the necessary contracts?
> > > >> > >
> > > >> > > See adjusted code below:
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > import java.util.ArrayList;
> > > >> > > import java.util.Collection;
> > > >> > > import java.util.Comparator;
> > > >> > > import java.util.HashSet;
> > > >> > > import java.util.Iterator;
> > > >> > > import java.util.TreeSet;
> > > >> > >
> > > >> > > public class TestWithStrings
> > > >> > > {
> > > >> > > public static void main(String[] args)
> > > >> > >
Re: Button onSubmit not called, instead page reloads
Some more code:
public class SearchPage extends BasePage {
private String name = "";
public SearchPage(PageParameters parameters) {
super(parameters);
// TODO Auto-generated constructor stub
init();
}
private void init() {
Form form = new SearchForm("searchForm");
getContentContainer().addOrReplace(form);
getContentContainer().addOrReplace(new
Label("result","").setVisible(false));
}
class SearchForm extends Form{
public SearchForm(String id){
super(id);
TextField Name = new TextField("search.tf.name", new
PropertyModel(SearchPage.this, "name"));
add(Name);
Button searchButton = new Button("searchButton"){
@Override
public void onSubmit() {
super.onSubmit();
System.out.println("in searchButton");
SearchPage.this.updateList();
}
};
add( searchButton );
}
public void onSubmit(){
//do nothing extra
}
@Override
public boolean isVersioned() {
return false;
}
}
´ public String getPageTitleKey() {
return "searchpage.pagetitle";
}
public String getPageContextKey() {
return "searchpage";
}
@Override
public String getContentWidth() {
return "850px";
}
public String getname() {
return name;
}
public void setname(String name) {
this.name = name;
}
}
Michael Sparer wrote:
>
> the page reloading itself is expected behaviour as the form gets
> submitted, the onSubmit() method should however be called. if you provided
> us some more code (and the wicket version you're using)?
>
> regards,
> Michael
>
>
--
View this message in context:
http://www.nabble.com/Button-onSubmit-not-called%2C-instead-page-reloads-tp22350921p22351547.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
Re: DropDownChoice with disabled items
Would you have time to implement this? https://issues.apache.org/jira/browse/WICKET-1785 http://mail-archives.apache.org/mod_mbox/wicket-commits/200808.mbox/%3c784112037.1218385184286.javamail.j...@brutus%3e I was planning to do it but it hasn't been an issue for me lately. ** Martin 2009/3/5 Adriano dos Santos Fernandes : > Is there an easy way to do it? Output would be: > > > Enabled item > Disabled item > ... > > > > Adriano > > > - > 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: Button onSubmit not called, instead page reloads
alright, then show us more code :-) ... and I'd recommend upgrading to 1.3.5 anyway ... Edwin Ansicodd wrote: > > I'm using Wicket 1.3.0 > > > Michael Sparer wrote: >> >> the page reloading itself is expected behaviour as the form gets >> submitted, the onSubmit() method should however be called. if you >> provided us some more code (and the wicket version you're using)? >> >> regards, >> Michael >> >> > > - Michael Sparer http://techblog.molindo.at -- View this message in context: http://www.nabble.com/Button-onSubmit-not-called%2C-instead-page-reloads-tp22350921p22351487.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
Re: a bit of topic but i couldnt resist ....
hmm, that is weird indeed
On Thu, Mar 5, 2009 at 2:05 PM, Johan Compagner wrote:
> yes i know but the TreeSet does also say that in the javadoc that it is an
> exception because of the Comparator
>
> And they could really just make it a black box. The only things they just
> need to fix then is the removeAll and retainAll methods
>
> Why the removeAll iterates by default over itself and ask for a contains on
> the other and then removes itself again is beyond me
> I wouldnt never implement it that way. Why would you do that in the first
> place?
> It wouldnt come into my mind to do it like that
>
> besides that AbstractSet.removeAll makes it even worse:
>
> public boolean removeAll(Collection c) {
>boolean modified = false;
>
> if (size() > c.size()) {
> for (Iterator i = c.iterator(); i.hasNext(); )
>modified |= remove(i.next());
> } else {
>for (Iterator i = iterator(); i.hasNext(); ) {
>if (c.contains(i.next())) {
>i.remove();
>modified = true;
>}
>}
>}
>return modified;
>}
>
> see partly it does what i expect to happen (the if)
> but what sun wants to happen is the else..
>
> So now we just have 2 behaviors depending on what size the collection
> has...
> nice..
>
>
>
> On Thu, Mar 5, 2009 at 13:58, Maarten Bosteels >wrote:
>
> > It is in the javadoc for Comparator
> >
> > "Caution should be exercised when using a comparator capable of imposing
> an
> > ordering inconsistent with equals to order a sorted set (or sorted map).
> > Suppose a sorted set (or sorted map) with an explicit comparator c is
> used
> > with elements (or keys) drawn from a set S. If the ordering imposed by c
> on
> > S is inconsistent with equals, the sorted set (or sorted map) will behave
> > "strangely." In particular the sorted set (or sorted map) will violate
> the
> > general contract for set (or map), which is defined in terms of equals."
> >
> >
> > http://java.sun.com/javase/6/docs/api/java/util/Comparator.html
> >
> > On Thu, Mar 5, 2009 at 1:50 PM, Johan Compagner > >wrote:
> >
> > > For example.
> > >
> > > You want a tree set with a case insensitive comparator.. Because you
> want
> > > to
> > > order case insensitive..
> > > That breaks the equals contract.
> > >
> > > So that "note" in the doc just makes the TreeSet completely worthless
> > >
> > > johan
> > >
> > >
> > > On Thu, Mar 5, 2009 at 13:46, Johan Compagner
> > > wrote:
> > >
> > > > that is then the wrong spec that i talk about
> > > > That is completely stupid
> > > >
> > > > With a comparator you just OVERRIDE the equals, thats the whole
> point!
> > > >
> > > > johan
> > > >
> > > >
> > > >
> > > > On Thu, Mar 5, 2009 at 13:44, Pointbreak <
> > pointbreak+wicketst...@ml1.net <
> pointbreak%2bwicketst...@ml1.net ><
> > pointbreak%2bwicketst...@ml1.net <
> pointbreak%252bwicketst...@ml1.net
> >>
> > > <
> pointbreak%252bwicketst...@ml1.net >
> <
> > pointbreak%252bwicketst...@ml1.net<
> pointbreak%25252bwicketst...@ml1.net
> >
> > >>
> > > > > wrote:
> > > >
> > > >> Sorry, I have to correct myself. According to the API-docs, the
> > compare
> > > >> method in a TreeSet must be consistent with equals. In Johan's
> example
> > > >> it is not.
> > > >>
> > > >> On Thu, 05 Mar 2009 13:36 +0100, "Pointbreak"
> > > >> <
> pointbreak%2bwicketst...@ml1.net > <
> > pointbreak%2bwicketst...@ml1.net <
> pointbreak%252bwicketst...@ml1.net >>
> <
> > > pointbreak%2bwicketst...@ml1.net <
> pointbreak%252bwicketst...@ml1.net >
> <
> > pointbreak%252bwicketst...@ml1.net<
> pointbreak%25252bwicketst...@ml1.net
> >
> > >>>
> > > >> wrote:
> > > >> > You are missing the point. With a string it will work, because the
> > > >> > elements will actually be the same string objects, so the
> > > String.equals
> > > >> > and the overridden compare method will give the same results in
> the
> > > >> > example. Johan's point is that while set1.removeAll() is called,
> it
> > is
> > > >> > not the compare method of set1 that is used, which seems
> > > >> > counterintuitive.
> > > >> >
> > > >> > On Thu, 05 Mar 2009 13:13 +0100, "Dave Schoorl" <
> > > mailli...@cyber-d.com>
> > > >> > wrote:
> > > >> > > If I change every MyObject in a String, everything is fine.
> > Perhaps
> > > >> the
> > > >> > > MyObject is not obeying the necessary contracts?
> > > >> > >
> > > >> > > See adjusted code below:
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > import java.util.ArrayList;
> > > >> > > import java.util.Collection;
> > > >> > > import java.util.Comparator;
> > > >> > > import java.util.HashSet;
> > > >> > > import java.util.Iterator;
> > > >> > > import java.util.TreeSet;
> > > >> > >
> > > >> > > public class TestWithStrings
> > > >> > > {
> > > >> > > public static void main(String[] args)
> > > >> > > {
> > > >> > > TreeSet set1 = getCleanSet();
> > > >> > >
> > > >> > > HashSet
DropDownChoice with disabled items
Is there an easy way to do it? Output would be: Enabled item Disabled item ... Adriano - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Button onSubmit not called, instead page reloads
I'm using Wicket 1.3.0 Michael Sparer wrote: > > the page reloading itself is expected behaviour as the form gets > submitted, the onSubmit() method should however be called. if you provided > us some more code (and the wicket version you're using)? > > regards, > Michael > > -- View this message in context: http://www.nabble.com/Button-onSubmit-not-called%2C-instead-page-reloads-tp22350921p22351291.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
Re: a bit of topic but i couldnt resist ....
yes i know but the TreeSet does also say that in the javadoc that it is an
exception because of the Comparator
And they could really just make it a black box. The only things they just
need to fix then is the removeAll and retainAll methods
Why the removeAll iterates by default over itself and ask for a contains on
the other and then removes itself again is beyond me
I wouldnt never implement it that way. Why would you do that in the first
place?
It wouldnt come into my mind to do it like that
besides that AbstractSet.removeAll makes it even worse:
public boolean removeAll(Collection c) {
boolean modified = false;
if (size() > c.size()) {
for (Iterator i = c.iterator(); i.hasNext(); )
modified |= remove(i.next());
} else {
for (Iterator i = iterator(); i.hasNext(); ) {
if (c.contains(i.next())) {
i.remove();
modified = true;
}
}
}
return modified;
}
see partly it does what i expect to happen (the if)
but what sun wants to happen is the else..
So now we just have 2 behaviors depending on what size the collection has...
nice..
On Thu, Mar 5, 2009 at 13:58, Maarten Bosteels wrote:
> It is in the javadoc for Comparator
>
> "Caution should be exercised when using a comparator capable of imposing an
> ordering inconsistent with equals to order a sorted set (or sorted map).
> Suppose a sorted set (or sorted map) with an explicit comparator c is used
> with elements (or keys) drawn from a set S. If the ordering imposed by c on
> S is inconsistent with equals, the sorted set (or sorted map) will behave
> "strangely." In particular the sorted set (or sorted map) will violate the
> general contract for set (or map), which is defined in terms of equals."
>
>
> http://java.sun.com/javase/6/docs/api/java/util/Comparator.html
>
> On Thu, Mar 5, 2009 at 1:50 PM, Johan Compagner >wrote:
>
> > For example.
> >
> > You want a tree set with a case insensitive comparator.. Because you want
> > to
> > order case insensitive..
> > That breaks the equals contract.
> >
> > So that "note" in the doc just makes the TreeSet completely worthless
> >
> > johan
> >
> >
> > On Thu, Mar 5, 2009 at 13:46, Johan Compagner
> > wrote:
> >
> > > that is then the wrong spec that i talk about
> > > That is completely stupid
> > >
> > > With a comparator you just OVERRIDE the equals, thats the whole point!
> > >
> > > johan
> > >
> > >
> > >
> > > On Thu, Mar 5, 2009 at 13:44, Pointbreak <
> pointbreak+wicketst...@ml1.net <
> pointbreak%2bwicketst...@ml1.net >
> > <
> pointbreak%252bwicketst...@ml1.net
> >>
> > > > wrote:
> > >
> > >> Sorry, I have to correct myself. According to the API-docs, the
> compare
> > >> method in a TreeSet must be consistent with equals. In Johan's example
> > >> it is not.
> > >>
> > >> On Thu, 05 Mar 2009 13:36 +0100, "Pointbreak"
> > >> <
> pointbreak%2bwicketst...@ml1.net > <
> > pointbreak%2bwicketst...@ml1.net <
> pointbreak%252bwicketst...@ml1.net
> >>>
> > >> wrote:
> > >> > You are missing the point. With a string it will work, because the
> > >> > elements will actually be the same string objects, so the
> > String.equals
> > >> > and the overridden compare method will give the same results in the
> > >> > example. Johan's point is that while set1.removeAll() is called, it
> is
> > >> > not the compare method of set1 that is used, which seems
> > >> > counterintuitive.
> > >> >
> > >> > On Thu, 05 Mar 2009 13:13 +0100, "Dave Schoorl" <
> > mailli...@cyber-d.com>
> > >> > wrote:
> > >> > > If I change every MyObject in a String, everything is fine.
> Perhaps
> > >> the
> > >> > > MyObject is not obeying the necessary contracts?
> > >> > >
> > >> > > See adjusted code below:
> > >> > >
> > >> > >
> > >> > >
> > >> > > import java.util.ArrayList;
> > >> > > import java.util.Collection;
> > >> > > import java.util.Comparator;
> > >> > > import java.util.HashSet;
> > >> > > import java.util.Iterator;
> > >> > > import java.util.TreeSet;
> > >> > >
> > >> > > public class TestWithStrings
> > >> > > {
> > >> > > public static void main(String[] args)
> > >> > > {
> > >> > > TreeSet set1 = getCleanSet();
> > >> > >
> > >> > > HashSet set2 = new HashSet();
> > >> > > set2.add("johan");
> > >> > >
> > >> > >
> > >> > > set1.removeAll(set2);
> > >> > >
> > >> > > System.err.println("this works: " + set1.size() + " == 1,
> > and
> > >> > > remaining object is " + set1.iterator().next() + " == rob");
> > >> > >
> > >> > > // add removed back in
> > >> > > set1 = getCleanSet();
> > >> > >
> > >> > > // increase the size of set2 with some other random others
> > >> > > set2.add("random1");
> > >> > > set2.add("random2");
> > >> > >
> > >> > > // now size is bigger then set1, call removeall again:
> > >> > > set1.removeAll(set2);
> > >> >
Re: Button onSubmit not called, instead page reloads
the page reloading itself is expected behaviour as the form gets submitted,
the onSubmit() method should however be called. if you provided us some more
code (and the wicket version you're using)?
regards,
Michael
Edwin Ansicodd wrote:
>
> Have a page that extends another page that in turn extends
> org.apache.wicket.markup.html.WebPage. Have added a form that extends
> org.apache.wicket.markup.html.form.Form to this page. In this form, I
> have a org.apache.wicket.markup.html.form.Button
>
> Button searchButton = new Button("searchButton"){
> @Override
> public void onSubmit() {
>super.onSubmit();
>System.out.println("in searchButton");
>SearchPage.this.updateList();
> }
>
> in the html for the button:
>
>
>
> but when I click the button, instead of calling the onSubmit(), the page
> itself is reloaded.
>
> Would anyone have any ideas what might be wrong?
>
>
>
-
Michael Sparer
http://techblog.molindo.at
--
View this message in context:
http://www.nabble.com/Button-onSubmit-not-called%2C-instead-page-reloads-tp22350921p22351127.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
Re: a bit of topic but i couldnt resist ....
It is in the javadoc for Comparator
"Caution should be exercised when using a comparator capable of imposing an
ordering inconsistent with equals to order a sorted set (or sorted map).
Suppose a sorted set (or sorted map) with an explicit comparator c is used
with elements (or keys) drawn from a set S. If the ordering imposed by c on
S is inconsistent with equals, the sorted set (or sorted map) will behave
"strangely." In particular the sorted set (or sorted map) will violate the
general contract for set (or map), which is defined in terms of equals."
http://java.sun.com/javase/6/docs/api/java/util/Comparator.html
On Thu, Mar 5, 2009 at 1:50 PM, Johan Compagner wrote:
> For example.
>
> You want a tree set with a case insensitive comparator.. Because you want
> to
> order case insensitive..
> That breaks the equals contract.
>
> So that "note" in the doc just makes the TreeSet completely worthless
>
> johan
>
>
> On Thu, Mar 5, 2009 at 13:46, Johan Compagner
> wrote:
>
> > that is then the wrong spec that i talk about
> > That is completely stupid
> >
> > With a comparator you just OVERRIDE the equals, thats the whole point!
> >
> > johan
> >
> >
> >
> > On Thu, Mar 5, 2009 at 13:44, Pointbreak
> >
> >
> > > wrote:
> >
> >> Sorry, I have to correct myself. According to the API-docs, the compare
> >> method in a TreeSet must be consistent with equals. In Johan's example
> >> it is not.
> >>
> >> On Thu, 05 Mar 2009 13:36 +0100, "Pointbreak"
> >> <
> pointbreak%2bwicketst...@ml1.net >>
> >> wrote:
> >> > You are missing the point. With a string it will work, because the
> >> > elements will actually be the same string objects, so the
> String.equals
> >> > and the overridden compare method will give the same results in the
> >> > example. Johan's point is that while set1.removeAll() is called, it is
> >> > not the compare method of set1 that is used, which seems
> >> > counterintuitive.
> >> >
> >> > On Thu, 05 Mar 2009 13:13 +0100, "Dave Schoorl" <
> mailli...@cyber-d.com>
> >> > wrote:
> >> > > If I change every MyObject in a String, everything is fine. Perhaps
> >> the
> >> > > MyObject is not obeying the necessary contracts?
> >> > >
> >> > > See adjusted code below:
> >> > >
> >> > >
> >> > >
> >> > > import java.util.ArrayList;
> >> > > import java.util.Collection;
> >> > > import java.util.Comparator;
> >> > > import java.util.HashSet;
> >> > > import java.util.Iterator;
> >> > > import java.util.TreeSet;
> >> > >
> >> > > public class TestWithStrings
> >> > > {
> >> > > public static void main(String[] args)
> >> > > {
> >> > > TreeSet set1 = getCleanSet();
> >> > >
> >> > > HashSet set2 = new HashSet();
> >> > > set2.add("johan");
> >> > >
> >> > >
> >> > > set1.removeAll(set2);
> >> > >
> >> > > System.err.println("this works: " + set1.size() + " == 1,
> and
> >> > > remaining object is " + set1.iterator().next() + " == rob");
> >> > >
> >> > > // add removed back in
> >> > > set1 = getCleanSet();
> >> > >
> >> > > // increase the size of set2 with some other random others
> >> > > set2.add("random1");
> >> > > set2.add("random2");
> >> > >
> >> > > // now size is bigger then set1, call removeall again:
> >> > > set1.removeAll(set2);
> >> > >
> >> > > System.err.println("this doesnt work: " + set1.size() + " !=
> >> 1,
> >> > > so now both objects stil remain! This is because " +
> >> > > "removeAll isnt overwritten by TreeSet and
> AbstractSet
> >> > > walks over the smallest set but then compare fails");
> >> > >
> >> > > // same for retainAll that also compares wrong.
> >> > > set1 = getCleanSet();
> >> > > set1.retainAll(set2);
> >> > >
> >> > > System.err.println("set1 is now completely empty, but it
> >> should
> >> > > have 1 left: " + set1);
> >> > >
> >> > > // so both methods should always iterator through the
> >> colleciton
> >> > > they get and do the compare on its self
> >> > >
> >> > > set1 = getCleanFixedSet();
> >> > >
> >> > > set1.removeAll(set2);
> >> > >
> >> > > System.err.println("now this works: " + set1.size() + " ==
> 1,
> >> > > and remainng object is " + set1.iterator().next() + " == rob");
> >> > >
> >> > > // add removed back in
> >> > > set1 = getCleanFixedSet();
> >> > >
> >> > > set1.retainAll(set2);
> >> > >
> >> > > System.err.println("set1 is now correct, it has 1 left: " +
> >> > > set1);
> >> > >
> >> > > }
> >> > >
> >> > > public static TreeSet getCleanSet() {
> >> > > TreeSet set1 = new TreeSet(new
> >> > > Comparator(){
> >> > >
> >> > > public int compare(String o1, String o2)
> >> > > {
> >> > > return o1.compareToIgnoreCase(o2);
> >> > > }
> >> > > });
> >> > >
> >> > > set1.add("johan");
> >> > > set1.add("rob");
> >>
Re: a bit of topic but i couldnt resist ....
Yes it's stupid. If it was the only stupid thing sun did in the java
specs, i might have understood why it is one of the most populair
languages around...
On Thu, 05 Mar 2009 13:46 +0100, "Johan Compagner"
wrote:
> that is then the wrong spec that i talk about
> That is completely stupid
>
> With a comparator you just OVERRIDE the equals, thats the whole point!
>
> johan
>
>
> On Thu, Mar 5, 2009 at 13:44, Pointbreak
>
> > wrote:
>
> > Sorry, I have to correct myself. According to the API-docs, the compare
> > method in a TreeSet must be consistent with equals. In Johan's example
> > it is not.
> >
> > On Thu, 05 Mar 2009 13:36 +0100, "Pointbreak"
> > > wrote:
> > > You are missing the point. With a string it will work, because the
> > > elements will actually be the same string objects, so the String.equals
> > > and the overridden compare method will give the same results in the
> > > example. Johan's point is that while set1.removeAll() is called, it is
> > > not the compare method of set1 that is used, which seems
> > > counterintuitive.
> > >
> > > On Thu, 05 Mar 2009 13:13 +0100, "Dave Schoorl"
> > > wrote:
> > > > If I change every MyObject in a String, everything is fine. Perhaps the
> > > > MyObject is not obeying the necessary contracts?
> > > >
> > > > See adjusted code below:
> > > >
> > > >
> > > >
> > > > import java.util.ArrayList;
> > > > import java.util.Collection;
> > > > import java.util.Comparator;
> > > > import java.util.HashSet;
> > > > import java.util.Iterator;
> > > > import java.util.TreeSet;
> > > >
> > > > public class TestWithStrings
> > > > {
> > > > public static void main(String[] args)
> > > > {
> > > > TreeSet set1 = getCleanSet();
> > > >
> > > > HashSet set2 = new HashSet();
> > > > set2.add("johan");
> > > >
> > > >
> > > > set1.removeAll(set2);
> > > >
> > > > System.err.println("this works: " + set1.size() + " == 1, and
> > > > remaining object is " + set1.iterator().next() + " == rob");
> > > >
> > > > // add removed back in
> > > > set1 = getCleanSet();
> > > >
> > > > // increase the size of set2 with some other random others
> > > > set2.add("random1");
> > > > set2.add("random2");
> > > >
> > > > // now size is bigger then set1, call removeall again:
> > > > set1.removeAll(set2);
> > > >
> > > > System.err.println("this doesnt work: " + set1.size() + " != 1,
> > > > so now both objects stil remain! This is because " +
> > > > "removeAll isnt overwritten by TreeSet and AbstractSet
> > > > walks over the smallest set but then compare fails");
> > > >
> > > > // same for retainAll that also compares wrong.
> > > > set1 = getCleanSet();
> > > > set1.retainAll(set2);
> > > >
> > > > System.err.println("set1 is now completely empty, but it should
> > > > have 1 left: " + set1);
> > > >
> > > > // so both methods should always iterator through the
> > colleciton
> > > > they get and do the compare on its self
> > > >
> > > > set1 = getCleanFixedSet();
> > > >
> > > > set1.removeAll(set2);
> > > >
> > > > System.err.println("now this works: " + set1.size() + " == 1,
> > > > and remainng object is " + set1.iterator().next() + " == rob");
> > > >
> > > > // add removed back in
> > > > set1 = getCleanFixedSet();
> > > >
> > > > set1.retainAll(set2);
> > > >
> > > > System.err.println("set1 is now correct, it has 1 left: " +
> > > > set1);
> > > >
> > > > }
> > > >
> > > > public static TreeSet getCleanSet() {
> > > > TreeSet set1 = new TreeSet(new
> > > > Comparator(){
> > > >
> > > > public int compare(String o1, String o2)
> > > > {
> > > > return o1.compareToIgnoreCase(o2);
> > > > }
> > > > });
> > > >
> > > > set1.add("johan");
> > > > set1.add("rob");
> > > >
> > > > return set1;
> > > > }
> > > >
> > > > public static TreeSet getCleanFixedSet() {
> > > > TreeSet set1 = new MyFixedTreeSet(new
> > > > Comparator(){
> > > >
> > > > public int compare(String o1, String o2)
> > > > {
> > > > return o1.compareToIgnoreCase(o2);
> > > > }
> > > > });
> > > >
> > > > set1.add("johan");
> > > > set1.add("rob");
> > > > return set1;
> > > > }
> > > >
> > > > public static class MyFixedTreeSet extends TreeSet
> > > > {
> > > > public MyFixedTreeSet(Comparator comparator)
> > > > {
> > > > super(comparator);
> > > > }
> > > >
> > > > @Override
> > > > public boolean retainAll(Collection c)
> > > > {
> > > > ArrayList list = new ArrayList();
> > > > Iterator e = c.iterator();
> > > > while (e.hasNext()) {
> > > > Obj
Re: Callbacks with abstract method in ModalWindow
It might have something to do with which Page the AjaxRequestTarget belongs to. The AjaxRequestTarget from the Ajaxbutton in the CallBackPanel belong to ModalContentPage. Not the Page that Uses the ModalWindow. AnyOne have a explanation? Jens -- View this message in context: http://www.nabble.com/Callbacks-with-abstract-method-in-ModalWindow-tp22349647p22351024.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
Re: a bit of topic but i couldnt resist ....
For example.
You want a tree set with a case insensitive comparator.. Because you want to
order case insensitive..
That breaks the equals contract.
So that "note" in the doc just makes the TreeSet completely worthless
johan
On Thu, Mar 5, 2009 at 13:46, Johan Compagner wrote:
> that is then the wrong spec that i talk about
> That is completely stupid
>
> With a comparator you just OVERRIDE the equals, thats the whole point!
>
> johan
>
>
>
> On Thu, Mar 5, 2009 at 13:44, Pointbreak
>
> > wrote:
>
>> Sorry, I have to correct myself. According to the API-docs, the compare
>> method in a TreeSet must be consistent with equals. In Johan's example
>> it is not.
>>
>> On Thu, 05 Mar 2009 13:36 +0100, "Pointbreak"
>> >
>> wrote:
>> > You are missing the point. With a string it will work, because the
>> > elements will actually be the same string objects, so the String.equals
>> > and the overridden compare method will give the same results in the
>> > example. Johan's point is that while set1.removeAll() is called, it is
>> > not the compare method of set1 that is used, which seems
>> > counterintuitive.
>> >
>> > On Thu, 05 Mar 2009 13:13 +0100, "Dave Schoorl"
>> > wrote:
>> > > If I change every MyObject in a String, everything is fine. Perhaps
>> the
>> > > MyObject is not obeying the necessary contracts?
>> > >
>> > > See adjusted code below:
>> > >
>> > >
>> > >
>> > > import java.util.ArrayList;
>> > > import java.util.Collection;
>> > > import java.util.Comparator;
>> > > import java.util.HashSet;
>> > > import java.util.Iterator;
>> > > import java.util.TreeSet;
>> > >
>> > > public class TestWithStrings
>> > > {
>> > > public static void main(String[] args)
>> > > {
>> > > TreeSet set1 = getCleanSet();
>> > >
>> > > HashSet set2 = new HashSet();
>> > > set2.add("johan");
>> > >
>> > >
>> > > set1.removeAll(set2);
>> > >
>> > > System.err.println("this works: " + set1.size() + " == 1, and
>> > > remaining object is " + set1.iterator().next() + " == rob");
>> > >
>> > > // add removed back in
>> > > set1 = getCleanSet();
>> > >
>> > > // increase the size of set2 with some other random others
>> > > set2.add("random1");
>> > > set2.add("random2");
>> > >
>> > > // now size is bigger then set1, call removeall again:
>> > > set1.removeAll(set2);
>> > >
>> > > System.err.println("this doesnt work: " + set1.size() + " !=
>> 1,
>> > > so now both objects stil remain! This is because " +
>> > > "removeAll isnt overwritten by TreeSet and AbstractSet
>> > > walks over the smallest set but then compare fails");
>> > >
>> > > // same for retainAll that also compares wrong.
>> > > set1 = getCleanSet();
>> > > set1.retainAll(set2);
>> > >
>> > > System.err.println("set1 is now completely empty, but it
>> should
>> > > have 1 left: " + set1);
>> > >
>> > > // so both methods should always iterator through the
>> colleciton
>> > > they get and do the compare on its self
>> > >
>> > > set1 = getCleanFixedSet();
>> > >
>> > > set1.removeAll(set2);
>> > >
>> > > System.err.println("now this works: " + set1.size() + " == 1,
>> > > and remainng object is " + set1.iterator().next() + " == rob");
>> > >
>> > > // add removed back in
>> > > set1 = getCleanFixedSet();
>> > >
>> > > set1.retainAll(set2);
>> > >
>> > > System.err.println("set1 is now correct, it has 1 left: " +
>> > > set1);
>> > >
>> > > }
>> > >
>> > > public static TreeSet getCleanSet() {
>> > > TreeSet set1 = new TreeSet(new
>> > > Comparator(){
>> > >
>> > > public int compare(String o1, String o2)
>> > > {
>> > > return o1.compareToIgnoreCase(o2);
>> > > }
>> > > });
>> > >
>> > > set1.add("johan");
>> > > set1.add("rob");
>> > >
>> > > return set1;
>> > > }
>> > >
>> > > public static TreeSet getCleanFixedSet() {
>> > > TreeSet set1 = new MyFixedTreeSet(new
>> > > Comparator(){
>> > >
>> > > public int compare(String o1, String o2)
>> > > {
>> > > return o1.compareToIgnoreCase(o2);
>> > > }
>> > > });
>> > >
>> > > set1.add("johan");
>> > > set1.add("rob");
>> > > return set1;
>> > > }
>> > >
>> > > public static class MyFixedTreeSet extends TreeSet
>> > > {
>> > > public MyFixedTreeSet(Comparator comparator)
>> > > {
>> > > super(comparator);
>> > > }
>> > >
>> > > @Override
>> > > public boolean retainAll(Collection c)
>> > > {
>> > > ArrayList list = new ArrayList();
>> > > Iterator e = c.iterator();
>> > > while (e.hasNext()) {
>> > > Object next = e.next();
>> > > if (conta
Re: a bit of topic but i couldnt resist ....
that is then the wrong spec that i talk about
That is completely stupid
With a comparator you just OVERRIDE the equals, thats the whole point!
johan
On Thu, Mar 5, 2009 at 13:44, Pointbreak
> wrote:
> Sorry, I have to correct myself. According to the API-docs, the compare
> method in a TreeSet must be consistent with equals. In Johan's example
> it is not.
>
> On Thu, 05 Mar 2009 13:36 +0100, "Pointbreak"
> > wrote:
> > You are missing the point. With a string it will work, because the
> > elements will actually be the same string objects, so the String.equals
> > and the overridden compare method will give the same results in the
> > example. Johan's point is that while set1.removeAll() is called, it is
> > not the compare method of set1 that is used, which seems
> > counterintuitive.
> >
> > On Thu, 05 Mar 2009 13:13 +0100, "Dave Schoorl"
> > wrote:
> > > If I change every MyObject in a String, everything is fine. Perhaps the
> > > MyObject is not obeying the necessary contracts?
> > >
> > > See adjusted code below:
> > >
> > >
> > >
> > > import java.util.ArrayList;
> > > import java.util.Collection;
> > > import java.util.Comparator;
> > > import java.util.HashSet;
> > > import java.util.Iterator;
> > > import java.util.TreeSet;
> > >
> > > public class TestWithStrings
> > > {
> > > public static void main(String[] args)
> > > {
> > > TreeSet set1 = getCleanSet();
> > >
> > > HashSet set2 = new HashSet();
> > > set2.add("johan");
> > >
> > >
> > > set1.removeAll(set2);
> > >
> > > System.err.println("this works: " + set1.size() + " == 1, and
> > > remaining object is " + set1.iterator().next() + " == rob");
> > >
> > > // add removed back in
> > > set1 = getCleanSet();
> > >
> > > // increase the size of set2 with some other random others
> > > set2.add("random1");
> > > set2.add("random2");
> > >
> > > // now size is bigger then set1, call removeall again:
> > > set1.removeAll(set2);
> > >
> > > System.err.println("this doesnt work: " + set1.size() + " != 1,
> > > so now both objects stil remain! This is because " +
> > > "removeAll isnt overwritten by TreeSet and AbstractSet
> > > walks over the smallest set but then compare fails");
> > >
> > > // same for retainAll that also compares wrong.
> > > set1 = getCleanSet();
> > > set1.retainAll(set2);
> > >
> > > System.err.println("set1 is now completely empty, but it should
> > > have 1 left: " + set1);
> > >
> > > // so both methods should always iterator through the
> colleciton
> > > they get and do the compare on its self
> > >
> > > set1 = getCleanFixedSet();
> > >
> > > set1.removeAll(set2);
> > >
> > > System.err.println("now this works: " + set1.size() + " == 1,
> > > and remainng object is " + set1.iterator().next() + " == rob");
> > >
> > > // add removed back in
> > > set1 = getCleanFixedSet();
> > >
> > > set1.retainAll(set2);
> > >
> > > System.err.println("set1 is now correct, it has 1 left: " +
> > > set1);
> > >
> > > }
> > >
> > > public static TreeSet getCleanSet() {
> > > TreeSet set1 = new TreeSet(new
> > > Comparator(){
> > >
> > > public int compare(String o1, String o2)
> > > {
> > > return o1.compareToIgnoreCase(o2);
> > > }
> > > });
> > >
> > > set1.add("johan");
> > > set1.add("rob");
> > >
> > > return set1;
> > > }
> > >
> > > public static TreeSet getCleanFixedSet() {
> > > TreeSet set1 = new MyFixedTreeSet(new
> > > Comparator(){
> > >
> > > public int compare(String o1, String o2)
> > > {
> > > return o1.compareToIgnoreCase(o2);
> > > }
> > > });
> > >
> > > set1.add("johan");
> > > set1.add("rob");
> > > return set1;
> > > }
> > >
> > > public static class MyFixedTreeSet extends TreeSet
> > > {
> > > public MyFixedTreeSet(Comparator comparator)
> > > {
> > > super(comparator);
> > > }
> > >
> > > @Override
> > > public boolean retainAll(Collection c)
> > > {
> > > ArrayList list = new ArrayList();
> > > Iterator e = c.iterator();
> > > while (e.hasNext()) {
> > > Object next = e.next();
> > > if (contains(next)) {
> > > list.add((E)next);
> > > }
> > > }
> > > boolean modified = list.size() < size();
> > > if (modified)
> > > {
> > > clear();
> > > for (E item : list)
> > > {
> > > add(item);
> > > }
> > > }
> > > return modified;
> > > }
> > >
> >
Button onSubmit not called, instead page reloads
Have a page that extends another page that in turn extends
org.apache.wicket.markup.html.WebPage. Have added a form that extends
org.apache.wicket.markup.html.form.Form to this page. In this form, I have
a org.apache.wicket.markup.html.form.Button
Button searchButton = new Button("searchButton"){
@Override
public void onSubmit() {
super.onSubmit();
System.out.println("in searchButton");
SearchPage.this.updateList();
}
in the html for the button:
but when I click the button, instead of calling the onSubmit(), the page
itself is reloaded.
Would anyone have any ideas what might be wrong?
--
View this message in context:
http://www.nabble.com/Button-onSubmit-not-called%2C-instead-page-reloads-tp22350921p22350921.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
Re: a bit of topic but i couldnt resist ....
yes thats my point
The TreeSet doesnt use hash or equals
you define that with the comparator what it should do
If you look at my last reply where i do define hash and equals then it also
doesnt work.
Problem is that i did encounter this in an eclipse plugin we use
Sometimes it worked (collection was smaller then the set) other times i got
very weird behavior
It is just something you dont expect. I expect that it honors the objects
contract when i call something on that object..
I dont say
collection.removeIn(set) no i call set.removeAll(collection)
johan
On Thu, Mar 5, 2009 at 13:36, Pointbreak
> wrote:
> You are missing the point. With a string it will work, because the
> elements will actually be the same string objects, so the String.equals
> and the overridden compare method will give the same results in the
> example. Johan's point is that while set1.removeAll() is called, it is
> not the compare method of set1 that is used, which seems
> counterintuitive.
>
> On Thu, 05 Mar 2009 13:13 +0100, "Dave Schoorl"
> wrote:
> > If I change every MyObject in a String, everything is fine. Perhaps the
> > MyObject is not obeying the necessary contracts?
> >
> > See adjusted code below:
> >
> >
> >
> > import java.util.ArrayList;
> > import java.util.Collection;
> > import java.util.Comparator;
> > import java.util.HashSet;
> > import java.util.Iterator;
> > import java.util.TreeSet;
> >
> > public class TestWithStrings
> > {
> > public static void main(String[] args)
> > {
> > TreeSet set1 = getCleanSet();
> >
> > HashSet set2 = new HashSet();
> > set2.add("johan");
> >
> >
> > set1.removeAll(set2);
> >
> > System.err.println("this works: " + set1.size() + " == 1, and
> > remaining object is " + set1.iterator().next() + " == rob");
> >
> > // add removed back in
> > set1 = getCleanSet();
> >
> > // increase the size of set2 with some other random others
> > set2.add("random1");
> > set2.add("random2");
> >
> > // now size is bigger then set1, call removeall again:
> > set1.removeAll(set2);
> >
> > System.err.println("this doesnt work: " + set1.size() + " != 1,
> > so now both objects stil remain! This is because " +
> > "removeAll isnt overwritten by TreeSet and AbstractSet
> > walks over the smallest set but then compare fails");
> >
> > // same for retainAll that also compares wrong.
> > set1 = getCleanSet();
> > set1.retainAll(set2);
> >
> > System.err.println("set1 is now completely empty, but it should
> > have 1 left: " + set1);
> >
> > // so both methods should always iterator through the colleciton
> > they get and do the compare on its self
> >
> > set1 = getCleanFixedSet();
> >
> > set1.removeAll(set2);
> >
> > System.err.println("now this works: " + set1.size() + " == 1,
> > and remainng object is " + set1.iterator().next() + " == rob");
> >
> > // add removed back in
> > set1 = getCleanFixedSet();
> >
> > set1.retainAll(set2);
> >
> > System.err.println("set1 is now correct, it has 1 left: " +
> > set1);
> >
> > }
> >
> > public static TreeSet getCleanSet() {
> > TreeSet set1 = new TreeSet(new
> > Comparator(){
> >
> > public int compare(String o1, String o2)
> > {
> > return o1.compareToIgnoreCase(o2);
> > }
> > });
> >
> > set1.add("johan");
> > set1.add("rob");
> >
> > return set1;
> > }
> >
> > public static TreeSet getCleanFixedSet() {
> > TreeSet set1 = new MyFixedTreeSet(new
> > Comparator(){
> >
> > public int compare(String o1, String o2)
> > {
> > return o1.compareToIgnoreCase(o2);
> > }
> > });
> >
> > set1.add("johan");
> > set1.add("rob");
> > return set1;
> > }
> >
> > public static class MyFixedTreeSet extends TreeSet
> > {
> > public MyFixedTreeSet(Comparator comparator)
> > {
> > super(comparator);
> > }
> >
> > @Override
> > public boolean retainAll(Collection c)
> > {
> > ArrayList list = new ArrayList();
> > Iterator e = c.iterator();
> > while (e.hasNext()) {
> > Object next = e.next();
> > if (contains(next)) {
> > list.add((E)next);
> > }
> > }
> > boolean modified = list.size() < size();
> > if (modified)
> > {
> > clear();
> > for (E item : list)
> > {
> > add(item);
> > }
> > }
> > return modified;
> > }
> >
> > @Override
> > public boolean removeAll(Collection c)
> > {
> >
Re: a bit of topic but i couldnt resist ....
Sorry, I have to correct myself. According to the API-docs, the compare
method in a TreeSet must be consistent with equals. In Johan's example
it is not.
On Thu, 05 Mar 2009 13:36 +0100, "Pointbreak"
wrote:
> You are missing the point. With a string it will work, because the
> elements will actually be the same string objects, so the String.equals
> and the overridden compare method will give the same results in the
> example. Johan's point is that while set1.removeAll() is called, it is
> not the compare method of set1 that is used, which seems
> counterintuitive.
>
> On Thu, 05 Mar 2009 13:13 +0100, "Dave Schoorl"
> wrote:
> > If I change every MyObject in a String, everything is fine. Perhaps the
> > MyObject is not obeying the necessary contracts?
> >
> > See adjusted code below:
> >
> >
> >
> > import java.util.ArrayList;
> > import java.util.Collection;
> > import java.util.Comparator;
> > import java.util.HashSet;
> > import java.util.Iterator;
> > import java.util.TreeSet;
> >
> > public class TestWithStrings
> > {
> > public static void main(String[] args)
> > {
> > TreeSet set1 = getCleanSet();
> >
> > HashSet set2 = new HashSet();
> > set2.add("johan");
> >
> >
> > set1.removeAll(set2);
> >
> > System.err.println("this works: " + set1.size() + " == 1, and
> > remaining object is " + set1.iterator().next() + " == rob");
> >
> > // add removed back in
> > set1 = getCleanSet();
> >
> > // increase the size of set2 with some other random others
> > set2.add("random1");
> > set2.add("random2");
> >
> > // now size is bigger then set1, call removeall again:
> > set1.removeAll(set2);
> >
> > System.err.println("this doesnt work: " + set1.size() + " != 1,
> > so now both objects stil remain! This is because " +
> > "removeAll isnt overwritten by TreeSet and AbstractSet
> > walks over the smallest set but then compare fails");
> >
> > // same for retainAll that also compares wrong.
> > set1 = getCleanSet();
> > set1.retainAll(set2);
> >
> > System.err.println("set1 is now completely empty, but it should
> > have 1 left: " + set1);
> >
> > // so both methods should always iterator through the colleciton
> > they get and do the compare on its self
> >
> > set1 = getCleanFixedSet();
> >
> > set1.removeAll(set2);
> >
> > System.err.println("now this works: " + set1.size() + " == 1,
> > and remainng object is " + set1.iterator().next() + " == rob");
> >
> > // add removed back in
> > set1 = getCleanFixedSet();
> >
> > set1.retainAll(set2);
> >
> > System.err.println("set1 is now correct, it has 1 left: " +
> > set1);
> >
> > }
> >
> > public static TreeSet getCleanSet() {
> > TreeSet set1 = new TreeSet(new
> > Comparator(){
> >
> > public int compare(String o1, String o2)
> > {
> > return o1.compareToIgnoreCase(o2);
> > }
> > });
> >
> > set1.add("johan");
> > set1.add("rob");
> >
> > return set1;
> > }
> >
> > public static TreeSet getCleanFixedSet() {
> > TreeSet set1 = new MyFixedTreeSet(new
> > Comparator(){
> >
> > public int compare(String o1, String o2)
> > {
> > return o1.compareToIgnoreCase(o2);
> > }
> > });
> >
> > set1.add("johan");
> > set1.add("rob");
> > return set1;
> > }
> >
> > public static class MyFixedTreeSet extends TreeSet
> > {
> > public MyFixedTreeSet(Comparator comparator)
> > {
> > super(comparator);
> > }
> >
> > @Override
> > public boolean retainAll(Collection c)
> > {
> > ArrayList list = new ArrayList();
> > Iterator e = c.iterator();
> > while (e.hasNext()) {
> > Object next = e.next();
> > if (contains(next)) {
> > list.add((E)next);
> > }
> > }
> > boolean modified = list.size() < size();
> > if (modified)
> > {
> > clear();
> > for (E item : list)
> > {
> > add(item);
> > }
> > }
> > return modified;
> > }
> >
> > @Override
> > public boolean removeAll(Collection c)
> > {
> > boolean modified = false;
> > for (Iterator i = c.iterator(); i.hasNext(); )
> > modified |= remove(i.next());
> > return modified;
> > }
> > }
> > }
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicke
Re: a bit of topic but i couldnt resist ....
You are missing the point. With a string it will work, because the
elements will actually be the same string objects, so the String.equals
and the overridden compare method will give the same results in the
example. Johan's point is that while set1.removeAll() is called, it is
not the compare method of set1 that is used, which seems
counterintuitive.
On Thu, 05 Mar 2009 13:13 +0100, "Dave Schoorl"
wrote:
> If I change every MyObject in a String, everything is fine. Perhaps the
> MyObject is not obeying the necessary contracts?
>
> See adjusted code below:
>
>
>
> import java.util.ArrayList;
> import java.util.Collection;
> import java.util.Comparator;
> import java.util.HashSet;
> import java.util.Iterator;
> import java.util.TreeSet;
>
> public class TestWithStrings
> {
> public static void main(String[] args)
> {
> TreeSet set1 = getCleanSet();
>
> HashSet set2 = new HashSet();
> set2.add("johan");
>
>
> set1.removeAll(set2);
>
> System.err.println("this works: " + set1.size() + " == 1, and
> remaining object is " + set1.iterator().next() + " == rob");
>
> // add removed back in
> set1 = getCleanSet();
>
> // increase the size of set2 with some other random others
> set2.add("random1");
> set2.add("random2");
>
> // now size is bigger then set1, call removeall again:
> set1.removeAll(set2);
>
> System.err.println("this doesnt work: " + set1.size() + " != 1,
> so now both objects stil remain! This is because " +
> "removeAll isnt overwritten by TreeSet and AbstractSet
> walks over the smallest set but then compare fails");
>
> // same for retainAll that also compares wrong.
> set1 = getCleanSet();
> set1.retainAll(set2);
>
> System.err.println("set1 is now completely empty, but it should
> have 1 left: " + set1);
>
> // so both methods should always iterator through the colleciton
> they get and do the compare on its self
>
> set1 = getCleanFixedSet();
>
> set1.removeAll(set2);
>
> System.err.println("now this works: " + set1.size() + " == 1,
> and remainng object is " + set1.iterator().next() + " == rob");
>
> // add removed back in
> set1 = getCleanFixedSet();
>
> set1.retainAll(set2);
>
> System.err.println("set1 is now correct, it has 1 left: " +
> set1);
>
> }
>
> public static TreeSet getCleanSet() {
> TreeSet set1 = new TreeSet(new
> Comparator(){
>
> public int compare(String o1, String o2)
> {
> return o1.compareToIgnoreCase(o2);
> }
> });
>
> set1.add("johan");
> set1.add("rob");
>
> return set1;
> }
>
> public static TreeSet getCleanFixedSet() {
> TreeSet set1 = new MyFixedTreeSet(new
> Comparator(){
>
> public int compare(String o1, String o2)
> {
> return o1.compareToIgnoreCase(o2);
> }
> });
>
> set1.add("johan");
> set1.add("rob");
> return set1;
> }
>
> public static class MyFixedTreeSet extends TreeSet
> {
> public MyFixedTreeSet(Comparator comparator)
> {
> super(comparator);
> }
>
> @Override
> public boolean retainAll(Collection c)
> {
> ArrayList list = new ArrayList();
> Iterator e = c.iterator();
> while (e.hasNext()) {
> Object next = e.next();
> if (contains(next)) {
> list.add((E)next);
> }
> }
> boolean modified = list.size() < size();
> if (modified)
> {
> clear();
> for (E item : list)
> {
> add(item);
> }
> }
> return modified;
> }
>
> @Override
> public boolean removeAll(Collection c)
> {
> boolean modified = false;
> for (Iterator i = c.iterator(); i.hasNext(); )
> modified |= remove(i.next());
> return modified;
> }
> }
> }
>
>
>
> -
> 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: How can I injecting a Springbean into a custom session.
Thanks, Igor; this worked perfectly. -- View this message in context: http://www.nabble.com/How-can-I-injecting-a-Springbean-into-a-custom-session.-tp22340379p22350445.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
Re: a bit of topic but i couldnt resist ....
If I change every MyObject in a String, everything is fine. Perhaps the
MyObject is not obeying the necessary contracts?
See adjusted code below:
import java.util.ArrayList;
import java.util.Collection;
import java.util.Comparator;
import java.util.HashSet;
import java.util.Iterator;
import java.util.TreeSet;
public class TestWithStrings
{
public static void main(String[] args)
{
TreeSet set1 = getCleanSet();
HashSet set2 = new HashSet();
set2.add("johan");
set1.removeAll(set2);
System.err.println("this works: " + set1.size() + " == 1, and
remaining object is " + set1.iterator().next() + " == rob");
// add removed back in
set1 = getCleanSet();
// increase the size of set2 with some other random others
set2.add("random1");
set2.add("random2");
// now size is bigger then set1, call removeall again:
set1.removeAll(set2);
System.err.println("this doesnt work: " + set1.size() + " != 1,
so now both objects stil remain! This is because " +
"removeAll isnt overwritten by TreeSet and AbstractSet
walks over the smallest set but then compare fails");
// same for retainAll that also compares wrong.
set1 = getCleanSet();
set1.retainAll(set2);
System.err.println("set1 is now completely empty, but it should
have 1 left: " + set1);
// so both methods should always iterator through the colleciton
they get and do the compare on its self
set1 = getCleanFixedSet();
set1.removeAll(set2);
System.err.println("now this works: " + set1.size() + " == 1,
and remainng object is " + set1.iterator().next() + " == rob");
// add removed back in
set1 = getCleanFixedSet();
set1.retainAll(set2);
System.err.println("set1 is now correct, it has 1 left: " + set1);
}
public static TreeSet getCleanSet() {
TreeSet set1 = new TreeSet(new Comparator(){
public int compare(String o1, String o2)
{
return o1.compareToIgnoreCase(o2);
}
});
set1.add("johan");
set1.add("rob");
return set1;
}
public static TreeSet getCleanFixedSet() {
TreeSet set1 = new MyFixedTreeSet(new
Comparator(){
public int compare(String o1, String o2)
{
return o1.compareToIgnoreCase(o2);
}
});
set1.add("johan");
set1.add("rob");
return set1;
}
public static class MyFixedTreeSet extends TreeSet
{
public MyFixedTreeSet(Comparator comparator)
{
super(comparator);
}
@Override
public boolean retainAll(Collection c)
{
ArrayList list = new ArrayList();
Iterator e = c.iterator();
while (e.hasNext()) {
Object next = e.next();
if (contains(next)) {
list.add((E)next);
}
}
boolean modified = list.size() < size();
if (modified)
{
clear();
for (E item : list)
{
add(item);
}
}
return modified;
}
@Override
public boolean removeAll(Collection c)
{
boolean modified = false;
for (Iterator i = c.iterator(); i.hasNext(); )
modified |= remove(i.next());
return modified;
}
}
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
XML localization
I've tried search the forum and googled but no answer so I'll give it a try. A while ago we needed to implement a new language to our wicket site. We changed from .properties to .xml to get this to work. The problem is that some things has stopped working. Consider the following We have a textfield in a form that needs to be required. In our .properties file I added form.email.Required=Please fill in email when doing this is a .xml it does not work. form.email.Required ( not working ) email.Required ( not working ) Required ( working ) Any comments? -- View this message in context: http://www.nabble.com/XML-localization-tp22349788p22349788.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
Re: Expected close tag for ??
I've checked through the html and couldn't find anything unusual.
I'm making calls to wicket links in the html:
# Customer
{how do we add html to a post?}
in the java:
add(new BookmarkablePageLink("PageLink", CustomerPage.class));
The html for HomePage.html exists between
.
.
.
HomePage.java extends a base page Base.java that in its html has most of the
html tags, the link tags and :
which is inside where the HomePage.html is placed.
--
View this message in context:
http://www.nabble.com/Expected-close-tag-for-%3Cwicket%3Alink%3Etp22335083p22349654.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
Re: Expected close tag for ??
Hello Thomas, org.apache.wicket.markup.MarkupException: Expected close tag for [markup = file:/C:/Programme/Apache Software Foundation/geronimo-2.1.2/repository/default/test/app.war/WEB-INF/classes/com/path/app/web/pages/base/HomePage.html then the html for the page HomePage.html is displayed . . . , index = 114, current = [Raw markup]] at org.apache.wicket.markup.MarkupStream.throwMarkupException(MarkupStream.java:464) at org.apache.wicket.Component.renderClosingComponentTag(Component.java:4035) at org.apache.wicket.Component.renderComponent(Component.java:2427) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1354) at org.apache.wicket.Component.render(Component.java:2256) at org.apache.wicket.MarkupContainer.autoAdd(MarkupContainer.java:222) at org.apache.wicket.markup.resolver.WicketLinkResolver.resolve(WicketLinkResolver.java:73) at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1267) at org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1407) at org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java:1344) at org.apache.wicket.Component.renderComponent(Component.java:2419) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1354) at org.apache.wicket.Component.render(Component.java:2256) at org.apache.wicket.MarkupContainer.autoAdd(MarkupContainer.java:222) at org.apache.wicket.markup.resolver.WicketLinkResolver.resolve(WicketLinkResolver.java:73) at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1267) at org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:1407) at org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java:1344) at org.apache.wicket.Component.renderComponent(Component.java:2419) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1354) at org.apache.wicket.Component.render(Component.java:2256) at org.apache.wicket.MarkupContainer.autoAdd(MarkupContainer.java:222) at org.apache.wicket.markup.parser.filter.RelativePathPrefixHandler.resolve(RelativePathPrefixHandler.java:183) at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1267) at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1370) at org.apache.wicket.Page.onRender(Page.java:1442) at org.apache.wicket.Component.render(Component.java:2256) at org.apache.wicket.Page.renderPage(Page.java:891) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.respond(BookmarkablePageRequestTarget.java:231) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:103) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1100) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1169) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1248) at org.apache.wicket.RequestCycle.request(RequestCycle.java:489) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:121) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(U
Callbacks with abstract method in ModalWindow
Hi. Im having a problem with the modalwindow again. It's probably my code so
I'll try to explain what I doing.
I have a Panel that I want to reuse. It's a panel with a form where you can
update som data. Because it will be used by different pages with Ajax
Behavior I want a to add
a callback when the Panel form is commited.
So the Panels form contains a AjaxButton where I can handle the onSubmit
method. The Panel is abstract with the abstract method
onFinished(AjaxRequestTarget target).
Looks something like this:
public abstract class CallBackPanel extends Panel {
public CallBackPanel(String id) {
...
add(form);
AjaxButton saveButton = new AjaxButton("savebutton", form) {
//Also override onError
@Override
protected void onSubmit(AjaxRequestTarget pTarget,
org.apache.wicket.markup.html.form.Form pForm) {
...
onFinished(pTarget);
}
}
form.add(saveButton);
//also adds a cancel button
...
}
protected abstract void onFinished(AjaxRequestTarget pTarget);
}
I got some problems with this Panel. If I add it as a Panel in a ModalWindow
with the setContent method the callback method 'onFinished' is able to
update the
components in the page that use the it.
But if I add the panel to a Page and then use the ModelWindow.setPageCreator
method the callback method 'onFinished' wont update the components.
Ex (in my page that uses the CallBackPanel):
...
public Page createPage() {
ModalContentPage mcp = new
ModalContentPage();
mcp.add(new CallBackPanel("thepanel"){
@Override
protected void onFinished(AjaxRequestTarget pTarget){
modalWindow.close(pTarget);
pTarget.addComponent(myPageComponentThatNeedsUpdating);
//myPageComponentThatNeedsUpdating is set to final
}
);
return mcp;
}
...
The method inFinished is running but myPageComponentThatNeedsUpdating is not
updated.
Should I avoid doing solution like abstract CallBackPanel when morking with
modalwindows?
Or is it something with the AjaxRequestTarget that I missed?
Jens Alenius
--
View this message in context:
http://www.nabble.com/Callbacks-with-abstract-method-in-ModalWindow-tp22349647p22349647.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
Re: [vote] In Wicket 1.4 and onwards, remove widening from the list of choices model in DropDownChoice, changing it from IModel> to IModel>
-1 from me. I prefer the wildcards. It let's the client code be more flexible On Mar 5, 2009 1:20 AM, "Martijn Reuvers" wrote: +1 for me too. On Tue, Mar 3, 2009 at 9:39 PM, Martijn Dashorst wrote: > Though I hav...
Re: a bit of topic but i couldnt resist ....
Yes i know that that COULD help but not really for all the situations.
The thing is that i give the TreeSet a Comparator that defines the order and
equal of the objects
And i expect that that will be used when i do:
treeset.removeAll(Collection)
So then it is the same thing as i do:
Iterator it = collection.iterator()
while(it) treeset.remove(it.next())
Because then MY definition of what is equals for that treeset is used. But
the above removeAll one isnt! (depending on the size of the collection!!)
For example the equals or hashcode really doesnt work
Use this :
public static class MyObject
{
private final String aString;
private final String aId;
MyObject(int id, String str)
{
aString = str;
aId = id;
}
public int hashCode(){ return aId;}
public boolean equals(Object object)
{
if (object instanceof MyObject)
{
return aId == ((MyObject)object).aId;
}
return false;
}
public String toString()
{
return aString;
}
}
So if you use that
Then create this
set1.add(new MyObject(1,"johan"));
set1.add(new MyObject(2,"rob"));
HashSet set2 = new HashSet();
set2.add(new MyObject(3, "johan")); <<< SEE the other id this is another
johan!!
then still if i do this:
set1.removeAll(set2)
i expect that "johan" whith id 1 is removed from the set2 because my
Comparator tells that those 2 are the same!!!
i just expect that:
treeset.removeAll(Collection)
==
Iterator it = collection.iterator()
while(it) treeset.remove(it.next())
its just weird that that isnt the case.
I think it is a bug. Sun things no we follow the spec. Then the spec is
wrong.
Sun does think the 2 behaviors depending if the collection is smaller or
bigger then the set is a bug. But that seems to be very low proi.
johan
On Thu, Mar 5, 2009 at 11:58, jWeekend wrote:
>
> Johan,
>
> I can't have a thorough look at this until later, but the first thing I
> noticed is that MyObject does not have equals and hashCode defined, yet you
> are putting instances of it into hashed collections.
> Even if that isn't causing the main issue you are demonstrating, you may
> witness "surprising" behaviour.
>
> Regards - Cemal
> http://jWeekend.com jWeekend
>
>
> Johan Compagner wrote:
> >
> > it has nothing to do with threading or concurent modification
> >
> > Its really a simple test just run this:
> >
> > import java.util.ArrayList;
> > import java.util.Collection;
> > import java.util.Comparator;
> > import java.util.HashSet;
> > import java.util.Iterator;
> > import java.util.TreeSet;
> >
> > public class Test
> > {
> > public static void main(String[] args)
> > {
> > TreeSet set1 = new TreeSet(new
> > Comparator(){
> >
> > public int compare(MyObject o1, MyObject o2)
> > {
> > return o1.aString.compareToIgnoreCase(o2.aString);
> > }
> > });
> >
> > set1.add(new MyObject("johan"));
> > set1.add(new MyObject("rob"));
> >
> > HashSet set2 = new HashSet();
> > set2.add(new MyObject("johan"));
> >
> >
> > set1.removeAll(set2);
> >
> > System.err.println("this works: " + set1.size() + " == 1, and
> > remainng object is " + set1.iterator().next() + " == rob");
> >
> > // add removed back in
> > set1.add(new MyObject("johan"));
> >
> > // increase the size of set2 with some other random others
> > set2.add(new MyObject("random1"));
> > set2.add(new MyObject("random2"));
> >
> >
> > // now size is bigger then set1, call removeall again:
> > set1.removeAll(set2);
> >
> > System.err.println("this doesnt work: " + set1.size() + " != 1,
> so
> > now both objects stil remain! This is because removeAll isnt overwritten
> > by
> > TreeSet and AbstractSet walks over the smallest set but then compare
> > fails");
> >
> > // same for retainAll that also compares wrong.
> > set1.retainAll(set2);
> >
> > System.err.println("set1 is now completely empty, but it should
> > have
> > 1 left: " + set1);
> >
> > // so both methods should always iterator through the colleciton
> > they get and do the compare on its self
> >
> > set1 = new MyFixedTreeSet(new Comparator(){
> >
> > public int compare(MyObject o1, MyObject o2)
> > {
> > return o1.aString.compareToIgnoreCase(o2.aString);
> > }
> > });
> >
> > set1.add(new MyObject("johan"));
> > set1.add(new MyObject("rob"));
> >
> > set1.removeAll(set2);
> >
> > System.err.println("now this works: " + set1.size() + " == 1, and
> > remainng object is " + set1.iterator().next() + " == rob");
> >
> > // add removed back in
> > set1.add(new MyObject("johan"));
> >
> > set1.retainAll(set2);
> >
> > System.err.println("set1 is now correct, it has 1 left: " +
> set1);
> >
> > }
> >
> >
Re: a bit of topic but i couldnt resist ....
Johan,
I can't have a thorough look at this until later, but the first thing I
noticed is that MyObject does not have equals and hashCode defined, yet you
are putting instances of it into hashed collections.
Even if that isn't causing the main issue you are demonstrating, you may
witness "surprising" behaviour.
Regards - Cemal
http://jWeekend.com jWeekend
Johan Compagner wrote:
>
> it has nothing to do with threading or concurent modification
>
> Its really a simple test just run this:
>
> import java.util.ArrayList;
> import java.util.Collection;
> import java.util.Comparator;
> import java.util.HashSet;
> import java.util.Iterator;
> import java.util.TreeSet;
>
> public class Test
> {
> public static void main(String[] args)
> {
> TreeSet set1 = new TreeSet(new
> Comparator(){
>
> public int compare(MyObject o1, MyObject o2)
> {
> return o1.aString.compareToIgnoreCase(o2.aString);
> }
> });
>
> set1.add(new MyObject("johan"));
> set1.add(new MyObject("rob"));
>
> HashSet set2 = new HashSet();
> set2.add(new MyObject("johan"));
>
>
> set1.removeAll(set2);
>
> System.err.println("this works: " + set1.size() + " == 1, and
> remainng object is " + set1.iterator().next() + " == rob");
>
> // add removed back in
> set1.add(new MyObject("johan"));
>
> // increase the size of set2 with some other random others
> set2.add(new MyObject("random1"));
> set2.add(new MyObject("random2"));
>
>
> // now size is bigger then set1, call removeall again:
> set1.removeAll(set2);
>
> System.err.println("this doesnt work: " + set1.size() + " != 1, so
> now both objects stil remain! This is because removeAll isnt overwritten
> by
> TreeSet and AbstractSet walks over the smallest set but then compare
> fails");
>
> // same for retainAll that also compares wrong.
> set1.retainAll(set2);
>
> System.err.println("set1 is now completely empty, but it should
> have
> 1 left: " + set1);
>
> // so both methods should always iterator through the colleciton
> they get and do the compare on its self
>
> set1 = new MyFixedTreeSet(new Comparator(){
>
> public int compare(MyObject o1, MyObject o2)
> {
> return o1.aString.compareToIgnoreCase(o2.aString);
> }
> });
>
> set1.add(new MyObject("johan"));
> set1.add(new MyObject("rob"));
>
> set1.removeAll(set2);
>
> System.err.println("now this works: " + set1.size() + " == 1, and
> remainng object is " + set1.iterator().next() + " == rob");
>
> // add removed back in
> set1.add(new MyObject("johan"));
>
> set1.retainAll(set2);
>
> System.err.println("set1 is now correct, it has 1 left: " + set1);
>
> }
>
> public static class MyObject
> {
> private final String aString;
>
> MyObject(String str)
> {
> aString = str;
> }
>
> @Override
> public String toString()
> {
> return aString;
> }
> }
>
> public static class MyFixedTreeSet extends TreeSet
> {
> public MyFixedTreeSet(Comparator comparator)
> {
> super(comparator);
> }
>
> @Override
> public boolean retainAll(Collection c)
> {
> ArrayList list = new ArrayList();
> Iterator e = c.iterator();
> while (e.hasNext()) {
> Object next = e.next();
> if (contains(next)) {
> list.add((E)next);
> }
> }
> boolean modified = list.size() < size();
> if (modified)
> {
> clear();
> for (E item : list)
> {
> add(item);
> }
> }
> return modified;
> }
>
> @Override
> public boolean removeAll(Collection c)
> {
> boolean modified = false;
> for (Iterator i = c.iterator(); i.hasNext(); )
> modified |= remove(i.next());
> return modified;
> }
> }
> }
>
> johan
>
>
>
> On Wed, Mar 4, 2009 at 15:35, Brill Pappin wrote:
>
>> if "xxx" is a mutable Set then it should work.
>>
>> However you have to be careful about how you remove elements from the
>> collection you working with, depending on your you do it, you'll get an
>> exception about concurrent modification.
>>
>> - Brill
>>
>>
>> On 3-Mar-09, at 5:44 PM, Johan Compagner wrote:
>>
>> Is this the same?
>>>
>>> Set set1 = xxx
>>> Collection col1 = xxx;
>>>
>>> foreach (col in col1)
>>> set1.remove(col)
>>>
>>> or
>>>
>>> set1.removeAll(col1);
>>>
>>>
>>> ???
>>>
>>
>>
>> -
Re: a bit of topic but i couldnt resist ....
it has nothing to do with threading or concurent modification
Its really a simple test just run this:
import java.util.ArrayList;
import java.util.Collection;
import java.util.Comparator;
import java.util.HashSet;
import java.util.Iterator;
import java.util.TreeSet;
public class Test
{
public static void main(String[] args)
{
TreeSet set1 = new TreeSet(new
Comparator(){
public int compare(MyObject o1, MyObject o2)
{
return o1.aString.compareToIgnoreCase(o2.aString);
}
});
set1.add(new MyObject("johan"));
set1.add(new MyObject("rob"));
HashSet set2 = new HashSet();
set2.add(new MyObject("johan"));
set1.removeAll(set2);
System.err.println("this works: " + set1.size() + " == 1, and
remainng object is " + set1.iterator().next() + " == rob");
// add removed back in
set1.add(new MyObject("johan"));
// increase the size of set2 with some other random others
set2.add(new MyObject("random1"));
set2.add(new MyObject("random2"));
// now size is bigger then set1, call removeall again:
set1.removeAll(set2);
System.err.println("this doesnt work: " + set1.size() + " != 1, so
now both objects stil remain! This is because removeAll isnt overwritten by
TreeSet and AbstractSet walks over the smallest set but then compare
fails");
// same for retainAll that also compares wrong.
set1.retainAll(set2);
System.err.println("set1 is now completely empty, but it should have
1 left: " + set1);
// so both methods should always iterator through the colleciton
they get and do the compare on its self
set1 = new MyFixedTreeSet(new Comparator(){
public int compare(MyObject o1, MyObject o2)
{
return o1.aString.compareToIgnoreCase(o2.aString);
}
});
set1.add(new MyObject("johan"));
set1.add(new MyObject("rob"));
set1.removeAll(set2);
System.err.println("now this works: " + set1.size() + " == 1, and
remainng object is " + set1.iterator().next() + " == rob");
// add removed back in
set1.add(new MyObject("johan"));
set1.retainAll(set2);
System.err.println("set1 is now correct, it has 1 left: " + set1);
}
public static class MyObject
{
private final String aString;
MyObject(String str)
{
aString = str;
}
@Override
public String toString()
{
return aString;
}
}
public static class MyFixedTreeSet extends TreeSet
{
public MyFixedTreeSet(Comparator comparator)
{
super(comparator);
}
@Override
public boolean retainAll(Collection c)
{
ArrayList list = new ArrayList();
Iterator e = c.iterator();
while (e.hasNext()) {
Object next = e.next();
if (contains(next)) {
list.add((E)next);
}
}
boolean modified = list.size() < size();
if (modified)
{
clear();
for (E item : list)
{
add(item);
}
}
return modified;
}
@Override
public boolean removeAll(Collection c)
{
boolean modified = false;
for (Iterator i = c.iterator(); i.hasNext(); )
modified |= remove(i.next());
return modified;
}
}
}
johan
On Wed, Mar 4, 2009 at 15:35, Brill Pappin wrote:
> if "xxx" is a mutable Set then it should work.
>
> However you have to be careful about how you remove elements from the
> collection you working with, depending on your you do it, you'll get an
> exception about concurrent modification.
>
> - Brill
>
>
> On 3-Mar-09, at 5:44 PM, Johan Compagner wrote:
>
> Is this the same?
>>
>> Set set1 = xxx
>> Collection col1 = xxx;
>>
>> foreach (col in col1)
>> set1.remove(col)
>>
>> or
>>
>> set1.removeAll(col1);
>>
>>
>> ???
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Dutch government picks Hippo CMS for all public websites
goed nieuws! this is a great step forward for wicket, a fact that reveals its quality and maturity (without having to pass through a JSR, btw). congratulations to the hippo team! francisco On Thu, Mar 5, 2009 at 11:08 AM, jWeekend wrote: > > Martijn, > > This really is big news for anyone that wants more people to be aware of > just how good Wicket is and benefit from building serious systems with it. > > It says a lot about the quality of the framework, the people that have built > it, and the community that supports it. > > Arje, special congratulations to your team, and thanks for making this > breakthrough that puts Wicket onto a new level of "yes we can"ness for large > organisations all over the world. > > Regards - Cemal > http://jWeekend.com jWeekend > > > > > Martijn Dashorst wrote: >> >> This is of huge interest for the Wicket community: HippoCMS is a large >> supporter and user of Apache open source software in general, and >> Wicket in particular. >> >> HippoCMS uses Wicket in large parts of their infrastructure and I am >> excited to hear that Wicket will be at the basis for the Dutch >> government. >> >> In a publication at the local IT gossip site 'webwereld' it is >> announced that all government websites will be consolidated into one >> portal using the Hippo technology. >> >> Kudos to the Hippo team! >> >> Martijn >> >> [1] >> http://webwereld.nl/nieuws/56024/n-website-gaat-alle-rijksoverheidssites-vervangen.html >> >> -- >> Become a Wicket expert, learn from the best: http://wicketinaction.com >> Apache Wicket 1.3.5 is released >> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> > > -- > View this message in context: > http://www.nabble.com/Dutch-government-picks-Hippo-CMS-for-all-public-websites-tp22347866p22348659.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 > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Help: AjaxEditableLabel error
sorry
the reason for the error is AjaxEditableLabel descriptionEditableLabel = new
AjaxEditableChoiceLabel("description", new PropertyModel(fileObj,
"description"))
it should be
AjaxEditableLabel descriptionEditableLabel = new
AjaxEditableLabel("description", new PropertyModel(fileObj, "description"))
wch2001 wrote:
>
> Dear all,
>
> I am using AjaxEditableLabel, with the following codes,
> it is ok to show the description, but when i clicked it, error happened.
> "onEdit ..." is on the console , so it already call onEdit()
> method,
> how to implement the method? how to solve the question?
>
> thanks a lot.
>
>
>
> AjaxEditableLabel descriptionEditableLabel = new
> AjaxEditableChoiceLabel("description", new PropertyModel(fileObj,
> "description")){
>
> @Override
> protected void onEdit(AjaxRequestTarget arg0) {
> System.out.println("onEdit ...");
> super.onEdit(arg0);
> }
>
> @Override
> protected void onError(AjaxRequestTarget arg0) {
> System.out.println("onError ...");
> super.onError(arg0);
> }
>
> @Override
> protected void onSubmit(AjaxRequestTarget arg0) {
> System.out.println("onSubmit ...");
> super.onSubmit(arg0);
> }
>
> };
> item.add(descriptionEditableLabel);
>
>
> Exception:
>
> onEdit ...
> org.apache.wicket.WicketRuntimeException: Exception in rendering
> component: [MarkupContainer [Component id = editor, page =
> sg.sphsearch.dira.web.wicket.pages.people.EditPersonPage, path =
> 3:tabpanel:panel:attachedFilesPanelContainer:saveUploadFilesForm:group:fileList:0:description:editor.DropDownChoice,
> isVisible = true, isVersioned = false]]
> at
> org.apache.wicket.Component.renderComponent(Component.java:2467)
> at
> org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1354)
>
>
--
View this message in context:
http://www.nabble.com/Help%3A-AjaxEditableLabel-error-tp22347654p22348774.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
Re: Dutch government picks Hippo CMS for all public websites
Martijn, This really is big news for anyone that wants more people to be aware of just how good Wicket is and benefit from building serious systems with it. It says a lot about the quality of the framework, the people that have built it, and the community that supports it. Arje, special congratulations to your team, and thanks for making this breakthrough that puts Wicket onto a new level of "yes we can"ness for large organisations all over the world. Regards - Cemal http://jWeekend.com jWeekend Martijn Dashorst wrote: > > This is of huge interest for the Wicket community: HippoCMS is a large > supporter and user of Apache open source software in general, and > Wicket in particular. > > HippoCMS uses Wicket in large parts of their infrastructure and I am > excited to hear that Wicket will be at the basis for the Dutch > government. > > In a publication at the local IT gossip site 'webwereld' it is > announced that all government websites will be consolidated into one > portal using the Hippo technology. > > Kudos to the Hippo team! > > Martijn > > [1] > http://webwereld.nl/nieuws/56024/n-website-gaat-alle-rijksoverheidssites-vervangen.html > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > Apache Wicket 1.3.5 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://www.nabble.com/Dutch-government-picks-Hippo-CMS-for-all-public-websites-tp22347866p22348659.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
setRequired() final?
I have a form component to select items and would like to add lower and upper constraints on the number of items that need to be set by the user. I added setMin() and setMax() methods and would like to override setRequired() to call setMin(1). However, FormComponent.setRequired is final. Is there a particular reason for this? Thanks, Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Martijn,
Is there not already an EasyUpperCaseRUs.com web service you can subscribe
to for unlimited conversions at an annual fee of under 30,000USD (or
100USD/conversion) who also have a "5 free conversions" trial subscription?
Ether way, I would suggest this be done at conversion time so validation can
do its job properly and you're not handing off conversion responsibilities
where they don't belong. Some solutions leaving this transformation of the
text input by the user until after conversion in the form processing
life-cycle may be less lines of code (or less classes), but IMO, are bending
rules and ignoring good design principles.
Of course, others may disagree and come up with all sorts of "neat"
solutions that still manage to upper-case a string; how about "just cut out
the middle-man altogether and do it in a stored-procedure triggered on
INSERT and UPDATE" - that would work too, but wouldn't be my choice.
There's also a degree of "it depends" here, but generally, the
form-processing life-cycle should be respected or explicitly overridden for
a good design reason (to meet user requirements).
Regards - Cemal
http://jWeekend.com jWeekend
Martijn Dashorst wrote:
>
> I suggest setting up an ESB with a UppercaseService that is available
> through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
> that UppercaseService to make the value uppercase.
>
> Martijn
>
> On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg
> wrote:
>> you can create a convertermodel that takes an instance of iconverter
>> and uses that to convert the values, then you can subclass textfield,
>> override initmodel() and wrap any model the textfield had with this
>> one.
>>
>> that way everyone is happy!
>>
>> -igor
>>
>> On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
>> wrote:
>>> LOL! Nah - I would just change all the setters on every domain object
>>> to
>>> be:
>>>
>>> public void setFoo(String foo) {
>>> this.foo = foo == null ? null : foo.toUpperCase();
>>> }
>>>
>>> Or, maybe I'd use AOP and build an aspect that could automatically
>>> intercept
>>> calls to com.mydomain setters that take a single string argument and do
>>> the
>>> upper-casing there!
>>>
>>> It's makes me smile to think of how many ways a single thing can be
>>> done.
>>>
>>> Leszek - you should now definitely have plenty of choices. Pick which
>>> feels
>>> best / most comfortable for you!
>>>
>>> On Wed, Mar 4, 2009 at 5:22 PM, jWeekend
>>> wrote:
>>>
Igor,
Nope, not for me (this time).
Here's the Javadoc for updateModel:
* Updates this components model from the request, it expects
that
the
object is already
* converted through the convertInput() call that is called by
the
validate() method when a form
* is being processed.
Regards - Cemal
http://jWeekend.com jWeekend
igor.vaynberg wrote:
>
> pft, you guys!
>
> i would go with the simplest!
>
> class uppercasetextfield extends textfield {
> public void updatemodel()
> {
> final String str=getconvertedinput();
>
setdefaultmodelobject((str==null)?null:str.touppercase());
> }
> }
>
> done!
>
> -igor
>
> On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
> wrote:
>>
>> Jeremy,
>>
>> I sensed you were uncomfortable with my "most Wicket-way" suggestion
when
>> I
>> read
http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
>> previous post on this thread stating that the model doing the
>> transformation work was on the "right track"; it is not unusual that
more
>> than one design can satisfy a given requirement.
>>
>> Do you like the idea of a model being responsible for conversion of
>> users'
>> textual input?
>>
>> Your article illustrates the use of nested models nicely but on this
>> occasion I would probably go with
>> http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html
Adriano's
>> idea
>> for a client side, instant gratification, solution, and a custom
text
>> field
>> with a converter if the conversion can happen later, on the server.
>>
>> Regards - Cemal
>> http://jWeekend.com jWeekend
>>
>>
>>
>> Jeremy Thomerson-5 wrote:
>>>
>>> Cemal,
>>> I think I have to respectfully disagree with you here. I
describe
>>> what
>>> I
>>> feel is a better solution, and a little bit of why in this blog
post
>>> from
>>> a
>>> few months ago:
>>>
>>>
http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
>>>
>>> Basically, doing it the way you suggested isn't reusable across
many
>>> components - you have to create overridden
Dutch government picks Hippo CMS for all public websites
This is of huge interest for the Wicket community: HippoCMS is a large supporter and user of Apache open source software in general, and Wicket in particular. HippoCMS uses Wicket in large parts of their infrastructure and I am excited to hear that Wicket will be at the basis for the Dutch government. In a publication at the local IT gossip site 'webwereld' it is announced that all government websites will be consolidated into one portal using the Hippo technology. Kudos to the Hippo team! Martijn [1] http://webwereld.nl/nieuws/56024/n-website-gaat-alle-rijksoverheidssites-vervangen.html -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
LOL! That sounds scalable!
Martijn Dashorst wrote:
I suggest setting up an ESB with a UppercaseService that is available
through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
that UppercaseService to make the value uppercase.
Martijn
On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg wrote:
you can create a convertermodel that takes an instance of iconverter
and uses that to convert the values, then you can subclass textfield,
override initmodel() and wrap any model the textfield had with this
one.
that way everyone is happy!
-igor
On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
wrote:
LOL! Nah - I would just change all the setters on every domain object to
be:
public void setFoo(String foo) {
this.foo = foo == null ? null : foo.toUpperCase();
}
Or, maybe I'd use AOP and build an aspect that could automatically intercept
calls to com.mydomain setters that take a single string argument and do the
upper-casing there!
It's makes me smile to think of how many ways a single thing can be done.
Leszek - you should now definitely have plenty of choices. Pick which feels
best / most comfortable for you!
On Wed, Mar 4, 2009 at 5:22 PM, jWeekend wrote:
Igor,
Nope, not for me (this time).
Here's the Javadoc for updateModel:
* Updates this components model from the request, it expects that
the
object is already
* converted through the convertInput() call that is called by the
validate() method when a form
* is being processed.
Regards - Cemal
http://jWeekend.com jWeekend
igor.vaynberg wrote:
pft, you guys!
i would go with the simplest!
class uppercasetextfield extends textfield {
public void updatemodel()
{
final String str=getconvertedinput();
setdefaultmodelobject((str==null)?null:str.touppercase());
}
}
done!
-igor
On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
wrote:
Jeremy,
I sensed you were uncomfortable with my "most Wicket-way" suggestion
when
I
read http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
previous post on this thread stating that the model doing the
transformation work was on the "right track"; it is not unusual that
more
than one design can satisfy a given requirement.
Do you like the idea of a model being responsible for conversion of
users'
textual input?
Your article illustrates the use of nested models nicely but on this
occasion I would probably go with
http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html Adriano's
idea
for a client side, instant gratification, solution, and a custom text
field
with a converter if the conversion can happen later, on the server.
Regards - Cemal
http://jWeekend.com jWeekend
Jeremy Thomerson-5 wrote:
Cemal,
I think I have to respectfully disagree with you here. I describe
what
I
feel is a better solution, and a little bit of why in this blog post
from
a
few months ago:
http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
Basically, doing it the way you suggested isn't reusable across many
components - you have to create overridden variants of each type of
input.
Also, a converter (or more specifically, an implementation of
IConverter)
is
supposed to be for transforming a type of object to a string usable in
the
browser / form post / etc, as it's javadoc mentions.
Anyway, as the saying goes "there are many ways to skin a cat" -
although
the saying isn't that great, I think it applies - there are multiple
ways
of
accomplishing the same thing.
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Mar 4, 2009 at 12:04 PM, jWeekend
wrote:
Leszek,
... or, probably the most "Wicket-way" of doing this is to make a
TextField
subclass that overrides getConverter to return your special IConverter
implementation which performs the capitalisation in its
convertToObject.
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data should
be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22335650.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---
Help: AjaxEditableLabel error
Dear all,
I am using AjaxEditableLabel, with the following codes,
it is ok to show the description, but when i clicked it, error happened.
"onEdit ..." is on the console , so it already call onEdit() method,
how to implement the method? how to solve the question?
thanks a lot.
AjaxEditableLabel descriptionEditableLabel = new
AjaxEditableChoiceLabel("description", new PropertyModel(fileObj,
"description")){
@Override
protected void onEdit(AjaxRequestTarget arg0) {
System.out.println("onEdit ...");
super.onEdit(arg0);
}
@Override
protected void onError(AjaxRequestTarget arg0) {
System.out.println("onError ...");
super.onError(arg0);
}
@Override
protected void onSubmit(AjaxRequestTarget arg0) {
System.out.println("onSubmit ...");
super.onSubmit(arg0);
}
};
item.add(descriptionEditableLabel);
Exception:
onEdit ...
org.apache.wicket.WicketRuntimeException: Exception in rendering component:
[MarkupContainer [Component id = editor, page =
sg.sphsearch.dira.web.wicket.pages.people.EditPersonPage, path =
3:tabpanel:panel:attachedFilesPanelContainer:saveUploadFilesForm:group:fileList:0:description:editor.DropDownChoice,
isVisible = true, isVersioned = false]]
at org.apache.wicket.Component.renderComponent(Component.java:2467)
at
org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1354)
--
View this message in context:
http://www.nabble.com/Help%3A-AjaxEditableLabel-error-tp22347654p22347654.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
Re: Uppercasing inputs
I suggest setting up an ESB with a UppercaseService that is available
through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
that UppercaseService to make the value uppercase.
Martijn
On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg wrote:
> you can create a convertermodel that takes an instance of iconverter
> and uses that to convert the values, then you can subclass textfield,
> override initmodel() and wrap any model the textfield had with this
> one.
>
> that way everyone is happy!
>
> -igor
>
> On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
> wrote:
>> LOL! Nah - I would just change all the setters on every domain object to
>> be:
>>
>> public void setFoo(String foo) {
>> this.foo = foo == null ? null : foo.toUpperCase();
>> }
>>
>> Or, maybe I'd use AOP and build an aspect that could automatically intercept
>> calls to com.mydomain setters that take a single string argument and do the
>> upper-casing there!
>>
>> It's makes me smile to think of how many ways a single thing can be done.
>>
>> Leszek - you should now definitely have plenty of choices. Pick which feels
>> best / most comfortable for you!
>>
>> On Wed, Mar 4, 2009 at 5:22 PM, jWeekend wrote:
>>
>>>
>>> Igor,
>>>
>>> Nope, not for me (this time).
>>> Here's the Javadoc for updateModel:
>>> * Updates this components model from the request, it expects that
>>> the
>>> object is already
>>> * converted through the convertInput() call that is called by the
>>> validate() method when a form
>>> * is being processed.
>>>
>>> Regards - Cemal
>>> http://jWeekend.com jWeekend
>>>
>>>
>>> igor.vaynberg wrote:
>>> >
>>> > pft, you guys!
>>> >
>>> > i would go with the simplest!
>>> >
>>> > class uppercasetextfield extends textfield {
>>> > public void updatemodel()
>>> > {
>>> > final String str=getconvertedinput();
>>> > setdefaultmodelobject((str==null)?null:str.touppercase());
>>> > }
>>> > }
>>> >
>>> > done!
>>> >
>>> > -igor
>>> >
>>> > On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
>>> > wrote:
>>> >>
>>> >> Jeremy,
>>> >>
>>> >> I sensed you were uncomfortable with my "most Wicket-way" suggestion
>>> when
>>> >> I
>>> >> read http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
>>> >> previous post on this thread stating that the model doing the
>>> >> transformation work was on the "right track"; it is not unusual that
>>> more
>>> >> than one design can satisfy a given requirement.
>>> >>
>>> >> Do you like the idea of a model being responsible for conversion of
>>> >> users'
>>> >> textual input?
>>> >>
>>> >> Your article illustrates the use of nested models nicely but on this
>>> >> occasion I would probably go with
>>> >> http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html Adriano's
>>> >> idea
>>> >> for a client side, instant gratification, solution, and a custom text
>>> >> field
>>> >> with a converter if the conversion can happen later, on the server.
>>> >>
>>> >> Regards - Cemal
>>> >> http://jWeekend.com jWeekend
>>> >>
>>> >>
>>> >>
>>> >> Jeremy Thomerson-5 wrote:
>>> >>>
>>> >>> Cemal,
>>> >>> I think I have to respectfully disagree with you here. I describe
>>> >>> what
>>> >>> I
>>> >>> feel is a better solution, and a little bit of why in this blog post
>>> >>> from
>>> >>> a
>>> >>> few months ago:
>>> >>>
>>> >>>
>>> http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
>>> >>>
>>> >>> Basically, doing it the way you suggested isn't reusable across many
>>> >>> components - you have to create overridden variants of each type of
>>> >>> input.
>>> >>> Also, a converter (or more specifically, an implementation of
>>> >>> IConverter)
>>> >>> is
>>> >>> supposed to be for transforming a type of object to a string usable in
>>> >>> the
>>> >>> browser / form post / etc, as it's javadoc mentions.
>>> >>>
>>> >>> Anyway, as the saying goes "there are many ways to skin a cat" -
>>> >>> although
>>> >>> the saying isn't that great, I think it applies - there are multiple
>>> >>> ways
>>> >>> of
>>> >>> accomplishing the same thing.
>>> >>>
>>> >>> --
>>> >>> Jeremy Thomerson
>>> >>> http://www.wickettraining.com
>>> >>>
>>> >>>
>>> >>> On Wed, Mar 4, 2009 at 12:04 PM, jWeekend
>>> >>> wrote:
>>> >>>
>>>
>>> Leszek,
>>>
>>> ... or, probably the most "Wicket-way" of doing this is to make a
>>> TextField
>>> subclass that overrides getConverter to return your special IConverter
>>> implementation which performs the capitalisation in its
>>> convertToObject.
>>>
>>> Regards - Cemal
>>> http://jWeekend.com jWeekend
>>>
>>>
>>> Leszek Gawron-2 wrote:
>>> >
>>> > Hello,
>>> >
>>> > one of my customers has this weird requirement that all data should
>>> be
>>> > input/shown uppercase. I can easily add
>>> >
>>> > input {
>>> > text-transform: uppercase;
>>> > }
>>> >
