you missed solution3:
the real-wicket-way(tm) for multiple content-places in a tied page-area:
eg: html:
...
<div wicket:id="anything">Place to put anything</div>
...
java:
public abstract MyPage extends AnyPageExtendingWicketsWebPage {
private boolean initialized = false;
private final RepeatingView anything;
MyPage() {
super();
anything = new RepeatingView("anything");
add(anything);
}
/**
* Abstract place to add content to the containers
*/
protected abstract void initialize();
@Override
protected void onBeforeRender() {
super.onBeforeRender();
if(!initialized) {
initialize();
initialized = true;
}
}
/**
* Adds the content-Component c to Column A
* (the smaller one on the left)
*
* @return
*/
public void addToAnthing(Component c) {
c.setRenderBodyOnly(true);
getAnything().addOrReplace(c);
}
public RepeatingView getAything() {
return anything;
}
}
and in extending classes you can easily do this:
protected void initialize() {
addToAnything(new AnyPanel("id"));
addToAnything(new AnyPanel2("id2"));
}
etc.
this is maximum flexible, fast implemented, beeing checked by the IDE
and nice OO behaviour as it allows you to chain this over several
levels, plus it aids you when it comes to security-limitations as you
have a logic hirarchy where you can use each step for more restricted
access-rules
e.g: BasePage -> SecureBasePage -> HighlySecuredBasePage -> MyPage
if you then need a panel manipulating other areas this is easily done by:
e.g:
(MyPage getPage()).getAnything().doWhatYouWantToDo(WhatYouWant)
(you could also make this final thing abstract and then only override it
in the page you place it in wich gives even more control and makes it
reusable over projects)
and this is sth. that happens more often than you expect IMHO
plus the biggest advancement: the HTML tied to the classes stays clean
and is not poluted with some fancy tags (wich is the bigest plague in
the Javaworld IMHO... i never understood how they could invent things
like JSP or JSF that are worse to even PHP code in a page)
Best
Korbinian
Stefan Fußenegger schrieb:
Hi Mats, let me try to explain what Chris and I see here that others don't -
may it be there or not ;)
You can of course do everything with panels that could be done with multiple
abstract sections (may they be named wicket:child or wicket:abstract).
However, if this is the only argument, you wouldn't need markup inheritance
at all! The proposed change is just an extension of exactly this markup
inheritance concept (that everybody loves) to make it even more powerful
than it already is.
I was quite new to wicket (which I still am) and came across a situation
where I wanted to use two abstract sections: one for a sub-navigation that
was common for several pages in a section and one for the actual content.
For me, as a wicket newbie, it would have been most natural to use markup
inheritance to solve this problem. Using abstract methods, while being a
nice solution (workaround?), didn't come to my mind at once, nor did I find
it somewhere in the docs.
imho, there are two possible solution to this problem:
1. promote using abstract methods for this in the docs as the wicket-way of
doing it
2. extend the current markup inheritance mechanism (which I tried to do with
my patch/prototype)
-- stefan
Mats Norén-2 wrote:
On Nov 7, 2007 11:31 AM, Mats Norén <[EMAIL PROTECTED]> wrote:
Hmm...I'm interested in seeing the difference as well. I would love to
get it but right now I don't.
Chris Colman wrote:
"This new feature, or extension of the exiting feature, allows more than
one section of markup to be "specialized" by derived (extended) markups
whereas currently wicket only supports the deferred
definition/implementation of a single markup section in any page. In
other words we want to make a powerful feature even more powerful."
Is the above statement really true considering that by adding abstract
methods to your page you defer the creation of the markup in just the
same way as the new proposed solution?
BasePage.java
public BasePage() {
addAbstract1("abstractId1");
addAbstract2("abstractId2);
}
public abstract addAbstract1(String abstractId1);
public abstract addAbstract2(String abstractId2);
A little typo here..I meant:
public BasePage() {
add(addAbstract1("abstractId1"));
add(addAbstract2("abstractId2));
}
public abstract Component addAbstract1(String abstractId1);
public abstract Component addAbstract2(String abstractId2);
/Mats
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
