[Design of JBoss jBPM] - Re: HTML Formatted Emails
by alex.guizar＠jboss.com
"kukeltje" wrote : The webarchive/ear/AS classpath should be one as well. Hierarchical just like with actionhandlers
Right. We can use relative URLs for this as well. If the resource is not present in the archive we look in the classpath using the context class loader.
As an alternative, we can use a classpath: prefix as in Spring.
classpath:some/resource/path/myTemplate.txt
anonymous wrote : The difficulty we encountered once is images from css (e.g. background etc). Those needed real file references afaik. I'm just not sure anymore if that was the apache mail component or the sun 'flyingsaucer' html->pdf renderer (would be a nice addition though)
We can deal with more specific problems like this later on, or count on the help of someone in the community -wink, wink-.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224203#4224203
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224203
15 years, 8 months
[Design of JBoss jBPM] - Mail session configuration
by alex.guizar＠jboss.com
Here is the preeliminary format.
<mail-session>
| <mail-server>
| <address-filter>
| <include>.+(a)jbpm.org</include>
| <exclude>.+(a)jboss.com</exclude>
| </address-filter>
| <session-properties>
| <property name='mail.host' value='localhost' />
| <property name='mail.user' value='aguizar' />
| <property name='mail.from' value='noreply(a)jbpm.org' />
| </session-properties>
| </mail-server>
| </mail-session>
Some notes:
It is not particularly easy to make the address filter implementation pluggable, and the usefulness of a filter other than a pattern matcher is doubtful. So I have turned the AddressFilter interface into a concrete class, and absorbed the functionality of WildCardAddressFilter.
Element session-properties is parsed via PropertiesBinding, so properties can be read from an external file, resource or URL as well. The properties are used to create a javax.mail.Session
Multiple mail-server elements can be specified.
MailSessionWireTest was added to test correct parsing
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224187#4224187
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224187
15 years, 8 months
[Design of JBoss jBPM] - HTML Formatted Emails
by bradsdavis
I am working on HTML emails. This would be for stylized emails within companies.
The first stab is: org.jbpm.pvm.internal.email.producer.impl.HtmlScriptMailProducer.java within the email_branch.
The class allows a user to populate the field "html", and will run through the HTML embedding images into the message as attachments, replacing URLs for the images with cid: references.
Also, this extends the Script Email Producer, which allows the subject, body, and now HTML to resolve fields using the ScriptManager from jBPM.
I would like to add template support for emails [both HTML and non-HTML emails]. I am currently looking at alternatives to the JBPM 3.x email template implementation. While the 3.x solution worked quite well for textual emails, I would like to package templates such that rich templates containing images and HTML could be available to JBPM.
Has anyone given any thought to how to package rich templates in JBPM yet?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224152#4224152
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224152
15 years, 8 months
[Design of JBoss jBPM] - Re: jBPM 4 Emails Sync vs Async
by tom.baeyens＠jboss.com
"bradsdavis" wrote : When you write something to intentionally limit the scope, some client will inevitably need the functionality that you are limiting. If you write something that is open and flexible, clients will find uses for it that you never even thought of.
|
| With that in mind, if both cost the same as far as time, I am just saying side with the flexible approach rather than the limiting approach.
i'm differentiating between MailSession and the jpdl features.
MailSession is an api that mainly should be used by our jpdl implementation intenally.
jpdl features documented in the userguide must be stable. so that's why i want to go slowly on that front. i am ok with adding lots of jpdl features and only documenting them in the developer guide. consider this kind of incubation system inside of jbpm. the ultimate target of jpdl is that it will have stable, flexible and lots of features documented in the userguide.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224088#4224088
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224088
15 years, 8 months
[Design of JBoss jBPM] - Re: jBPM 4 Emails Sync vs Async
by tom.baeyens＠jboss.com
"bradsdavis" wrote : I dont see the benefit of limiting the email producer to one email.
|
| To code that in jbpm 3 would mean creating a dynamic fork, and forking over the email node multiple times, or creating a loop in the process and looping over for each person.
|
| Not only is this inefficient [multiple forks or looping would produce a lot more records in logging, more records for tokens, etc] versus just allowing the email node to produce multiple emails, it is also messy looking in the process definition.
|
| If we get a generic service for sending email for free, why not? It is free, and it allows much more flexibility.
this MailSession does not limit the jpdl email language features that we want to build on top of it.
we could still have something like eg
<mail to-groups="sales-dept, #{claim.type.department}" send-individually="true">
| ...
| </mail>
and internally, the mail activity can translate that to first obtaining all users to which this email is to be sent. and then send a mail with the MailSession for each user that is supposed to receive a mail.
the main point i try to make is that the jpdl attributes and behaviour is decoupled from the MailSession interface.
buiding out the jpdl language attributes is the biggest challenge imo. we should not introduce attributes lightly. after we release GA, we cannot just remove, change or rename attributes.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224087#4224087
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224087
15 years, 8 months