Problem with JSScript vs JSObject

On 1 Feb 2017, at 12:33, Jupiter Jones <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 2 Feb 2017, at 6:30 am, Johan Brichau <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside