mootools vs.jQuery discussion

Thanks for the answer, OpenGeek.

Most likely, it will be better, when the same library both in a system kernel, and in interface development will be used.
1. Will be less conflicts between libraries.
2. A site code will take less places (less essentially).

Not at all. The manager interface has its own context and has absolutely nothing to do with the front end context. MODx itself is not responsible for what you choose to do with your front-end pages.

The bottom line is that the developer is going to have to take responsibility for his design decisions. MODx isn’t going to do it for you.

I think some of the confusion is that some of the nice plugins and snippets use Mootools. I love AjaxSearch and MaxiGallery and both use MooTools, which is fine. The problem is that I couldn’t get anything of my own to work after days of playing around with it, so I switched to jQuery and got some nice Ajax stuff to work. Nothing fancy, just moving windows, etc.

The problem is now I am downloading MooTools and jQuery for some pages and that really adds weight that I don’t need. I have AjaxSearch on every page, so maybe we can petition to get a jQuery branch of AjaxSearch. That might help.

Anyway, that is my two bits.

Eric

The problem mentioned above might be a thing that is going to be ModX "weakness".

But i understand the filosofy, ModX should be the most flexible CMS out there.
Just trying to see what problems might arise in the future, and if i need to master Jquery or mootools

If you incist on keeping it totally open, alot of snippets, plugins, modules etc, that
get developed will have one version for each javascript library. I find that it might get
hard to maintain reliablity in the different versions and it probably will spawn different
programers for each javascript adopted version, and that might cause projects to die, giving
the open source modx newbie users alot of headache, and especially the support staff.

Also, when important components like quick edit or maxigallery uses a certain javascript library, it might
cause users to adopt their contributions to mootools just so that they dont have to rewrite quick edit
or maxigallery for the javascript library the would prefer to use.

It looks like that in my eyes, one javascript library will eventually rule the modx anyways.

This is a problem of perception cause by the inclusion of the default components with MODx (and yes, QuickEdit is included).

This is seen as positive by non-developers, as it makes it easy to quickly create something with MODx. It is completely negative in my mind, as it creates the perception that those default components represent the only way of doing things in MODx. This simply is not true, and by inclusion, these components, however handy to specific people, are going to turn others unnecessarily away. As a developer, I want a blank slate to work with; a framework that doesn’t get in the way. Not a bunch of generic, easy-to-use components from various sources that do way more than I may need or want them to for a specific task or site I’m developing. And as a part of a relatively small community of MODx component developers, I recognize that it is absolutely essential that we attract additional development talent to the platform at this early stage. Without this, the potential of MODx will be prematurely exhausted on the wrong target market IMHO.

In any case, I see developers creating and marketing a whole class of related components around specific javascript libraries for end-users that do not want to deal with such details. That’s what we want. That means we have attracted enough developers to the platform for innovation to continue, and more and more components will start to emerge and thrive.

Quote from: OpenGeek at Mar 11, 2008, 12:29 AM

This is a problem of perception cause by the inclusion of the default components with MODx (and yes, QuickEdit is included).

This is seen as positive by non-developers, as it makes it easy to quickly create something with MODx. It is completely negative in my mind, as it creates the perception that those default components represent the only way of doing things in MODx. This simply is not true, and by inclusion, these components, however handy to specific people, are going to turn others unnecessarily away.

I think that the responsibility lies in the presentation of the various aspects of what MODx is and what it can be. I wholeheartedly agree that people need to distinguish between the bundled addons (this is marketing) and the MODx core. There has been much responsibility taken on the part of the core team in documenting and getting users up and running and while I feel that a build should have an available set of addons shipped that a stripped dev-kit should be built as well and marketed as the next step against Cake, Symfony, Expression Engine or RoR. I know much of this will be happeing more readily in/with 0.9.7.

To get back to topic, I am not an AJAX guy at all but I think that if you have been building with MODx for a while that you have figured out what addons to install and which to leave out. Personally, QuickEdit will never see another install on one of my systems. I don’t see the point in Managers to edit in the front end when they can edit from the login and have a more linear entry plane.

Again, I agree with Jason that people need to not think of MODx as a set of boxes to tick/check but as a basis for whatever app you are building for yourself and/or your client. If you want to do mootools or do JQuery or ExtJS or the library of the month you can do it just be mindful that you may need to slim down the install bulk.
Quote from: OpenGeek at Mar 11, 2008, 12:29 AM

As a developer, I want a blank slate to work with; a framework that doesn’t get in the way. Not a bunch of generic, easy-to-use components from various sources that do way more than I may need or want them to for a specific task or site I’m developing.

This is a bit of a stretch because your "framework" is inherently a structure designed as a vision of one or more people. For someone with the intimate knowledge of the framework as the one who wrote/writes it is exhaustively useful. For those who approach it from afar--from the API or documentation missing the intimacy of the one who created it it will always be a greater challenge to learn. Honestly the idea of a blank slate personally bothers me as it is counterintuitive for a developer. The blank slate assumes that you have not already envisioned that canvas 100 times over in your mind, that you have never walked those steps with this function or that class or set of classes. Developers--at least good ones I have observed (I spout this off as a student of programming) generally operate on DRY for everything, hording away libraries, and classes and functions either in their head, in a file or in a larger library that they can grab and snatch for each "new" project.

As an example, I started building a CSS framework for my company and then BlueprintCSS came out then I tried it but now in its latest iteration I have found that the framework has become bigger than the problem it was intended to solve--to have a group be able to work on an agreed starting point for CSS based projects. Now it is file after file after file and a compressor and etc. I decided last project to abandon it, grab the latest version of Eric Meyer’s CSS Reset and rebuild my own starting point. Not a blank canvas but one that has been prepped and has the brushes set beside and one with the paints all out on the pallete.
Quote from: OpenGeek at Mar 11, 2008, 12:29 AM

In any case, I see developers creating and marketing a whole class of related components around specific javascript libraries for end-users that do not want to deal with such details. That’s what we want. That means we have attracted enough developers to the platform for innovation to continue, and more and more components will start to emerge and thrive.

True

Quote from: smashingred at Mar 11, 2008, 02:24 AM

Honestly the idea of a blank slate personally bothers me as it is counterintuitive for a developer. The blank slate assumes that you have not already envisioned that canvas 100 times over in your mind, that you have never walked those steps with this function or that class or set of classes. Developers--at least good ones I have observed (I spout this off as a student of programming) generally operate on DRY for everything, hording away libraries, and classes and functions either in their head, in a file or in a larger library that they can grab and snatch for each "new" project.

I think I meant blank slate in terms of components again. In other words nothing more than what is needed to start a project; the lowest common-denominator. This does not mean I want to reinvent the whole vehicle for every project; rather, I want an arsenal of techniques for transporting something from here to there when I start so I can choose the best one for the job at hand.

FWIW, I personally operate on DRY CRUD where KISSing made me realize YAGNI, though it might have been the ACID.

Quote from: smashingred at Mar 11, 2008, 02:24 AM

As an example, I started building a CSS framework for my company and then BlueprintCSS came out then I tried it but now in its latest iteration I have found that the framework has become bigger than the problem it was intended to solve--to have a group be able to work on an agreed starting point for CSS based projects. Now it is file after file after file and a compressor and etc. I decided last project to abandon it, grab the latest version of Eric Meyer’s CSS Reset and rebuild my own starting point. Not a blank canvas but one that has been prepped and has the brushes set beside and one with the paints all out on the pallete.

Right; you went back to the lowest common denominator. "I know I need help organizing all these CSS resources, so let’s try this way. It had some benefits, but ultimately it didn’t help, so let’s start over from the what we do know is minimally necessary for dealing with this..."

That’s how I view deploying a project with MODx. It helps me prototype solutions quickly, optimize them easily, and rearrange or change them dramatically with relative ease. But other than the basic data structures and CMS features, I want to start a project and be able to look into a library of reusable, building-block solutions that I or someone else has made for previous projects, picking and choosing only what I need, or seeing how a similar solution was crafted and quickly refactoring it for my needs. I do not want a one-size-fits-all blog, or login, or Ajax solution; I want to be able to pick and choose from an ever-growing variety of palletes and brushes that are easily utilized for very specific subjects.

In our case, the lowest common denominator is being a PHP CMS. Not a CSS framework, not an Ajax or Javascript framework, or even a PHP/ExtJS framework. Not a front-end editing solution for everyone. Not a blog tool. Not an image gallery. Not an online shopping cart. Just a PHP CMS. I want to continue to help make managing content easier for everyone involved in the process.

Quote from: OpenGeek at Mar 11, 2008, 03:23 AM

In our case, the lowest common denominator is being a PHP CMS. Not a CSS framework, not an Ajax or Javascript framework, or even a PHP/ExtJS framework. Not a front-end editing solution for everyone. Not a blog tool. Not an image gallery. Not an online shopping cart. Just a PHP CMS. I want to continue to help make managing content easier for everyone involved in the process.

Now the approach of developers of kernel MODx became definitively clear.
This approach reminds the approach of adherents of Unix which like to gather OS "from zero", in contrast to adherents of Windows who wish to receive ready to OS operation at once.
Then it is necessary to write in advertising, that "MODx is PHP CMS" first of all. And AJAX and other features are secondary things.

However site development includes not only handle of a content. There is still a weight of different necessary tools which should face the developer. These tools inseparably linked with a content. Certainly, they are original in different projects. Nobody argues with it. Additional time for handle of these tools is required a lot of. And time always does not suffice.

For this reason the simple site from distribution kit MODx is very useful starting point to Study MODx. It is a pity, that documentation release lags behind release of versions.

The guidelines would be not less useful, what toolkit of development is friendly in relation to MODx. For example, what JavaScript-libraries etc. which are discussed in the present topic. Experience of community concerning other tools of development is not less useful.

I find it odd that a CMS that "created" the slogan "AJax CMS" has decided to go for "php framework cms"

Anyhow, thank you the the detailed answeres, now i know what direction to go.

Well, it’s still easy to add your own AJAX, whatever you want it to be. I’ve added a very pretty paging data grid with a simple search to one site using extjs. I’ve done much the same thing on another site using mootools. It’s just that while MODx doesn’t do it for you, it makes it insanely easy to do whatever you want in that regard.