I think allowing arbitrary parameter names instead of wicket:param is a big mistake. What happens if a user users a parameter and then it becomes reserved by Wicket in the future? Or the opposite?
At least with <wicket:param> you are differentiating between parameters passed from the markup to the Java component, from parameters of the actual Wicket command. The two should remain independant of one another.
Gili Juergen Donnerstag wrote:
IMO they should be in the wicket namespace e.g. wicket:color in order to clearly separate wicket tags from the rest and to remain (X)HTML compliant. And I think it would be a little bit more efficient as well, as we do not have to test all attributes. A requisite would be that the tag does have a wicket:id as well or the tag being in the wicket namespace like <wicket:panel wicket:width="10">. We do have something similiar with <wicket:param> already but this approach doesn't work well for several reasons. May be your suggestion is a better approach and may be we can remove <wicket:param> all together. Note: wicket:id would be reserved and we won't try to call setId(). Juergen On 7/6/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:Setting component properties from tag attributes could be a valueable addition to our arsenal. /IF/ we can do this /efficiently/ we could support things like: <a href="#" wicket:id="link" color="brown">set color</color> private class ColorLink extends Link { private String color; public void setColor(String color) { this.color = color; } public String getColor() { return color; } public void onClick() { ... } }; where attribute color would be set the the color property on a ColorLink instance. I think this is a lot like Tapestry's informal parameters. Any readers that have experience with that? And what do you think. Can it be a good thing, or does it encourage scripting too much. Personally, I think that it could help in cases where the properties to be set are really about the visuals in the first place. In that case supporting this could be a good idea. Eelco p.s. though this is a develop discussion, I hope on broader opinions here which is why I posted to the user list. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
-- http://www.desktopbeautifier.com/ ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
