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

[Nikolay Elenkov]

On 2010/05/25 21:39, Pete Muir wrote:
> 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.

OK, thanks.

> 
> On 25 May 2010, at 03:01, Nikolay Elenkov wrote:
> 
> 
> 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?
> 

Yes, I know about this, not sure where/how well it is documented. I rejected it
because it is still XML.

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

Not business analysts, just users. Still, the weapon of choice of business
analysts is Excel and maybe PowerPoint, not even close to XML.


>> 
>> * make it pluggable
> 
> This is a "generic" requirement. I like to know the real use cases.

The original use case is 'make it easy for end users to edit templates without
breaking stuff'. If the default is facelets/DSL/whatever, at least make it easy
for us to plug our own templating engine. Here's another one: 'edit templates
based on user role'. If you have multiple templates that should be editable
based on user role, the natural way is to save those to the DB. As far as I
know, to render stuff with Faclets you need files. So now you will need to dump
templates to a (temp) file to send email. In this case, a custom templating
engine makes things easier.

> 
>> * separate rendering from sending/routing.
> 
> Would like to understand more about your problems here.

Well, now if you call Renderer.render(), it goes ahead and sends the message.
But we might need the actual message (MimeMessage or whatever). The usual use
case is save it to DB (for auditting, resending, etc.), but you might also want
to do some preprocessing/additional checking before sending. So related to
SEAMMAIL-5, but saving to JPA doesn't solve all problems and might be overkill
for some cases.

> 
> 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.

Sure, don't throw it away. Just make it easy to use something else if needed.