mootools vs.jQuery discussion - My Forums

Re: mootools vs.jQuery discussion

Jelen — Sep 02, 2009, 12:21 AM

Hey, i’m using YSHOUT and MAxi gallery on same page

and I think i have the same problem.

The Yshout doesn’t display when i’m calling maxigallery slimbox

I’m using this to call snippet :
[!MaxiGallery? &display=`embedded` &embedtype=`slimbox` &pics_per_row=`3` &max_thumb_size=`110` &max_pic_size=`0` &thumb_use_dropshadow=`1`!]

and when I add a disable java, Yshout works, but slimbox doesn’t show in the way it showe before

i this the problem with two jquery libraries

Re: mootools vs.jQuery discussion

iRolf — Dec 26, 2008, 09:41 AM

Hi all,
I’m noob-not-sure, if this is the right context to place a note that figure out how the "jQuery, jQuery" proclaimers will become their part of the show.
Maybe somewhere else an equal posting was placed already, but I noticed this thread today while searching for a 0.9.6.3/mootools/gallery problem that I coudn’t fix the "mootools way". I integrated the SmoothGallery for mootools into a snippet, that automatically collects images from a given folder, but that gallery always delivered an error within the mootools.js

So I decided to use jQuery and the innerfade plugin. That works like a charme, even with QuickEdit and ajaxSearch in the frontend.

So this is my solution:
All you have to do, is to capsule your jQuery scripts within the jQuery namespace -- just like mentioned before:

(function($){

//    ...PLACE YOUR jQUERY STUFF HERE...

})(jQuery);

regards,
iRolf

Re: mootools vs.jQuery discussion

smashingred — Mar 11, 2008, 08:51 AM

Quote from: beryl at Mar 11, 2008, 09:53 AM

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.

There is the catch in marketing a tool that people are passionate about. A successful project becomes what the users experience no matter what marketing is used to promote, present or lure. Ultimately the marketing needs to correctly present the brand that most effectively represents the meaning of MODx and that has to be inline with user perception or it will confuse or frustrate. Personally I would like to see the whole focus on AJAX and gadgetry disappear and shift focus back onto flexibility, ease of use and extensibility with freedom for developers instead.

I don’t think you will see MODx abandon a packaged release but I think better than that you will start seeing builds and addons for one flavour or another of AJAX or JSON or the as I call the library of the month.

I don’t foresee MODx sidestepping into the realm of PHP Rapid Application Framework although I plan on using it somewhat as such on a personal project.

I am speaking personally and not for the MODx team when I say that I have grown to appreciate Jason’s POV on shipping MODx as a clean/prepped canvas, while at the same time I know that solution packages are essential to the migration of new users to MODx--I was one. I barely understood how to read an API until recently and that is all thanks to the snippets and plugins that come with MODx. I have taken my PHP "skills" to new levels and do so on every project.

The point is that MODx is whatever you make it into. I can’t wait until I can devises custom builds for client deployments and I don’t need to weed out the junk at every install.

Re: mootools vs.jQuery discussion

sottwell — Mar 11, 2008, 08:35 AM

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.

Re: mootools vs.jQuery discussion

beryl — Mar 11, 2008, 04:53 AM

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.

Re: mootools vs.jQuery discussion

traveller — Mar 11, 2008, 03:41 AM

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.

Re: mootools vs.jQuery discussion

opengeek — Mar 10, 2008, 10:23 PM

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.

Re: mootools vs.jQuery discussion

smashingred — Mar 10, 2008, 09:24 PM

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

Re: mootools vs.jQuery discussion

opengeek — Mar 10, 2008, 07:29 PM

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.

Re: mootools vs.jQuery discussion

beryl — Mar 10, 2008, 06:07 PM

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.