MultiHandler extentsions

[jimboejw]

Heya,

I'm currently trying to get my head around the MultiHandler extentsions and was hoping I could get some help

At the moment I have the following code in my extension init:

Code: Select all

addRequestHandler("multi", MultiReqHandler.class);

This then calls the following class:

Code: Select all

@MultiHandler
public class MultiReqHandler extends BaseClientRequestHandler
{
    @Override
    public void handleClientRequest(User sender, ISFSObject obj) 
    { 
    	
    	String key = obj.getUtfString(SFSExtension.MULTIHANDLER_REQUEST_ID);
    	    	
        
       if( key.equals( "first" ) ) 
          trace( "first" ); 
       else 
       if( key.equals( "second" ) ) 
          trace( "second" );    
    }
}

Now this works fine, but I was hoping that I would be able to do something similar to this (which currently doesn't work due to addRequestHandler not being valid):

Code: Select all

@MultiHandler
public class MultiReqHandler extends BaseClientRequestHandler
{
    @Override
    public void handleClientRequest(User sender, ISFSObject obj) 
    {     	        
          addRequestHandler("first", FirstReqHandler.class);    	
          addRequestHandler("second", SecondReqHandler.class);
    }
}

Is this possible? I'd really like to have a class that will take all the "multi.*" values and then be able to call other handlers such as FirstReqHandler and SecondReqHandler so that I can really split out the requests.

Thanks,

[jpardoe]

If you were going to do that, why wouldn't you just put the two addRequestHandlers in the exention init instead?

[jimboejw]

If you were going to do that, why wouldn't you just put the two addRequestHandlers in the extension init instead?

Just to be clear the "first" and "second" values are passed to the server as "multi.first" and "multi.second", the 'addRequestHandler' call in the extension init takes everything with "multi.*" and passes it to the MultiReqHandler class.

The reason why I don't want to do all this in the extension init is simply due to having logical objects in the code. So I have an object that handles all the "multi.*" packets, and a separate object that handles all the "foo.*" packets therefore instead of having potentially hundreds of requestHandlers in the extension init, I can have them split out into separate classes to make the code a lot more manageable.

FYI my naming conventions are for test purposes only

[jpardoe]

Ah I see. Makes sense, but this is out of my scope...over you you, Lapo!

[sHTiF]

Even though i am an OOP freak and try to elementarize algorithms into many objects i still see this as overuse of OOP design. Is there any other functionality you will be doing inside the MultiHandler? If not why not put the addRequestHandler into the extension code, since there is no additional functionality involved all it will do is add a couple of clear readable lines to the extension code and not unreadable as when OOP patterns are not used properly.

However if you insist then its doable, although not using native SFS2X functionality as far as i know. You will need to do it yourself using java language reflection.

[ThomasLund]

Its not possible.

I started down the same idea - to structure my code logically into "separate" modules that are then each using multihandler.

Had some discussions with Marco and its not possible to do what you expect - I'll let him answer for himself, but personally I would definitely have liked to be able to do so

For me it has nothing to do with OOP or similar - but the ability to structure my code into modules (world transforms, chat, game admin, etc) modules that I can/could pull in from other games withouth them needing to be linked together in one large monster addRequestHandler list of the top extension class.

/Thomas

[sHTiF]

Thomas i don't see why not, i didn't do any research into this but i already use my custom extended request handler as a super class for my handlers. It is build on top of base request handler and it uses reflection to forward requests into appropriate method calls. I would imagine that i can use same architecture to instantiate and forward them to a custom class. I don't see into sfs sources so i don't know if its possible using the native sfs classes such as forwarding requests from one handler to subhandler but i think its definitely possible to break it up into modules.

I would like to hear Lapo's explanation either way, just to learn something or if there is a critical issue i am overlooking.

[jimboejw]

Damn, that's a big shame

It's not so much being an OOP freak about this, but the fact that the separation would have real world benefits as ThomasLund pointed out.

Would love to hear from Marco regarding this, as I feel it would be a great feature to have/add

[jpardoe]

Might I suggest implementing PureMVC?

You would set up your request handler to forward the type of request into the PureMVC system.

PureMVC will then handle the request by executing a macro command which supports multiple standard commands that can be initialised depending on the situation. This is exactly what you are looking for, and offers so many more benefits in terms of code separation throughout the whole server.

The downside is the steep learning curve, but as you said, you are an OOP freak, so it is something you really should know. Once you understand it, you'll wonder how you ever lived without it.