[jifty-devel] Upgrading Jifty::Notification to support
jesse at bestpractical.com
Fri Jul 13 15:46:25 EDT 2007
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
> 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,
> 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
>> 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.
>> jifty-devel mailing list
>> jifty-devel at lists.jifty.org
> jifty-devel mailing list
> jifty-devel at lists.jifty.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20070713/941f3f7a/PGP.pgp
More information about the jifty-devel