[jira] Updated: (WICKET-1134) Multiple abstract/implement tags instead of child/extend

["Stefan Fußenegger (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Fußenegger updated WICKET-1134:
--------------------------------------

    Attachment: wicket-abstract-implement.patch

from http://www.nabble.com/Patch%3A-Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4759260.html:

I want to post this patch that was inspired by this discussion: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf

I added two new tags called <wicket:abstract> and <wicket:implement>. They can be used similar to <wicket:child> and <wicket:extend> but with an additional (optional) attribute id. In fact, the submitted patch uses child and extend as aliases for abstract and implement respectively.

The patch currently disables the old Markup merging completely (MergedMarkup.java). However, this is easy to change in InheritedMarkupMarkupLoader.java by commenting in the code in checkForMarkupInheritance(...) in order to use the old implementation for child/extend and the new code for abstract/implement.

I also added a new JUnit Test that demonstrates the new feature: MarkupInheritance*_13.(html|java) (btw: all other test cases in MarkupInheritanceTest.java work with the new and old implementation)

Please have a look and tell me what you think. 

> Multiple abstract/implement tags instead of child/extend
> --------------------------------------------------------
>
>                 Key: WICKET-1134
>                 URL: https://issues.apache.org/jira/browse/WICKET-1134
>             Project: Wicket
>          Issue Type: New Feature
>          Components: wicket
>            Reporter: Stefan Fußenegger
>            Priority: Minor
>         Attachments: wicket-abstract-implement.patch
>
>
> The current implementation of wicket:child and wicket:extend only allows for a single extension per subpage. However, this restriction is neither mandated by java class hierarchy nor by any other reason. Therefore, it should be possible to extend the current implementation to support multiple 'abstract' sections, just like abstract methods in java classes. This could be done by replacing
> <wicket:child>
>   <wicket:extend>
>     some content
>   </wicket:extend>
> </wicket:child>
> with
> <wicket:abstract id="foo">
>   <wicket:implement id="foo">
>     some content
>   </wicket:extend>
> </wicket:child>
> (new names have been suggested in http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html)
> A possible application is a layout with two columns, e.g. a header with navigation, a left column with sub-navigation and a right column with content (where the sub-navigation may change depending on the section. In deed, this is already possible using panels or similar means. However, it would allow to take advantage of markup inheritance only:
> BasePage extens WebPage:
> <div wicket:id="links>[some nav links here]</div>
> <div><wicket:abstract id="subNavigation">[left navigation goes here]</wicket:abstract></div>
> <div><wicket:abstract id="content">[content goes here]</wicket:abstract</div>
> SectionPage extends BasePage:
> <wicket:implement id="subNavigation">[sub navigation links here]</wicket:implement>
> FooPage extends SectionPage:
> <wicket:implement id="content">[content goes here]</wicket:implement>
> -- stefan

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.