phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Phpgroupware-developers] Adding ajax (prajax) and a test for it - p


From: Dave Hall
Subject: RE: [Phpgroupware-developers] Adding ajax (prajax) and a test for it - patch #5311
Date: Wed, 16 Aug 2006 20:12:29 +1000

On Wed, 2006-08-16 at 09:18 +0200, Sigurd Nes wrote:
> > From: Dave Hall address@hidden
> > Sent: 2006-08-16 05:44:54 CEST
> > To: address@hidden
> > Subject: Re: [Phpgroupware-developers] Adding ajax (prajax) and a test for 
> > it - patch #5311
> > 
> > On Tue, 2006-08-15 at 20:51 +0200, Sigurd Nes wrote:
> > > http://savannah.gnu.org/patch/index.php?func=detailitem&item_id=5311
> > > 
> > > I have added a patch (#5311) that ports PRAjax - PHP Reflected Ajax to
> > > phpgroupware (HEAD) and a demonstration of usage.
> > > 
> > > http://prajax.sourceforge.net/
> > > 
> > > Check out a fresh copy of 'phpgwapi' and 'hrm' before applying the patch
> > > with 'patch -p0 < prajax.diff'.
> > > 
> > > Install 'hrm' - and go to:
> > > /~phpgroupware/index.php?menuaction=hrm.ajax_test.index
> > > 
> > > The ajax library resides in phpgwapi/inc/prajax
> > > 
> > > It is very easy to use - but to compare with 'SARISSA' or 'YUI' - it
> > > would be nice if someone could write a similar test for them as well.
> > > 
> > 
> > Sarissa is just a very simple cross browser XHR/XML wrapper so you can
> > use the same methods on all browsers which support them.  It isn't
> > really possible to write a test for it.
> > 
> > I am open to suggestions about best we can integrate YUI into phpgw.  I
> > have spent some time looking at various "ajax toolkits" and found yui to
> > be the nicest. see http://developer.yahoo.com/yui for more info.  I
> > haven't looked at how we can make this easier to integrate for
> > developers (at this stage).
> > 
> > > (The reason for using 'hrm' for testing is just to minimize my effort to
> > > make this work)
> > > 
> > > Any comments ?
> > 
> > Here are my initial comments, without running the demo.  I have only
> > scanned over the patch.
> > 
> > * Services_JSON is already in the api - class.Services_JSON.inc.php
> > * prototype is pretty ugly, even tho it can do some nice things
> > * $phpgw_info['flags']['java_script'] will be deprecated in 18,
> >   - use the js class instead
> > * We could look at using ?phpgw_return_as=json (see attached)
> >   - make sure you are using the latest version of phpgw/index.php
> > 
> > I think PRAJAX is ok, but it hasn't grabbed me as an optimal solution.
> > A toolkit independent implementation of ajax across phpgw would be the
> > best solution imho.  You should also notice that there is phpGWlink() in
> > js now (enabled by default in idots others to follow), so GET based
> > sessions are fully supported.
> > 
> > We should look at developing some basic "AJAX widgets" that devs can
> > easily drop in their apps to make easier.
> > 
> I am all for it - as long as it works and is easy to use (code) - how about 
> implementing some basic examples to flatten the learning curve ?

Not sure what you mean by this?  The widgets? the server side? the
client side?

The widgets really depend on how we implement them.  I have notes on it,
but no time to do anything this or next week.  I also think some
discussion about UI guidelines and consistency would be good here.

For the server side just use the patch I posted and any
"public_function" of a class is exposed via json, pretty simple.  There
is probably some additional logic needed to handle the requests within
the methods, but any php dev with some basic knowledge should cope fine.
I would suggest that you just expose bo layer methods via
"this->public_function" and add phpgw_return_as=json to the url.  I have
addded an optional 3rd paramater to the js function phpGWLink in head
which when set to true appends the phpgw_return_as=json to the request
query string.

To request a method return data as a json string, use the following
code:

//this assumes you have used the JS class to include sarissa and json

/**
* Handles my update for me
*
* @param array arRows this should be an array of objects to fill a table
*/
function (arRows)
{
        var oTR, oTD;   
        var oTarget = 
document.getElementById('myTable').getElementsByTagName('tbody').item(0);
        //empty out the existing table
        while (oTarget.firstChild)
        {
                oTargetRemoveChild( oTarget.firstChild() );
        }
        //fill it up
        iRowsLen = arRows.length;
        for ( var i = 0; i < iRowsLen; ++i )
        {
                oTR = createElement('tr');
                oTR.id = arRows[i].id;

                var oTD = document.createElement('td');
                oTD.appendChild(document.createTextNode(arRows[i].id));
                oTR.appendChild(oTD);

                var oTD = document.createElement('td');
                oTD.appendChild(document.createTextNode(arRows[i].descr));
                oTR.appendChild(oTD);
        }
}

/**
* @var object oParams the normal arguments you would use for phpgw::link
*/
var oParams = {menuaction: 'app.class.method', id: 1};

/**
* @var object the XMLHttpRequest object for request (may use sarissa)
*/
var xhr = new XMLHttpRequest();
xhr.open('GET', phpGWLink('/index.php', oParams, true), true);
xhr.onreadystatechange = function()
{
        // I am being a little lazy here, google has better examples
        if ( xhr.readyState == 4 )
        {
                updateContent(JSON.parse(xhr.responseText));
        }
}

For those of you wonder what it does, it requests some new records which
are returned in JSON form, but start off similar to this:

$my_array = array();
$my_array[] = array('id' => 1, 'descr' => 'this is the first entry');
$my_array[] = array('id' => 2, 'descr' => 'this is the second entry');
//etc

That is loaded into a 2 column table that has a tag within it which
looks like <table id="my_table"><thead>...</thead><tbody>...</tbody>

I hope this makes sense to people

For the client side, it is generally just DOM based js.  I am not going
to pretend it is easy.  I also don't like most toolkits as they either
over simplify things so you lose the power of the DOM or they just wrap
it in some layer which means you have to remember their annoying methods
for using the DOM.  For example an ajax based vfs navigator I am working
on, it is far easier to use the DOM than any toolkit.  See above for how
much work is needed

Cheers

Dave
-- 
Dave Hall (aka skwashd)
API Coordinator
phpGroupWare
+-------------------------------------+-------------------------------+
| e address@hidden          | w phpgroupware.org            |
| j address@hidden                 | aim skwashd                   |
| icq 278064022                       | msn address@hidden       |
| sip address@hidden       | y! skwashd                    |
+-------------------------------------+-------------------------------+





reply via email to

[Prev in Thread] Current Thread [Next in Thread]