<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks Johan - worked perfectly :)<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 2 Feb 2017, at 6:30 am, Johan Brichau <<a href="mailto:johan@inceptive.be" class="">johan@inceptive.be</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Jupiter,<div class=""><br class=""></div><div class="">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.</div><div class="">You need this url, which is not working anymore.</div><div class=""><br class=""></div><div class="">So, the code for this indeed stopped working in Seaside 3.2 because the way caches work was changed [1]. </div><div class="">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.</div><div class=""><br class=""></div><div class="">You need to take an approach similar to how the retrieval of the url of a WASession instance was changed in Seaside 3.2.</div><div class="">The url for a WASession instance can now be produced by the WASession instance itself. </div><div class="">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.</div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class="">It should be as simple as keeping the key in the handler and implementing the url retrieval method similar to the one in WASession.</div><div class=""><br class=""></div><div class="">Hope this helps you on your way.</div><div class="">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.</div><div class=""><br class=""></div><div class="">cheers,</div><div class="">Johan</div><div class=""><br class=""></div><div class="">[1] <a href="https://github.com/SeasideSt/Seaside/issues/262" class="">https://github.com/SeasideSt/Seaside/issues/262</a></div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On 1 Feb 2017, at 12:33, Jupiter Jones <<a href="mailto:jupiter.jones@mail.com" class="">jupiter.jones@mail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Johan,<br class=""><br class="">Thanks for the reply.<br class=""><br class="">I’m working on getting Pier working in 3.2 and the PREditCommand registers it’s handler like:<br class=""><br class="">updateRoot: aHtmlRoot<br class=""> | handler |<br class=""> super updateRoot: aHtmlRoot.<br class=""> PREditorScripts default updateRoot: aHtmlRoot.<br class=""> handler := PREditorHandler on: self context copy sanitize.<br class=""> aHtmlRoot javascript<br class=""> add:<br class=""> 'EditorEnh.linkOptionUrl='<br class=""> ,<br class=""> (WACurrentRequestContext value registry<br class=""> register: handler;<br class=""> urlFor: handler) asJavascript<br class=""><br class="">I found a similar thing in MAFileModel, and in the registry test, so I thought it was a legitimate way of doing things :)<br class=""><br class="">What’s the preferred way of achieving this?<br class=""><br class="">Thanks again.<br class=""><br class="">J<br class=""><br class=""><blockquote type="cite" class="">On 1 Feb 2017, at 7:09 pm, Johan Brichau <<a href="mailto:johan@inceptive.be" class="">johan@inceptive.be</a>> wrote:<br class=""><br class="">If you need to ‘mess’ with this part of the code to achieve a simple registration of handlers, I think there is something wrong :)<br class=""><br class="">Before taking a look, I want to understand what is going wrong and why you are doing this.<br class="">Why are you registering a handler in the updateRoot: method?<br class=""><br class="">Johan<br class=""><br class=""><blockquote type="cite" class="">On 31 Jan 2017, at 22:37, Udo Schneider <<a href="mailto:udo.schneider@homeaddress.de" class="">udo.schneider@homeaddress.de</a>> wrote:<br class=""><br class="">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:<br class=""><br class="">My code in your example might look like this (not tested):<br class=""><br class="">updateRoot: anHtmlRoot<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>| handler |<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>super updateRoot: anHtmlRoot.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>handler := MySubclassOfWARequestHandler on: self.<br class=""> registry := self requestContext registry.<br class=""> url := registry url.<br class=""> key := registry register: handler.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>registry trackingStrategy addKey: key toUrl: url.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><br class=""><br class="">Hope this helps.<br class=""><br class="">CU,<br class=""><br class="">Udo<br class=""><br class=""><br class="">On 31/01/17 21:47, Jupiter Jones wrote:<br class=""><blockquote type="cite" class="">I’m having an issue registering a handler in Seaside 3.2 that I’m hoping someone will recognise.<br class=""><br class="">In the test "WARegistryTest>>testUrlFor” a handler is registered with an instance of WARegistry by simply creating a WARegistry with "WARegistry new".<br class=""><br class="">In my app I’m doing something like this:<br class=""><br class="">updateRoot: anHtmlRoot<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>| handler |<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>super updateRoot: anHtmlRoot.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>handler := MySubclassOfWARequestHandler on: self.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>url := WACurrentRequestContext value registry<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>register: handler;<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>urlFor: handler.<br class=""><br class="">…however "WACurrentRequestContext value registry” answers my WAApplication instance, which overrides #register: from WARegistry for registering sessions - not handlers.<br class=""><br class="">So…<br class=""><br class="">I tried copying the way WARegistry>>register: does the registration into my method:<br class=""><br class="">updateRoot: anHtmlRoot<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>| handler |<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>super updateRoot: anHtmlRoot.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>handler := MySubclassOfWARequestHandler on: self.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>anHtmlRoot application cache<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> store:<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> (handler<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> setParent: anHtmlRoot application;<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> yourself).<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>url := WACurrentRequestContext value registry urlFor: handler.<br class=""><br class="">Which appears to store the handler in the application cache (instance of WABulkReapingCache).<br class=""><br class="">However, when I call "WACurrentRequestContext value registry urlFor: handler” it ends up calling “WABulkReapingCache(WAExpiringCache)>>keyAtValue:ifAbsent:” method which calls #shouldNotImplement<br class=""><br class="">Can anyone see what I’ve done wrong, or know how to register an application handler?<br class=""><br class="">Thanks in advance :)<br class=""><br class="">Cheers,<br class=""><br class="">J<br class="">_______________________________________________<br class="">seaside mailing list<br class=""><a href="mailto:seaside@lists.squeakfoundation.org" class="">seaside@lists.squeakfoundation.org</a><br class=""><a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" class="">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br class=""><br class=""></blockquote><br class=""><br class="">_______________________________________________<br class="">seaside mailing list<br class=""><a href="mailto:seaside@lists.squeakfoundation.org" class="">seaside@lists.squeakfoundation.org</a><br class=""><a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" class="">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br class=""></blockquote><br class="">_______________________________________________<br class="">seaside mailing list<br class=""><a href="mailto:seaside@lists.squeakfoundation.org" class="">seaside@lists.squeakfoundation.org</a><br class=""><a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" class="">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br class=""></blockquote><br class="">_______________________________________________<br class="">seaside mailing list<br class=""><a href="mailto:seaside@lists.squeakfoundation.org" class="">seaside@lists.squeakfoundation.org</a><br class=""><a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" class="">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br class=""></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">seaside mailing list<br class=""><a href="mailto:seaside@lists.squeakfoundation.org" class="">seaside@lists.squeakfoundation.org</a><br class="">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside<br class=""></div></blockquote></div><br class=""></div></body></html>