-
1. Re: schema for mail template and activity
bradsdavis Apr 13, 2009 6:53 PM (in response to aguizar)How do you determine from that template the implementation of the email producer to use?
-
2. Re: schema for mail template and activity
aguizar Apr 14, 2009 3:14 AM (in response to aguizar)You don't. After some more analysis, I think the template should be a value class, just representing the data provided in the configuration. The mail producer should be associated to the mail activity. The class can be indicated explicitly (see below), otherwise one of the built-in producers will be determined from the template content: HtmlMailProducer if there is an element, SimpleMailProducer otherwise.
<mail-activity template='mytemplate' producer='org.example.CustomMailProducer />
-
3. Re: schema for mail template and activity
tom.baeyens Apr 14, 2009 3:23 AM (in response to aguizar)1) i think elements text and html should be renamed to:
body-text
body-html
2) shouldn't attachments have names ?
3) i don;t get the mail producers yet. it doesn't seem to fit with the rest of the architecture. also, what is the exact use case for these custom mail producers ? -
4. Re: schema for mail template and activity
kukeltje Apr 14, 2009 6:23 AM (in response to aguizar)1: No preference, without body it is shorter
2: Can be deduced from the url or the resource
3: My guess? So I can use JSF for my template while you use velocity ;-) -
5. Re: schema for mail template and activity
bradsdavis Apr 14, 2009 10:11 AM (in response to aguizar)I would have really liked the templates to be defined in the same way as in the jPDL. If you think about it, templates really are just mail nodes that have been externalized from the process definition. Keeping then consistent with jPDL would have allowed people to pick that up pretty easily.
However, if we want to have a seperate language for templates, I think what you are doing looks good. My only suggestion from the last post is that the producer attribute be moved within the template as well. This will allow users to change the email template type outside of deploying a new process.
@tom:
I think making it body-text and body-html would be fine. I also agree that attachments should have a name element.
Also Tom, I can install skype if you want to walk over the basis for producers. I also have written a bit of documentation thats in the email_branch if you check it out and package the documentation module. -
6. Re: schema for mail template and activity
aguizar Apr 14, 2009 12:22 PM (in response to aguizar)How about the following proposal on the body.
<body type="text"> | <body type="html">
Indeed, the attachment name can be deduced from the URL/resource/file but we can have an attribute to specify a different name.
@tom, I think of the producer as the "Mail" class in jBPM 3, only truly replaceable.
@brad, the templates and the activity are the same, the only difference is the option to refer to a template in the activity. I will take your suggestion to specify the producer in the template itself, and add a getProducer() method to the MailTemplate class. If you can, please take a look at what I have so far. -
7. Re: schema for mail template and activity
bradsdavis Apr 14, 2009 1:29 PM (in response to aguizar)@alejandro:
Don't forget for HTML emails that you can have both regular text [for users that cant render HTML in their email client] and HTML body text.
Keeping that in mind, make sure that it can take both of those within the template.
Brad -
8. Re: schema for mail template and activity
tom.baeyens Apr 14, 2009 2:17 PM (in response to aguizar)"alex.guizar@jboss.com" wrote:
How about the following proposal on the body.<body type="text"> | <body type="html">
ok. a type attribute is best."alex.guizar@jboss.com" wrote:
Indeed, the attachment name can be deduced from the URL/resource/file but we can have an attribute to specify a different name.
distilling the file name from the url/resource/file is ok"alex.guizar@jboss.com" wrote:
@tom, I think of the producer as the "Mail" class in jBPM 3, only truly replaceable.
i got that.
MailSession should become what Mail was before: the impl class that exposed the functionality that we have implemented.
Customisation of mail functionality should be another level. E.g. our base class MailActivity can be customized by users into a CustomMailActivity. -
9. Re: schema for mail template and activity
tom.baeyens Apr 14, 2009 2:21 PM (in response to aguizar)could you work out a set of examples that explain the schema ?
the template example i have already:<mail template="managerNotification" />
that could be used as an activity or an event-listener
what about other use cases ? -
10. Re: schema for mail template and activity
tom.baeyens Apr 14, 2009 2:23 PM (in response to aguizar)have a look at the userguide. i want to discuss the mail schema further in terms of use cases just like in the userguide. is that ok ?
-
11. Re: schema for mail template and activity
bradsdavis Apr 14, 2009 2:32 PM (in response to aguizar)@tom, which section of the userguide should I take a look at? Are you saying to look at the Email section of the user guide or use cases elsewhere in the userguide?
-
12. Re: schema for mail template and activity
tom.baeyens Apr 15, 2009 2:50 AM (in response to aguizar)i'm referring to the other activities and how they are explained in terms of examples. one activity might be explained in 1, 2 or 3 examples. each example shows one specific use case.
for email that would be something like:
email.inline: this would show an activity that sends an email which has all the properties like to, subject, body defined inline.
email.template: an mail activity using a template
task.reminder: another example in the list of task examples showing the task reminder
those are imo the first targets for email. all the other advanced functionality should be postponed.
i'ld like to see examples in the example package. then we can discuss and then the docs should explain the story in detail just like with the other activities. -
13. Re: schema for mail template and activity
aguizar Apr 15, 2009 8:49 PM (in response to aguizar)Examples cannot be produced at this point because the syntax and the design have not been agreed upon. Unlike other activities email has more complex setup and more moving parts. Let us focus on making the design decisions first.
There are two concepts in play.
* mail template describes the contents of an email
* mail producer takes a template as input and produces a template as output
In Brad's current model, the above concepts are treated as two parts of the same thing. The mail activity configuration is read into the fields of the mail producer, and the produce(Execution) method reads those fields to create an email.public interface MailProducer { Email produce(Execution); }
In my alternate proposal, the template is a separate entity object that represents the configuration. The template is passed to the producer to create an email. The producer thus becomes a control object: it appears to be stateless from the outside.public interface MailProducer { Email produce(Execution, MailTemplate); }
In my current conception, MailTemplate is a concrete class, as emails have a standard-defined structure. The extension points are narrowed to the producer itself.
As soon as we decide on a design, we can jump to work out examples. -
14. Re: schema for mail template and activity
tom.baeyens Apr 16, 2009 3:43 AM (in response to aguizar)"alex.guizar@jboss.com" wrote:
Examples cannot be produced at this point because the syntax and the design have not been agreed upon.
i'm pushing for examples in the example test code exactly because that improves the discussion on the syntax. you work out examples from simple to complex. then we can review."alex.guizar@jboss.com" wrote:
Unlike other activities email has more complex setup and more moving parts. Let us focus on making the design decisions first.
ok. but i think that should be trivial :-)"alex.guizar@jboss.com" wrote:
There are two concepts in play.
* mail template describes the contents of an email
* mail producer takes a template as input and produces a template as output
i think that is already too complex. this is splitting up our implementation to introduce some kind of user pluggability in the middle of our implementation.
check out my alternative MailSession:interface MailSession { Mail createMail(); Mail createMail(String templateName); } interface Mail { Mail setTo(String to); Mail setCC(String cc); Mail setBCC(String bcc); Mail setSubject(String subject); Mail setBody(String subject); Mail addAttachment(String name, InputStream attachment, String mimeType); void send(); }
building that implementation should be the basis. this exposes all the functionality that we want to build on top of JavaMail. this implementation can be leveraged by 1) our mail activity and event-listener 2) task notify and reminder 3) users that want to build custom mail activities programatically.
i don't think it needs to be more complex then that.