From: Cor B. <co...@xs...> - 2006-11-14 09:01:48
|
Hi Paul, > - Tentative class that encapsulates a "message". SM already has a > "Message" class that is done at a lower level (basically a parsed > representation of the mime structure of a message), so I named it > "IMAP_Message": it is intended as a higher-level message > representation so anyone (plugins, API, etc) can just instantiate it > with a mailbox and message ID and then do what they need with that > message (retrieve it, delete it, etc). Great! > DISCUSSION POINTS > ################# > > The Smarty thing is irrelevant, but as long as I was sending some > template set, I thought I may as well get the Smarty stuff out there. > Please don't mistake me for a big Smarty advocate, but it is important > to show an example of how to code a Smarty-based skin for > SquirrelMail. Personally I dont find the smarty thing irrelevant. I know this has been discussed many times before, but I still dont quite understand why SM is reinventing the wheel when it comes to templating. Smarty is out there, works, many larger projects are using it and are churning out plenty of themes. It's really not too difficult to use. > * I'd like to have us finish off the Ajax JavaScript stuff and put > it somewhere for template designers to use. What if a plugin or theme wants to add its own ajax javascript? > * There is also a HUGE problem with the SM core in that errors are > almost entirely handled *on-the-spot* by spitting out some error to > the browser. This is entirely unacceptable (not to mention somewhat > naive architecturally) when we are dealing with an API request that > cannot return output in this manner. This is pervasive and rooting it > out from the core will take some serious effort. Before we embark on > that mission, IMO we need to first decide on a better error handling > architecture. Do we let the API just start an output buffer and > capture errors on its own (NO WAY!)? Do we set a special error > handler for the API calls and throw errors from the core that can be > caught and returned in the right format for API clients? Do we > re-write the core to return error messages (an error class object?) > whenever an error happens and make it percolate all the way up through > the core functions so the original caller (the API, for instance) gets > to decide what to do with the error? I believe we should also create > a known set of integer constants for every possible error SM > generates. A better error handling system is very very necessary. Not only the API, also plugins should have access to the error messages and do what they want with it (including nothing at all, or even fix it for the customer in the background). I run a largish SM installation and our number one issue is spurious error messages that customers dont understand. I would love to be able to catch every error message and decide what to do with it. So I agree with a set of integer constants and with a way to percolate error messages all the way back to the original caller. I'll leave the actual API discussion to the SM coders :) Cor |