MODX Staff
Each context can define a custom assets folder as well (i.e. manager/assets/) and this is only for presentation artifacts.
As for add-ons, I’m considering where the best location for snippet logic is, and I believe it belongs in the core, separated distinctly from the presentation.
In addition, there is going to be a mechanism for aggregating physical resources and data into installable packages with custom itineraries that describe their installation.
MODX Staff
You can create a separate front controller (like the current index.php) for each context or you can have one controller handle requests to multiple contexts. It was designed specifically that way, and the idea is to always have the constants MODX_BASE_PATH, MODX_ASSETS_PATH, MODX_MANAGER_PATH, etc. available from any context, while the config values could be overridden by context when applicable... and components could take advantage of both local contextual values, as well as the ones for the ’controlling’ or ’primary’ context. I’m trying to make that as flexible as possible...
Does it mean that each context will reside in its own folder? That would make sense when combined with presentation templates and optional add-ons’ template files. But then, will a multi-language site with country specific subdomains (just for example) have to be split into separate contexts and, thus, folders? What if all subdomains will have exactly the same templating?
The real issue is separating the domain model from the views and controllers, and keeping them loosely coupled. This is why the piece about distributing physical packages of all these disparate file and db resources is so important IMO...
I agree that add-ons belong to the core. They are common for all contexts. But also I do remember that you put stress on scaling the core down to the bare engine and putting all non-critical functionality in addons. Following this logic it would be natural to separate the core and extensions to achieve a clean and easily maintainable architecture. So, I would go for separate folders as I described above.
Well, no, these are separate issues; the packages would store the physical files and their dependencies to other files and/or database records, along with an intinerary for installation on a target. The database records, to avoid MySQL platform dependencies, will be stored as PHP code that, when executed, rebuild the object instances in the deployment it is installed/imported into. These are then saved to the new db via the xPDO scaffolding according to the itinerary (which can be a chain of PHP scripts and/or interactive events that present UI in the installer). There would also be a package building interface for constructing the packages.
Does it mean a way to distribute packages of files, chunks, snippets and tvs that form a solution? I think I recall you answered to that question already somewhere (probably multiple times) but want to get an explicit answer. If so, does it mean there will also be a way to work on chunks, tvs and snippets from outside manager? I mean, I would be more than happy if I could work just on physical files instead of database fields displayed in a textarea.
the idea is to always have the constants MODX_BASE_PATH, MODX_ASSETS_PATH, MODX_MANAGER_PATH, etc. available from any context, while the config values could be overridden by context when applicable... and components could take advantage of both local contextual values, as well as the ones for the ’controlling’ or ’primary’ context.
the packages would store the physical files and their dependencies to other files and/or database records, along with an intinerary for installation on a target. (..) There would also be a package building interface for constructing the packages.
As for file-system access, I plan to eventually enable protocol-based access (i.e. WebDAV/DeltaV, FTP, etc.) to the database-managed content,
I am also working on a way to optionally store the content for all the element types (snippets, chunks, templates, etc.) on the file system directly, as opposed to storing it in the content table itself. But this would likely be as a copy of the current revision constructed from the database, and I have not yet solved how writes directly to those files on the filesystem could be detected by MODx so it could create a new revision, etc. Could definitely be done, but I think protocol access to the database managed content is the better option in the long run.
The alternative approach for file-system access, would be to use MODx as a framework only, and create individual PHP files that bootstrap the MODx class and use only the parts of the framework they need, per file. I plan to use this in conjunction with context support to make it much easier to use MODx within existing PHP scripts that are not built in a MVC paradigm (e.g. MODx menus in WordPress).
Remember the more feedback the better on this, just to make sure these ideas are the right way to go. So feel free to pick what I’m saying apart...
If you put the add-ons (i’m assuming snippets, modules, etc) in the core, then some snippets and modules might not function properly if the core is placed outside the document root because AjaxSearch for instance, includes javascript which is included in pages.
/core (can go anywhere, even outside the web server document root)
As for add-ons, I’m considering where the best location for snippet logic is, and I believe it belongs in the core, separated distinctly from the presentation.
Question: After only briefly looking over the 0.9.7 architecture I may not know what I’m talking about yet. But would it be possible to create a new xPDO class that, instead of making tables in the database, it would make files on the system? I imagine you’ve already considered that, but just thought I’d bring it in to the thread
I am also working on a way to optionally store the content for all the element types (snippets, chunks, templates, etc.) on the file system directly, as opposed to storing it in the content table itself.
MODX Staff
That’s what the context-specific assets directories are for: containing all the web resources that would have to be served from directories accessible by the web server. It would be the responsibility of the import/export mechanisms to a) define the specific location within an assets directory it would live and b) decide if the web resource would be imported into the ’main’ assets directory (defined by MODX_ASSETS_PATH), or allow the $modx->config[’assets_path’] to define it’s root location, which can be overridden by context (i.e. if I wanted to import a component only into a specific context such as the ’mgr’ context).
So I propose that if the add-ons are not to remain in the assets/ directory, it should be placed in it’s own directory (like ’add-ons/’) which is user-defineable.
Well, the file caching mechanisms in xPDO and the MODx extension of xPDO (yes, class modX extends xPDO) already write executable PHP code to file. This is used in writing the script elements (modSnippet, modPlugin, modModule) to file (as functions) to be included, rather than having the source loaded in memory for all scripts, and being eval()’d each time. It’s also used for the database result set caching, which stores the entire PHP object, including content, as a PHP file in the cache.
Quote from: OpenGeek at Jan 24, 2007, 02:15 PMQuestion: After only briefly looking over the 0.9.7 architecture I may not know what I’m talking about yet. But would it be possible to create a new xPDO class that, instead of making tables in the database, it would make files on the system? I imagine you’ve already considered that, but just thought I’d bring it in to the thread
I am also working on a way to optionally store the content for all the element types (snippets, chunks, templates, etc.) on the file system directly, as opposed to storing it in the content table itself.
xPDO looks very cool btw!
Ah, that part confused me..... So let me get this straight: There is a base (core shall we say) assets directory where core snippets, modules are stored, and then on top of that will be an additional assets directory where more snippets can be stored? Or is there just one?
That’s what the context-specific assets directories are for: containing all the web resources that would have to be served from directories accessible by the web server.
MODX Staff
Typically, it would be one, shared by all contexts, but the ability to override that by context, and isolate some physical web resources to a particular context, might come in handy...
Ah, that part confused me..... So let me get this straight: There is a base (core shall we say) assets directory where core snippets, modules are stored, and then on top of that will be an additional assets directory where more snippets can be stored? Or is there just one?