It is "worse", because now I need to write a code, which previously I got for "free" in 1.4 :D and by "clumsy" I meant my attempt of implementing this functionality ;)

Now my superclass base page add method looks like this :(
  @Override
  public MarkupContainer add(Component... childs) {
    for (Component component : childs) {
// If border has not been created yet or component is being added to page header call super.add
      if (border == null || component.getId().startsWith("_header")) {
        super.add(component);
      } else {
        border.add(component);
      }
    }
    return this;
  }

Obviously  there are several problems with my code:
1.I assume "_header" is staff added to page header? Can I identify it differently, not by string "_header"? instanceof HtmlHeaderContainer?
2. is it sufficient to just override the add?
3. Checking that border has been added in a base class will not always work - I would have to come up with some generic way to decide which component goes into border and witch in a base class. Can I use page and border getAssociatedMarkup().find(wicketId) and decide based on checking, if specified wicked id is in a base class/border?

Would it be better to implement IComponentResolver? I tried this first (using modified TransparentWebMarkupContainer as an example), but it caused problems with not found markup for many Fragments and ModalWindows. (possibly related to https://issues.apache.org/jira/browse/WICKET-4545 ?)

I also do not like the extra path "border:border_body" now to be added in wicket tester asserts, but I can see the logic requiring this... :(



On 2012-05-11 14:30, Martin Grigorov wrote:
Hi,

It is not very clear to me what exactly is clumsy.
Can you explain in more details how it got worse. Show some code maybe.

On Fri, May 11, 2012 at 2:20 PM, Girts Ziemelis
<girts.zieme...@gmail.com>  wrote:
I was using border in 1.4 to dynamically add different borders to the page
(like - for printing, popup, plain, with header/ footer etc based on page
parameters and some other criteria) and really liked this method in 1.4.
Seems that 1.5 makes this  approach clumsy :( Now I must override the
page.add method and do some magic to decide where I am adding the component,
etc. I got it to work (pretty sure I am not covering all cases ) , then
realized, that in  WicketTester also now all the component paths must be
prefixed with the "border:border_body" string which is rather ugly :(

Is there a better way to implement this (instead of borders)? It just does
not feel right - most of the changes in 1.5 made my code cleaner, but this
one feels like a hack ... :(

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Reply via email to