Re: [Wicket-user] Wicket fundamentals
and in 2.0 this would even be harder because the parent also must be given in the constructorso you can give a child component to a parent component anymore anyway.johan
On 6/27/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Hi Frank,What you stumble upon is largely a matter of individual taste of thecore developers. There is no overall design strategy for things likethis, and you'll find that depending on who wrote classes, the way
extension points are setup can be very different. For instance theListView was set up like that by Jonathan when he was still working onhis own on Wicket. The repeater packages in wicket-extensions weremostly developed by Igor, who felt ListView doesn't quite cut it, as
an alternative for ListView and friends.Even the kind of patterns that you describe are possible. I think ifyou look at the repeater packages implementations you'll get some goodideas. If you feel you have found some better patterns for some things
to do, we would be very interested to get some patches and e.g. putthem in wicket-extensions.Cheers,EelcoOn 6/26/06, Frank Silbermann [EMAIL PROTECTED]
wrote: 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 theseabstract 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=lnkkid=120709bid=263057dat=121642
Re: [Wicket-user] Wicket fundamentals
Hi Frank,
What you stumble upon is largely a matter of individual taste of the
core developers. There is no overall design strategy for things like
this, and you'll find that depending on who wrote classes, the way
extension points are setup can be very different. For instance the
ListView was set up like that by Jonathan when he was still working on
his own on Wicket. The repeater packages in wicket-extensions were
mostly developed by Igor, who felt ListView doesn't quite cut it, as
an alternative for ListView and friends.
Even the kind of patterns that you describe are possible. I think if
you look at the repeater packages implementations you'll get some good
ideas. If you feel you have found some better patterns for some things
to do, we would be very interested to get some patches and e.g. put
them in wicket-extensions.
Cheers,
Eelco
On 6/26/06, Frank Silbermann [EMAIL PROTECTED] wrote:
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=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
[Wicket-user] Wicket fundamentals
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:idmarking the place whereI 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, butvarious 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 thoseWicket: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 createa sub-class of
ListView that implements a methodto 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 abad
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=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
