Even I’m not following it, but I resent your comment. So basically you’d rather we were spending our time helping users rather than discussing within a mixed-ability group matters that some other users won’t understand or want to understand? And "our" user base is becoming the MODx community. (I fail to see how it works the other way around.) People can help each other out. No support is owed to anyone. We have to have our eye on the future, and this discussion originated from a link posted by an member of the user base. We are in the "Development & Coding" forum here. This is what this forum is about. This is not at all intended for the typical CMS user.
While I marvel with great interest (and esteem) at the forward looking intentions of these posts, I can’t halp but question whether or not this debate is far too esoteric for the typical CMS user ... I wish such talented capacities were being applied to the guidance of the MODx community that is becoming your user base.
Even I’m not following it, but I resent your comment. So basically you’d rather we were spending our time helping users rather than discussing within a mixed-ability group matters that some other users won’t understand or want to understand? And "our" user base is becoming the MODx community. (I fail to see how it works the other way around.) People can help each other out. No support is owed to anyone. We have to have our eye on the future, and this discussion originated from a link posted by an member of the user base. We are in the "Development & Coding" forum here. This is what this forum is about. This is not at all intended for the typical CMS user.
Without the dev-team doing things you can NOW call "masturbating intellects" there would never be anything for the "common user" to use, and no opportunity for this kind of "amusement" either.
[I found this thread amusing because I AM the typical CMS user who would like to gain a better understanding of the use and capabilities, but not just to serve my own interests, nor for an opportunity to masturbate my intellect.
Without the dev-team doing things you can NOW call "masturbating intellects" there would never be anything for the "common user" to use, and no opportunity for this kind of "amusement" either.
Just keep that in mind. And if you can’t keep up, keep out. There is neither need nor right to call the developers to supporting-tasks. They do more of that stuff than any other developers I’ve seen so far.
☆ A M B ☆
MODX Staff
Yes, yes, yes, and yes. Even more so, I thought the thread was about the implementation and approach to templating suggested by the author, being compared and contrasted with the MODx implementation and approach (and beyond, or anything related to it).
Indeed, all very good stuff. I just don’t understand what this thread is actually about.
Is it the templating system? Is it the fact that snippets may return HTML, and hypothetically a large site may be cluttered and confusing? Is it that a particular MODx website might get messy, or is it that the MODx core’s a bit messy? Or is it just reminding us that there’s a reason we use MODx rather than just writing pure PHP?
What I meant to get across is that without sacrificing compatibility with existing add-ons, and the approaches they’ve taken, the way it works behind the scenes is completely changing for all of the reasons I’ve described in this thread, and more. And I truly believe the benefits to all of the issues being raised about templating in this thread, and many others in this community, will be addressed by this new underlying architecture.
The only way I can reconcile OpenGeek’s point with what he originally said in response to the hypothetical snippet clutter issue is for it to be summarised as "Nothing is being changed in how the templates work. What we’re working on instead is a load of funky cool stuff to do with databases and object-oriented stuff which has no actual bearing on the templating", only it missed out the "Nothing is being changed in how the templates work" part.
That’s precisely what I was trying to explain (sorry, I tend to think very abstractly quite often, and have a hard time describing these things in common language at times); part of the planned core improvements include the ability to define external files to represent the content of an object, the ability to control the precise content-type of every component that returns content, as well as import and export a package of objects and objects related to those objects (a document, it’s template, the chunks it uses, the snippets it uses, etc.), including external file resources in the package where applicable. So by simply defining relationships between these objects in the data model, you can easily import and export packages of related objects, in any format you want. With a proper admin interface on it, you can then easily provide silent the ability to import a package exported by someone else that includes everything needed to duplicate their creation -- the navigation script, a chunk of CSS or a CSS document, a collection of HTML sub-elements serving as templates, and maybe a help page or other admin interface that goes along with it and gets imported into the manager context.
@OpenGeek - What part of Silent’s post did you agree with? Given that he talked about wanting to import a navigation system, and talked purely about the management and sharing of snippets and similar things added into MODx (what he now terms subsystems), what relevance did talking about improvements to the core fit into this? I was assuming there was some relevance and therefore assumed that you were talking about snippets, given that that was tillda’s area of concern too. This therefore means that your conclusion that we’ll be able to "import and export objects and exchange them with other MODxers via whatever agnostic data format we choose, be it executable PHP, XML, YAML, JSON, or whatever else becomes popular for a while, and this same import/export can be utilized to easily define and distribute vertical solutions of just about any kind" doesn’t actually help silent crib the navigation snippet from another site in any way. Or does it?
So by simply defining relationships between these objects in the data model, you can easily import and export packages of related objects, in any format you want. With a proper admin interface on it, you can then easily provide silent the ability to import a package exported by someone else that includes everything needed to duplicate their creation -- the navigation script, a chunk of CSS or a CSS document, a collection of HTML sub-elements serving as templates, and maybe a help page or other admin interface that goes along with it and gets imported into the manager context.Jaah: That’s exactly what I’m dreaming of! Being more talented in abstracting/analyzing than practising or coding I can only make a guess, bot no plan of how to do it.
This gutsy statement deserves another donation.
our goal needs to squarely be on making a killer framework. We’ll gladly sacrifice massive uptake and "market share" for a platform that stands a chance of making it in the long term. We want to see MODx around in 10 years, and I honestly don’t think where it stands today will take us there. It’s time to make some serious changes for the better.
☆ A M B ☆
