Hi Fred! On 08/29/2007 02:25 PM Frederik Holljen wrote: > On Monday 27 August 2007, Tobias Schlitt wrote:
>> I wonder if this is necessary at all? Maybe it is a better solution to >> implement the caching completly transparent to the current >> implementation, by just adding the __set_state() method to ezcMailPart >> and simply serialize the objects to be cached. This way, the complete >> email is cached and can be re-used. >> The mail parts don't need to know if they are cachable. If you just want >> to change the plain-text part, the overhead of restoring this is not as >> large as it would make sense to disable its caching. >> >> What still needs to be done is, that message ID and stuff must be reset, >> which should be up to the user on de-serialization. This way, caching >> can be used more flexible, like building a mail step-wise over muliple >> requests, if someone wants something like this. >> >> We can then offer a backend in the Cache component, which can handle >> objects that implement __set_state(), which we should do anyway, I think. >> >> I'm I misleaded? > Maybe.. or maybe not :D. Can you explain to me how your solution fixes the > case in the original doc, that is... explain exactly what your solution will > do. > original case: >> - Write some multipart mail with attachments. All the mail are the same >> except for the text part where you substitute the "Dear mr. XXX" with the >> correct name from the database. Enabling __set_state() in the ezcMailPart class will allow that you can serialize a complete email-structure to PHP source code using var_export( $mail, true );, as we already do it elsewhere. This way, a user can cache (meaning store on the hard disc) a complete email structure and can re-store it almost in no-time. If you cache the complete structure, it is easy to just replace an ezcMailTextPart in the object tree, adjust some stuff (like message ID) and you are done. I think this is what the issue desires, isn't it? Regards, Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
