On Jan 15, 2008 2:15 PM, Peter Bell <[EMAIL PROTECTED]> wrote:
> Hi Brian,
>
> I'll disagree with you here. The calling code has to know three things:
>
I think you're agreeing with me and you don't even know it. ;-)
>
>
> - How to pass information to the service in the format it wants
> - How to tell whether the save succeeded
> - How to pass any error messages in a way the display will want to
> see them (actually, it'll probably just be a conduit for the information,
> so
> it is more likely the view will have to know this).
>
>
> It needs to know how to pass well formed data to the service otherwise the
> save won't work. It needs to tell whether the save succeeded as otherwise it
> won't be able to make the controller decision to say whether to cflocation
> to another screen or to redisplay the form (or whatever approach you're
> using), and it needs to pass the errors along in a way the view can
> understand as otherwise the view won't be able to display the correct error
> messages.
>
Absolutely, in my example this is what the result object that is returned
would be used for, as you show in your second example below. The controller
would do:
result = myService.saveUser(userData);
if (result.isSuccess()) {
cflocation
}
else {
data = result.getOriginalData();
errors = result.getErrorMessages();
redisplay form;
}
>
> So, whether you make it:
> If UserService.isValid()
> UserService.save();
> location("UserList");
> Else
> Display Form
>
> OR
>
> Success = UserService.Save()
> If Success
> location("UserList")
> Else
> DisplayForm
>
> (o rmore likely, a variant where "Success" is really ErrorCollection and
> you test whether ErrorCollection has any members, or is ErrorBean and test
> whether ErrorBean.hasErrors())
>
> In any of these cases you are performing both a command and a query. The
> command is to save the data and the query is whether it was saved
> successfully. Nothing wrong with turning that into a single mixed method
> call (some purists might say you should keep commands and queries separated,
> but I'm not that picky), but it isn't reducing the amount of information
> required or the knowledge of the API. You're just doing the command and the
> query in a single line so it isn't making the controller any dumber – just
> more concise.
>
Well, it's also ensuring that it isn't the calling code's responsibility to
run the validation. If my controller doesn't call isValid(), won't that save
invalid data? It will, unless you force the validation again, internally, in
the save() method anyway. Which defeats the purpose of having the controller
call isValid() anyway, doesn't it?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
