Quote from: PaulGregory at Dec 18, 2006, 06:25 PM
on the side issues raised in this thread
This is a fundamental that needs addressing. I would argue that MODx as rewritten by Jason is the CMF; MODx as expanded upon by Mark et al is the CMS.
Absolutely, I agree, and supplement that with the observation that the CMF and the CMS add-ons can only be made better by respecting the symbiotic relationships that exist between them, not avoiding them, which is where I was originally going with this conversation. This push and pull of CMF architecture and CMS component helps shape a more robust API.
Quote from: PaulGregory at Dec 18, 2006, 06:25 PM
Yes, "core snippets" is wrong, but they’re not just "example snippets". If they were example snippets they would be heavily documented Hello World jobs. They are more like the common applications in Linux distros, there because they are useful rather than because they are good examples. If I’m following posts elsewhere correctly, Jason doesn’t use any of the snippets from the main distribution. From that perspective, it would be very easy to underestimate their significance to the average MODx user, and their significance to the wider MODx system.
Agreed again, and I fully retract my use of the word example. I meant no disrespect, and I most certainly do use these contributions. I think I may have been exaggerating something to make a point that it should be clear what the difference is to a new MODx user. It’s just a hard thing to describe concisely, and a long session with the Visual Thesaurus hasn’t proven fruitful in providing a better word for them than what I already use in many places. I think
add-on or possibly
component, are the simplest and most concise, and should be the official terminology. As we move forward, we’ll see the reason for this clarify as Resources, Elements, and anything else represented in your Model (aka Domain Model, Data Model, or M in MVC), can be combined into packages that need a concise name, regardless if they are distributed with the framework or as a separate package. I think Add-ons or Add-on packages is the best choice to represent all the possibilities generically enough.
Quote from: PaulGregory at Dec 18, 2006, 06:25 PM
The MODx documentation should be purely about the framework, with a few pointers to the Repo.
The Repo should contain sufficient information about add-ons from the author(s) and source code... of course, there are no compiled parts to MODx so there’s no real distinction.
Yep, the distinction needs to be increased in many ways, and is part of the reason this is coming up as a separate point.
Quote from: PaulGregory at Dec 18, 2006, 06:25 PM
Work-in-progress (betas) and official support should be hosted wherever is most convenient for the author. This may of course be a commercial application and/or support from the author might be on a commercial basis.
User-generated user-to-user support may additionally be in the MODx forum, and that seems to be the natural place for communication between MODx users.
User-generated documentation should be in the Wiki.
It might be that authors prefer to use the forum as the place that they host betas and give support.
In the specific case of Ditto, I don’t think that the Ditto pages in the main MODx documentation ’fit’, but other than that everything seems to follow sensible practices for a project of this scale.
I would also argue that people are more likely to contribute towards hosting costs if it is the centre of their MODx world rather than if it’s just a place that they download updates to the core from.
Again, agreed, and especially this last point. It should absolutely serve as the central point of aggregated information for MODx. It just should not be the resource bottleneck for every possible subproject or idea someone has in conjunction with it.
MODX Staff