Re: [Wicket-user] How to set a date on backing model obj from contents of drop down lists?
David Leangen wrote:
One suggestion: what about having a date pojo like:
public class MyDate
{
get/setMonth()
get/setDay()
get/setYear()
public Date getDate()
{
// translate object state into a Date object
}
}
Then use PropertyModel to get/set the individual fields:
Component myComponent = new WhateverComponent( id, new
PropertyModel( myDate, fieldOfDate );
That should work.
Maybe more experienced people know of a more elegant way, though this
way's not so bad.
Cheers,
Dave
That's how I would do it.
DR
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
IMPORTANT NOTICE:
This mailing list is shutting down. Please subscribe to the Apache Wicket user
list. Send a message to: users-subscribe at wicket.apache.org and follow the
instructions.
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] PasswordTextField encryption
Just wondering: anyone know what's the reason behind 1) making PasswordTextField's automatically encrypting their contents by default, and 2) making this not configurable? I lost several hours debugging tonight till I finally pinpointed this as the cause of my bug. TIA, DR - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] PasswordTextField encryption
Martijn Dashorst wrote: It is configurable: don't use PasswordTextField but TextField instead. No. If you try to use a TextField, then wicket will insist that you convert your HTML to use input type=text/ instead of input type=password/ - and thus lose the masked password entry capabilities (i.e., echoing * characters). The reason behind PTF's encryption is that we want to provide a secure solution out-of-the-box. You can circumvent it, but then *you* need to open up Pandorra's box, not us. Same with escaping markup while outputting model values: the default is safe. Martijn Well, I guess I don't have a problem with that. But I think that there's a bug going on here. I just filed it at: https://issues.apache.org/jira/browse/WICKET-768 DR - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] PasswordTextField encryption
Martijn Dashorst wrote:
On 7/19/07, David Rosenstrauch [EMAIL PROTECTED] wrote:
Martijn Dashorst wrote:
It is configurable: don't use PasswordTextField but TextField instead.
No. If you try to use a TextField, then wicket will insist that you
convert your HTML to use input type=text/ instead of input
type=password/ - and thus lose the masked password entry capabilities
(i.e., echoing * characters).
In 1.3-beta2 the type is not specified: so you can use any type of
field.
? I am using 1.3-beta2.
IIUC (I don't have the code open) you can override the
getType() method of the textfield, and return null.
Martijn
Hmmm ... I don't think I totally understand what you're suggesting here:
new RequiredTextField() {
public Class getType() {
return what?!?!?;
}
}
And now that I check, that's not even allowed. getType() is final in
FormComponent.
DR
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] PasswordTextField encryption
Daniel Fernández Garrido wrote: David, I think your problem (not wanting password to come encrypted from the input component) would be solved by simply making your Application object return your own implementation of the wicket.settings.ISecuritySettingsinterface for its getSecuritySettings method. And in this extension (MySecuritySettings, for instance) make that the getCryptFactory method return a wicket.util.crypt.NoCryptFactory object. This way you would be able to use PasswordTextField component while not getting your text encrypted from it. Regards, Daniel. Hmmm ... well, I guess I'll do that if I have to. But (despite my initial message) I think I actually don't have a problem with Wicket encrypting the password internally (as long as it gets delivered to the model and the model target unencrypted). But as per the bug I found, it looks like perhaps I ran into a case where Wicket is encrypting the password field when it shouldn't be. As long as it was working correctly, though, (or there's some workaround) then I guess I don't really have any need to bypass the internal encryption. Thanks, DR - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] PasswordTextField encryption
Martijn Dashorst wrote:
PasswordTextField {
protected String getInputType()
{
return password;
}
}
TextField {
/**
* Subclass should override this method if this textfields mappes on
a different
* input type as text. Like PasswordField or HiddenField.
*
* @return The input type of this textfield, default is 'text'
*/
protected String getInputType()
{
return null;
}
}
Maybe so, but this is what I get when I use a RequiredTextField coupled
to an input type=password/:
org.apache.wicket.markup.MarkupException: Component password must be
applied to a tag with 'type' attribute matching 'text', not 'password'
[markup = file:/usr/local/.pr/jb/test_classes/unit/PasswordPage.html
html
headtitlePassword required test page/title/head
body
span wicket:id=errors/
form wicket:id=form
input type=password wicket:id=password/
!--input type=text wicket:id=password/--
/form
/body
/html
, index = 11, current = 'input type=password wicket:id=password/'
(line 6, column 1)]
...
You can grab the code from
https://issues.apache.org/jira/browse/WICKET-768 if you want to try this
yourself.
DR
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] PasswordTextField encryption
Martijn Dashorst wrote: Ok, my bad: you need to provide your own type... So create a MyRequiredPasswordTextField, and override the getInputType() and have it return password Martijn K. That makes much more sense. Thx. BTW, I'm curious to hear if anyone has any thoughts about the related bug I filed: https://issues.apache.org/jira/browse/WICKET-768 Seems like a weird issue. Thx, DR - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] wicket-picocontainer?
I saw that the 1.3 distribution contains wicket-ioc*.jar, along with wicket-guice*.jar, and wicket-spring*.jar. Just wondering: has anybody put together a wicket-picocontainer package too, perchance? TIA, DR - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] wicket-picocontainer?
Eelco Hillenius wrote: On 7/18/07, David Rosenstrauch [EMAIL PROTECTED] wrote: I saw that the 1.3 distribution contains wicket-ioc*.jar, along with wicket-guice*.jar, and wicket-spring*.jar. Just wondering: has anybody put together a wicket-picocontainer package too, perchance? That that I know of, but a contribution would be welcome :) Eelco Understood. Let me dig into my project a bit more and see how much I need it - and how much work it would be. If the cost/benefit looks good then I'll try to put one together. Thanks, DR - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] confusion about Wicket models and serialization
Hi. I started using Wicket recently, and found have found it excellent. However, although my development had gone very smoothly early on, recently I've started to hit a bit of a wall because of some issues around Wicket models (as well as my decision to switch to Wicket 1.3 from 1.2). I've already RTFM rather extensively (Karthik G.'s book, plus lots of stuff on the wiki) but I'm still very puzzled about a number of points. If anyone could help with some of my questions below, I'd really appreciate it! My over-arching question at this point is: Is it a requirement that a model's target object be Serializable? I ask because I've been running into a number of different issues and questions regarding models and serialization: 1) I tried to use a LoadableDetachableModel, partly as a way to avoid making my data object Serializable. But I'm wondering if that's not correct. Take for example a data object with gettters and setters for the following fields: id (int), foo (string), and bar (string). Using LoadableDetachableModel, I can load the object on demand by id - and so all I need to do is hold the id in the LoadableDetachableModel, and can discard the object itself. Thus the object doesn't need to be serializable. However, lets say that a form submission by the user sets the foo property to foo, and bar property to bar. And let's say further that foo is a valid value, but bar fails validation for some reason - which will keep the user on the same form page. In this case won't a logic error result? Since I'm not retaining (or serializing) my instance of the data object, but rather loading it fresh from the database each time, won't the foo value disappear? Because when the model needs to access the target object, it wouldn't be accessing a working copy that had the value set to foo, but rather a pristine copy from the database that had an old value? 2) How am I to handle the situation where I want to use a new (not yet saved) instance of a data object as the target for a model? Since the object is not yet saved to the database, I can't use a LoadableDetachableModel to load it fresh from the database every time. And I can't just have the Model create a new instance each time either, since it looks like repeated form submissions would wind up discarding old values? Is there any way to handle this situation without making my model target serializable? 3) You might be asking yourself: why doesn't he just make his data object serializable? And I guess I'll do that if I have to. But I'd like to avoid it if possible - because it means a lot of extra work. It might sound trivial to make an object serializable, but it's not. To do that, you need to make sure that its entire object tree, including every object it references, is serializable as well. This will not be a trivial task in my code, as there's numerous objects that I would need to make serializable. I'd like to avoid this if I can. So is it possible for a model's target object to not be serializable? Or is there some way to turn off this requirement? I noticed that in 1.2, when you use DEPLOYMENT mode, you wouldn't get serialization errors. Has that changed for 1.3? I'm fairly certain that I won't be deploying Wicket with clustering (or at least not session clustering like with Tomcat or Terracotta - I might cluster at the database level) so why should I need to be forced to make all my data serializable? 4) If serialization is now a requirement for model data objects, then it would seem to me that it'd no longer be true that Wicket can be used with POJO's. To me a POJO means a java object that doesn't need to extend any particular subclass or implement any particular interface - you can integrate it in to a framework as is without any coding changes. But if model data objects are forced to implement Serializable (and so are all of it's referenced fields ... and all of THEIR referenced fields ...) then they're not POJO's any longer. There'd then be a strict requirement on how those objects must be implemented, right? Can someone please help clear up some of this confusion? As things stand right now, it looks as if I have no choice but to change large sections of my code to make it all serializable, and I'm less than thrilled at the prospect. And if that's the case, then it'd seems to me that there's a fairly hefty cost that I'm forced to incur in using Wicket. I hope that I've just misunderstood things here, and this is not the case. Would appreciate any help and clarifications that people can offer this Wicket noob. TIA! DR - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Re: [Wicket-user] confusion about Wicket models and serialization
Igor Vaynberg wrote: On 7/16/07, David Rosenstrauch [EMAIL PROTECTED] wrote: My over-arching question at this point is: Is it a requirement that a model's target object be Serializable? no if validation fails the models are not updated, wicket will hold on to input for you and redisplay it in the form. model updates are atomic in regard to validation. so you are ok. the only thing to worry when using db backed beans directly is locking. martijn has a great example on how to handle optimistic locking in the form on his blog. see above answer. you can use an ldm and in load() return new instance every time. IModel is in part to allow the dto beans to not be serializable if you do not want them to. -igor Thanks much for the quick reply, Igor. OK, cool - that's good news. I'm glad I don't have to do a massive conversion to serializable. Let me try what you suggested and see how it goes. Thanks again! DR - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] How to control where HTML files are loaded from in 1.3?
David Rosenstrauch wrote: Actually, it looks like my fix won't work. Suddenly the resource stream locator can no longer find ExceptionErrorPage.html. Could someone please help me figure out what I did wrong here? Again, I posted my (now erroneous) approach at http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html Why was CompoundResourceStreamLocator removed? That's really making this sort of thing immensely difficult now. TIA, DR Urk! NM again. I think I figured it out. Updating the wiki page ... Sorry for the noise. DR - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] How to control where HTML files are loaded from in 1.3?
David Rosenstrauch wrote: David Rosenstrauch wrote: http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html I needed a way to load up HTML files that are all inside the same directory. That directory happened to be /WEB-INF/html. Essentially, I needed to chop off the fully qualified class name and turn com/example/wicket/app/HomePage.html into simply /WEB-INF/html/HomePage.html There's perfect instructions on how to do this in 1.2 (see the bottom of that page). But that code broker upon upgrading to 1.3. Anyone have any idea how this code should be updated for 1.3? NM ... I think I fixed it myself. I updated the wiki page accordingly. Maybe someone can proofread it for me pls? Tnx, DR Actually, it looks like my fix won't work. Suddenly the resource stream locator can no longer find ExceptionErrorPage.html. Could someone please help me figure out what I did wrong here? Again, I posted my (now erroneous) approach at http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html Why was CompoundResourceStreamLocator removed? That's really making this sort of thing immensely difficult now. TIA, DR - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] How to control where HTML files are loaded from in 1.3?
Hi. Wicket newbie here - and loving the framework. Great work! I started tinkering with it a few weeks ago, and wrote some code, but then realized that I probably ought to switch to use v1.3. Running into some conversion problems, though. Specifically, I used the approach described here: http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html I needed a way to load up HTML files that are all inside the same directory. That directory happened to be /WEB-INF/html. Essentially, I needed to chop off the fully qualified class name and turn com/example/wicket/app/HomePage.html into simply /WEB-INF/html/HomePage.html There's perfect instructions on how to do this in 1.2 (see the bottom of that page). But that code broker upon upgrading to 1.3. Specifically, the CompoundResourceStreamLocator class appears to no longer exist. In addition, the IResourceFinder.find method now appears to take 2 parms (Class and String) whereas it previously only took a String. Anyone have any idea how this code should be updated for 1.3? TIA, DR - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] How to control where HTML files are loaded from in 1.3?
David Rosenstrauch wrote: http://cwiki.apache.org/WICKET/control-where-html-files-are-loaded-from.html I needed a way to load up HTML files that are all inside the same directory. That directory happened to be /WEB-INF/html. Essentially, I needed to chop off the fully qualified class name and turn com/example/wicket/app/HomePage.html into simply /WEB-INF/html/HomePage.html There's perfect instructions on how to do this in 1.2 (see the bottom of that page). But that code broker upon upgrading to 1.3. Anyone have any idea how this code should be updated for 1.3? NM ... I think I fixed it myself. I updated the wiki page accordingly. Maybe someone can proofread it for me pls? Tnx, DR - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
