Skip to content
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

Closed
ultraq opened this issue Apr 24, 2015 · 4 comments
Closed

Allow <title> elements to get processed, before using in decoration #72

ultraq opened this issue Apr 24, 2015 · 4 comments
Assignees

Comments

@ultraq
Copy link
Owner

ultraq commented Apr 24, 2015

The title-pattern processor relies on a lot of special-casing code paths in the HtmlHeadDecorator 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:

  • copy each of the title elements to the resulting HTML, extracting the title-pattern directive
  • create a new title element with the title-pattern directive, after the copies
  • let Thymeleaf run over the first 2 titles
  • when reaching the third, extract the values from processing the first 2 and run them through the title pattern
  • delete the title copies

This 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.

@ultraq
Copy link
Owner Author

ultraq commented Apr 29, 2015

Done! :)

@ultraq ultraq closed this as completed Apr 29, 2015
@chrylis
Copy link

chrylis commented Jul 1, 2015

This is not working for me in 1.3.0-SNAPSHOT. Steps to reproduce:

Declare "target" view:

<!DOCTYPE html>
<html data-layout-decorator="layout/dashboard-layout">
<head>
    <title data-th-text="foo">bar</title>
</head>

<body>
    <div data-layout-fragment="page-content">
        <p>Stuff goes here.</p>
    </div>
</body>
</html>

Use the title selector in the layout:

<!DOCTYPE html>
<html>
<head>
    <title data-layout-title-pattern="$CONTENT_TITLE | $DECORATOR_TITLE">My Site</title>
</head>

<body>
    <div id="view-title-text">
        <h2><span data-layout-include="::title"/></h2>
    </div>

    <div id="dashboard-content-pane" data-layout-fragment="page-content" />
</body>
</html>

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 data-th-text or data-th-inline="text" with inline replacement placeholders.

@ultraq
Copy link
Owner Author

ultraq commented Jul 2, 2015

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: layout:include works mostly the same as th:include in that it gets a fresh copy of the contents of the element you select straight from the template repository and cache (if enabled). Because of that, any modifications I make to the <title> are never reflected in the content retrieved by layout:include.

@ultraq
Copy link
Owner Author

ultraq commented Jul 5, 2015

New issue created to continue discussion of your more recent comments: #76

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants