CRUD application with Wicket

For several days I am working now with the development of a no further exceptional CRUD application with Wicket. While the concept behind it is somewhat disconcerting at first when you come out of the Struts-stock, but you learn the component-based approach to estimate quickly. But is this or that question. Maybe I have problems in the eyes, but one point me so far is not clear how this "problem solve" with a wicket in the rule: I often want parts of the page displays only if certain conditions are met, with Struts So a simple If statement in the JSP. If I have understood correctly Wicket, dissolve this by outsourcing the relevant parts into components and shows them or not. However, this is very tedious after a while, particularly when it is very often little things like links. for every time a not inconsiderable extra piece of code must be written. If it just so, then I will accept it that way. However, I would be interested but how they solve the everyday that have something to do even more with Wicket.

You can instantiate the component always as an anonymous inner class and then the method isVisible () override. The following example will help you :

Code:

---

add (new Label ("comp", "Invisible") (
public boolean isVisible () (
return false;
)
));

---

But actually I now have not answered the real question. I think that accurately represents the use of components of the stimulus. Instead of packing all sorts of components on one "side", one can simply replace existing components as required:

Code:

---

someContainer = new WebMarkupContainer ("someContainer");
someContainer.setOutputMarkupId (true);
add (someContainer);

someContainer.replaceWith (anotherContainer);
someContainer = anotherContainer;

---

I unfortunately (?) No experience with Wicket, but plenty of Tapestry, also a component based framework.:no: In Tapestry, it is an if component in Wicket it is not. But a For / Repeat component, there must be yes or not? So if there is a possibility to share, from the Template / Component Body repeated arbitrarily many times, then you can repeat it zero times.

The add () method is in final wicket, so there's nothing to override. According to my interpretation of the wicket-philosophy, I would propose, concepts such as session and request only once removed from the memory - of course you need them, but to come up with the component it is based on this trip are a hindrance. Ackley's solution was the best, here is a WebMarkupContainer:

Code:

---

add (new WebMarkupContainer ("comp") (
public boolean isVisible () (
return false;
)
)

---

Note the 'Pull' model, ie the current state of isVisible () is calculated again and again. Often attached to it so complicated technical requirements, such as:

Code:

---

public boolean isVisible () (
isSuperUser return () & & (isLeapYear () | | foo.getBar (). getBaz ());
)

---

Since there is no danger that once the call to setVisible () was forgotten.

Since I am decidedly different opinion. If I understand correctly the application's well so dependent on one side of a component of any condition show times, sometimes not display. If you wanted to be regulated under this add (Component) component of the Father, we would have probably produce the component again and again. Obviously, you would need for the two cases provide markup. boolean isVisible () is exactly the place for determining whether a component should be shown. Simple example:

Code:

---

add (new Link ("logoff") (
public boolean isVisible ()
(
LoginHelper.userIsLoggedIn return ();
)
public void onClick ()
(
LoginHelper.logoff ();
)
));

---

So natural and elegant I cannot imagine.