[Seaside] Registering a WARequestHandler

Thu Feb 2 17:30:52 UTC 2017

Hi Jupiter,

could you post your code? I ran into a similar problem getting Magritte 
File Handlers to work and did not quite figure out what you did.

Thanks,

Udo

On 01/02/17 21:36, Jupiter Jones wrote:
> Thanks Johan -  worked perfectly :)
>
>> On 2 Feb 2017, at 6:30 am, Johan Brichau <johan at inceptive.be
>> <mailto:johan at inceptive.be>> wrote:
>>
>> 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
>>
>>> On 1 Feb 2017, at 12:33, Jupiter Jones <jupiter.jones at mail.com
>>> <mailto: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
>>>> <mailto: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
>>>>> <mailto: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
>>>>>> <mailto:seaside at lists.squeakfoundation.org>
>>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> seaside mailing list
>>>>> seaside at lists.squeakfoundation.org
>>>>> <mailto:seaside at lists.squeakfoundation.org>
>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>
>>>> _______________________________________________
>>>> seaside mailing list
>>>> seaside at lists.squeakfoundation.org
>>>> <mailto:seaside at lists.squeakfoundation.org>
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>> _______________________________________________
>>> seaside mailing list
>>> seaside at lists.squeakfoundation.org
>>> <mailto:seaside at lists.squeakfoundation.org>
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> <mailto: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
>