-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow <title> elements to get processed, before using in decoration #72
Comments
Done! :) |
This is not working for me in 1.3.0-SNAPSHOT. Steps to reproduce: Declare "target" view:
Use the title selector in the layout:
Expected behavior: page title is "foo | My Site" and the header element is "foo". Actual behavior with 1.3.0-SNAPSHOT: page title is "foo | My Site" and the header element is "bar". This behavior is consistent whether I use |
You mentioned a similar issue in #64, and I just made a comment there recently where I tried to fix it but couldn't get it to work. I even tried on the 1.2.x branch of the layout dialect and didn't find it to work there (you claimed it was a regression): #64 (comment) TL;DR: |
New issue created to continue discussion of your more recent comments: #76 |
The
title-pattern
processor relies on a lot of special-casing code paths in theHtmlHeadDecorator
to work, namely the copying of the state of the<title>
elements in both content and layout templates, before creating a new<title>
that approximates the intent of the developer. However, this special casing is starting to fall apart (see #64 and #66), and the code that developers put inside those elements should fulfil all the processors that are put in there.So a better solution I think would be to allow Thymeleaf to process each of the title elements, before being put together for the final
title-pattern
processor. To do this:title
elements to the resulting HTML, extracting thetitle-pattern
directivetitle
element with thetitle-pattern
directive, after the copiestitle
stitle
copiesThis way, each
title
gets everything done to it without special code paths.There might be some difficulty with deep layout hierarchies, so some solution for how that works should be decided, and appropriate tests (if they don't already exist for these cases - I think they do...?) should be made.
The text was updated successfully, but these errors were encountered: