Confusing naming

[mnlipp]

I've pondered quite some time about the names used and I find them confusing -- at least if you start with the common interpretation.

A model usually manages your data over time. But instances of RockerModel are short lived. After invoking the render method once, they can no longer be used. I've therefore started to call my rocker sources XyzRenderer.rocker.html. This generates XyzRenderer and I can call new XyzRenderer().render(...) which makes sense.

Of course, looking at the examples, the suggested use is XyzRenderer.template(...).render(...). But the template(...) method is not properly named, however you look at it. It returns a RockerModel and should therefore actually be named model(...) (or, if you follow my interpretation renderer(...)). Its current name (template(...)) suggests that it returns an instance of the inner class XyzRenderer.Template, which it certainly does not.

I suppose the name template() was inspired by the use case "including another template". But, at least to me,

@views.MyOther.renderer()

would look very natural (I include another template by calling its renderer, obvious, isn't it).

[jjlauer]

I appreciate your feedback. Some of the naming is due to Rocker's first release which didn't support hot reloading and the base class for your template was simply RockerTemplate. To get hot reloading to work, I had to split up the arguments & template interface (model) from the actual code that did the rendering (template). They had to be in two classes so the classloader could be reloaded.

The two combined (model & renderer) are the template. When calling the static method "template()" -- i does return a model, but it logically is a template.

In my own java code, I always use a fully qualified class name to help make it clear I'm using a template. For example, I'll do "views.Xyz.template(arg1, arg2, ...)". If you personally like to use non qualified names, then I think naming it "XyzView" is maybe more appropriate. I think your being a little nitpicky on the base class being called a Model since you directly use the name of your template. Is model a perfect name, no, I'd agree with you there. But I was trying to reflect that it represents the arguments & interface to a template.

As for single use that was a design decision both for backwards and forwards compat. The original Rocker w/o hot reloading, required the setup of many variables that were only good for single use. That case doesn't hold in today's version, but I can think of a few ideas down the road where it's still good to encourage users to think of templates as single use / immutable once their used. If you can pitch me on ideas why you would like reuse, I'm open to understanding your use case.

Hope that helps!

[jjlauer]

@mnlipp Wanted to circle back with you on this issue.

[mnlipp]

To be honest, I had to rule out rocker from my project. I should have noticed earlier, but rocker isn't "OSGi compatible" (a feature that I need on the long run). I thought about making rocker (runtime) an OSGi bundle, but (1) I don't know how to do this with a maven build (2) rocker has too many dependencies which I'd have to check for OSGi support first. It's a danger when using maven-style repos and dependencies that one actually doesn't really care enough about transient dependencies because they are pulled in automatically. (Probably the "worst" dependency from my personal point of view is the dependency on netty because my project is partially about an alternative to netty, so kind of silly to get this pulled in.)

Actually, OSGi support seems to be a kind of blind spot with template engines. I had to "revert" to "good" old Freemarker, which seems to be the only one that claims active OSGi support (and has no dependencies, which makes it really easy to integrate). Rocker's template syntax is much nicer and I would have loved to use it, but, well, see above...

[jjlauer]

@mnlipp Appreciate the feedback. Rocker-runtime doesn't have any other runtime dependencies -- so not sure I totally understand some of your feedback. Netty, for example, is scoped as a test dependency for a demo of rocker w/ asynchronous IO. As far as OSGI, I'd be open to it, but I suspect Java 9 will change the game dramatically. I do plan on fully supporting Java 9 modules once its released.

[mnlipp]

Ah, I admit that I have only looked at the pom.xml and seen the dependencies enumerated there. Maybe I'll try to setup a gradle build to find out about the real dependencies (and add OSGi info), but it won't be any time soon.

Java 9 modules aren't a replacement for OSGi (e.g. no versioning, no support for dynamic service loading). I'm not sure yet, however, if the two can coexist in one module/bundle project or if one has to make a choice.