How to register a WADispatcher derivate?

I learnt how to register new application under default dispatcher or unders
specified one with WAAdmin>>register:at: and its derivated functions.

But now, I subclassed WADispatcher and I want to register it for later using
to add root components to it programatically.

It can be done via web config so I guess it can also be done
programatically, but have no idea.

Any hint?

Thanks.

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

On 02/03/15 09:33, David Carlos Manuelda wrote:
> I learnt how to register new application under default dispatcher or unders
> specified one with WAAdmin>>register:at: and its derivated functions.
>
> But now, I subclassed WADispatcher and I want to register it for later using
> to add root components to it programatically.
>
> It can be done via web config so I guess it can also be done
> programatically, but have no idea.

In QCMagritte, we do the following to make it easy to have
production and development versions
- production has no development tools
- production sets itself as default application (assumes one
application/image)
- development sets the debugger error handler

QCApplication class>>registerForProductionAt: anApplicationName
        | application |
        application := self registerAt: anApplicationName.
        WAAdmin disableDevelopmentTools.
        WAAdmin defaultDispatcher defaultName: anApplicationName.
        ^application

QCApplication class>>registerForDevelopmentAt: anApplicationName
        | application |
        WAAdmin enableDevelopmentTools.
        application := self registerAt: anApplicationName.
        application filter configuration at: #exceptionHandler put:
WADebugErrorHandler.
        (self overridesDefaults includes: WAAdmin defaultDispatcher defaultName)
                ifTrue: [ WAAdmin defaultDispatcher defaultName: anApplicationName ].
        ^application

QCApplication class>>registerAt: anApplicationName
        ^(WAAdmin register: self asApplicationAt: anApplicationName)
                preferenceAt: #sessionClass put: self sessionClass;
                addLibrary: JQDeploymentLibrary;
                addLibrary: JQUiDeploymentLibrary;
                yourself

With overridesDefault we determine which application gets to be
default when loading multiple applications that all want to
be default. There are several groups in the QCMagritte configuration,
and when you load the tutorial, that should override the demo as
default.

QCTutorialApplication>>overridesDefaults
        ^#( 'browse' 'welcome' 'QCMagritte Demo' )

QCApplication class>>overridesDefaults
        ^#( 'browse' 'welcome' )

You can find a QCMagritte image at
https://ci.inria.fr/pharo-contribution/job/QCMagritte/

Stephan

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

Stephan Eggermont wrote:
Yes, I have something like this to handle development/deployment stuff.

>From your code it is not clear for me how is the dispatcher registered, I
only see application registration/modification using the default dispatcher.

But what about adding my own dispatcher? Like you can do via config panel in
localhost:8080/config -> add .-> type (Dispatcher)


I need dispatchers, for example, to have /something_here/ as a dispatcher
(not an application) so I can handle it, have its subapplications, and so
programatically.

So what I would need is something like register:at: but instead of
applications, a dispatcher.

ATM, I only know how to create a dispatcher, and manage it, add/remove
applications, debuggers and so, but nothing about telling seaside to
actually use my dispatcher on a given entry point as string :(

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

On 02/03/15 12:25, David Carlos Manuelda wrote:
> So what I would need is something like register:at: but instead of
> applications, a dispatcher.
>
> ATM, I only know how to create a dispatcher, and manage it, add/remove
> applications, debuggers and so, but nothing about telling seaside to
> actually use my dispatcher on a given entry point as string :(
>

I think I misunderstood you. What are you actually trying to achieve?
Subclassing WADispatcher is not often needed/the right thing to do.

Stephan

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

Stephan Eggermont wrote:
I noticed that if I do WAAdmin register: aComponent at: '/en/SomePoint' it
creates the 'en' dispatcher for me, and after, registers the application
aComponent inside that dispatcher.

This is more or less what I want, except that I want to have functionality
added to that dispatcher (for example the language variable set).

Also, to be cleaner, if I unregister the application, only "SomePoint" gets
unregistered, while its dispatcher remains, which is not so clean.

That is why I am thinking of subclassing the WADispatcher, so I can add the
functionality, and still control how it registers/unregisters with its
children content programatically.

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

Playing around with it, I found how to do it like this:

|waa|
waa:=MyWADispatcher new defaultName: 'es'.
"Do aditional configuration on waa instance (...)"
WADispatcher default handlers at: ( waa defaultName ) put: waa.


That will add my dispatcher to the list (I can verify it in
localhost:8080/config ), is that the way to go, or should be it more simple?

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

On 02/03/15 13:38, David Carlos Manuelda wrote:
> I noticed that if I do WAAdmin register: aComponent at: '/en/SomePoint' it
> creates the 'en' dispatcher for me, and after, registers the application
> aComponent inside that dispatcher.
>
> This is more or less what I want, except that I want to have functionality
> added to that dispatcher (for example the language variable set).

Do you want to encode the language in the url? Why?

Stephan

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

Stephan Eggermont wrote:
Encoding the language in the url like /en/foo /es/foo is a better thing to
do for SEO for example than having session side initializated.

URLs are very important in this matter, also, it is better to understand a
bookmarkable url like /en/forum than /forum?_k=2345234523452 or
/forum?lang=en (just an example).

Note that not in all languages forum is the same word, example in spanish is
foro, so it make sense.

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

On 02/03/15 17:16, David Carlos Manuelda wrote:
> Encoding the language in the url like /en/foo /es/foo is a better thing to
> do for SEO for example than having session side initializated.

What are your considerations for choosing to override WADispatcher,
vs one of the other WARequestHandler subclasses (i.e. WAApplication)?

Stephan

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

Stephan Eggermont wrote:

> On 02/03/15 17:16, David Carlos Manuelda wrote:
>> Encoding the language in the url like /en/foo /es/foo is a better thing
>> to do for SEO for example than having session side initializated.
>
> What are your considerations for choosing to override WADispatcher,
> vs one of the other WARequestHandler subclasses (i.e. WAApplication)?
>
> Stephan
My idea is to process any request under /xx/* in the same app regardless of
the language (same logic).

I register a testing app under /es/test and I realized seaside adds a
dispatcher automatically for me, that is why I thought it could be the way
to go.

But I am starting to see why you said it may not be a good idea, inside
dispatcher I can't seem to configure things like gettext, which I can in an
application.

In theory it would be possible to register an WAApplication subclass
instancein language entry point, like /es and let it handle all the
requests, like /es/foo or /es/bar to decide which component(s) to render?

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

On 03/03/15 09:40, David Carlos Manuelda wrote:
> But I am starting to see why you said it may not be a good idea, inside
> dispatcher I can't seem to configure things like gettext, which I can in an
> application.
>
> In theory it would be possible to register an WAApplication subclass
> instance in language entry point, like /es and let it handle all the
> requests, like /es/foo or /es/bar to decide which component(s) to render?

That would be the place where I would start looking, yes.
I've never had to do SEO optimization, it was less relevant
for complex/internal applications.

Please keep us posted.

Stephan

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