|
I find
that I like using Wicket very much, but there are some aspects which I found
quite strange at first that may confuse and put off new users unless the
textbooks being written can motivate the Wicket way of doing things. One
stumbling block for me was the requirement that the Wicket:id be known at the
time of a component's construction.
For
example, suppose my application is based on a template with a
Wicket:id marking the place where I insert a Panel that differs page
by page. On some pages I want to place there two existing panels side by
side in that spot -- not the same two panels every time, but various pairs
of panels on each page. It seems silly to create a different Panel class
for each different pair of panels I might want to display; it makes more sense
is to create a Panel object that displays any two arbitrary sub-panels
side-by-side -- call it HorizontalPanels_panel..
I
think most Java programmers would expect that this class might have a
constructor that takes two Panel objects as input. Or, perhaps, it might
contain methods that would allow a user to assign component panels to the
object. Neither is the Wicket way. You see, in order to display two
panels side-by-side the HorizontalPanels_panel requires HTML that contains the
Wicket:id for each sub-panel. When writing HorizontalPanels_panel I
can choose whatever values I please for those Wicket:id's, but these values
must be known by whoever constructs the component panels -- a low-level
implementation detail that should not concern them.
To
avoid burdening users of this class with the need to remember such arbitrary,
low-level HorizontalPanels_panel implementation details, instead of
accepting the sub-panel's as constuctor or method arguments I make my
HorizontalPanels_panel class abstract, with abstract methods that build the
sub-panels (to be implemented by the user) which take the Wicket:id as an input
argument:
public
class HorizontalPanels_panel {
public HorizontalPanels_panel(String parentPanelWicketId) throws Exception
{
...create a component container using
parentPanelWicketId...
...call the abstract methods
createLeftPanel(wicketId1) and
createRightPanel(wicketId2)...
...add to the component container the panels
returned by these
abstract
methods...
}
abstract public Panel createLeftPanel(String wicketId) throws
Exception;
abstract public Panel createRightPanel(String wicketId) throws
Exception;
}
Anywhere in the application where I need to create a Panel displaying two
sub-panels side-by-side I simply instantiate an anonymous subclass of
HorizontalPanels_panel that implements the methods creating the
sub-panels.
This
approach works, and seems to be the Wicket way of doing things. A similar
approach is taken with ListView -- the user cannot provide the ListView with a
list of components to display, rather, the user must create a sub-class of
ListView that implements a method to create each component in the list
(based on a list of data sets, one set for each component to be
constructed). Here again, the abstract method provides the Wicket:id for
each list component being contructed.
I must
confess that this approach was far from intuitive to me; in fact it seemed quite
weird. It would have been much more intuitive if I could have accepted the
input components as arguments, and then let the HorizontalPanel_panel set their
id's to match the Wicket:id's in the HTML. Apparently, there must be some
crucial reasons based on the way Wicket works that would make this a bad
idea. This is one of the issues that I hope the coming textbooks
explain.
|
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
