[Seaside] Registering a WARequestHandler

[Johan Brichau]

Hi Jupiter,

I see what the idea is now. A handler is being registered in the WAApplication for which the url is passed to a JS script.
You need this url, which is not working anymore.

So, the code for this indeed stopped working in Seaside 3.2 because the way caches work was changed [1]. 
More precisely, the issue is that the session cache (where you want to register this handler) is not a bidirectional cache anymore that supports lookup of the session key by means of the handler, which is what the code you use tries to do when you ask for the url of the registered handler.

You need to take an approach similar to how the retrieval of the url of a WASession instance was changed in Seaside 3.2.
The url for a WASession instance can now be produced by the WASession instance itself. 
Take a look at WASession>>basicUrl which was introduced to ‘fix’ the fact that the session cache cannot respond the url for a handler (i.e. session) anymore.
A WASession instance now stores its key, so you do not need to look it up via the cache. This key is stored when the session is registered in the cache.

So, my take on this would be to see of you can change the PREditorHandler such that it can give you the url similar to how it’s done for WASession.
It should be as simple as keeping the key in the handler and implementing the url retrieval method similar to the one in WASession.

Hope this helps you on your way.
If there is some codebase I can load easily with a script that exposes the problem, I can try to help as well. Though I guess it should be relatively easy to adapt the code to Seaside 3.2.

cheers,
Johan

[1] https://github.com/SeasideSt/Seaside/issues/262 <https://github.com/SeasideSt/Seaside/issues/262>

> On 1 Feb 2017, at 12:33, Jupiter Jones <jupiter.jones at mail.com> wrote:
> 
> Hi Johan,
> 
> Thanks for the reply.
> 
> I’m working on getting Pier working in 3.2 and the PREditCommand registers it’s handler like:
> 
> updateRoot: aHtmlRoot
>  | handler |
>  super updateRoot: aHtmlRoot.
>  PREditorScripts default updateRoot: aHtmlRoot.
>  handler := PREditorHandler on: self context copy sanitize.
>  aHtmlRoot javascript
>    add:
>      'EditorEnh.linkOptionUrl='
>        ,
>          (WACurrentRequestContext value registry
>            register: handler;
>            urlFor: handler) asJavascript
> 
> I found a similar thing in MAFileModel, and in the registry test, so I thought it was a legitimate way of doing things :)
> 
> What’s the preferred way of achieving this?
> 
> Thanks again.
> 
> J
> 
>> On 1 Feb 2017, at 7:09 pm, Johan Brichau <johan at inceptive.be> wrote:
>> 
>> If you need to ‘mess’ with this part of the code to achieve a simple registration of handlers, I think there is something wrong :)
>> 
>> Before taking a look, I want to understand what is going wrong and why you are doing this.
>> Why are you registering a handler in the updateRoot: method?
>> 
>> Johan
>> 
>>> On 31 Jan 2017, at 22:37, Udo Schneider <udo.schneider at homeaddress.de> wrote:
>>> 
>>> I hit a similar problem when dealing with Files in Magritte/Seaside. I kind of (re-)implemented WAApplication>>#urlFor: in my own component based on WARegistry>>#urlFor: . Not quite sure if the code is "legal" - but it works:
>>> 
>>> My code in your example might look like this (not tested):
>>> 
>>> updateRoot: anHtmlRoot
>>> 	| handler |
>>> 	super updateRoot: anHtmlRoot.
>>> 	handler := MySubclassOfWARequestHandler on: self.
>>>      registry := self requestContext registry.
>>>      url := registry url.
>>>      key := registry register: handler.
>>> 	registry trackingStrategy addKey: key toUrl: url.
>>> 	
>>> 
>>> Hope this helps.
>>> 
>>> CU,
>>> 
>>> Udo
>>> 
>>> 
>>> On 31/01/17 21:47, Jupiter Jones wrote:
>>>> I’m having an issue registering a handler in Seaside 3.2 that I’m hoping someone will recognise.
>>>> 
>>>> In the test "WARegistryTest>>testUrlFor” a handler is registered with an instance of WARegistry by simply creating a WARegistry with "WARegistry new".
>>>> 
>>>> In my app I’m doing something like this:
>>>> 
>>>> updateRoot: anHtmlRoot
>>>> 	| handler |
>>>> 	super updateRoot: anHtmlRoot.
>>>> 	handler := MySubclassOfWARequestHandler on: self.
>>>> 	url := WACurrentRequestContext value registry
>>>> 		register: handler;
>>>> 		urlFor: handler.
>>>> 
>>>> …however "WACurrentRequestContext value registry” answers my WAApplication instance, which overrides  #register: from WARegistry for registering sessions - not handlers.
>>>> 
>>>> So…
>>>> 
>>>> I tried copying the way WARegistry>>register: does the registration into my method:
>>>> 
>>>> updateRoot: anHtmlRoot
>>>> 	| handler |
>>>> 	super updateRoot: anHtmlRoot.
>>>> 	handler := MySubclassOfWARequestHandler on: self.
>>>> 	anHtmlRoot application cache
>>>> 	    store:
>>>> 	      (handler
>>>> 	        setParent: anHtmlRoot application;
>>>> 	        yourself).
>>>> 	url := WACurrentRequestContext value registry urlFor: handler.
>>>> 
>>>> Which appears to store the handler in the application cache (instance of WABulkReapingCache).
>>>> 
>>>> However, when I call "WACurrentRequestContext value registry urlFor: handler” it ends up calling “WABulkReapingCache(WAExpiringCache)>>keyAtValue:ifAbsent:” method which calls #shouldNotImplement
>>>> 
>>>> Can anyone see what I’ve done wrong, or know how to register an application handler?
>>>> 
>>>> Thanks in advance :)
>>>> 
>>>> Cheers,
>>>> 
>>>> J
>>>> _______________________________________________
>>>> seaside mailing list
>>>> seaside at lists.squeakfoundation.org
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> seaside mailing list
>>> seaside at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>> 
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20170201/a91661c2/attachment.html>