On Monday 27 August 2007, Tobias Schlitt wrote: > Hi Fred! > > 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. Cheers, FreDork -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
