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 > [email protected] > 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. _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
