benefits of using fw.service()?
Henry Ho
What're the reason behind queuing them up, instead of having them
executed right away?
Thanks!
Henry Ho
Sean Corfield
> What're the benefits of using fw.service()?
>
> What're the reason behind queuing them up, instead of having them
> executed right away?
So that the convention-based lifecycle is enforced.
The intention is that you either use:
* controller.startItem()
* service.item() + plus any other queued services
* controller.endItem()
or:
* controller.item() - and call services directly
Some people like the convention-based approach, some like the direct approach.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
Henry Ho
Thanks Sean!
--
FW/1 on RIAForge: http://fw1.riaforge.org/
FW/1 on github: http://github.com/seancorfield/fw1
FW/1 on Google Groups: http://groups.google.com/group/framework-one
Sean Corfield
> If I choose to use
> controller.item() and call services directly, is there a way to disable fw
> calling service.item()?
If you're calling services directly, put them in a model/ folder
instead of the services/ folder.
Julian Halliwell
> Some people like the convention-based approach, some like the direct approach.
FW1 is excellent in so many ways, but the service convention is the
one thing that hasn't made sense to me.
1) I prefer having more flexibility as to where my service methods are
called and what I can do with the results (although I understand
that's always a trade off with conventions: the restriction is imposed
for a reason)
2) The convention seems to tie service and controller methods together
in a way I'm not comfortable with: in my mind they're completely
separate and rarely match in terms of naming (not Sean's experience I
know, and he has a lot more of it than me).
3) The whole "startItem()" "enditem()" sandwich thing just strikes me
as needlessly complex. I prefer the simplicity of just one controller
method within which I call whatever services I want directly and store
the results in whatever variables I want.
To prevent the fw handling them I store my services in a "service"
folder, without the "s". I also make sure my service beans are named
in ColdSpring without "Service", for example <bean id="userSvc">
instead of <bean id="userService">.
I did think of suggesting that the FW have a switch for turning off
the service convention for those who don't want it, to make the FW run
even more simply, but I understand that would probably interfere with
the whole lifecycle process. It's quite possible to ignore it anyway
so the choice is yours as Sean says.
Cheers
Julian.
Sean Corfield
<julianh...@gmail.com> wrote:
> FW1 is excellent in so many ways, but the service convention is the
> one thing that hasn't made sense to me.
Well, that's why it's *optional*.
> To prevent the fw handling them I store my services in a "service"
> folder, without the "s".
Frankly, I'd put them in the model/ folder if I didn't want FW/1 to
invoke them automatically, something like:
model/
beans/
data/
services/
> I also make sure my service beans are named
> in ColdSpring without "Service", for example <bean id="userSvc">
> instead of <bean id="userService">.
If you're not using a bean factory (and a lot of people aren't!), this
doesn't matter.
> I did think of suggesting that the FW have a switch for turning off
> the service convention for those who don't want it
I can see the benefit since if you're using a bean factory and you use
fooService as the convention for your service beans, then FW/1 will
see them and potentially try to call them.
It's always been the part of FW/1 I've not been entirely comfortable
with. I think for folks not used to OO, the convention is easy enough
to use and leads them gently and naturally to using services
explicitly in the controllers as their application grows over time.
Since I'm developing DI/1 to go along with FW/1 2.0, I may remove the
implicit service invocation in 2.0 on the assumption that folks will
use a bean factory (or at least provide the option to remove the
implicit invocation - it's very simple to do).
John Allen
Tantalizing.
--