enable a session context for users of dm4-webactivator

[Malte]

As you mentioned in one of our last talks, it would be necessary for "ctx.setVarialbe()" (thymeleaf page preparation) to get a Session-Scope instead. Maybe this requires DM to create a session also for not logged-in users, and for such, a max lifetime might be a sensible choice.

[jri]

Yes, currently the Thymeleaf Context is kept globally and thus does not allow for a) concurrent requests to the same web application, and b) the deployment of more than one web application plugin at the same time. These are crucial restrictions with the current Web Activator 0.3.1 prototype.

However, holding the Thymeleaf Context in session-scope is not strictly required and would be more difficult to achieve. It would be sufficient to create the Context in request-scope. I think I'll go this way.

Note: for page preparation your plugin could still rely on data kept in the (authenticated) user session. Just keep in mind a new Thymeleaf Context would be created with each request.

[Malte]

Thanks for your reply.

Note: for page preparation your plugin could still rely on data kept in the (authenticated) user session. Just keep in mind a new Thymeleaf Context would be created with each request.

1. In my use-case visitors to the webpage won't necessarily have an (authenticated) user session.

2. Could I access the data stored in such a user session from within all my Thymeleaf Template Files by ObjectGraphNotation? or similarly easy or do I have to re-write all my templates? (if I change my mind and find time to implement point 1)

I think, introducing a session-scope is very clearly the way to go. For now I am just in the hope that the memory of my current webserver can bear with all the extra Thymeleaf Contexts created after switching to request-scope

Thanks for your support.

[Jörg Richter]

WebActivator? fix: concurrent requests (#492).

The Thymeleaf Context object (the view model) is created in request-scope (instead of WebActivator?-global).
This allows for

a) concurrent requests to the same web application.
b) deployment of more than one web application plugin at the same time.

BREAKING CHANGES

1. Your web application plugin's init() hook must call initTemplateEngine().

Formerly this was named setupRenderContext().

2. For page preparation call setViewModel(name, value).

Formerly you did context.setVariable(name, value).

3. Keep in mind a new Thymeleaf Context object is created with each request. For page preparation your plugin could still rely on data kept in the (authenticated) user session. You just need to transfer the required session data to the context (by calling setViewModel()) when preparing the page.

See #492.

• Changeset: 619e9b220d66a261e7c6f86868573d6eb994af57
• URL: ​https://github.com/jri/dm4-webactivator/commit/619e9b220d66a261e7c6f86868573d6eb994af57

[jri]

The "DeepaMehta 4 Example Webapp" is now adapt to the current WebActivator?.
​https://github.com/jri/dm4-example-webapp

[jri]

Replying to Malte:

1. In my use-case visitors to the webpage won't necessarily have an (authenticated) user session.

Do you mean you need a session despite the user is not logged in?
In this case I would see 2 possibilities:

1. Your plugin could create the session oneself.
2. DM's policy could be revised in the way a session is created for *every* user (authenticated or not).

I would opt for a.

2. Could I access the data stored in such a user session from within all my Thymeleaf Template Files by ObjectGraphNotation? or similarly easy or do I have to re-write all my templates? (if I change my mind and find time to implement point 1)

Yes, inside a template you could access all the session attributes in usual OGNL notation via the session context variable. However, the WebActivator? first would have to create Thymeleaf WebContext objects instead of Context objects. A WebContext? contains web-specific data, like the request (and thus the session), the response, the servlet context and so on. I think WebActivator? should be adapted this way.

I think, introducing a session-scope is very clearly the way to go.

I don't think so. Thymeleaf is designed to have the session inside the context (as described above) and not vice-versa (the context in the session).
The responsibility of the context is to hold the data needed to render one page. Then the context is of no interest anymore. The rendered page is the response to a particular request. This is directly reflected in the Thymeleaf API: the WebContext? constructor takes a HTTP request and a HTTP response. So, when using Thymeleaf in a web application environment the context is request-scoped by nature.

For now I am just in the hope that the memory of my current webserver can bear with all the extra Thymeleaf Contexts created after switching to request-scope

The number of Context (or WebContext?) objects is certainly not a problem for the web server (a lot of Java objects are created for each request anyway). Once the request is processed the corresponding Context object is garbage collected.

However, your question about accessing the session data within a template clearly suggested for WebActivator? to switch from a Context to a WebContext?. Thank you!

[Jörg Richter]

Access session attributes from template (#492).

Within your template you can access the session object with ${session} and its attributes, e.g. ${session.username}.

Internally a Thymeleaf WebContext? object is created (instead a Context object).
Thanks to Malte for raising this issue!

BREAKING CHANGES

The method for adding data to the view model is renamed:

setViewModel(..) -> viewData(..)

See #492.

• Changeset: 2ebd49deb674f200ad2c3efb147d03f540b1e258
• URL: ​https://github.com/jri/dm4-webactivator/commit/2ebd49deb674f200ad2c3efb147d03f540b1e258

[Malte]

Thanks, thanks, thanks, so everything is fine for now!

And I have something to think about. Thanks for your input and for highlighting some of the Thymeleaf specifics around this issue.

[jri]

The example web application now demonstrates how to access session attributes. It shows the user's login status.

​https://github.com/jri/dm4-example-webapp

Thank you, Malte, for feedback!

[Jörg Richter]

Update Thymeleaf 2.0.16 -> 2.0.17 (#492).

See #492.

• Changeset: f6ad1d859d0e645add19c5541f1f4cd70df87c78
• URL: ​https://github.com/jri/dm4-webactivator/commit/f6ad1d859d0e645add19c5541f1f4cd70df87c78

[Jörg Richter]

Fix sub-resource methods (#492).

Thanks, Malte, for reporting!

See #492.

• Changeset: c139bec2ae51b780a1b7146d9c8dc83fbc74452f
• URL: ​https://github.com/jri/dm4-webactivator/commit/c139bec2ae51b780a1b7146d9c8dc83fbc74452f

[jri]

Now where session attributes are accessible from templates this ticket is regarded as complete.