[Search and Autocomplete] Autocomplete - Behaviour doesn't match lesson

Hi.  Thanks for the component and the detailed documentation.  However, I am getting stuck in Lesson 3 at the point where DocumentSearch web block is supposed to show an error due to a missing Notify event.  I have no such error and I also can't find anything in this or the previous lesson that placed any kind of widget into the DocumentSearch web block or parent web screen that demanded a Notify event handler.

I am not an expert on the events subsystem but I would have expected that we should have put an EventHandler in the DocumentSearch web block and perhaps in the parent web screen.

I downloaded the lesson code and, strangely, it doesn't seem to contain much of what we did in the lesson 3, so that didn't answer the question unfortunately.

Are you able to state in general terms which widget in the DocumentSearch or parent screen is expecting a Notify event handler?

Hi. I would suggest that you take a closer look on the code from lesson 03. Specially the action SelectDocument from the web block Results.



This action is invoked whenever the user selects a document, and all it does is to invoke a NotifyWidget handler with an event argument (the selected document id).

Please, note that this exception is a necessary trick for making ServiceStudio recognize that the web block can trigger a NotifyWidget. I believe this is the source of your confusion, specially because it is explained on the Event System help (search for Faking a Notification). There could be other alternatives to the exception handler that achieve the same goal.

When you create that code (including the exception handler), your web block will require a OnNotify event handler, everytime you use it. Thus the error that is mentioned on the lesson 03.

The next step on lesson 03 is to build the generic web block DocumentSearch. This web block uses the Results web block, so it needs to bind something to its OnNotify. But the DocumentSearch is still supposed to be generic, so we simply bubble up the event. Bubbling the event means that we don't want to handle the event, so we let it through to be handled by the next widget. This is the code of SelectDocument from the DocumentSearch web block:



This exception handler is also necessary, for the same reason as before. And, when this code goes into the DocumentSearch web block, you will be required to handle the OnNotify whenever you use the DocumentSearch web block. If this is not happening to you, then you are probably missing that exception handler.

Again, you can see all of this code on the downloadable lesson.

As far as I can tell, the problem starts in Lesson 3 at the end of section 4, where it says "You will notice that the application will contain an error. This is because we must define how the screen would react to the event triggered from the Results web block. But, before we do that, let's do a little refactoring." 

The application doesn't contain an error at that point.  I suspect because the parent screen is not aware that there is a Notify action that it needs to respond to.

Looks like our replies crossed.  It seems that I am trying to jump across too many steps of understanding at once.  I think my question comes down to this:  How do I tell the DocumentSearch web block and/or the ultimate parent screen to know about the Notify event in order that I can set a screen action to handle that event?  It doesn't seem to know about that automagically.

I will ready your comment above, and the Event system documentation it refers to, again in case I can answer this myself. 

Is there any actual documentation for the Autocomplete component (aside from the tutorial)?

I sure do appreciate your very quick and detailed response, esp during the weekend.

You're right, Service Studio doesn't understand magically. Hence, you need the exception handler which I talk about above. It basically puts a NotifyWidget invocation inside dead code.

The documentation for the component is the tutorial itself. I expect to write more lessons, but time is scarce at least for now.

You could also use the Notify from 9.1 (which works server-side) instead of using Event System altogether. You could encode the document id on the Message argument of the Notify action. You would need to downcast the NotifyGetMessage() to get the document id back.

I'm attaching the Lesson 03 code, rewritten by using the 9.1 Notify action.

OK that is indeed the key point I was missing - thanks again.  At least I was barking up the right tree.

And thanks for taking the time to upload Lesson 3 using Notify.  Really beyond the call of duty, and much appreciated.

I am clearly a novice on the "events" component and I need to go study that some more because I'd really like to benefit from the tools it provides.  In the meantime, out of interest, would it also have been possible for me to just use Trigger and the EventHandler to bubble these messages up thru the web blocks to the parent screen (including having access to the Entity Identifier via ProvideArgumentEntityIdentifier)?  I tried to hack around with that without success, but it would help my understanding if you could confirm whether that is indeed a viable alternative approach.

Yes, it is possible, the EventHandler works in the same way.
But to invoke it you would need its Runtime Id (or at least the Id of some parent container). So the problem of using an EventHandler is that you don't have its Id, when you need to launch the event (on the Results web block). If you could work around that problem (e.g. putting its Id on a session variable), it would indeed be possible to use EventHandler, even with event arguments.

And just like that it started to work.  Thanks again.