Re: Registering a WARequestHandler

Udo Schneider <[email protected]>
Newsgroups gmane.comp.lang.smalltalk.squeak.seaside
Message-ID <[email protected]>
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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>>> <mailto:[email protected]>> 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 <[email protected]
>>>> <mailto:[email protected]>> 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
>>>>> <[email protected]
>>>>> <mailto:[email protected]>> 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
>>>>>> [email protected]
>>>>>> <mailto:[email protected]>
>>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> seaside mailing list
>>>>> [email protected]
>>>>> <mailto:[email protected]>
>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>
>>>> _______________________________________________
>>>> seaside mailing list
>>>> [email protected]
>>>> <mailto:[email protected]>
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>> _______________________________________________
>>> seaside mailing list
>>> [email protected]
>>> <mailto:[email protected]>
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>> _______________________________________________
>> seaside mailing list
>> [email protected]
>> <mailto:[email protected]>
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>
> _______________________________________________
> seaside mailing list
> [email protected]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>


_______________________________________________
seaside mailing list
[email protected]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.