[
https://issues.apache.org/jira/browse/WICKET-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15676198#comment-15676198
]
Tobias Haupt edited comment on WICKET-4978 at 11/18/16 8:56 AM:
----------------------------------------------------------------
In my opinion the unerlying problem is the following: When using a component,
you have to have some knowledge about its internals - the tag it requires to
work correctly. On the one hand I would consider this a weakness of wicket
regarding encapsulation of internals of components. It leads to redundant
markup if the component is reused a lot. It also makes it hard to change the
internal behavior. Think of making a component ajax updateable in a project
there it has been used a lot with and without specifying a tag.
On the other hand it is also the very big plus of wicket that it allows to
define chunks of markup that are big enough to fully describe more complex
components in a single markup file. Like forms with all their fieldsets and
input fields.
In my project I want to construct the component tree in a generic way so that
the containers don't know how their children will render. More specific: they
are not allowed to specify the concrete tag of the child. The child is defining
the tag and whether it needs to be rendered at all.
To achieve this, I rewrite the markup of the panel to accept a "tag" attribute
(and other attributes like "class") in the <wicket:panel> tag. Please see the
attached java classes for clarification. This way I am required to include any
of these panels with the <wicket:container> tag.
I personally would be glad to see somthing like this beeing directly supported
in wicket.
was (Author: tobiashaupt):
In my opinion the unerlying problem is the following: When using a component,
you have to have some knowledge about its internals - the tag it requires to
work correctly. On the one hand I would consider this a weakness of wicket
regarding encapsulation of internals of components. It leads to redundant
markup if the component is reused a lot. It also makes it hard to change the
internal behavior. Think of making a component ajax updateable in a project
there it has been used a lot with and without specifying a tag.
On the other hand it is also the very big plus of wicket that it allows to
define chunks of markup that are big enough to fully describe more complex
components in a single markup file. Like forms with all their fieldsets and
input fields.
In my project I want to construct the structure of the component tree in a
generic way so that the containers don't know how their children will render.
More specific: they are not allowed to specify the concrete tag of the child.
The child is defining the tag and whether it needs to be rendered at all.
To achieve this, I rewrite the markup of the panel to accept a "tag" attribute
(and other attributes like "class") in the <wicket:panel> tag. Please see the
attached java classes for clarification. This way I am required to include any
of these panels with the <wicket:container> tag.
I personally would be glad to see somthing like this beeing directly supported
in wicket.
> Add possibility to force usage of (renderable) tag for own Components
> ---------------------------------------------------------------------
>
> Key: WICKET-4978
> URL: https://issues.apache.org/jira/browse/WICKET-4978
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Reporter: Peter Parson
> Attachments: wicketPanel_Tag_Rewriting.zip
>
>
> Sometimes, Components don't work as expected when not used with a DOM element.
> This generates bugs, which are often and especially only visible on ajax
> interaction.
> Common scenario: updating a component via Ajax which is used with
> wicket:container or setRenderBodyOnly(true). Or updating those (non-existent)
> DOM element with HTML attributes.
> To allow for fail-fast behavior, I suggest to add an overridable getter to
> indicate that the component must be rendered as DOM element, e.g.
> isDomElementMandatory().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
