[jifty-devel] Server pushed region updates (was Re: Manipulating page regions from actions)

[Sterling Hanenkamp]

Attached you find a patch that modifies the webservices/xml template and
jifty.js to include a feature for updating parts of the web site not
requested by the client, i.e., server pushed updates.

It works like this. An action or dispatcher on the server could decide to
update other regions other than those requested by the "fragments" part of a
webservices request. The webservices request might not even include a
fragments request. It works like this:

(1) The action or dispatcher before rule (or something else called before
the on rules start) calls Jifty->web->request->add_fragment() and adds a
custom fragment request. As the code currently works, an action might do
this, but that response would be ignored by the client.

(2) When add_fragment() is called, an additional parameter named "metadata"
is passed a hashref of options. These options are a subset of the options
normally passed to an event handler added to a hyperlink() or other form
element. For example, a request might be something like:

Jifty->web->request->add_fragment(
    name => 'journal_list-new_comment_entry-status',
    path => '/status_message',
    arguments => { message => 'Add a comment to a task.' },
    metadata => {
        region => 'journal_list-new_comment_entry-status',
        mode => 'Replace',
    },
);

(3) This will cause the dispatcher to invoke "/status_message" when handling
the response. This will be added to the webservices/xml response with an
additional <metadata> section added. The metadata section is parsed and read
by Jifty.update() to take the place of the fragment information normally
used to determine where and how to update the page.

One interesting thing I changed was the allowance for an "element" attribute
to be included to update multiple elements on the page with a single
fragment. This is both powerful and dangerous since you might replace lots
of things unintentionally if your selector is too inclusive.

I'm not sure the actual implementation I've included is idea, but it is
along the lines of what I was thinking when I posted my last message.

Another implementation I thought of during the process is somehow providing
hooks that could be run to do really fancy customized updates based upon the
same principle. The way I thought of implementing that would be to include
class attributes on the <fragment>s returned that could be matched by hooks
which are then setup in a Behaviour-esque manner. When such a fragment is
returned, the matching hook or hooks would be called and giving the fragment
as a data structure to be dealt with in whatever manner suits the
application.

As a side note, Jifty.update() does includes a little more than just the web
services call and the handling of the fragments and action results that I
expected. It also includes some code for client-side templating (very cool)
and single page app stuff that seems like it belongs elsewhere to be invoked
only when those things are used by the application, but that's just my
opinion. Seems like Jifty.update() ought to be more easily moddable though
since it is such a central feature of Jifty. If it were, these things might
be easily extracted off into specialized hooks of some kind.

Cheers,
Sterling

On Sat, Aug 16, 2008 at 9:41 PM, Sterling Hanenkamp
<sterling at hanenkamp.com>wrote:

> Maybe there's a way to do this, but I have found myself recently wanting to
> be able to manipulate page regions on the basis of an action's result.
>
> For example, I have an action that does a bunch of magic based upon the
> input. I have a page that shows a list of timers. These timers each belong
> to an entry, which groups a set of timers together. Each entry has a list of
> tasks associated with it that is displayed in a sidebar of each timer for
> that entry.
>
> My magic action may have one of the following 5 manipulations that could
> happen. I've listed the region manipulations I wish to do for each:
>
>    1. *Create a task.* If the action creates a new task, it will need to
>    insert the task into zero or more lists (zero or more page regions depending
>    on how many timers are currently being displayed on the page).
>    2. *Comment on a task.* In this case, we don't need to refresh
>    anything. All regions should remain unchanged.
>    3. *Comment on a timer.* I'd need to insert the new comment at the top
>    of the comments list (a region) on the top-most timer.
>    4. *Restart an entry.* I'd need to insert a new timer (complete with a
>    list of comments and tasks) at the top of the timers list.
>    5. *Start a new entry.* This is exactly the same as (4), it just
>    happens to represent a new, never before seen entry.
>
> I can do this pretty easily by just refreshing the whole page, but I'd
> rather not. The page can get pretty long by the end of a day and the point
> of using ajax is so that I don't have to refresh the whole page.
>
> What I feel like I'd like to do is something like this from the action:
>
> # on create a task
> $self->result->update_page({
>     region => 'entry_list-entry_14-task_list',
>     prepend => '/journal/task',
>     arguments => {
>         task_id => 103,
>         format => 'journal',
>     },
> });
>
> # on comment on a task.... nothing
>
> # on comment on a timer
> $self->result->update_page({
>     region => 'entry_list-entry_14-comment_list',
>     prepend => '/journal/view_comment',
>     arguments => { comment_id => 7813 },
> });
>
> # on restart an entry
> $self->result->update_page({
>     region => 'entry_list',
>     prepend => '/journal/view_timer',
>     arguments => { timer_id => 155 },
> });
>
> # on start a new entry
> # same as above
>
> Essentially, I'd like to change the onclick actions in the response from
> the action itself rather than having to foreknow them during at click time.
>
> The other solution I've come up with (and quite possibly the one I use for
> now) is to include 5 different buttons that each do these things. Then,
> present the button that does the right thing as soon as we have enough input
> to make that judgment. I do that to some extent now by having an extra ajax
> request that changes the name of the button to something that hints at
> what's going on (1=Taskinate, 2=Comment, 3=Post, 4=Restart, 5=Start), but
> there are a couple places where I'm going to have to handle that delicately
> to make sure it DWIMs.
>
> I'm open to doing this anyway that works reasonably well and will to commit
> smallish sized patches to help at thsi time, but I don't have much time to
> spare at the moment for anything moderate to largish.
>
> Any suggestions?
>
> Cheers,
> Sterling
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jifty.org/pipermail/jifty-devel/attachments/20080824/afaea1e6/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jifty-region-server-push.patch
Type: application/octet-stream
Size: 6633 bytes
Desc: not available
Url : http://lists.jifty.org/pipermail/jifty-devel/attachments/20080824/afaea1e6/attachment.obj