Can I make AjaxFormSubmitBehavior submit raw form data but not validate it?
Hello, I have a form with a DropDownChoice, on which onchange event I want to update some form components. But I need to read data from other fields of the form for doing so, and so I added an AjaxFormSubmitBehavior to the DropDownChoice. My intention is to read the data from the drop down and from the other fields, and depending on these data, update some other components... but the problem is that AjaxFormSubmitBehavior not only sends the form data, but also *validates it*, which I don't want (I don't want validation messages to appear when changing the value of the drop down). If it where an AjaxButton I would be able to just setDefaultFormProcessing(false), but I don't see anything like that in AjaxFormSubmitBehavior... Is there a way to do this? Regards, Daniel.
Re: Spring 2.5 and Wicket, our vision about integration
Hello Lars,
What do you mean by transient and magic? The attributes are not transient. A
proxy is generated that is serialized. At runtime the real dependency is
retrieved from the spring container.
The problem with that magic, as I already expressed in this list some time
ago, is a formal issue. When you use the @SpringBean annotation you end with
something like this:
@SpringBean
MyService myService;
The problem here is that, in a Serializable class (the page), you are
declaring a non-serializable attribute (the service). Service interfaces are
not serializable (normally), and thus they should be declared as transient
here, and provide a way to recover the object after page serialization.
Of course, the SpringBean annotation does this for you... because it injects
a Serializable proxy in between the page and the service. Here comes the
magic. So, it works perfectly... but it is formally incorrect. A
non-serializable attribute of a serializable class, made serializable
under-the-scenes by a proxy... my IDE would not like that ;)
I wouldn't use the approach you suggest for the following reasons:
- Scatters your Application class all over your code. Any Component
(Pages,
Components) that need a Spring dependency need to the make the verbose
method call ((MyApplication)Application).get().getService().
I don't really see a problem in that, but Sergio and I have discussed about
the possibility of having getXXXService() methods in a base page from which
the rest of your pages inherit, if that is more convenient for you.
And anyway, we include a static get() method in our application beans which
does the cast from Application.get(), so in fact it is:
MyApplication.get().getService()
much more elegant (IMHO, of course).
- All your dependencies need to be in the Application class which can lead
to a gigantic Application class if you use a lot of spring beans in your
application.
As I see it, 90% or even 99% of the spring beans you should need to use
from your wicket pages (at least with our architecture) are only services...
and we don't usually have more than 10 or 15 services. Maybe 30 in a really
really big application... and these methods are only setters. Many
persistent beans are far bigger than that.
- Risk of serializing your spring beans: Since the Annotaion Based
approach
generates proxies for your spring beans they can be safely serialized. The
approach you suggest just returns the spring beans. This increases the
change of accidentally serializing a spring bean if you do for instance:
public class MyPage {
private Service service;
public MyPage() {
this.service = Application.get().getService();
}
}
Well... yes, this can happen. But this can happen with any of your
non-serializable objects. It's just a matter of being careful ;)
Regards,
Daniel.
On Mon, Apr 28, 2008 at 10:39 AM, Sergio García [EMAIL PROTECTED]
wrote:
This posts is about the vision that my colleague Daniel Fernández and me
have
about how should be the integration between Wicket and Spring, using the
new
annotation functionalities provided by Spring 2.5. The @SpringBean
approach
is very useful, but its magic about a transient attribute that is not
transient make us fell uncomfortable.
Four main steps are needed in this approach:
1) Change applicationClassname web.xml parameter to:
init-param
param-nameapplicationFactoryClassName/param-name
param-value
org.apache.wicket.spring.SpringWebApplicationFactory
/param-value
/init-param
2) Declare the application class as a Spring bean (Spring 2.5 way)
@Component
public class MyApplication extends WebApplication
3) Declare into the application class the services with the correct
Spring
2.5 annotations
@Autowired
private AaaService aaaService;
4) Add getters for the services
public AaaService getAaaService(){
return this.aaaService;
}
For convenience, you can add a static get() method to retrieve the
casted
application class
public static MyApplication get() {
return (MyApplication) Application.get();
}
So you can retrieve the service from any page with a simple
MyApplication.get().getAaaService()
As the applications class is not serializable, there are no need to make
transient magic.
What do you think about this approach?
--
View this message in context:
http://www.nabble.com/Spring-2.5-and-Wicket%2C-our-vision-about-integration-tp16930960p16930960.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with HybridUrlCodingStrategy and PageParameters
Well, that's a pity... Anyway, I finally had to go with passing page id and page map name so that I could retrieve the previous page back from the page map... if it existed. I used HybridUrlCodingStrategy anyway so that, once I get these two parameters from the PageParameters object and remove them from there, the URL coding strategy rewrites the URL (redirect) not showing the removed parameters. Thanks, Daniel. Matej Knopp wrote: Hi, this is unfortunately not possible at the moment. The reason is that the pageparameters are set to page as page metadata, but the metadata key is private (HybridUrlCodingStaretegy#PAGE_PARAMETERS_META_DATA_KEY). So while I could make the key public, but you'd have to use snapshot releases until 1.3.1 is out. -Matej On Jan 3, 2008 3:09 PM, Daniel Fernández Garrido [EMAIL PROTECTED] wrote: Hello everyone, I have the following scenario: * I have a page PageA with lots of Ajax-driven state, with a link to PageB * PageB needs a parameter (an object id, to be specific), which it can receive with a PageParameters constructor argument. * PageB needs a reference to the PageA object that the user came from, so that it can link back to a PageA with the very same ajax-modified state. * Both PageA and PageB must have bookmarkable URLs. For that, I am using: * HybridUrlCodingStrategy for both PageA and PageB. * Two constructors in PageB, one wich only receives PageParameters (so that the page is considered bookmarkable) and another one which receives PageParameters and a WebPage (which will be the PageA object). * Anonymously-defined Link subtypes for links in both directions. My problem is that, although everything works fine, when I get to PageB, I have a bookmarkable URL like: /my/path/my/page/.3, which includes a version number, but not the contents of the PageParameters (so, it's not truly bookmarkable). I need to have /my/path/my/page/param1/value1/.3... how can I get this? Thank you very much in advance. And congratulations for 1.3! ;-) Regards, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Trouble with HybridUrlCodingStrategy and PageParameters
Hello everyone, I have the following scenario: * I have a page PageA with lots of Ajax-driven state, with a link to PageB * PageB needs a parameter (an object id, to be specific), which it can receive with a PageParameters constructor argument. * PageB needs a reference to the PageA object that the user came from, so that it can link back to a PageA with the very same ajax-modified state. * Both PageA and PageB must have bookmarkable URLs. For that, I am using: * HybridUrlCodingStrategy for both PageA and PageB. * Two constructors in PageB, one wich only receives PageParameters (so that the page is considered bookmarkable) and another one which receives PageParameters and a WebPage (which will be the PageA object). * Anonymously-defined Link subtypes for links in both directions. My problem is that, although everything works fine, when I get to PageB, I have a bookmarkable URL like: /my/path/my/page/.3, which includes a version number, but not the contents of the PageParameters (so, it's not truly bookmarkable). I need to have /my/path/my/page/param1/value1/.3... how can I get this? Thank you very much in advance. And congratulations for 1.3! ;-) Regards, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jasypt + ICrypt + ICryptFactory
Thank you for your answers. As you can see, I have already done the release.
Let's hope this is useful for someone :-)
Regards,
Daniel.
Eelco Hillenius wrote:
But the question here is... what is the real use of the ICryptFactory today
(1.3.0-rc1) in wicket? Is it only encrypting URLs? (I see
PasswordTextFields are not encrypted anymore)
Yep, I think we removed the other uses. I don't know exactly from the
top of my head, but it is in the (recent) mail archives.
And if so, would it be of real use/need? Of course, It would increase much
(as much as Java can) the security of the URLs' encryption but, would you
see any other uses?
I can't really think of anything else besides that it is available as
a nice utility class.
If this is only used for encrypting URLs, and if I am not wrong, our
WebApplication class would also need something like this:
--(CODE WHICH WOULD GO INTO OUR WebApplication CLASS)--
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor() {
@Override
protected IRequestCodingStrategy newRequestCodingStrategy() {
return new CryptedUrlWebRequestCodingStrategy(new
WebRequestCodingStrategy());
}
};
}
Something like that yeah :-)
And more important: can I consider wicket's ICrypt and ICryptFactory
interfaces *stable*? (at least until a stable 1.3.0 release). Have you got
any short-term plans for changing anything in this encryption
infrastructure?
That's definitively a stable interface. I don't see us changing that
any time soon. Btw, now that we are in RC mode, we won't be changing
any of the API unless there are very pressing matters, in which case
we'll have a vote about it. The idea is to enable users to just drop
in new versions/ jars in RC/ finals without having to fix for API
changes.
So, JasyptCrypt will always throw an exception if this method is called.
Currently in wicket, setKey is only called from
org.apache.wicket.util.crypt.ClassCryptFactory, which jasypt does not
extend, so this would not pose any problems for the future, but... could it
make sense that that setKey method were called by the developer anywhere
else? this would render jasypt integration quite complicated...
I guess we'll hear if that is a problem for someone :-)
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Jasypt 1.4 released including Wicket integration for URL encryption
Hello, I have just released Jasypt (Java Simplified Encryption) version 1.4 [http://www.jasypt.org], which includes Wicket integration features for more powerful and robust URL encryption in secure applications where URL encryption may a requirement. You can read more about Jasypt + Wicket integration here: http://www.jasypt.org/wicket.html About Jasypt Jasypt (Java Simplified Encryption) is a library aimed at providing developers a simple way to add encryption capabilities to their projects including: password digesting, text/binary encryption, Hibernate transparent encryption and Spring Security (ACEGI) integration. What's new in 1.4 - * Encryptable .properties files (including Spring placeholder integration). * Encryptable Hibernate datasource configuration (at hibernate.cfg.xml). * Command line interface (CLI) tools. * Apache Wicket integration for URL encryption. * Updated docs (including Jasypt + Seam 2 integration guide). Regards, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jasypt + ICrypt + ICryptFactory
Hello everyone,
I am about to release a new version (1.4) of Jasypt [http://www.jasypt.org],
and I am considering the addition of some wicket integration features for
improving wicket's encryption capabilities.
But I would first need to ask a couple of things :-)...
First, what I will do (have already done, in fact): I have added to jasypt
both an implentation of the org.apache.wicket.util.crypt.ICrypt and
org.apache.wicket.util.crypt.ICryptFactory interfaces. The idea is to use
JasyptFactory as the desired ICryptFactory implementation for the
application, like this:
--(CODE WHICH WOULD GO INTO OUR WebApplication CLASS)--
@Override
protected void init() {
super.init();
/*
* In the following code example we will create a Jasypt byte
* encryptor by hand, but in real world we can get it from Spring,
* configure it via Web PBE configuration... whatever we want to.
*/
StandardPBEByteEncryptor encryptor = new StandardPBEByteEncryptor();
encryptor.setAlgorithm(PBEWithMD5AndDES);
encryptor.setPassword(jasypt);
/*
* Create the Jasypt Crypt Factory with the desired encryptor,
* which will return org.jasypt.wicket.JasyptCrypt objects
implementing
* the org.apache.wicket.util.crypt.ICrypt interface.
*/
ICryptFactory jasyptCryptFactory = new JasyptCryptFactory(encryptor);
/*
* Set the Jasypt Crypt Factory into the application configuration.
*/
getSecuritySettings().setCryptFactory(jasyptCryptFactory);
}
But the question here is... what is the real use of the ICryptFactory today
(1.3.0-rc1) in wicket? Is it only encrypting URLs? (I see
PasswordTextFields are not encrypted anymore)
And if so, would it be of real use/need? Of course, It would increase much
(as much as Java can) the security of the URLs' encryption but, would you
see any other uses?
If this is only used for encrypting URLs, and if I am not wrong, our
WebApplication class would also need something like this:
--(CODE WHICH WOULD GO INTO OUR WebApplication CLASS)--
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor() {
@Override
protected IRequestCodingStrategy newRequestCodingStrategy() {
return new CryptedUrlWebRequestCodingStrategy(new
WebRequestCodingStrategy());
}
};
}
Would this be correct/adequate?
And more important: can I consider wicket's ICrypt and ICryptFactory
interfaces *stable*? (at least until a stable 1.3.0 release). Have you got
any short-term plans for changing anything in this encryption
infrastructure?
And the last thing: the setKey() method in ICrypt is not usable in Jasypt,
as encryptor configuration and initialization is quite more complex and PBE
keys (encryption passwords) cannot be changed once an encryptor has already
been initialized (password is set on the jasypt encryptor, not the
wicket-friendly JasyptCrypt).
So, JasyptCrypt will always throw an exception if this method is called.
Currently in wicket, setKey is only called from
org.apache.wicket.util.crypt.ClassCryptFactory, which jasypt does not
extend, so this would not pose any problems for the future, but... could it
make sense that that setKey method were called by the developer anywhere
else? this would render jasypt integration quite complicated...
Sorry for the size of the message and the lot of questions :-)
Regards,
Daniel.
