Customer Portal

Get Involved. Join the Conversation.


    Bastiaan van der Kooij
    Widgets view gets rendered for an Ajax request - Bug..?
    Topic posted June 8, 2016 by Bastiaan van der KooijGold Crown: 30,000+ Points 
    413 Views, 15 Comments
    Widgets view gets rendered for an Ajax request - Bug..?

    I am experiencing some real strange behavior with the Ajax handling of Widgets. Suppose you have the following setup;

    Parent Widget
    Child widget in the view of the Parent Widget

    The Parent Widget makes an Ajax call to its own controller using the standard Widget Ajax handling setup.

    All is fine in development, but once you switch to staging a very informative(.....) 500 internal error is thrown for the ajax request. When you remove the child widget all is fine (that's not where you search first.... ). So that means that the view is rendered for an Ajax request..?? And if it is rendered why does it not render ok? I stripped down the child widget to nothing and still an error.

    I guess the big issue is that the view of the widget should not be rendered at all for an ajax request. I start wondering about speed sensitive stuff I build like Auto Suggest, whereby the whole view is rendered for each request...??


    Nov 2015



    • Scott Harwell

      If you're worried about the view rendering on an ajax call, then you can probably echo your JSON output and then call exit() in the controller which would prevent the view from rendering in any case, or create an Ajax-specific view renderer when the content type is "application/json".  Since the controller of the widget is likely unaware of the type of the request, unless you specifically code it to be aware, then I think this is likely expected behavior.

      Regarding the 500 error...that is odd.  Perhaps you can wrap the entire controller method in a try/catch block and try to output an exception.  Normally, I see hiccups in the JS that gets minified in prod, but since this is happening on request back to the server, it sounds like something else is getting in the way.  If you use a tool like Postman to post data to the controller, does it give you the 500 error as well?

    • Bastiaan van der Kooij

      hey Scott,

      I do not see any scenario where you would want to render the view for an Ajax request. That is just a waste of resources. I would expect the standard Widget function in the Ajax controller to only call the Ajax function in the widget controller and not render the view at all.

      I have tried to catch everything; parent and child controller (init, getdata and ajax function) but I cannot catch it, it seems to be happening in the standard Ajax controller. Furthermore I still get an 500 error when I have on top in getData():

      if (\RightNow\Controllers\Base::isAjaxRequest())
          return false;

      I also tried the same if statement in the view to exclude the child widget when it was an ajax request, but still 500 error. The problem is also that debugging takes a lot of time since you need to deploy it all the time.... :(

      I have removed the child widget now for production so we can continue, but I think I'll create a ticket for Oracle anyway to get them have a look at this..


    • Scott Harwell

      Hi Bastian, Most web MVC frameworks supply views for Ajax requests. You're making an assumption that all Ajax requests use JSON as the response, which is not the case. You might have to render JSON, XML, HTML, or something else depending on the request, and a view let's you format the data for an Ajax request using proper MVC paradigms; your controller is responsible for brokering the info while the view is responsible for providing the returned data to the browser. The controller can be agnostic of the request type. OSvC's examples of outputting Ajax request from the controller could be considered bad practice if you're and MVC purist.

    • Bastiaan van der Kooij

      Good point. However when trying to adhere to the typical structure of the OSC Widgets, Ajax data is sent via Json and rendered using JS templates. The duplication of views and JS templates in standard widgets is not that nice either, but I tend not to run into those issues. Sending pure JSON via Ajax is performance wise nice though.

      Anyway the thing is, suppose I would like to render the view and return that for the Ajaxrequest, then I should call render myself using the Ajax data and return the results in the Ajax response. The main Ajax controller should not do this standard, when say 99% of the times it is not needed and not used.

      The issue here is ofcourse that you might have a big query running for the initial view and then you setup a nice slim fast Ajax call for some tiny bits of data and unaware of anything, for each tiny call the huge query is run....

      Assuming ofcourse that the view is rendered by the main Ajax controller, but that seems to be the case based on the issue I have.

    • Bastiaan van der Kooij

      got me thinking to do a quick test.

      Added sleep(5) to the getData function: Widget loads slow but has no effect on the ajaxcall. So although the view might be rendered it is not calling the getData function to provide it the initial data, which is good.

      Added sleep(5) to the view: Widget loads slow, no effect on the ajax call.

      So is the view then rendered at all?? Since otherwise you might expect the call to be slow in any of the two situations. Apparently it is not rendered, so why does the ajax call fail then when the view has a child widget.....??

    • Bastiaan van der Kooij

      Ok Oracle considers it a bug and they'll fix it. In the meantime no child widgets ...:(

      This issue has been identified as a software defect which has been assigned to our product development department. The defect will be scoped and corrected in an upcoming version of Oracle Service Cloud.
      The issue occurs when one custom widget is used inside another custom widget.
      As a workaround, we should not include custom widgets inside a custom widget.
      After scoping the fix, Development will schedule the work and determine the target release. The target release depends on the severity of the defect and the significance of the necessary code changes.
      We do not yet have a date on which you can expect a fix in a new release but we will update this service request again in the future when the solution has been included in a new production release that is available for upgrade. 
    • Scott Harwell

      Very strange!  Thanks for posting the infor from CC.  Hopefully you'll hear back when the patch is applied.

    • Dietrik

      That might take some time....

    • Bastiaan van der Kooij

      not too cynical now Dietrik ;)

    • Dietrik

      Keep the faith. At least you received a reply pretty quickly.

      And a nice workaround: "As a workaround, we should not include custom widgets inside a custom widget."

    • Bastiaan van der Kooij

      hehe, yeah it is a intelligent work around I'd have to say, similar to;

      Customer: 'I cannot log in'

      CS: We identified this as a defect, as a workaround do not log in.

    • Rajan Davis

      Just curious, but is this an error exclusive to framework version or is it something that has always existed?

    • Bastiaan van der Kooij

      well the ajax calls for widgets did not exist in V2. I only know that V3.3 has this issue, but I assume that any V3 has the same issue..

    • Chris Story


      I am experiencing the same issue and we are upgrading from V3.0 to V3.3.  During our UAT, we noticed 500 errors on the AJAX requests for our custom widgets that had a custom widget as its parent.  Thank you for reporting it to Oracle and I will be very happy when it is fixed.

      We are going to go back and find out what version of the framework introduced this error and I will report back.  Seems like we may be in the business of not going to all the way to V3.3 or will be doing some code rework :(.  Thanks for your help and diligence with the blog!

    • Narendra Muttineni
      Bastiaan van der Kooij said:

      well the ajax calls for widgets did not exist in V2. I only know that V3.3 has this issue, but I assume that any V3 has the same issue..

      View original

      Well, the Ajax calls for widgets are working fine in V 3.2. Recently I did the migration from V2 to V3.2 and I don't see any issues with the Ajax calls. I have seen the Ajax calls issues with the V3.3 widgets only.