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:
  
Could anybody point me to prototype demos and sample code?
      
Though there's not really demos, did you see this page:http://prototypejs.org/learn/introduction-to-ajax

    
Yes I've read all three tutorials but are most interested in JSON/PHP.

  
Ajax requires server-side code, which makes it hard to demo something
in your language of choice, so that could be why it was left off of
the prototype website.

    
True, yet Prototype probably looses every second visitor just because
of no demos. I know you can't put up demos for all server sides but at
least one or some for the most used would help a lot. Another maybe
even better way is to put up downloadable samples so anybody can get
his favorite sample an try it out in his own environment.

Another very important aspect of working samples, they're already
working! That way one can tweek them until they suit one's own needs.
In case of errors one can always fall back to the working code and
start afresh.

O. Wyss




  

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to