Quote from: PaulGregory at Aug 31, 2006, 06:13 PM
See, very often there is presentation logic that is most efficiently executed at the same time as other logic. If you make a rigid separation between "applying presentation" and "producing output from data according to logic", you risk stopping "producing output with presentation applied". Which actually means that instead of there being one place to go to to find the date/time snippet, you have to look at some PHP code and a mini-template.
Where is the benefit?
I’m clueless as to what you mean here in regards to the topic at hand, which is the implementation of the templating system itself. Nothing I said included making a rigid separation between those concepts, nor would I ever. I was arguing just the contrary, that MODx provides the framework for you to approach templating in just about anyway you want to. That is the benefit.
Quote from: PaulGregory at Aug 31, 2006, 06:13 PM
And if you switch to objects... what? I want to pass a datestamp to MyDateMyWay and use the output in another.. object. And I want a class around Date and a class around Time. My understanding of objects is that I would have to first set the input time on one line and then I could get each output. This seems quite far away from the existing snippet format - which is largely function based. That just doesn’t sound like MODx any more.
And what’s with the object-sharing? What the heck is wrong with sharing snippets etc? I just don’t get the need to change. I like MODx and what you are talking about sounds so far removed from what I like about MODx that it freaks me out.
I just think you’re missing the point of what I’m talking about that is changing. In fact, it’s not different on the surface at all, so don’t freak out (not sure why you are). All it does is make maintaining, evolving, and extending the core of MODx itself much easier, more enjoyable, and more prone to collaborative development. And, I hope will help make MODx a more realistic choice for serious PHP developers.
It’s just the core I’m discussing that is going to be implemented in an object-oriented way, not that snippets are becoming objects or anything like that, though being able to manipulate objects like any other snippet parameter or placeholder is already possible in MODx. But to stay on topic, rather than a endless spaghetti stream of redundant core code that must be hacked in 12 places to change very simple things, you can simply extend core classes to modify their behavior, or extend it in some creative way (i.e. modDynamicSnippet extends modSnippet = a snippet that parses any tags in the PHP source before execution, or modAjaxResource extends modResource could return XML or JSON representations of any core or custom class). By encapsulating this core behavior, the development of snippets is benefited, by a more consistent approach to the API and a centralized place to modify or extend the behavior of things. Something that is painful at best now when working with or extending the core of MODx, and IMO, still painful when developing snippets with the rather ad hoc API that have been stuffed into one huge class.
Other benefits of objectifying persistent data classes (or your model): it makes working with them in more generic ways (form generation/processing, table generation/processing, etc.) possible, making snippets more applicable to more situations; and it can certainly help in opening new possibilities for caching and other performance improvements. I’ve used the concepts on several live sites with a significant number of custom data objects, and accomplished some very cool things that I think might also make you freak out when you see them, but in a happier kind of way.
An example, the data layer can generate instant models or API’s of any database, making the data instantly available to you in the same familiar way as any core data in this new MODx core, built on top of PDO. I’ve used it to design a custom calendar system I’m going to release soon, to reverse-engineer the db’s of WordPress, MD-Pro, and even a commercial Flash gallery toolset with a MySQL backend, and then use the generated API’s to write snippets, single-page scripts to migrate data, to develop a single new class to loosely integrate two user systems, or to extend a single method in my user class to change the way it works.
Once you have this ability to create and manage models, or business logic layers, in the same simple and intuitive way MODx makes designing XHTML/CSS layouts, presentation of the model via snippets, chunks, and such becomes much more focused on presentation as it should, while still allowing access to the model in what I think are revolutionary ways, all made possible by combining these changes (which are all either MVC-derivatives or based on other proven or emerging design patterns) I’m trying to describe with the existing way MODx works.
I could go on, but the benefits of object-orientation, design-patterns, and these other things I’m describing, are in my mind, indisputable.
Quote from: silent at Aug 31, 2006, 06:43 PM
The other practical issue I see here is the handling of snippets/plugins/modules which tend to become "subsystems" like Ditto. More than once I found it more difficult to handle these components than MODx itself. And I argue that there is a tendency behind that. If, for instance, I compare Wayfinder with its predecessor DropMenu, the latter was more self-contained. Wayfinder uses chunks to store its config-params, and those chunks use special WF-tags. It works, ok, but I fear if this tendency continues, only a few gurus will be able to find out why and how it works... 
The degree of expertise required to accomplish something with MODx is increasing. And there are good reasons to reflect the causes for that - and possible consequences.
I think it’s just the opposite; it’s getting less complex to develop better custom solutions with it. I don’t think any of us contributing here are in the business of providing out-of-the-box solutions on top of the MODx framework that are easy for everyone to use. I contribute to it so I can do what I do, which is make a living from developing and maintaining custom database-driven web sites with it.
MODX Staff
And even more than that: It could function as a "proof of concept":
MODX Staff
