Mark,
great news to see what's coming :-)
I think, the collection with email address and display name would be enough.
perhaps there could be a helper method to change a collection with only
email addresses into the collection with both (putting the part before @
into the display name)
then you have only to maintain the collection with both fields
ekke
Mark Proctor wrote:
I've split the subject/body into it's own tab, so now I have a headers
tab and a body tab. The reason for this is the list of recipients
currently is for fixed recipients, yes there is variable interpolation,
but one row is one recipient. However there may be cases there the
recipients are in a Collection, for this I was thinking of having a
derived recipients list where the expression must return a collection.
Now the Q is what does that Collection maintain? It could just be a
collection of string email address, but what about display name? I think
we can can do two things. One create an interface can return the email
and optional display name, and the collection must contain entries of
this interface. The other alternative, and we can do both (but it means
a gui for each idea, including the existing fixed) is to allow two
collections to be used, one is a collection of strings representing the
email addresses the other is a collection of strings representing the
display name and it'll iterate over both in parallel. so any ideas? I
have a feeling that in trying to fit most expected requirements I maybe
making things too complex.... what do people need?
Mark
Mark Proctor wrote:
> I'm just working on a email gui for ruleflow. The idea here is a
> special action node for ruleflow where the variables used for the
> email action are determined by the rule LHS constraint, furhter more
> the email action GUI will execute for each matched tuple (row) of
> data. Nearly all fields will be processed as an MVEL template and thus
> its content will be interpolated if variables are used. Anyway looking
> for some feedback on initial GUI layout. Also any ideas on how best to
> impl error handling, I was just going to allow a logger to be
> specified, think it should do anything else? Are there any more
> JavaMail fields I should be exposing that would be useful?
>
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
View this message in context:
http://www.nabble.com/mailer-gui-tf4621876.html#a13206602
Sent from the drools - dev mailing list archive at
Nabble.com.