On Mon, Oct 20, 2008 at 8:23 PM, Matthew <[EMAIL PROTECTED]> wrote:
> 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)?
Sorry, wasn't very clear, was I? Something needs to do the dirty work
of taking a user's email address and returning a user object.
Ultimately it'll be a query to the database, but I'm talking about a
method call on some object. Since that has nothing to do with
emailing a user their forgotten password and could easily be used for
other things (linking friends together, for example), it belongs in
it's own spot. At some point your "forgot password" workflow will
delegate to that conceptual method. Here's a sample controller
(stripped, of course):
try {
user = thing.getUserFromEmail(form.email);
service.emailUserPassword(user);
location("success.cfm");
} catch (UnknownEmailAddressException e) {
location("form.cfm?message=invalidEmail");
}
Constrast this with the in-service invocation. Here's the controller:
try {
service.emailUserPassword(form.email);
location("success.cfm");
} catch (UnknownEmailAddressException e) {
location("form.cfm?message=invalidEmail");
}
and here's emailUserPassword:
function emailUserPassword(email) {
user = thing.getUserFromEmail(email);
// do the email thing
}
The point is that these are exactly same, the only difference is the
type of the param passed to emailUserPassword and where the "user =
thing.getUserFromEmail(email);" line goes. I've intentionally named
the container of that method "thing" to imply nothing about it.
Chances are good it's "userService" or something, but who knows.
cheers,
barneyb
> 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/
> >
>
--
Barney Boisvert
[EMAIL PROTECTED]
http://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
-~----------~----~----~----~------~----~------~--~---
