email templates

[tom.baeyens]

imo the first direction to search for the solution is a separate, dummy SEAM web app that is only used for our email templating. maybe that webapp could be secured to only allow access from localhost...

other opinions on email templating ?

below the response from pete muir when i asked him if it was possible to run seam email templating without JSF. the answer was no.

> Yeah, you need JSF and Facelets for Seam mail.
>
> I was working on having it so Seam mail would be able to use JSF even if
> it wasn't running in an application server (i.e. Seam mail would boot
> JSF itself), but this never got 100% finished.
>
> On 10 Feb 2009, at 13:11, Tom Baeyens wrote:
>
>> Hi Pete,
>>
>> Since MailFacesContextImpl extends DelegatingFacesContext, i assume
>> that seam leverages the delegate faces context from the jsf
>> implementation and hence it can only run inside a JSF application,
>> right ?
>>
>> Or is it also possible with the seam-mail classes to generate mails in
>> a standalone java app ?
>>
>> --
>> regards, tom.

[kukeltje]

Yes, I have another option: Develop one completely ourselves... is probably much easier, costs less time, easier to maintain, makes us independent of other frameworks (so e.g. not using velocity either). Best is even to not use EL.

Or am I cynical now?

Real answer: Depends on what the requirements are..... Velocity would be an option...

Since Pete Muir responded that work already started to make the templating (jsf+facelets, not jsp) independent of a webapp, I assume you asked him how much work (and what) still needs to be done for that. Both projects can benefit if this is completed.

[tom.baeyens]

finishing the (i.e. Seam mail would boot
> JSF itself) might be out of our reach for the GA release.

[kukeltje]

There was an additional reason I asked if you had more info from Pete. The bpm/b2b/... framework I'm developing on top of jBPM uses Facelets/JSF for the webapp, XForms for complex forms (already nicely integrated with seam contexts etc) ebMS for b2b messaging. Besides this, I need to use facelets with jsf for mail templating (customer requirement, does not want to learn new technology). So in my case it is not a big problem since there always is a webapp (even jsf based). But....out of the blue the customer asked me if it would be possible to use this mail templating in a rich client they have. So I have some payed time to look into this if I can get 'booted'. Pete just has to bootstrap me a little.

GA is July 1st right?

[kukeltje]

I've been looking into what is already in seam. There is a complete mock framework for testing seam including mocking lots of jsf stuff. From what I've seen, this could be leveraged, either by using those classes or by code duplication. So imo it is 100% feasible to have this in place before july 1st.

Never the less, some additional bootstrapping from Pete would help.

[kukeltje]

ok... bootstrapping works for 80% already... not realy that difficult with the seam mock, a small example from ICEFaces and some things from RichFaces....

Last thing to do seems to be getting the right EL resolvers in place...

[tom.baeyens]

keep me posted on your progress. i'm all ears.

[kukeltje]

It already works.... at least outside jBPM with the default JBoss EL. So the next step is to integrate it with the jBPM resolver.

Ofcourse the code needs some cleaning up, at least one unittest (:-P) (there only is one method).

[heiko.braun]

Keep it simple. Why should we hack around JSF when could aswell have a simple templating solution like velocity?

[tom.baeyens]

velocity is a bit out of the typical jboss components, no ? but it could be the right solution for us.

in what ways would velocity be simpler ?

[jbarrez]

I agree with Heiko here. Working around JSF to generate an email ... it just feels wrong.

It's not because the Seam guys are doing it, that jBPM must follow. Seam works in webapp-only environment. It makes (a bit) sense there. But what if one wants to use emailing in a Swing-jBPM app? Then they have to set up a seperate app server for the email-generating webapp? This just will not happen IRL.

I also think that using Velocity would be better. Velocity is nothing more than a fast engine that fills up a template with what is provided as input. It might be not as 'fancy' as JSF, but it gets the job done in a very simple and understandable way.Users can provide their own velocity templates that can easily plugged in a jbpm process definition. Heck, you can even create a custom JPDL node for this.

[heiko.braun]

Velocity.init();

// set payload, variables
VelocityContext context = new VelocityContext();
context.put( "name", new String("Velocity") );

// fetch a template
Template template = Velocity.getTemplate("mytemplate.vm");

// render it
StringWriter sw = new StringWriter();
template.merge( context, sw );

[tom.baeyens]

At this moment, velocity indeed seems to be solution that gets the job done without hacks so less risk of ending up with a buggy solution.

Let's explore that route first.

[heiko.braun]

+1

[pmuir]

Ronald - the work is mostly done, it should work in most cases. There have been some issues raised that in some situations the bootstrap we do doesn't work. The remaining work is more polish/edge cases than anything else. Currently you need to import all of Seam core and mail as we haven't done the modularisation of Seam yet. Please let me know if you have patches for this and I will try to look at them.

As for why we didn't use velocity - well for a start we would have used freemarker ;-) But really, Seam is about allowing you do to stuff without having to learn 101 ways of doing things so, as we already used JSF for the view layer, we wanted to allow people to reuse this knowledge.