Ah, ok, in the case of Database-loaded templates with Seam Render, that's
the reason why I made the *TemplateResolver *class in the first place. The
template path in render is actually an extensible lookup scheme.
*So:*
@include{"db:users/1/order/12/template"}@end{}
*Could be interpreted by a TemplateResolver which would perform the DB
lookup and provide the template.*
You'd need a *DatabaseTemplateResolver *and *DatabaseTemplateResource*. Once
that's done, and you define your path scheme, you're all set! The resolver
will handle lookups automatically! Caching templates so that you don't
hammer the database might be a few extra steps.
*
First, you register the resolver in the services file:*
/META-INF/services/org.jboss.seam.render.spi.TemplateResolver
com.example.myapp.DatabaseTemplateResolver
*Then it's then as simple as:*
@Inject TemplateCompiler compiler;
TemplateResource<?> template =
compiler.compile("db:nameOfTemplate/id12/param2/");
template.render(); //already integrated with CDI internally :)
// or the template lookup can be as simple as a name or id, but I still
recommend the use a "prefix:"
// "db:passwordRecovery"
*Templates of any resource type can reference templates of another type:
*
TemplateResource<?> template =
compiler.compile("db:nameOfTemplate/id12/param2/");
// the template above contains an include statement to a classpath template,
which in turn includes another database template.
@include{"/org/jboss/seam/mail/basicHtmlTemplate.render"} @end{}
----> @include{"db:templateThatChangesFrequently"} @end{}
// This from within your database template, will perform a classpath or
filesystem lookup (using the included resolvers.) So you can do cool things
like cross-resolver referencing of templates.
~Lincoln
On Mon, Mar 7, 2011 at 3:57 PM, Cody Lerum <cody.lerum(a)gmail.com> wrote:
You definitely want the ability to send in the template content via
inputstream however like I do with mail template.
I for example store my templates in the database.
-C
On Mon, Mar 7, 2011 at 1:19 PM, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com> wrote:
> :)
>
> BTW. RenderTemplate would look something like this... since Render has
its
> own TemplateResolver SPI, it wouldn't be very complicated from Seam
Mail's
> end.
>
> I don't think there's a real way that the MailTemplate interface would go
> with Render, unless an additional render TemplateResource implementation
> were provided to wrap it internally here. The only issue is that Render
> attempts to resolve relative paths in templates, so using MailTemplate
> doesn't really make sense here. Really render already implements a good
deal
> of what you are having to do in mail by trying to abstract the template
> input stream from the templating system itself... I believe you'll have a
> similar problem with Freemarker (or even with velocity if folks use any
> @Include("templateName.path") declarations.
>
> Thoughts?
>
> /*
> * JBoss, Home of Professional Open Source
> * Copyright 2011, Red Hat, Inc., and individual contributors
> * by the @authors tag. See the copyright.txt in the distribution for a
> * full listing of individual contributors.
> *
> * Licensed under the Apache License, Version 2.0 (the "License");
> * you may not use this file except in compliance with the License.
> * You may obtain a copy of the License at
> *
http://www.apache.org/licenses/LICENSE-2.0
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
>
> package org.jboss.seam.mail.templating.render;
>
> import java.io.InputStream;
> import java.util.HashMap;
> import java.util.Map;
>
> import org.jboss.seam.mail.templating.MailTemplate;
> import org.jboss.seam.mail.templating.TemplateImpl;
> import org.jboss.seam.render.TemplateCompiler;
> import org.jboss.seam.render.spi.TemplateResolver;
> import org.jboss.seam.render.spi.TemplateResource;
> import org.jboss.seam.render.template.CompiledTemplateResource;
>
> /**
> * @author <a href="mailto:lincolnbaxter@gmail.com">Lincoln Baxter,
III</a>
> */
> public class RenderTemplate implements TemplateImpl
> {
> private final CompiledTemplateResource template;
>
> public RenderTemplate(TemplateCompiler compiler, final MailTemplate
> template)
> {
> // not sure this integration really makes sense. Render should
> probably be responsible only for delivering a java.lang.String as output.
> TemplateResource<InputStream> resource = new
> TemplateResource<InputStream>()
> {
> @Override
> public String getPath()
> {
> return template.getTemplateName();
> }
>
> @Override
> public InputStream getInputStream()
> {
> return template.getInputStream();
> }
>
> @Override
> public long getLastModified()
> {
> return 0;
> }
>
> @Override
> public InputStream getUnderlyingResource()
> {
> return getInputStream();
> }
>
> @Override
> public TemplateResolver<InputStream> getResolvedBy()
> {
> return new TemplateResolver<InputStream>()
> {
> @Override
> public TemplateResource<InputStream> resolve(String
target)
> {
> // render will throw an error if this is reached
> return null;
> }
>
> @Override
> public TemplateResource<InputStream>
> resolveRelative(TemplateResource<InputStream> origin, String target)
> {
> // render will throw an error if this is reached
> return null;
> }
> };
> }
> };
>
> this.template = compiler.compile(resource);
> }
>
> public RenderTemplate(TemplateCompiler compiler, String path)
> {
> template = compiler.compile(path);
> }
>
> public RenderTemplate(TemplateCompiler compiler, TemplateResource<?>
> resource)
> {
> template = compiler.compile(resource);
> }
>
> public RenderTemplate(CompiledTemplateResource template)
> {
> this.template = template;
> }
>
> @Override
> public String merge(Map<String, Object> context)
> {
> Map<Object, Object> map = new HashMap<Object, Object>();
> map.putAll(context);
>
> String rendered = template.render(map);
> return rendered;
> }
> }
>
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"