|
One important distinction between Prototype and some other frameworks
is that Prototype really focuses on basic functionality. It doesn't
include widgets, just wrappers and utility classes so there isn't much
to demo. It's all about using various parts of prototype along with
other generic _javascript_ing to create your own widgets and
functionality. Also, it is server-agnostic so giving server-side code
demos wouldn't make much sense, but these things would be nice from the
respective communities of each server-side platform. That said, I'll share with you my PHP-Ajax philosophies since I think they may be useful. I don't use a standard templating library like I probably should, but what I've done has worked well so far. I use a separate "data" page for each Ajax-heavy page I serve. So for example if I have useradmin.php, all of the ajax requests for that page are handled by useradmindata.php I use the word data because this is what is served by the page, raw (JSON) data. Sometimes I'll serve up HTML as well, but I hate generating PHP for server requests. Here is what useradmindata.php might look like: <? //do authentication checks and includes here //declare some commonly used variables $json = Array(); $error = false; $printIsError = true; ob_start(); $action = ""> $value = trim(getPostOrGetValue('value')); $id = dbEscapeString(getPostOrGetValue('id')); $ids = parseid($id); // parses 'user-5_item-83' into hash: {user:5,item:83} switch( $action ){ case 'doSomething': if($value == 'notCool') $error = 'You did something not cool.'; else $json['userInfo'] = Array('id' => 10, 'name' => 'Joe', 'data' => Array(5,6,7,8)); $json['status'] = getStatus($value); break; ... } $content = ob_get_clean(); if($printIsError && $content){ $error .= htmlspecialchars(strip_tags($content),ENT_QUOTES); $content = ''; } if($error){ $json['error'] = $error; } if(!empty($json)) header('X-JSON: ('.json_encode($json).')'); if($content) print $content; ?> The _javascript_ may look something like this: ------------------- new Ajax.Request('useradmindata.php',{ parameters: { action: 'doSomething', value: 'cool' }, onSuccess: function(xhr,json){ if(json && json.error){ alert(json.error); return; } $(json.userInfo.id).update(json.userInfo.name); json.userInfo.data.each(function(value){ $('checkbox-'+value).checked = 'checked'; }); $('userStatus').addClassName(json.status); } }); -------------------- So I always use action="" in my Ajax requests, and inside the switch statement I have code that handles that action. If a JSON response is appropriate, it fills the $json variable with that data, which will then be directly accessible in the client code inside an onSomething callback. For cases where the response data may be large I use print and set $printIsError = false, then in the client code I have to xhr.responseText.evalJSON() to get the data. What the data is or how you use it is entirely up to you. It could be an array or hash of data that you can use with Builder.node, or messages or status flags or whatever, be creative. There are many ways to structure your code, Rails and other MVCs seem to like generating chunks of HTML/Javscript as the response, but if you are doing this manually it gets pretty messy. Separating the initial page load (HTML/_javascript_), the Ajax requests (typically just POST/GET encoded data), the Ajax response (JSON data is my favorite), and client-side processing (Generating DOM nodes, JS widgets, settings classNames, alerting error messages, etc..) is a good approach IMO. Having JS that generates DOM elements can save on extra Ajax requests and benefits from caching. Responding with just data keeps your code well organized and keeps UI and backend data handling logically distinct. Also, debugging blocks of code that are generated by the server and evaled by the client can be a major PITA, having all of your JS in .js files makes debugging a breeze. Does this help? Colin wyo wrote: On Apr 5, 11:11 pm, "Justin Perkins" <[EMAIL PROTECTED]> wrote: --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~--- |
- [Rails-spinoffs] Prototype and code samples wyo
- [Rails-spinoffs] Re: Prototype and code samples Justin Perkins
- [Rails-spinoffs] Re: Prototype and code samples wyo
- [Rails-spinoffs] Re: Prototype and code samp... Colin Mollenhour
