“Nathan Gray” nathan@goarctic.com schrieb:
Lars, could this work with your thinking?
Not with my thinking, but i’m sure it would work. 
I’m sure you’ve already considered this, but I’m wondering about the
flaws in this plan that caused you to go another way.
I’d guess the one-shot server side processing would not fit with the
extjs callback style, and caching the full record and updating the
few fields that the callback changes is considered wasteful.
Let’s make a short trip back in time, to better explain why we meet which
decision.
First we tried to integrate the Ext Combo Box and the Ext Grid into a
widget, to get a addressbook “live search” functionality, without reloading
the whole page. We also wanted some eye candy and we wanted to know, how we
could integrate ExtJS in eTemplate. We tought it might be a very cool
feature, when we could use the eTemplate GUI editor to create the layout and
let eTemplate render the required JavaScript code.
Creating the needed eTemplate widget was very easy. But working with the
data got complicated. As eTemplate is not prepared for just adding more data
on the client side. eTemplate just don’t except any additional data. That’s
good for creating static HTML forms, but was very limiting in our case. We
solved the problem, but it was a hack.
Because we need to hack around these eTemplate limitations, our CRM module
never found it’s way into the eGroupWare SVN.
Then I did a performance analysis of our new application. The result was
very frustrating for me. Just have a look at
http://cs.officespot.net/index.php/Egroupware_performance_analysis
The page request took 6 seconds. About 3 seconds got spend with initializing
the api. The other 3 seconds got spend for processing eTemplate. The
eTemplate time also contains 0,5 seconds for the application itself. You
will always spend 90% of the processor time with the eGroupWare framework.
That’s not acceptable when trying work with AJAX.
Let’s summarize. eTemplate not prepared for AJAX. eGroupWare api to slow for
AJAX requests.
Then we decided to drop eTemplate as whole(50% server processing time saved)
and let the rendering of the application be done on client side. ExtJS has
everything we need. You can let eTemplate render the required HTML tags on
server side or you can let ExtJS render the required HTML tags on client
side.
Let’s summarize. GUI get’s rendered by ExtJS. eGroupWare api still slow.
Then we decided to just write a wrapper around the existing eGW api.
Cornelius first try was to write a ExtJS based addressbook, which is talking
to the current addressbook api using XML/RPC. He really tried, but he
failed. It was to complicated.
I the mean time the Zend Framework got released. They have different server
available. Also the Zend_Json_Server, which makes it very easy to implement
a JSON server which can talk to the ExtJS framework. If you have a closer
look at the Zend Framework, you will discover that the developer of the ZF
have solved many problems, we also like to solve in eGroupWare too. They
have a general database abstraction based on PDO, they are PHP > 5.1 ready,
the have a general caching backend, they have proper locale and timezone
handling, the can use the same data to generate a JSON, XML/RPC or SOAP
interface, input filtering, autolaoding, pdf and much more. Why should we
still maintain the same features in eGroupWare ourself, when the ZF
developers are doing this already for us? So we decided to rewrite the core
components of eGroupWare to be based on the ZF but to work with the
datastructures. That would allow to just plug in the new application and
everything goes on.
Let’s summarize. GUI get’s rendered by ExtJS. eGroupWare api get’s rewriten.
Datastrcuture stays the same.
Then we started having a closer look at the backend classes. The acl class
is very good example for a class being used really strange. The acl
class/table handles access controls to data, access controls to application
features and also contains the sql group memberships. Trying to understand
the class/sql table was very hard. We couldn’t resist to correct this.
Which leads to:
- GUI gets rendered by ExtJS
- eGroupWare api get’s rewritten based on the Zend Framework
- when possible the datastructure stays untouched
If I understand the extjs and your implementation correctly, extjs +
(new UI code with better callbacks) is supposed to replace current
eTemplate + UI code? Or is it closer to extjs (= new UI code) + (new
BO code with finer callbacks) replaces eTemplate + UI + BO?
So it’s closer to the later one.
–
Lars Kneschke
CTO OfficeSpot.Net
Metaways Infosystems GmbH
Pickhuben 2-4, D-20457 Hamburg
eGroupWare Support: http://www.egroupware-support.net
OfficeSpot.Net Collaboration Server: http://cs.officespot.net
E-Mail: mailto:l.kneschke@metaways.de
Web: http://www.metaways.de
Tel: +49 (0)40 317031-21
Fax: +49 (0)40 317031-921
Mobile: +49 (0)175 9304324
Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel
Handelsregister: Amtsgericht Ahrensburg HRB 4508
Geschäftsführung: Hermann Thaele, Lüder-H.Thaele
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers
