1 2 Previous Next 20 Replies Latest reply on Apr 17, 2009 4:32 AM by camunda

    schema for mail template and activity

    aguizar

      Template:

      <template name='tmpl1' language='juel'>
       <to addresses='alex@jbpm.org, you@jboss.org'>
       <cc actors='theboss, qa-lead' />"
       <subject>mail template</subject>"
       <text>plain text content</text>
       <html><strong>rich</strong> content</html>
       <attachments>
       <attachment url="http://example.com/pictures/diagram.png" />
       <attachment resource="org/jbpm/pic.jpg" />
       </attachments>
      </template>


      Activity:
      <mail template="tmpl1" />

      If template attribute is not present, a template must be specified inline using the same attributes and nested elements as shown above.

        • 1. Re: schema for mail template and activity
          bradsdavis

          How do you determine from that template the implementation of the email producer to use?

          • 2. Re: schema for mail template and activity
            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

              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

                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

                  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

                    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

                      @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

                         

                        "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

                          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

                            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

                              @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

                                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

                                  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

                                     

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

                                    1 2 Previous Next