2 Replies Latest reply on Mar 15, 2013 6:40 AM by shabari

    Importance of prototype scope for handlers


      Can anyone please share your thoughts on why we should have scope of cartridge handlers as prototype?

      As per our understanding, even though we have multiple handlers that get called for one page request, it is the mdexRequestBroker that is merging all the pre-process requests and then execute method is called on the navigationRequest object for the first time it invoked from the process method of any handler.

      We tried to add multiple refinements in one page having the RefinementMenuHandler scoped at request and observed that there is no difference in the behavior when it was prototype scoped. Also we saw that only one query got logged in the dgraph logs with all the dimValIds.

      So what is the need for having the handlers prototype scoped when there is no data shared?

      Please correct me if I am wrong and let us know the impact (if any) by having the cartridge handlers request scoped.

        • 1. Re: Importance of prototype scope for handlers
          The Endeca cartridge handlers store state in member variables between the preprocess() and process() methods. If you scope Endeca cartridge handlers at a request level, then you will introduce state leakage across cartridges. This is of particular concern when you have multiple instances of the same cartridge type on a single page (e.g. you have multiple refinement menus on your page).

          Endeca cartridges must be scoped at prototype level. Doing otherwise will cause the product to behave erratically.
          • 2. Re: Importance of prototype scope for handlers
            Thanks chip!

            In fact that was our assumption as well initially. But as said in my previous post, we have already tried adding multiple refinements in a page all referring to RefinementMenuHandler which is scoped at request and have observed no difference in the behavior. We have got all the refinements with all the child refinements and observed that there is only one mdex request that is getting fired with all the dimValId's requested for.

            Can you please detail the erratic behavior that can occur by having the cartridge handlers request scoped with an example.