Hi everyone,
I’m new to enonic, so far I like a lot what I see!
I have run into a problem with the markup, would be great if someone can help me on this:
The Html-Template that I’m implementing heavily relies on <section> tags.
The Out-Of-The-Box Text Component also always adds <section> tags to the page, but they do not match the html structure I need.
Is there a way to remove these auto-generated <section> tags in the text component?
It would be ok if they are rendered in the content editor as the editing functionality seems to rely on it (which I btw think is not a good idea, but probably cannot be changed so quickly).
We considered an option to allow the user to choose the root element of each text component, but it’s still in the back-log. I guess you should be able to replace this element with something else yourself by processing the output. Maybe someone can come up with a piece of code to do this?
Just for curiosity: What do you want to replace it with?
Also, remember that you need to preserve the: data-portal-component-type=“part” attribute in order for the page editor mode to work properly.
I’m not sure how I can process the output of the text component, can you maybe give me a hint where to start?
I did check with the repo explorer, in the repo the tag is not stored, so I cannot remove it in my controller, can I?
“TextComponent”: {
“name”: “Text”,
“text”: “<h1>Dies ist die erste Section</h1>”
}
Some more background on what I’m doing: I have a region, where authors can add components. Each of these components should be displayed with a given html (that includes a section tag).
This is my code (${removeEditMode} is “tag” in editing mode and “none” otherwise, rendering these tags in edit mode breaks the authoring functionality):
<div data-portal-region=“content”>
<div data-th-if="${contentRegion}" data-th-each=“component : ${contentRegion.components}”
data-th-remove=“tag”>
<section data-th-remove="${removeEditMode}">
<div class=“container” data-th-remove="${removeEditMode}">
<div class=“col-md-8 col-md-offset-2 col-sm-10 col-sm-offset-1” data-th-remove="${removeEditMode}">
<div data-portal-component="${component.path}" data-th-remove=“tag”></div>
</div>
</div><!–end of container–>
</section>
</div>
</div>
The resulting html with one text component (in preview mode) now has my section tag, but also an additional section tag that breaks the layout:
<div data-portal-region=“content”>
<section>
<div class=“container”>
<div class=“col-md-8 col-md-offset-2 col-sm-10 col-sm-offset-1”>
<section data-portal-component-type=“text”>
<h1>Dies ist die erste Section</h1>
</section>
</div>
</div><!–end of container–>
</section>
</div>
Since I am in preview mode, I don’t see a reason why there should be an auto-generated tag.
You say you see this tag in preview. Don’t you also see this when going to the “live” site on /portal/master/ ? We add this because we must always wrap the result in any component with one - and only one - tag.
Also, looks like a few things with the way you do the region rendering is off, we normally don’t put any HTML in there as it can break many things. This way of adding html inside region rendering also breaks the Layout Component, a type of component used to structure your site into columns (or similar). See how lightweight the example Thymeleaf is here: http://docs.enonic.com/en/stable/developer/site/page/index.html#regions
So, structural html should go into Layout components.
The <section> comes from the Text Component. Dirty hack that would get you going straight away is to intercept the HTML before it is sent to the client, and then replace the <section data-portal-component-type="text"> with whatever you like, and also that ending <section>, perhaps with a regex.
As Bobby mentions, XP is designed so each component on a page must have a single root element. In relation to text components was chosen as the natural root element for such a piece of text as this semantically also makes sense. This root element also needs an attribute in order to be detected as a component by the page editor, ref data-portal-component-type=“text” attribute.
The sample code you are listing shows style formatting options which should be taken care of by layouts I think…
Hi Bobby,
I do see the section tag both on prievew and on master branches, but I don’t see why it should be necessary to render this tag unless I am in editing mode.
The answers you and Thomas gave are not very satisfying in my opinion.
SInce I am implementing a pre-defined html template, I should be able to achieve the html structure I want to achieve, which apparently I cannot without using Filters.
The feature I really need is that I can define the html structure that the text (and image) components produce, because then I can add the markup you call “structural” to the component and that’s where it should be.
I don’t feel this is actually a layout, because it only styles the appearance of one component.
In-Place editing is a key feature, using a part with HtmlArea feels like going back to type3 or so.
If enonic provided the ability to create custom parts that allow in-place editing, that would be great as well.
The markup in editing mode and in the “live” mode needs to be the same or else you would get pretty odd behaving JavaScripts and CSS on your site (since markup change).
I guess what we can subtract from this is that what you wish for is a way to control the tag that the Text Component outputs. This should be added as a feature request. And since they might take some time to be evaluated, I suggest you consider other approaches, like the once I’ve suggested. Or edit your front-end CSS/JS.
If you create the feature request yourself here in the Features category you’ll be able to answer feedback and questions directly from the developers, and follow progress: https://discuss-3.enonic.com/c/features
In-place editing of parts also sounds like yet another cool feature request =) I’d recommend you to create that as a separate feature request (makes it easier to handle for the developers).
So, you are really just looking to “wrap” a single text component with your flavour of markup? As Bobby explains one should avoid producing different markup for edit vs live mode - especially for in place editing cases, as this might cause a lot of other problems.
We have considered enabling in-place-editing of parts (not limited to htmlarea inputs) so this might be a solution. Another approach would be allowing you to handle the rendring of the text component. If we provide a way to override the built-in text component. In that case I guess the user would actually have to choose it from the text component settings or similar - maybe choose a default text controller for the site. How does that sound?
Finally, as bobby mentions you could use layouts. I know it will not solve every situation but we use this heavily to achive different presentation of content - for instance on enonic.com we use layouts to control if a panel is centered, background color and even top padding adjustments. The main region actually covers the whole viewport, so if you don’t add a layout, your component will fill the entire screen width.
A final solution might be some kind of decorators that can be added to any component, but would then also be supported within layouts I guess.
I’m not sure filters are a decent way of solving your requirements.
