Dan, I had a big, long response all written up, then got called away before sending it and when I got back someone had sent me a link in IM. So I clicked it and it left Gmail... which means that when I got back the message was gone. Probably just as well... I can say it more simply than I had before:
There's no reason why you can't make the location of the error handler instance a runtime decision, so you can use either an instance in the session scope or one in your BO's instance data. I would create a wrapper manager class that holds separate instances of the actual error instance... if you wanted an error manager base class and a separate extension class for the session scope and for an instance-data based version... I'm talkin theory here, not implementation. I'm not sure if there would be any differences between a session-based and an internal instance-data based version. I'm thinking that having an error object that's distinct from the rest of your system would be a good idea... it's composition at its best, and there's NO reason not to use the session scope, provided you create a means to cover all your bases. And there's some substantial benefits... Just my musings... if I were doing it, it's what I'd be shooting for, at least to start with. Then again, I'm NOT doing it! ;) Anyway, have fun... Laterz, J On Mon, 14 Mar 2005 22:38:00 -0800, Daniel Short <[EMAIL PROTECTED]> wrote: > > I'd suggest you create a basic error object with the methods you've > > outlined above, then cache it in the session scope. > > The thought of putting something like this into a session scope seems like > it would use resources that it shouldn't necessarily be hitting. It makes me > a little nervous to require the usage of a user's scoped object in order for > the object to work. This would basically preclude the use of the component > from any usage outside of the application, since some other application it > might live under may not support sessions (such as a web service or > something along those lines). > > Otherwise everything else sounded great :) > > Dan -- Continuum Media Group LLC Burnsville, MN 55337 http://www.web-relevant.com http://cfobjective.neo.servequake.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
