Repository Suggestions

I didn’t know where to put this but these are sort of "look and feel" issues if you use your imagination.

I have a few ideas on improving the Repository and wanted to get them down before I forgot them:

1. If we’re going to call it the "Repository," let’s be consistent and do that everywhere. This means changing all the references that say "Resources" and "MODx Resources" to "Repository," if they are referring to the Repository -- starting with the link at the top of this page, its tooltip, and the name of the folder/container the Repository is in (currently "Downloads/Resources") as shown in the breadcrumbs.

"Resources" is relatively vague compared to "Repository" and new users often won’t know what it refers to since the Wiki and the docs are also "resources."

2. Maybe it’s time to add 0.9.7 to the "compatibility" table for uploading Repository items? I’ve got two snippets that are 0.9.7 compatible but couldn’t choose that. Soon, there may be snippets that are *only* 0.9.7 compatible so we’ll need that option before long.

3. Maybe I’m doing something wrong, but I’ve included an image with the tags in the Repository instructions for one of my snippets (EZfaq). It works fine until I need to update the instructions or upload a new version. Then, when I save, the image link appears literally rather than showing the image and I have to go back in and re-enter the [img] tags to make it re-appear.

If there’s some way I can help make these changes (or some reason they shouldn’t be made), let me know.

Bob

@BobRay
Item 1. I am sure that Jason and Ryan will chime in here but I think that we should call them 3rd Party Addons or Community Developed Addons (Vs. Official Addons). I personally don’t like the term repository at all. It is confusing and we use all sorts of different terms and on top of it all the files are under download (which on most OS sites is completely separate from addons or extensions). As Bob says Resources is vague. This is worse than repository. Another thought would be to look at what common terms are used at big OS project sites like Mozilla and use the word Extensions but no matter what you do you need to define it clearly an stick to the definition. Lets call it what people expect no matter if it is by dictionary definition it is incorrect.

Item 2. Done. (but it may have to be changed if the API has any significant changes, not sure if it should be listed as 0.9.7 (Requires Post Release Testing) or a note should appear somewhere on the page. But I have updated the array. (Don’t kill me Ryan. )

Item 3. I know nothing about this. BBCode is not my friend.

Cheers,

Jay

Personally, I like Repository because it’s exactly what it is, a place to put stuff so people can find it. Per Websters: "A place, room, or container where something is deposited or stored."

It also is neutral with respect to whether the stuff there is officially sanctioned or not and it’s not easily confused with any other MODx site or spot, although it might help if it had a slightly different theme.

My main point, though, is that whatever we call it, we should be consistent.

Bob

Agreed on both the naming of the thing and the usability. I think we honestly set out to be a bit over-ambitious and could use some simplification. I tend to favor "add ons" as pretty much everyone can get that, and it further reinforces the important distinction between the core and third-party additions.

Addons
Add ons
Add-ons
?

Though, I certainly am not opposed to "extensions" either, though that might be a bit ambiguous to those coding cool stuff by extending the core classes. YMMV

There is a clear, and important distinction between add-ons and extensions in the upcoming releases. I personally think we should refer to both of these simply as components at the top level, and then add-ons and extensions will be the second-level classifications.

See http://modxcms.com/forums/index.php/topic,16135.msg103353.html#msg103353 for the original discussion on why this distinction is important.

Hoping that distinction will become clear in an edited post...

Also, it should avoid the use of Resources, which in 0.9.7+ = Documents -- Component Repository is fine though IMO.

Quote from: OpenGeek at Mar 15, 2008, 12:43 PM

Also, it should avoid the use of Resources, which in 0.9.7+ = Documents -- Component Repository is fine though IMO.

Component Repository is a nice compromise. It would help bring along the people who already know it as the Repository and I like the idea of calling them "components" since resources and elements are already used in 0.9.7. I also think it’s superior to "add-ons" since many of them are such integral parts of MODx (e.g. Wayfinder) and "add-on" makes me think of loosely coupled stuff like SMF, FoxyCart, and WordPress.

I wonder if it would work to call it just the "Repository" in links like the one on this page and put "MODx Component Repository" on it as a heading?

Bob

Quote from: BobRay at Mar 15, 2008, 03:56 PM

Component Repository is a nice compromise. It would help bring along the people who already know it as the Repository and I like the idea of calling them "components" since resources and elements are already used in 0.9.7. I also think it’s superior to "add-ons" since many of them are such integral parts of MODx (e.g. Wayfinder) and "add-on" makes me think of loosely coupled stuff like SMF, FoxyCart, and WordPress.

Actually after some more thought, we already have a new name for this, it’s the Web Transport Facility, and needs to be generic in this way since it means everything from transporting components to transporting core updates to transporting actual MODx content, or even custom xPDO data from custom data models.

And loose coupling is absolutely the goal here, and though some disagree with me on things like Wayfinder being an add-on, that’s exactly what it is. Same with Ditto. I’ve built plenty of sites with them, and I build plenty of sites without them. They are not part of MODx itself, thus they are add-ons. I don’t want MODx to be in the situation where the core framework and libraries are dependent on the viability (or even potential security flaws) of a single component someone wrote for it, shared with everyone, and most people think it should "be in the core".

As brilliant as they are, in really serious sites where optimization and speed are critical, some of the add-ons that are distributed with the core are simply too generic to really do some tasks in the most efficient way needed. This is typical of anything that tries to meet the needs of a great number of people, and I certainly do not mean that to sound in anyway insulting to the various authors and contributors to these components; I do use them and am grateful for them, but I also recognize they do not solve every problem, nor should they try. I just simply am saying it’s critical to keep component development and innovation alive by:

a) making it clear that the MODx core is a content management framework that should serve both component and content contributors (be they developers, designers, copy writers, or whatever) and focus on that, not all the various web application components everyone wants to have out of the box with their favorite CMS management interface,

b) that the distribution of everything else is either an add-on or an extension; even the index.php, the manager and connector directories are contexts and not part of the MODx core, they are "reference" implementations of the a web context, a manager context, and a connector (or service-oriented) context, but they are also not components; yet as content they can be transported and installed in the same manner as the components...

c) additional "reference" components will be developed, distributed, and supported by MODx itself through a project incubation process TBA in the near future, and all of the components distributed with MODx by default now will be available in various packages through the WTF

I guess what I’m getting at is there is more involved in going from our current "component-oriented repository" to one that also takes into account "content and data delivery".

Integration with external, stand-alone applications like SMF and Wordpress is another animal entirely; that’s not anything to do with loose coupling really; it’s just that a lack of application server features in PHP that can be utilized by many applications (identity, security, etc.) has driven most PHP applications to be very difficult to integrate with. The only true solutions to this are hacking up each app, web-services, or one standard framework for all PHP’ers (like Rails for the Ruby language); yeah right...

As for FoxyCart, this is already a web application built on a service-oriented architecture. This SOA approach represents the future of application integration IMHO.

Quote from: BobRay at Mar 15, 2008, 03:56 PM

I wonder if it would work to call it just the "Repository" in links like the one on this page and put "MODx Component Repository" on it as a heading?

I think the best idea would be to simply introduce WTF, and keep the legacy "MODx Component Repository" separate for the 0.9.6.x user-base that perhaps doesn’t want to make the leap to the next generation, or at least not right away. And referring to it as the Repository seems fine by me, but what do others think?

I think it makes sense to separate the new facility and give it a new name, but I think Web Transport Facility might not be the best choice for a variety of reasons (even if it’s a perfectly descriptive name).

For one thing, it sounds unfriendly and difficult. I think it will scare off potential users rather than sounding like a positive (which it definitely is). I wouldn’t want to go so far as calling it 10,000 elements in your pocket, but something more in that vein might be better. I appeal to the marketing team for suggestions.

There’s also its unfortunate acronym:

http://en.wiktionary.org/wiki/wtf

Although I have to admit that the possibility of writing, "Wtf is up with the WTF" when it’s down appeals to me.