The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.

NAME

wxpoe.pl - example app for POE::Loop::Wx

DESCRIPTION

Here is a *rough* little wxPOE sample app that we have used on win32, GTK and OS X. We wanted a wxPerl and POE environment that allowed parallel non-blocking data transactions in the background (using POE::Component::Client::UserAgent) and wxPerl cross-platform GUIs. While were at it, we want a subscribe/publish data model to allow multiple frames to re-use the same data and/or to allow multiple frames to be refreshed when data changed.

In our actual application our DataManager (Brain.pm in this example), we do aggressive data caching, avoiding going across the wire for a lot of the calls. In turn, we subclassed a number of wxPerl controls to know how to do their own data calls on instantiation. So when a frame/dialog is instantiated, each control (for example a wxChoice) can go and get its data from the DataManager (which may or may not be using cache) and populate itself asynchronously -- so the user gets more immediate visual feedback. Because we use the parallel user agent, a frame that has 10 controls for example will fire off 10 requests at once (configurable) and populate the controls in parallel.

SYNOPSIS

Here is a brief summary of what this app should do (thanks to Ed Heil).

It opens a frame, with "URL" and "key" sections, a "request data" button, and a "spawn" button.

The "spawn" button makes more frames like itself. Try making a few. (The only difference between them and the original one is that if you close the original one the app goes away.)

When you click "request data", it subscribes that frame to a "channel" identified by the current subscription key, and then requests that the data from that URL be brought back on that channel.

Try clicking "request data" on the first frame -- it will get data from google.com (Caveat: we don't have redirect handling working in this example, so if you are from another country where google redirects you to a local domain, try some other non-redirecting domain name).

Try opening a new frame. Leave the subscription key the same, but change the URL to something else (say, yahoo.com). Click "request data." It will update the data both in the new and the old frame, since they're both subscribed to the same subscription key.

Try opening yet another new frame. This time change the subscription key AND the URL. This third frame will update with new data but will leave the others unchanged, because that new data came in on the channel defined by the new subscription key, not the old one to which they are subscribed.

Just a proof of concept of the minimum infrastructure we absolutely need to implement publish/subscribe. There are only two POE sessions going on -- the main one tracks the components and subscriptions itself.

I implemented some of this functionality by inventing a new class, "Pobject," which is any object of which POE is aware. Viewer.pm is a Pobject as well as a Wx::Frame (multiple inheritance).

Pobjects don't even have to be frames -- frames don't have any special status in this publish/subscribe model. Any subclass we create could conceiveably be a Pobject and therefore deal with the Brain (which is the analogue of the DataManager in this demo).

AUTHOR

Ed Heil <ed-cpan@donorware.com>