Reuse Patterns between Sencha Touch, Ext and Sencha Architect
I am in the process of trying to determine specific patterns of reuse between different project structures based on Sencha Touch, Ext and Sencha Architect.
Specifically, I am trying to achieve the following high-level design:
Generally, there will be only one Commons project, differentiating between Ext (desktop) and Sencha Touch (mobile) specific APIs via packages/namespaces, and providing all common models, stores and utilities, as well as controllers, though most business logic will likely be abstracted to models to best facilitate reuse.
- Commons project
This project will consist of shared APIs including Models, Stores, Controllers, Views, Templates etc. The project will be implemented independent of Sencha Architect, and focused solely on providing tested, reusable common APIs.
- Ext based Desktop Web Applications
These projects will target Ext 4.1+ and will be built with Sencha Architect. They will contain application specific Views and Controllers, while also leveraging shared APIs from the Commons project; including, but not limited to, Models, Stores and Views.
- Sencha Touch 2 based Mobile Web Applications
These projects will target Sencha Touch 2.1+ and will be built with Sencha Architect. Likewise, these projects would also contain application specific views and controllers, while leveraging shared APIs from the common projects.
There could be one or many Sencha Touch 2 Mobile Web Application projects, as well as one or many Ext Desktop application projects; all of which will share source APIs from the Commons project.
After having tried a few different approaches to achieve this design, I am finding there are some issues with regards to API compatibility when importing shared code (via Ext.Loader) in Sencha Architect.
Specifically, an SA project using Ext (4-4.1.1) does not recognize config properties of imported source, whereas Sencha Touch 2+ projects do. Thus, config properties either need to be added as both configs as well as direct properties of classes when imported, otherwise, such properties are not recognized by an Ext (4-4.1.1) project in Sencha Architect. I have attempted to implement a shim preprocessor to augment imported class configs onto the class' prototype etc., but such an approach is likely to cause more problems than it solves, and has many limitations as augmentation does not go thru the full class pipeline and so forth.
In addition to this, irrespective of the above issue, it seems source code imported via Ext.Loader is not recognized by any of Sencha Architect's IDE features; e.g. the Inspectors, Toolbox etc. This issue is consistent regardless of the framework targeted when using Sencha Architect. While I imagine this to be due to imported source not containing an associated metadata file to be read by Sencha Architect, it is limiting in terms of reusing code created independently from Sencha Architect; i.e. reusing code in the typical sense rather than via Sencha Architect's requirements. That said, when in Rome... so if this is to be expected, it is understandable, but it is good to know for certain either way.
Thus, my question is, can one reuse shared code created independent of Sencha Architect within a Sencha Architect project and take advantage of Sencha Architect's IDE features? Additionally, is it possible to do so without the need to generate XDC files for each class created outside of Sencha Architect?
Perhaps I am missing something crucial here as I am rather new to Sencha, though based on my understanding it appears Sencha Architect is most beneficial for use when source is created exclusively within Sencha Architect, and the above project structures I have mentioned may be more suited when not using Sencha Architect. Would this be an accurate assumption?
Any recommendations for achieving the above project structure or something of a similar nature, or confirming that my findings are correct, would be greatly appreciated.
The config system in ST2 prevents reuse. There are other things like Container's control, etc.
you could potentially use some utilities, model field definitions, language, etc.
Thanks, Jay, you're insight is very much appreciated.
Just to clarify, are you confirming that my findings regarding the specific reuse patterns described above are correct? That is, is this particular design is not well suited for use with Sencha? If so, please just let me know so I can explore other options rather than explore this particular approach further.
Tags for this Thread