[
https://issues.apache.org/jira/browse/WICKET-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733974#action_12733974
]
Tim Boudreau commented on WICKET-2388:
--------------------------------------
One open question is how best to deal with failures - in particular, there are
a couple of cases that can throw a NumberFormatException (which may translate
into a relatively inscrutable "at Proxy0 (Unknown Source)" stack trace) - which
can happen if someone manually messes around with a URL.
Another failure mode is deserialization errors (although this really should not
be used heavily for passing serialized objects, both because they risk
overrunning the browser URL-length limit, and for the obvious security reasons)
- i.e. someone saves a bookmark; a new version of the app is deployed and the
class signature is changed, so the object can't be deserialized (unless they
were very conscientious and masochistic and wrote the horrible code you have to
write to deserialize old versions of a type).
> Use dynamic proxies to hide PageParameters key/value pairs
> ----------------------------------------------------------
>
> Key: WICKET-2388
> URL: https://issues.apache.org/jira/browse/WICKET-2388
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.0
> Environment: Any
> Reporter: Tim Boudreau
> Attachments: pageParametersProxy.diff
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Enable users to work with Java objects rather than key/value pairs in
> PageParameters.
> I'm attaching a patch (with tests) that adds a method
> public T <T> PageParameters.asObject (Class<T> type)
> The basic idea is that you pass in an interface type with getters and setters
> following the beans pattern. asObject() generates an implementation of that
> interface (using dynamic proxies). The bean property names of methods are
> mapped to keys in the PageParameters, and type conversion is transparent. So
> you can, say, pass
> public interface MyData {
> public String getCheese();
> public void setCheese(String cheese);
> public int getFoo();
> public void setFoo(int val);
> }
> Populating a PageParameters is as simple as
> PageParameters p = new PageParameters();
> MyData data = p.asObject(MyData.class);
> data.setCheese ("Gouda");
> data.setFoo (42);
> ...then make a BookmarkablePageLink or whatever with it.
> On the page that receives the object, you simply do the same thing but call
> getters to retrieve the data. Much nicer than working with key/value pairs,
> and completely eliminates the problem of typos in key names breaking things.
> See
> http://weblogs.java.net/blog/timboudreau/archive/2008/08/objects_not_str.html
> for the general concept - I'm putting together a small general framework for
> this, but it's not available yet, and I figured a patch for PageParameters
> would be nicer than adding a dependency to Wicket anyway.
> What would be truly slick is if this could be made completely transparent -
> i.e.,
> public class MyPage extends WebPage {
> public MyPage (MyData data) {
> }
> }
> ...so if parameters are present, Wicket would search
> 1. For a constructor taking PageParameters, as usual
> 2. For a constructor taking an object whose class is an Interface type; if
> so, it calls PageParameters.asObject() with the type, and passes that
> 3. A default no-arg constructor as now.
> This magical part could potentially be dangerous, so it might be best to mark
> pages that want their constructor arguments transparently dereferenced to
> have a marker annotation to indicate they really expect that behavior.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
