[jifty-devel] Upgrading Jifty::Notification to support multipart/alternative

[Jesse Vincent]

On Jul 13, 2007, at 11:47 AM, Andrew Sterling Hanenkamp wrote:

> Multipart email is too damn confusing. ;)
>
> I prefer the idea of keeping everything together in a single
> Notification class, but with the added ability to create attachments
> and separate text and HTML bodies.
>


We're definitely sticking with one notification base class that can  
support all three variants, depending on which notent your subclasses  
provide. It's mostly jsut a matter of how that particular class is  
built.

Best,
Jesse

> In addition I'd be supportive of and would be willing to help
> contribute code that would automatically translate an HTML
> representation into a fairly typical text body (i.e., change bullets
> into formatted "*" lists, numbered lists into the equivalent text,
> etc.).
>
> It seems like something like this would be easier if Notifications
> were always handled by the same class: A new user mixin that would add
> a "preferred_format" column to remember "no preference", "text only",
> or "HTML only" would be a great addition as well.
>
> On 7/13/07, Jesse Vincent <jesse at bestpractical.com> wrote:
>> Tonight, ternus committed the first steps to jifty getting nice,
>> simple multipart/alternative mail notifications.
>>
>> But it's going to require some refactoring to do right.
>>
>> trs' initial thoughts:
>>
>> #bps.07-02.log:18:50 < trs> ternus: I'm looking at
>> Email::MIME::CreateHTML and I'm
>>   thinking we don't actually want to use the create_html method it
>> puts in Email::M
>> IME.  I think we want to use it's methods to build the parts and
>> email ourselves s
>> o we have finer grain control of the message it builds (this is
>> something we'd do
>> in Jifty::Notification::parts)
>> #bps.07-02.log:18:52 < trs> ternus: that's if we want to keep plain
>> text and html
>> stuff in Jifty::Notification.  alternatively we could make
>> Jifty::Notification::HT
>> ML which uses create_html as-is and always sends an HTML part.
>>
>>
>> As I started to look at the existing code, it looked like we might
>> want to separate out "parts"  into "body" and "attachments".  If we
>> have only an html_body, we'd generate an html message. Only a
>> text_body, we'd generate a plaintext message.  If we had both, we'd
>> generate a multipart/alternative like $DIETY intended.   No matter
>> what, we'd attach ->attachments to the message.
>>
>> Thoughts? opinions?  Whatever we do likely needs some refactoring and
>> some new tests.
>>
>> -jesse
>>
>> _______________________________________________
>> jifty-devel mailing list
>> jifty-devel at lists.jifty.org
>> http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
>>
>>
>>
> _______________________________________________
> jifty-devel mailing list
> jifty-devel at lists.jifty.org
> http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20070713/941f3f7a/PGP.pgp