[seam-dev] Let me know what you need for a first stab at the PDF/Mail port from Seam 2

[Pete Muir]

As we've started make concrete requirements, I've set up a JIRA project to track.

For those where i've created JIRA issues, I suggest we continue the discussion there.

On 25 May 2010, at 03:01, Nikolay Elenkov wrote:

> On 2010/05/25 3:06, Gavin King wrote:
>> And, of course, this is why facelets is so appropriate for the task:
>> facelets was designed not for text rendering, but for object graph
>> construction. JSP and Velocity just render text.
>> 
>> On Mon, May 24, 2010 at 1:04 PM, Gavin King <gavin.king at gmail.com> wrote:
>>> I just don't buy this. On the contrary, the Seam mail functionality is
>>> NOT just rendering a bit of text, which is what I tried to explain,
>>> but nobody seems to be "getting". The template actually builds an
>>> object, with to/from addresses, a subject line, headers, etc.
>>> 
> 
> That's one of the problems with it. It does too much. As I said before, email is
> not a document, it is a message. It has recipients, reply-to, headers, subject
> and body. If people want to customize it, they would like to customize the body
> and maybe the subject. Headers and recipients are generated by the program and
> you don't usually want to touch those. The current implementation
> squishes all that together in one xml template (which happens to be
> facelets/JSF). IMHO, this is not a good idea.

We always intended people to use the templating feature of Facelets (ui:include) to work around this. Did you not realize you can do this (documentation problem), or reject it? If you rejected it, why did you reject it?

I've documented your comment that XML is too complex for your business analysts at https://jira.jboss.org/browse/SEAMMAIL-7

> Another thing the current implementation does is render and send at the same
> time. This is a bad idea as well. You'd generally want to save the rendered
> email, and retry on send errors.

Email has two types of errors, those that the MTA will automatically retry for, and those that cause bounces. If you are referring to bounces, how do you process the bounces?

https://jira.jboss.org/browse/SEAMMAIL-1

> The current implementation is driven by JSF,
> and hides those things from you (if you go out of your way, you can get them,
> but in this case the framework is working against you).
> 
> Again, what templating engine to use is not the main problem. The main points are:
> 
> * make it pluggable

This is a "generic" requirement. I like to know the real use cases.

> * make it modular

This is on the cards.

> * do not depend on JSF/reply/request, so that you can call it asynchronously

This is the problem we are trying to solve ;-)

> * separate rendering from sending/routing.

Would like to understand more about your problems here.

> * make it easier to test (yes, I know we have MockTransport

Agreed. This is definitely something we should work on.

https://jira.jboss.org/browse/SEAMMAIL-2

> 
> And please don't take my word for it, just do a search on the Seam forums. The
> majority of questions on Seam mail are:
> 
> * how to send to multiple recipients (use a faclets loop to add multiple to:s,
> really?)

We could easily introduce a component that takes multiple to addresses (e.g. a Collection). Not sure why I didn't do this originally ;-)

https://jira.jboss.org/browse/SEAMMAIL-3

> * how to send from JMS/async (I can't access my contexts! It doesn't work!: Oh,
> now I have this hack that makes it work.: repeat...)

Agreed. This is where this whole thread started.

https://jira.jboss.org/browse/SEAMMAIL-4

> * how to save the rendered message (you can't; write a custom JavaMail transport)

Useful functionality. We should definitely put this on the roadmap.

https://jira.jboss.org/browse/SEAMMAIL-5

> * how to retry if sending fails (catch this JSF exception, look at the cause,
> maybe if you are lucky, you will find the cause...)

Ok, this is definitely something to look at.

https://jira.jboss.org/browse/SEAMMAIL-6

> 
> So right now, Seam mail gets in the way more than it helps. If Seam3 is going to
> be better, things have to be changed, not just ported over, because that's how
> it used to be in Seam 2.
> The templating engine is just one part of the problem,
> and not the main one.

Exactly. So it's good we are now looking at your real problems, not the perceived solution.

I don't think throwing out the whole templating engine, just because there are issues with the implementation is a forgone conclusion. Or, to use one of my favourite sayings, let's not throw the baby out with the bathwater.