Forum OpenACS Q&A: Re: ]project-open[: Current status about AJAX, Sencha and AOLserver

Hi!

Sorry, I had notifications turned off, otherwise I would have answered earlier. Here is a summary of the current state of Sencha development in ]po[:

- Accessibility:
@Dave, I've got no information on this, sorry. Accessibility is not a priority for us.

- Reference Application:
We've developed a rather complex ticket tracking application for a Spanish gov site purely in Sencha. The result has been quite impressive. The most difficult issue was network performance, because the app requires to load the complete lists of customers and users into the browser. We can now work around this issue with a different architecture and nsreturnz, amongst other measures. We can setup a demo server if that's interesting to somebody.

- Embedding Sencha in HTML Pages:
We have created a number of Sencha charts as ]po[ portlets to be embedded into normal HTML pages. This works fine in general, with a certain delay between the load of the HTML page and the start of the Sencha app. The charts are very pretty, quite a difference to the rest of the ]po[ GUI... We've been playing around with using Sencha as a file-storage front-end now, and that also looks pretty good. However, we have no clear idea yet how multiple portlets on a single page will behave in terms of performance.

- License Issues:
Sencha Ext-JS is licensed under GPL V3 (or proprietary if you pay). However, GPL V3 code is really difficult to separate from GPL V2 and proprietary code if they are used in a single application. This is the reason why we have excluded any Sencha code from the current ]po[ V4.0 release. Instead, we are going to include an "app store" in V4.1, which will allow customers to dynamically load GPL V3 packages, thus allowing us to avoid any "license contamination".

- REST Interface:
@Taras: Our ticket tracker application above requires some 15 different object types via REST interface. So we have decided to use a generic REST interface using the OpenACS SQL metadata (http://www.project-open.org/en/package_intranet_rest). New OpenACS object types will automatically become accessible via REST, and you don't need to hand-code the interfaces. This greatly reduces errors and security/permission issues, because the code is reduced.

- ]po[ V4.0 vs. ]po[ V4.1:
We are releasing V4.0 at the moment, and the "release process" will still take several months (after the product is now getting ready for wide-spread use we need to work on PR and marketing...). V4.1 will probably take until summer 2014 or even later. Please see our roadmap for details: http://www.project-open.org/en/project_open_roadmap

- TCL vs PHP:
At the moment all back-end code is TCL. Maybe I've expressed myself a bit ambiguously. We don't _want_ to port all TCL stuff to PHP if we can avoid it. We just _need_ PHP as a fall-back option if OpenACS activity should go down even further. So it's a good idea to try to use the new ]po[ REST interface as much as possible and to avoid custom data-sources. This strategy will allows us to switch back-ends quickly if necessary.

Cheers,
Frank

Hey very nice. Seems like similar experiences as we've been doing our server-calls RESTful style too, and came up with tricks for sencha performance (gzipping/concatenation/minification, lazy rendering, buffered loading), and still supporting several openacs-based apps with newer interfaces.

One interesting thing I did reduced large amounts of reliance on tcl for an 'excel-like' interface that required all of the logic in the browser (for offline support). It was for what-if scenarios in the human resources work was write my own library for the client and re-use it on the backend in a plv8 function (javascript inside postgres). Openacs did nothing except handle the request and call the database function (after error checking, permissions). It allowed us just to 'replay' the front end actions in the database to keep the server in sync.

It would be interesting to have a chat one day and share techniques, especially relating to sencha, and patterns for highly dynamic apps. We could share a few things we've done that might have crossover to your apps, and vise versa (your ticket tracking app sounds cool).

Taras

Hi Taras,

> gzipping/...

Rrright, we've also added gzipping and a way to select the columns returned in object lists in order to reduce data volume, but I'm interested to learn about the other ones.

I'll send you a private message in order to schedule a call.

> what-if scenarios

_Very_ interesting, we will have to work with what-if scenarios for project resource planning at some point in the future...

> share

Here is a quick way to look at our Sencha client-side stuff. It's a complete ticket tracker/helpdesk system written in Sencha:
cvs -d :pserver:mailto:anonymous@cvs.project-open.net:/home/cvsroot checkout intranet-sencha-ticket-tracker

Cheers,
Frank