It's slightly more difficult. :)

I have my dispatcher because I have a lot of requirements to fulfill (for example the modules can subscribe to POE events, so a "master" event can be distributed to several events and they can all process the data as needed, while they can be called independently too). Another thing is that I have to do extensive authentication and access control on the HTTP modules, and it's easier to handle them in one, invisible place, than require to call one subroutine in their first line.

I have a _default state in the target session, in fact this is what dispatches the events, but I couldn't yet find the clean way of handling HTTPd 404s in that (the HTTPd is just a module in this stuff, the "outside" must be independent from it).

(2 is the most straightforward, I think I will choose that, but an event_exists would be much cleaner :)

Thanks,

On 2007.09.14. 17:33, Nicholas Perez wrote:
Are the events some how registered dynamically? Are you keeping track
of the events? Why write your own dispatcher when there is a
dispatcher built into SimpleHTTP?

There are a couple of ways around this if you insist on using the
module without its dispatcher:

1) provide a _default state in your session to capture unknown events
(ie. fire off the events regardless and let your _default send back
404s. See POE::Session wrt _default)

2) store a reference to the hash passed into POE::Session->create()
and test for existence of events, returning 404s as appropriate.

And there are probably more ways around this. Ideally, I would just
provide exact matches for what commands you are interested and leave
the catch all to return 404s


On 9/14/07, Attila Nagy <[EMAIL PROTECTED]> wrote:
Hello,

I'm sure you are right, I'm just learning POE.

The basic problem is that I run a POE::Component::Server::SimpleHTTP
from which I would like to dispatch some URIs to given events.

The idea is something like this:
if you pull http://webserver/module_command
then a module_command event fires.

The problem here is that the dispatcher is registered into SimpleHTTP as
DIR '.*', so it gets everything, but it should somehow tell if
module_command doesn't exist and give back a 404...

On 2007.09.14. 15:25, Nicholas Perez wrote:
Can you describe the situation in which the target session won't
exist? Or describe why a particular event on your target session
wouldn't exist? It would be easier to test for existence of the
session rather than the event on the session (unless of course the
session dynamically alters its events on the fly).

Testing for the existence of a session is easy. From POE::Kernel:

The post() method returns a boolean value indicating whether the event
was enqueued successfully.  $! will explain why the post() failed:

         ESRCH: The SESSION did not exist at the time of the post() call.

If the events are really that dynamic, and you want to base behavior
around that, you can always use POE::API::Peek:

http://search.cpan.org/~sungo/POE-API-Peek-1.0802/lib/POE/API/Peek.pm#session_event_list

But really, this sounds like an XY problem that could be solved
without "peeking" into the guts of POE.

HTH,

nperez

On 9/14/07, Attila Nagy <[EMAIL PROTECTED]> wrote:

Hello,

I would like to post data to different events, depending on the input.
If the target event doesn't exist, I should process the request locally,
but I don't know any ways to check the existence of an event.

What I would like to do:

if ($_[KERNEL]->event_exists($session, $event_name)) {
    $_[KERNEL]->post($session, $event_name, $args);
} else {
    do something else
}

How should I do that?

Thanks,



Reply via email to