Another question: do you need to VAR session variables in the listener layer (I'm aware of the session facade - but lets keep it simple for now)?
On Oct 21, 2:23 pm, Matthew <[EMAIL PROTECTED]> wrote: > Hi Barney > > Thanks for the response again. I realised after I wrote that session > question that the service layer shouldn't do it - thanks for > clarifying. > > Regarding your second point: I'm not sure I follow your explanation - > what does "inflate" mean? Perhaps I'll try to re-ask the question. Q: > When a user login form is submitted should the service layer validate > the email address (perhaps delegating this task to a UDF object)? > > Regarding the original Q: I'm starting to get it now. So the business > objects just throw an exception and leave it for the UI layer to deal > with it. That would mean if your app was using Mach-II you'd catch it > at the listener level and perhaps do nothing, or log it, and/or > redirect to a new event etc etc. Where as if your app was invoking > this service layer via a web service layer (which is the UI) than the > web service layer would need to trap the exceptions and handle them > accordingly e.g. pass a coded error back to the web service invoker. > > I'd be interested to see if others agree with this solution? > > Cheers > Matthew > > On Oct 21, 11:38 am, "Barney Boisvert" <[EMAIL PROTECTED]> wrote: > > > The successful return of the emailUserPassword() service method would > > indicate that it's been sent. If there were a problem sending it, an > > exception would be raised. > > > The service layer shouldn't know about the session scope, that's a UI > > construct as it's bound to HTTP. Consider if your service layer > > accepts both requests from an HTTP UI (accessed via browser) and a JMS > > buss via an event gateway. No sessions with the latter, so your > > service layer shouldn't depend on them. If you need to track user > > state, that happens at the UI layer. > > > For #2, I'd expect emailUserPassword() to either be passed a valid > > user (in which case your scenario can't happen), or be passed an email > > address to "inflate" via a call to some inflation method. In the > > later case, that inflation method (wherever it lives) would > > undoubtedly raise a InvalidEmailException or something if it can't > > find the address which the emailUserPassword() method would ignore and > > let bubble back up to the UI. So in either case, it's the controller > > that has to deal appropriately with that exception, and the actual > > notification method is unaware that it can even happen. I'd lead > > towards the first approach, where the controller inflates the user > > first, but that's personal preference. > > > cheers, > > barneyb > > > On Mon, Oct 20, 2008 at 5:16 PM, Matthew <[EMAIL PROTECTED]> wrote: > > > > Exceptions are meant to be used when there is a problem, so what if > > > you wanted to pass a message e.g. lets say someone has forgotten their > > > password so that submit their email via the "Forgot my PW" form and > > > when the service layer fires off the email with the pass (or perhaps > > > passes the task to a notification object... but let's keep it simple > > > for now), so how would you pass back to the view that the password has > > > been sent? > > > A few other questions: > > > 1. Would you push/copy/inject the User bean into the session scope at > > > the service layer? > > > 2. Would you do the form validation at the service layer e.g. validate > > > that they have typed in a valid email (this makes sense to me because > > > why bother instantiating a BEAN/DOA if they haven't even entered a > > > valid email)? > > > > Cheers > > > Matthew > > > > On Oct 21, 10:26 am, "Barney Boisvert" <[EMAIL PROTECTED]> wrote: > > >> For both of those cases, I'd use an exception. The UI layer can catch > > >> the first one and reprompt for the username. The second one should > > >> probably just bubble all the way up to the global onError handler, > > >> since the app is dead without the DB, at least for processing logins. > > >> By the time gets to the service layer, all your user validation should > > >> be complete. As such, if an error comes up that the service layer > > >> can't handle by itself (e.g. something besides a transaction > > >> deadlock), it's fatal to the service layer and bubbles out. Maybe the > > >> UI layer handles it (like invalid username exceptions), or maybe not > > >> (like database is dead), but the service layer needn't care. > > > >> cheers, > > >> barneyb > > > >> On Mon, Oct 20, 2008 at 4:23 PM, Matthew <[EMAIL PROTECTED]> wrote: > > > >> > Hi everyone > > > >> > How are people managing messages in their OO code i.e. how do you pass > > >> > errors or comments from a component which is deep down in the business > > >> > layer - say perhaps from a DAO back up to the view. I've had a look at > > >> > various projects which I've downloaded and seen that some people use > > >> > CFTHROW type=application which means that this can be picked up at the > > >> > top level (but it seems odd to me because it is making the assumption > > >> > that some other object / code will pick it up i.e. it is not > > >> > explicitly saying "I had an error"). Some other projects built arrays > > >> > of messages and returned this. But how would you use such an array > > >> > solution if you were wanting to pass a bean as well as the array (I > > >> > guess you would have to return a structure with the array and bean > > >> > inside)?. > > > >> > Perhaps an example would help, so let's take a very common user-login > > >> > scenario > > > >> > 1. User enters email/password. > > >> > 2. Controller/Listener passes form vars to service layer. > > >> > 3. Service layer invokes BEAN and passes it to the DAO for population. > > >> > ERROR TYPE 1: user not found (Q: So how would you pass this ERROR back > > >> > to the view.). > > >> > ERROR TYPE 2: DB error (Q: Perhaps there was a table error or DSN > > >> > error or database was down. So how would you pass this ERROR back to > > >> > the view. Obviously you would want to email the administrator with the > > >> > specific error as well as provide a generic message to the user). > > > >> > Cheers > > >> > Matthew > > > >> -- > > >> Barney Boisvert > > >> [EMAIL PROTECTED]://www.barneyb.com/ > > > -- > > Barney Boisvert > > [EMAIL PROTECTED]://www.barneyb.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
