Typesafe API for using ArrayOfByteArraysOutput about rocker HOT 7 CLOSED

ArrayOfByteArraysOutput is simply the current optimized output type, but I've played around with a ArrayOfByteBufferOutput privately and there currently is also a StringBuilderOutput and OutputStreamOutput in the repo. The general vision is that the application you're building would determine what kind of output makes the best sense and then allow you to customize handling that output type an application-specific thing. Since Rocker templates would most likely be used in some sort of web framework, then handling specific output types differently also makes sense since one couldn't predict how to best optimize it.

Getting into the nitty gritty of actually needing to access getArrays() means you want to optimize for that use case -- in which case I'd expect casting it to be the best way to do it. For example, if you wanted to optimize Rocker templates for output via asynchronous IO, you'd want to check if ArrayOfByteArraysOutput was used, then maybe wrap each byte array as a ByteBuffer and directly output it to the NIO stream. If the output isn't that type, then fallback to rendering the output to a larger byte array or string and then doing that.

from rocker.

The general vision is that the application you're building would determine what kind of output makes the best sense and then allow you to customize handling that output type an application-specific thing.

It sounds like this “configuration” is just missing right now. I don't see how to specify what the RockerOutput implementation should be.

in which case I'd expect casting it to be the best way to do it

This is at odds with your previous paragraph. Regardless, having an API require casting is a bit unfortunate. Sometimes it's unavoidable, but I don't see (with my limited knowledge of the internals) any reason why this concession needs to be made. It seems like the API could be redesigned to strongly type the output type.

from rocker.

The library is currently designed where a subclass is required to change
the default RockerOutput created on a render. It's designed that way
because templates are most likely IMO to be used within a "framework" such
as Ninja, Play, Sinatra, etc. In which case, customizing & optimizing the
underlying concrete output used is just one of a handful of things a
framework would likely want to do. See
https://github.com/fizzed/ninja-rocker/blob/master/module/src/main/java/com/fizzed/ninja/rocker/NinjaRockerTemplate.java
for an example of a customization (not of the output, but of something
else). Could this be exposed as a settable property or as an extra override
to render() -- sure. If you're tying this into a web framework from what I
recall of your earlier comments, why not go a step further and provide a
custom base template and/or model?

I'm not sure why you think my comment about casting is at odds with my
other statement. I never envisioned caller's wanting to work so closely
with the output since as I've mentioned many times now -- the major use
case is being integrated into "frameworks" -- which likely handle all that
stuff.

On Sun, Dec 20, 2015 at 7:32 PM, Luke Daley [email protected]
wrote:

The general vision is that the application you're building would determine
what kind of output makes the best sense and then allow you to customize
handling that output type an application-specific thing.

It sounds like this “configuration” is just missing right now. I don't see
how to specify what the RockerOutput implementation should be.

in which case I'd expect casting it to be the best way to do it

This is at odds with your previous paragraph. Regardless, having an API
require casting is a bit unfortunate. Sometimes it's unavoidable, but I
don't see (with my limited knowledge of the internals) any reason why this
concession needs to be made. It seems like the API could be redesigned to
strongly type the output type.

—
Reply to this email directly or view it on GitHub
#11 (comment).

from rocker.

If you're tying this into a web framework from what I
recall of your earlier comments, why not go a step further and provide a
custom base template and/or model?

Because I haven't seen a compelling reason to do so. I'd much rather avoid this if at all possible as super classes are hard to maintain binary compatibility on. This also pushes the runtime framework into build time, which is also not something I want to do.

I never envisioned caller's wanting to work so closely
with the output since as I've mentioned many times now -- the major use
case is being integrated into "frameworks" -- which likely handle all that
stuff.

My framework is the caller. I don't want a user's app to fail because I made a bad assumption about when the output was a certain type and when it wasn't.

from rocker.

Gotcha. A simple feature to address your need would result in something
like this:

template.render(yourOutput);

Overrides the default output. No typing/casting required as your injecting
the output you want the template rendered to.

The only other thing I'll point out about binary compat. I am using this
stuff in many, many projects and I have no desire of recompiling anything
if not necessary. So I have a vested interest in not breaking binary
compat or if it does happen the major version number would bump up.

I'm open to any PRs that implement this or the other idea you initiated. I
don't need them myself at the current time, so I won't be working on them
in the foreseeable future, but its an open project and I would welcome the
ideas.

On Tue, Dec 22, 2015 at 11:09 PM, Luke Daley [email protected]
wrote:

If you're tying this into a web framework from what I
recall of your earlier comments, why not go a step further and provide a
custom base template and/or model?

Because I haven't seen a compelling reason to do so. I'd much rather avoid
this if at all possible as super classes are hard to maintain binary
compatibility on. This also pushes the runtime framework into build time,
which is also not something I want to do.

I never envisioned caller's wanting to work so closely
with the output since as I've mentioned many times now -- the major use
case is being integrated into "frameworks" -- which likely handle all that
stuff.

My framework is the caller. I don't want a user's app to fail because I
made a bad assumption about when the output was a certain type and when it
wasn't.

—
Reply to this email directly or view it on GitHub
#11 (comment).

from rocker.

v0.11.1 has this feature.

ArrayOfByteArraysOutput out = model.render(ArrayOfByteArraysOutput.FACTORY);

from rocker.

Super cool. Thanks.

from rocker.