service call
Scott Conklin
calls inside my controller by calling
public void function service( string action, string key, struct args =
{ } )
i have a logout function defined inside of my controller like so:
function doLogoff(rc){
service('user.RemoveUserSession');
variables.fw.redirect('security');
}
but i get an error that says:
Variable SERVICE is undefined.
the stack trace says it is coming from this line
(.....\myfw1App\org\corfield\framework.cfc line 1301
am i missing something?
Ryan Cogswell
variables.fw.service('user.RemoveUserSession');
"service" is a method in the framework, not in your controller. I
suspect you're also looking at the wrong line of the stack trace and
that there is another stack trace line that refers to your controller
component.
Ryan
> --
> 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
>
Scott Conklin
clears that up; thanks!
Sean Corfield
> function doLogoff(rc){
> service('user.RemoveUserSession');
> variables.fw.redirect('security');
> }
What Ryan said - but also: redirect() does an *immediate* redirect so
no queued services would be executed.
If you want services to run first, you'd need to do this:
function startDoLogoff(rc){
variables.fw.service('user.RemoveUserSession');
}
... services run now ...
function endDoLogoff(rc){
variables.fw.redirect('security');
}
The start/end pair of controller methods wraps the service calls.
--
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
Sean Corfield
> OK, that makes sense... just realized that i did not have to do that in
> application.cfc when i called the controller() function but just now noticed
> that it extends org.corfield.framework.
In theory I could auto-inject the framework's API into your
controller's variables scope but that might conflict with your own
methods...
Scott Conklin
thanks in advance
Sean Corfield
> that makes sense, as a newbie only trying it out since yesterday, i would
> have chased my tail in that one.
NP. That's what we're all here for - to stop tail-chasing early :)
Scott Conklin
so far i am appreciating the simplicity of fw/1 immensely.
Dutch Rapley
Scott Conklin
function startDoLogoff(rc){
variables.fw.service('user.RemoveUserSession');
}
... services run now ...
function doLogoff(rc){
what goes on here; when does it get called?
do i need this?
what would it be useful for?
}
function endDoLogoff(rc){
variables.fw.redirect('security');
}
Dan Vega
variables.fw.service('user.RemoveUserSession');
variables.fw.redirect('security');--
Scott Conklin
from sean:
>>
What Ryan said - but also: redirect() does an *immediate* redirect so no queued services would be executed.
Dutch Rapley
function startDoLogoff(rc){ variables.fw.service('user.RemoveUserSession'); }
function doLogoff(rc){
what goes on here; when does it get called? do i need this? what would it be useful for? }
... services run now ...function endDoLogoff(rc){ variables.fw.redirect('security'); }
function doLogoff(rc){variables.fw.service('user.RemoveUserSession');variables.fw.redirect('security');}
Dan Vega
So don't listen to me, I was just rambling ;) Sorry
--
Scott Conklin
if i were to define doLogoff(rc) what would be something that i could do in there? if i needed to do more than i did in startdoLogooff?
that means i could do this as well? (seems weird to conceive a controller method name and not use it's actual name anywhere)
function DoLogoff(rc){ variables.fw.service('user.RemoveUserSession'); }
... services run now ...function endDoLogoff(rc){ variables.fw.redirect('security'); }
Ryan Cogswell
Sean's intent was that if you needed to do things in the controller
after the service executed, then you would use the start#item# /
end#item# pair of methods, otherwise you would just use the #item#
method. There is no reason to ever use both the start#item# and
#item# methods for the same action. All three of the methods are
optional. Even the existence of the controller is optional.
Ryan
Dutch Rapley
ok, but defining it is optional. so it can be left out.
if i were to define doLogoff(rc) what would be something that i could do in there? if i needed to do more than i did in startdoLogooff?
that means i could do this as well? (seems weird to conceive a controller method name and not use it's actual name anywhere)
Scott Conklin
i like your words: "pre-service" functionality here.
Sean Corfield
The intended usage is _either_:
function startSomeAction(rc){
... do stuff including queuing up services ...
}
... services run here ...
function endSomeAction(rc){
... do stuff with the results of services and/or do redirects ...
}
_or_ this:
function someAction(rc){
... do stuff including queuing up services ...
}
... services run here ...
start/end indicates you are wrapping service calls. The plain
controller action indicates you are not wrapping service calls.
I've talked a couple of times about changing the flow so if startXyz()
is present, xyz() would not be called - and similiarly if startXyz()
was not present, endXyz() would not be called. This would enforce the
style I would prefer people to follow.
But I suspect it would break some existing applications :)
However, since I'm going to change the default behavior for services
in 2.0, I may well change this behavior too (and provide a backward
compatibility flag).
Sean
Scott Conklin
>> However, since I'm going to change the default behavior for services in 2.0, I may well change this behavior too (and provide a backward compatibility flag).
i actually just saw in the samples where there was an implicit service call
service.someaction() and a matching endSomaction(rc) in the controller that is the recipient of rc.data
I sort of liked this flexibility and was actually planning to adopt this style of operation for quite a few of my
controller/service calls. should i not if this is going to change? would this no longer be best practice?
Sean Corfield
>>> However, since I'm going to change the default behavior for services
> in 2.0, I may well change this behavior too (and provide a backward
> compatibility flag).
>
> what will be the new default behavior?
Currently, FW/1 implicitly queues up a service call matching
section.item - in addition to any you queue up yourself. In release
1.2 there is a framework setting - suppressImplicitService - that
let's you turn that behavior off. In 2.0, that setting will default to
true (instead of false in 1.2) so the implicit queuing will not
happen, but you will be able to set it true to enable the
1.2-compatible behavior.
If you want more background, this was discussed in a thread a while
back so I can dig it up for you - and it was also discussed in depth
in the CFUnited BOF session and the proposed change in 2.0 was the
consensus of the FW/1 users present.
> i actually just saw in the samples where there was an implicit service call
> service.someaction() and a matching endSomaction(rc) in the controller
> that is the recipient of rc.data
Yes, I need to update those examples - they don't always follow FW/1
"best practices" because, well, we've evolved the best practices over
time and many of the examples predate current thinking :)
> I sort of liked this flexibility and was actually planning to adopt this
> style of operation for quite a few of my
> controller/service calls. should i not if this is going to change? would
> this no longer be best practice?
Which specific "flexibility"? I think using either the startItem() /
endItem() pair together or just the item() solo method is a reasonable
convention and would encourage everyone to follow that rather than
the, to me, rather weird item() / endItem() pair... 'end' without
'start' just seems... untidy :/
Scott Conklin
If you want more background, this was discussed in a thread a while back so I can dig it up for you - and it was also discussed in depth in the CFUnited BOF session and the proposed change in 2.0 was the consensus of the FW/1 users present.
Which specific "flexibility"? I think using either the startItem() / endItem() pair together or just the item() solo method is a reasonable convention and would encourage everyone to follow that rather than the, to me, rather weird item() / endItem() pair... 'end' without 'start' just seems... untidy :/
I understand that i will be able to do that still in V 2.0, but since it will not be the default and the consensus has said they prefer it to be this way; i will opt to follow the recommendations. I want to be compliant across all lines. My 2 cents (very late to the game) is to say that there was something very nice in writing by convention ONLY the name of service layer call to pick up a form submit and then "catch" the result of that service call in an endAction(rc) handler (OR NOT) where the only thing left to do is to redirect. I save the explicitness of having to write all the controller logic which in large part will be just delegates to a service.
Sean Corfield
> was something very nice in writing by convention ONLY the name of service
> layer call to pick up a form submit and then "catch" the result of that
> service call in an endAction(rc) handler (OR NOT) where the only thing left
I don't have a problem with having just endItem() in the controller
and relying on the implicit service call being queued up (and in 2.0
you'd need to set suppressImplicitService = true to do this).
My objection is to the inconsistency of having item() / endItem()
rather than startItem() / endItem().
Any controller method can be omitted if it would be empty.