Quote from: PaulGregory at Aug 20, 2006, 12:18 PM
Right. For the benefit of OpenGeek et al. There are 2 benefits to the "single template", and it is important that we don’t mix them up.
1: It is quicker to edit one file / on one screen than opening and closing umpteen chunks.
Leaving Ditto to one side, Wayfinder would be much easier and quicker to tweak if there was just one file to change rather than half a dozen. Creating/opening and then editing and saving all the various chunks is not fun. Having them all open at the same time would have the same benefit, and so yes I will have a look sometime soon at knocking that out.
2: It is easier to edit the complete desired output as a whole rather than in parts.
Well, it’s easier to design, certainly. But I think we’ve pretty much agreed that a series of code variables is easier and more efficient to process than a single block of code. I doubt any of us would seriously suggest having a routine that split up a PhotoShop file into a header, repeating background and footer on every page. No, you export the files once and reuse them.
...
The single file solution
There are presently two places to set variables: the snippet call, and in the snippet itself. A third method - loading from another file/chunk specified in the snippet call would indeed be great. As I have said before, I believe this should be part of MODx rather than part of Ditto.
Now we’re talking benefits; and thanks for the input Paul. I agree that these are benefits indeed, and the approaches being discussed would work for the interim, I suppose.
But let me say that a better solution to this problem, in my perspective, is to have an integrated editor of related templates and subtemplates, aggregated into one view, which is constructed from the pieces and resaved as the individual, reusable elements they are best represented by in the database. You could even have a tree to navigate to various sections, or out to say, other types of editable elements represented by tags (snippets, TV’s) that are used in the template.
This was my approach/goal for 1.0 in this regard. Without an approach like this, proper versioning and multi-cultural management of such content would be impossible. This is also why I argue we should stay away from additional methods of introducing themes/templates, and start moving towards staying consistent with the storage and retrieval of all content managed by MODx, letting the user interfaces do the work of managing that data for ease of use issues. This ultimately allows complete optimization of the rendering and caching processes for the front-end, and offloads it to the content management interfaces, where it belongs.
Quote from: Mark at Aug 20, 2006, 01:56 PM
If there were a tool that converted an XML template to a file containing separate chunk values, then this would be even better.
This is possible but would require a plugin to say on changing a chunk to flush out the cache...
Again, all part of the move to becoming consistent with our storage and retrieval methods, so caching and other important aspects can be better managed by the core. This is why a single, consistent API into the persistent data managed by MODx is so important; without it, we are forced into the solutions being suggested here.
So don’t take what I am saying as resistant, just trying to find the best path to solve this now without complicating future migratation efforts of our core snippets and every snippet someone creates based on the core snippets.
MODX Staff
MODX Staff