Ticket #365 (closed Feature Request: fixed)
Server-side HTML generation (Template Engine)
| Reported by: | jri | Owned by: | jri |
|---|---|---|---|
| Priority: | Major | Milestone: | Release 4.1 |
| Component: | DeepaMehta Standard Distribution | Version: | 4.0.12 |
| Keywords: | Cc: | dgf, Malte | |
| Complexity: | 8 | Area: | |
| Module: |
Description (last modified by jri) (diff)
First try was JSP for the views.
-> No success. Loading dynamically created servlet classes is big problem in OSGi environment.
Apache Velocity could be an alternative, but ...
The hot candidate for the template engine is Thymeleaf
www.thymeleaf.org
Change History
comment:2 Changed 12 years ago by jri
- Status changed from new to accepted
- Description modified (diff)
- Summary changed from Web Framework to Server-side HTML generation (Template Engine)
comment:3 Changed 12 years ago by Jörg Richter
Core: plugins have access to their Bundle (#365).
Plugin framework:
Through "bundle" a plugin activator has access to the plugin's OSGi Bundle object.
In preparation for "Server-side HTML generation".
See ticket 365.
comment:4 Changed 12 years ago by Jörg Richter
Core: plugins have access to their Bundle (#365).
Plugin framework:
Through "bundle" a plugin activator has access to the plugin's OSGi Bundle object.
In preparation for "Server-side HTML generation".
See ticket 365.
comment:5 Changed 12 years ago by Jörg Richter
Core: flexible REST resources registration (#365).
Plugin framework:
A plugin who provides no REST service can still provide JAX-RS provider classes.
Such a plugin might provide e.g. a Jersey View Processor.
In preparation for "Server-side HTML generation".
See ticket 365.
comment:6 Changed 12 years ago by Jörg Richter
Core: flexible REST resources registration (#365).
Plugin framework:
A plugin who provides no REST service can still provide JAX-RS provider classes.
Such a plugin might provide e.g. a Jersey View Processor.
In preparation for "Server-side HTML generation".
See ticket 365.
comment:7 Changed 12 years ago by jri
The basis for web application development with DeepaMehta is provided:
https://github.com/jri/dm4-webactivator
Custom web applications are regular DM plugins. The plugin class acts as controller. The views are located at /resources/views. The views are wellformed XML (HTML5) Thymeleaf templates.
A web application plugin is derived from
de.deepamehta.plugins.webactivator.WebActivatorPlugin
instead of
de.deepamehta.core.osgi.PluginActivator
Simple example web application:
https://github.com/jri/dm4-example-webapp
Thymeleaf template engine:
http://www.thymeleaf.org/
comment:8 Changed 12 years ago by jri
- Status changed from accepted to closed
- Resolution set to fixed
Proof-of-concept is complete.
Issues remain.
comment:9 Changed 12 years ago by Jörg Richter
Core: fix REST resource registration (#388).
The Jersey servlet is not registered before any root resources are added.
Note: since Nov 16, a plugin may provide just provider classes (but no root resources).
See ticket 365.
Close ticket 388.
comment:10 Changed 12 years ago by Jörg Richter
Core: fix REST resource registration (#388).
The Jersey servlet is not registered before any root resources are added.
Note: since Nov 16, a plugin may provide just provider classes (but no root resources).
See ticket 365.
Close ticket 388.
comment:11 Changed 12 years ago by Jörg Richter
Initial commit: Web Activator base plugin (#365).
Rename project to "DeepaMehta 4 Web Activator" (dm4-webactivator).
The WebActivatorPlugin? provides a base class for the custom webapp plugins.
The custom webapp plugins must no longer care about
- Consuming a service.
- Instantiating a TemplateEngine? and a Context
See ticket 365.
Core: experimental support for JSP (#365).
Relies on new external plugin dm4-test-jsp.
Plugin API:
Core internal:
NOT SUCCESSFUL.
Loading dynamically created servlet classes is big problem in OSGi environment.
Not to be continued.
See ticket 365.