[
https://issues.apache.org/jira/browse/WICKET-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502931#comment-13502931
]
Chris Colman commented on WICKET-4408:
--------------------------------------
Use case scenario:
We use Wicket to produce many differently branded sites with a wide variety of
layouts for clients - the Wicket 'variation' feature is totally awesome for
this.
The ability to use the ComponentResolver really let's us take separation of
concerns to the next level: It makes it possible for the web graphics guys to
configure the markup for different variations in very flexible ways. For
example, with the SystemPanel (shows 'log in' link if not logged in or email,
profile settings and log off if logged on) the graphics guys can place that at
the top of the page or they can embed it within the main menu - or they could
even place it in a side bar if they like - it's location is flexible.
With a component resolver solution the Java code doesn't have to change based
on where they want to place it so the code is clean, simple and efficient.
Without a component resolver solution the Java code needs to know where they
will place it in a particular layout or just add the component in all possible
places that the graphics guys *may* want to place it - which produces redundant
components and makes for ugly, unmaintainable code - what if they decide to
place it in a different component that it has never been placed in before?
SystemPanel is only one of many panels that we allow to be dynamically added
via this flexible markup feature - we would have to duplicate that ugliness for
each of these panels.
Analyzing the markup in #onInitialize:
Would that effectively be double processing the markup?
To allow the flexibility that the component resolver solution gives, i.e. the
web designer can place the panel *anywhere*, wouldn't we have to make *every*
component analyze it's markup in onInitialize? Wouldn't that mean every
component in every page render is analyzed twice? Once by our app and then
later by the Wicket framework?
> Components resolved by an IComponentResolver fail to contribute to header via
> renderHead
> ----------------------------------------------------------------------------------------
>
> Key: WICKET-4408
> URL: https://issues.apache.org/jira/browse/WICKET-4408
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.4
> Environment: Happens on all FireFox Chrome, IE
> Windows XP
> Reporter: Chris Colman
> Assignee: Igor Vaynberg
> Labels: wicket
>
> If a component is resolved via an IComponentResolver implementation then its
> overridden renderHead method never gets called.
> If the same component is added explicitly to its parent then its renderHead
> method is called.
> This is critical for us because we have markup variations that may or may not
> include certain panels. We thus leave the construction/adding of these panels
> to our IComponentResolver implementation because we can't explicitly add them
> because not all markup will require all panels.
> Class MyPanel extends Panel
> {
> /**
> * Write out necessary header markup.
> */
> @Override
> public void renderHead(IHeaderResponse response)
> {
> StringBuffer sb = new StringBuffer();
>
> sb.append("<script src=\"/jquery.easing.1.3.min.js\"></script>");
> sb.append("<script src=\"/trans-banner.min.js\"></script>");
>
> response.renderString(sb.toString());
> }
> }
> We aren't using any markup inheritance at the panel level.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
