On 08/29/2007 04:48 PM Frederik Holljen wrote: > On Wednesday 29 August 2007, Tobias Schlitt wrote: >> 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? > Hm.. no not at all actually. Since in the case you already _have_ the > structure. No need to get it again. The problem lies in generating the actual > MIME data. You don't want to do that all over again each time. Ah, ok, then I got the problem wrong. Ok, sorry for the noise then! :) 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
