[eluser]WolfgangA[/eluser]
@esra
seems that you work really hard on finding a design pattern to bring together the php and js world.
I am also trying to find away to bring those both together.
My general approach as follows:
In CI, i create a sort of main page that:
- loads all required JS, CSS
- provides required html elements (mostly DIVs to house EXT components)
I think this is pretty similar to your example using complex.php and basically one can refer to this as the "application".
(So EXT JS takes over the View part of an MVC model.)
Once this main page is loaded, all actions are created in the EXT JS world.
This means, usally CI responds "only" to an XHR requests and returns just data in JSON (or XML).
(So CI takes over the MC part)
In fact this is not fully true, bc EXT itself is used in the C of the MVC as well.
So far so good:
But:
- modularzation is uneasy in the JS world. (i.e. a grid requires a datamodel and a colummodel that must match the data)
- multilanguage support is uneasy in the JS world. (i.e. a grid header label needs to be defined at construction time)
...given one wants an integration with CI / PHP backend wise
In other words: the JS code should be separated from the CI / PHP code, but on the other hand needs to interface to setup the JS components.
This really caused headaches to me.
Now looking to Matchbox and CFs viewlibray that helped a bit but does not solve those core issues:
Also i dislike writing tons of wrappers in php for EXT to build EXT components from PHP.
So my current approch as follows. Have a 2 stage loading process:
First Stage
==========
- Create a main page in the CI / PHP world that includes required JS, CSS and HTMl elements like DIVs as EXT UI container. (Which in fact is the application)
-- To do this use tools like to matchbox / modular separation. This would require a sort of modulemanger.
-- Each module can requests an UI (EXT) resource like a region, menu or tabpanel.
-- Each module provides UI components like a TreePanel, GridPanel, Contentpanel or menuItem which will be added/integrated to the requested UI resource.
-- the modulemanager takes care that the JS code gets loaded, together with resources like CSS and that the required HTML elements are created. Again the modulemanager gets this information from the modules.
At this stage, the page will not be initialized, because we miss some config options.
Second Stage:
=============
Now that the page and the JS files are loaded, the JS components needs to be initialized.
However, we need the config options for the UI elements, bc these are not part of the 1st stage loader.
- Because EXT 2.0 allows the creation of components using config objects in JSON notation, after this happend the main page sends an XHR request to get all configuration options. This is in the responsibilty of the modulemanager to ask the modules what they need. Response will be JSON stored in a JS object.
-- All JS code including core layout and module is written to reference the global config object that is populated via XHR. This includes also language specific strings like panel header, gridheader etc.
-- The JS world gets initialized.
From this point, the "application" has started and the will send only requests to the php world via XHR. In other words, CI controller methods will be called that in turn will usally respond with JSON or XML.
Note: Of cause one could create a JSON string in the first stage that contains config and language options. But i would not want them to be visible in a script tag. Also, the XHR method would be more flexible IMHO.
Any comments are welcome
Regards
Wolfgang
