<div dir="ltr"><div>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. <br><br>
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:<br>
<br></div><div>(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.<br>
<br></div><div>(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:<br>
<br></div><div>Jifty->web->request->add_fragment(<br> name => 'journal_list-new_comment_entry-status',<br> path => '/status_message',<br> arguments => { message => 'Add a comment to a task.' },<br>
metadata => {<br> region => 'journal_list-new_comment_entry-status',<br> mode => 'Replace',<br> },<br>);<br></div><br>(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.<br>
<div><br>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. <br>
<br>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. <br><br>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.<br>
<br>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.<br>
<br>Cheers,<br>Sterling<br><br><div class="gmail_quote">On Sat, Aug 16, 2008 at 9:41 PM, Sterling Hanenkamp <span dir="ltr"><<a href="mailto:sterling@hanenkamp.com">sterling@hanenkamp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr">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.<br><br>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.<br>
<br>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:<br><ol><li><b>Create a task.</b> 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).</li>
<li><b>Comment on a task.</b> In this case, we don't need to refresh anything. All regions should remain unchanged.</li><li><b>Comment on a timer.</b> I'd need to insert the new comment at the top of the comments list (a region) on the top-most timer.</li>
<li><b>Restart an entry.</b> I'd need to insert a new timer (complete with a list of comments and tasks) at the top of the timers list.</li><li><b>Start a new entry.</b> This is exactly the same as (4), it just happens to represent a new, never before seen entry.</li>
</ol>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.<br>
<br>What I feel like I'd like to do is something like this from the action:<br><br># on create a task<br>$self->result->update_page({<br> region => 'entry_list-entry_14-task_list',<br> prepend => '/journal/task',<br>
arguments => {<br> task_id => 103,<br> format => 'journal',<br> },<br>});<br><br># on comment on a task.... nothing<br><br># on comment on a timer<br>$self->result->update_page({<br>
region => 'entry_list-entry_14-comment_list',<br> prepend => '/journal/view_comment',<br> arguments => { comment_id => 7813 },<br>});<br><br># on restart an entry<br>$self->result->update_page({<br>
region => 'entry_list',<br> prepend => '/journal/view_timer',<br> arguments => { timer_id => 155 },<br>});<br><br># on start a new entry<br># same as above<br><br>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.<br>
<br>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.<br>
<br>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.<br>
<br>
Any suggestions?<br><br>Cheers,<br>Sterling<br></div>
</blockquote></div><br></div></div>