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
