[
https://issues.apache.org/jira/browse/WICKET-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Boudreau updated WICKET-2388:
---------------------------------
Attachment: pageParametersProxy.diff
Updating the patch - Eelco noticed that if you were doing a removal, the code
should never reach the switch statement below.
> 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, 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.
