Yes... ```component restHandler { ... }```
# box-products
r
Yes...
Copy code
component restHandler {
   ...
}
w
In that case can you not just do a
Copy code
super.onInvalidHttpMethod(event….) ?
Just looking at your error but don’t understand where your Page /views/Authentication/signin.cfm is coming from. Is your v1:Basehandler protected in some way?
r
I've tried
Copy code
function onInvalidHTTPMethod( event, rc, prc, faultAction, eventArguments ) {
		super.onInvalidHTTPMethod( event, rc, prc, faultAction, eventArguments );
	}
in my
v1:BaseHandler
I've not knowingly protected it, there's no
secured
in the definition. Is there another way I might have done that? I don't understand where that error message is coming from either!
If I remove my default layout definition it complains about not having a layout
Page /layouts/Main.cfm ... not found
w
This error suggest you have some authentication.signin event somewhere (implicit view) or you specified this view somewhere in your code. You could try to put some debug statement followed by an abort in your onInvalidHTTPMethod handler method. I suspect it is not even hitting this right now, because something else might be wrong
r
Well I have
post( '/signin', 'Authentication.signin' );
in my
Route.cfc
which directs
POST
events to the right place. Obviously that hander isn't secured. I was expecting a
GET
to be caught by the
onInvalidHTTPMethod()
which it is (thank you
writedump()
) but if I try to call the framework
onInvalidHTTPMethod()
it fails as shown.
STOP PRESS
component restHandler {
is not the same as
component extends=coldbox.system.RestHandler {
With
component extends=coldbox.system.RestHandler {
I can use
super
to access the extended component. A design "feature"?
w
I would always use
component extends=coldbox.system.RestHandler
why component resthandler ?? Is that in the manual somewhere?
r
Yes, I must have read it somewhere? Now I've got to find that!
w
Maybe they removed that somewhere in a release.. Not sue about that, never used it.
r
I feel a ticket coming on... Thanks for rubber ducking with me 🙂 rubber duck
w
I would just use this normal extends= . I’ll have a look tonight if i can find where it disappeared.
r
Hummm, I still can't do a simple...
Copy code
function onInvalidHTTPMethod( event, rc, prc, faultAction, eventArguments ) {
	event.getResponse()
		.setError( true )
		.setErrorMessage( 'Method Not Allowed' )
		.setStatus( 405 );
}
in my
BaseHandler
without it complaining that it can't find the view 🤔
w
Ok, calling super.onInvalidHTTPMethod in a rest onInvalidHTTPMethod makes no sense, unless you want to augment the parent handler with some extra functionality. The resthandler annotation as you used it is still there. Only in that case it is not extending the coldbox.system.RestHandler, but just adding methods from the RestHandler which were not there yet, so calling super will not work there. https://github.com/ColdBox/coldbox-platform/blob/development/system/web/services/HandlerService.cfc#L109-L124 I don’t see why your onInvalidHTTPMethod wants to see this view. What happens if you remove the onInvalidHTTPMethod from your basehandler? If you are extending the resthandler the default onInvalidHTTPMethod should still be there and it should DO this;
Copy code
arguments.event
            .getResponse()
            .setError( true )
            .addMessage(
                "InvalidHTTPMethod Execution of (#arguments.faultAction#): #arguments.event.getHTTPMethod()#"
            )
            .setStatusCode( arguments.event.STATUS.NOT_ALLOWED )
            .setStatusText( "Invalid HTTP Method" );

        // Render Error Out
        arguments.event.renderData(
            type        = arguments.prc.response.getFormat(),
            data        = arguments.prc.response.getDataPacket( reset = this.resetDataOnError ),
            contentType = arguments.prc.response.getContentType(),
            statusCode  = arguments.prc.response.getStatusCode(),
            statusText  = arguments.prc.response.getStatusText(),
            location    = arguments.prc.response.getLocation(),
            isBinary    = arguments.prc.response.getBinary()
        );
so some default response for the content type you need.
r
unless you want to augment the parent handler with some extra functionality
Yes, that's what I want to do. Ideally I'd prefer not to copy the framework version of the method into my
BaseHandler.cfc
and adapt it, better to capture the output and alter the contents, like the message, before returning it to the caller.
The resthandler annotation ... is not extending the coldbox.system.RestHandler ... just adding methods from the RestHandler which were not there
An interesting but important distinction that I hadn't realised, thank you - I'll look to add something to the docs.
What happens if you remove the onInvalidHTTPMethod from your basehandler?
• With
component _restHandler_ {
in my
BaseHandler.cfc
and no local
onInvalidHTTPMethod()
it all works as advertised • With
component _extends_=coldbox.system.RestHandler {
the same, as you would expect • With
component _restHandler_ {
and a copy of the framework
onInvalidHTTPMethod()
in my
BaseHandler.cfc
the local version of the method is called as expected • With
component _extends_=coldbox.system.RestHandler {
the same, as you would expect • Now with
component _restHandler_ {
and my own simple local
onInvalidHTTPMethod()
as shown above, I get the view or layout not found error • And with
component _extends_=coldbox.system.RestHandler {
I get the same error • Going back to
component _restHandler_ {
with this locally I get the same not found error
Copy code
function onInvalidHTTPMethod( event, rc, prc, faultAction, eventArguments ) {
	super.onInvalidHTTPMethod( event, rc, prc, faultAction, eventArguments );
}
• But with
component _extends_=coldbox.system.RestHandler {
and the same
super
call it works as you would expect The lesson learnt, as you said,
component _restHandler_ {
is not the same as
component _extends_=coldbox.system.RestHandler {
So, ideally, I'd like to capture the product of the
super
call, change a part of the contents like the message, and return the packet back to the caller. Do you think this possible or am I trying to bend the space-time continuum?
w
Why do you want to modify the
super
call instead of creating your own. There’s only two things happening in this call 1. set some properties of the response object 2. render the response with event.renderData You want to modify nr 1, so different message probably. And you have to do step 2 anyway.
Now I also understand why your own version of onInvalidHTTPMethod is not working. You probably assume your code
Copy code
event.getResponse()
		.setError( true )
		.setErrorMessage( 'Method Not Allowed' )
		.setStatus( 405 );
is rendering a response, because that’s what happening with all your normal responses. The point is: all normal responses are wrapped by the aroundHandler which does a event.renderdata on your prc.response (or event.getResponse() which is the same object). Your own onInvalidHTTPMethod will not be wrapped by this aroundhandler so you have to do the rendering yourself. If you take a look at the box Resthandler you will see that most exception handling ends with a
renderdata()
call. Considering all this I think it is pretty useless to try to capture the onInvalidHTTPMethod of super. Just create your own method which renders correctly and everything will be fine. If you don’t want to recreate this onInvalidHttpMethod in every handler, I would suggest you create your own BaseHandler by extending the coldbox rest handler and extend all other handlers from your own Basehandlers. That’s how we do it here. We also wanted some modifications in the around method and some other exception handling (like the onValidationException). This gives us maximum flexibility. We also wanted to modify the response format, so we created our own Response object by extending the coldbox version. I described this proces here in my blog https://shiftinsert.nl/problem-details-for-http-apis-modifying-your-coldbox-rest-handler-response/ . Actually it is quite simple and described in the coldbox manual here https://coldbox.ortusbooks.com/digging-deeper/rest-handler#extending-the-response-object
r
Thanks for your informative reply. I guess I'm so committed to usual way of extending a method with
super
I always see it as the solution irrespective of the size of the problem. I'll have a sit and think about your other points. I'd certainly like to have control of my own response object. Once again, thank you for your thoughts and advice.