Re: 1.5 migration and border magic

2012-05-14 Thread Girts Ziemelis


Sorry, answering my own questions ... ;)

On 2012-05-11 17:03, Girts Ziemelis wrote:
1.I assume "_header" is staff added to page header? Can I identify it 
differently, not by string "_header"? instanceof HtmlHeaderContainer?

Seems that check for HtmlHeaderContainer  works fine.

2. is it sufficient to just override the add?

No other problems so far.
3. Can I use page and border getAssociatedMarkup().find(wicketId) and 
decide based on checking, if specified wicked id is in a base 
class/border?

Yes, checking markup works fine, so I can use
  if (border == null
 || getAssociatedMarkup().find(component.getId()) != null
 || component instanceof HtmlHeaderContainer) {
super.add(component);
  } else {
border.add(component);
  }

I also do not like the extra path "border:border_body" now to be added 
in wicket tester asserts
I  actually decided to replace  border with 2 panels (header and 
footer). Simpler and no need to have a border in a hierarchy any more 


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



Re: 1.5 migration and border magic

2012-05-11 Thread Girts Ziemelis
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
  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






Re: 1.5 migration and border magic

2012-05-11 Thread Martin Grigorov
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
 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
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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