I was a little disappointed with tonight's presentation/conversation. We spent most of the night looking at how a few people have hacked together updated versions of JQuery and JQuery plugins with some custom code thrown in. The general message seemed to be JQuery is cool. Use it.
For those less familiar with JQuery, I'd like to reiterate the need for caution building on anything that other than the version of JQuery included in core. The way JQuery and JQuery plugins are updated in Drupal is basically chaos at this point. IMHO, this is in large part because because the normal CVS policies of "no third party code" are not enforced on JQuery or JQuery plugins. Because of the pace of change/improvement in JQuery and JQuery plugins, module developers will often role specific versions of plugins into their module. These updated plugins often be dependent on a specific version of JQuery. Just like Drupal's user contributed module have dependencies, JQuery plugins have dependencies. Once you move beyond the version of JQuery included with core and install your first module with a JQuery plugin rolled in you've entered the wild west.
AFAIK, there is still no standard for modules to report their JQuery version or plugin dependencies. Any other module can include/require a newer or older version of the same plugin. JQuery will only load one version of the plugin. My understanding is that JQuery uses the first instance of the plugin. Beyond the obvious issue of sending unnecessary duplicate code to the client, modules using the same JQuery plugins are essentially shooting it out for the version of these plugins loaded. Developers can alter the load order of their modules in an attempt to get compatible version of plugins loaded first, but as modules using JQuery plugins show up as being updated in Update Status, it is going to get increasing unclear for users who go down the "JQuery is cool" path.
JQuery IS cool, but the inconsistently enforced CVS policy and way the Drupal module developers are currently rolling plugins into modules is not.
If I'm wrong about any of this, I'd love to know about it.
Comments
basically right - cvs policy intricacies
I agree with your main points about jquery and compatibility being an area where it is very easy to add in bugs, inconsistencies, and generally break your site. They are also perhaps harder for the average user to debug. I don't like javascript effects very much so I just avoid them, but I know that's not what site users want, so... I hope that with jQuery becoming more mature we will see less and less of this compatibility/plugin problem.
The one part where I disagree is that the CVS policy being inconsistently enforced. The CVS policy is something like:
Really good reasons are currently limited to:
1. It's very difficult to get the exact version needed from a third party site (e.g. only available via svn like "svn co -r 123123 http://somesvnrepo.example.com/some/repo/path/hard/to/remember" )
2. You have forked the project. (Edit - that's another reason that's "allowed" - thanks for the reminder)
Based on the GHOP security report and the id3 software's inclusion of unsafe files in their example directory, I proposed including the id3 library in the audio module download but that hasn't been taken any further. That's a case where "making user sites safe by default" would be the really good reason.
Given my knowledge of your involvement with the project I imagine you are looking at this from the lense of the TinyMCE project issues you experienced last year. TinyMCE had a good reason to include the third party packages, but it seemed at the time like many folks felt it wasn't a really good reason. I think people were also recovering from the TinyMCE-drama related to the different maintainers and concerned with any deviations from "standard practice" taken with the module. Also, TinyMCE can easily be downloaded from a third party site...
Does that help explain the CVS policy situation? If not, we should move the discussion to the infra queue. No need to further pull off-topic from your points jquery compatibility.
--
Open Prediction Markets | Drupal Dashboard
knaddison blog | Morris Animal Foundation
Not a disappointment at all
I have to disagree with your first sentence ... quite completely! The presentation was informative and the conversation that it prompted was productive. The forum that we have at the DBUG is intended to prompt these types of discussions and present information about topics that are not in the average Drupal administrator's use. You are more advanced in the development of Drupal than many of the people at the event (certainly that goes for me) and, as such, have much to contribute to the conversations that take place.
Mike did a good job of giving the group an intro to JQuery and the PingV group showed some good examples of how they were using it successfully.
Your points about the "state of the art" on this feature set are well taken and have great possibilities for further conversation (which would also be valuable, as Greg points out above) and we can bring them up at subsequent meetings. Sometimes the topics that are presented are not going to be just the basic items, but bleeding edge items to show some of the possibilities that are available. This presentation falls into that category. It was certainly a case of "JQuery is cool. Use it." ... which was intended to be the message.
It is wonderful that a forum like this is available to us all and that these conversations can take place.
Also, I would extend an invitation to you to make a presentation to the group on some subject that would be of interest and it will hopefully create vibrant exchange as did this one.
See you next time ... Paul
Paul is basically making my
Paul is basically making my point for me. If someone is going to present something advanced like JQuery to newer Drupal users, they are doing the community a disservice if they don't include a disclaimer about the current issues. I would never present anything about TinyMCE without explaining the issues that go along with building on it as well as including it in work for clients.
To review, my points are...
If you agree with those points, you can stop reading now.
If Mike had done his basics of JQuery presentation and then showed how JQuery was used in Drupal, I wouldn't have gotten much from it but I'd feel like it was a solid presentation for new users. But the Drupal + JQuery part of the presentation was really confusing. Mike basically stuffed a perfectly functional site into Drupal that used all custom JQuery. The JQuery demos Kevin and the rest of the PingV crew showed were amazing implementations, but they required a lot of custom coding. Neither demo was an approach that many people can/should follow... but neither presenter said this.
My comments about CVS and the lack of consistency were directed mainly to Andy since he has a bit of influence in revising or universally enforcing those policies. Greg is right that much of my frustration stems from my attempts to improve TinyMCE the same way the WordPress developers have been improving it... by including a custom version of the TinyMCE code in the WordPress distribution. The TinyMCE download available from Moxiecode is always changing includes hundreds of k of code Drupal users don't need, and it has to be manually edited or patched to truly get it to work well with Drupal.
I use a customized version of TinyMCE in my projects I know several other developers who do this as well. TinyMCE is insanely popular despite all its flaws, but the developers improving it can't collaborate like the modules that are using JQuery plugins without hosting our own version control system. Borris has volunteered some SVN space, but I have been putting that off hoping that some progress might be made on either the CVS policies or a change in the way modules declare third party dependencies.
During my attempts to make the case for an exception to the CVS policy for TinyMCE (highlights of the thread here), I pointed out that Jeff Robins was violating the CVS policy by including JQuery in the JQuery Update module. Gerhard agreed. Jeff's response was that the people enforcing that policy were on crack and he was going to keep including .js files in his modules.
Derek Wright has outline a few different approaches third party code could be handled, but I doubt think anyone is going to make fixing the core issue with the CVS policies or JQuery plugins a priority when they can just ignore the policy.
Has any developer that has asked for a CVS exception gotten one? It seems like the policy is pointless when developers who just violate it can get "cool" functionality into their modules... despite creating an unsustainable environment in the process.
My only real point with this post is that promoting JQuery without explaining these issues doesn't help move the community towards a solution... unless the goal is to get JQuery plugins rolled into even more modules so we see more conflicts and get this issue to the boiling point sooner.
I'm not trying to detract from people who take the time to prepare a presentation. I'm just trying to offer some constructive criticism. If the technology you are demonstrating is going to lead users into a world of issues and conflicts, it could still be great demostration... just be upfront about that. Julian Tschannen's presentation about Drupal as a Wiki or Ken Richard's XML, Mashups, and Drupal-as-Platform are great examples of this. Both guys showed some really cool technology they had hacked together, but took the time to explain the issues associated with building on what they had done.
As this topic is really more
As this topic is really more about Drupal and jQuery than about the D/BUG, may I suggest taking this discussion over to http://groups.drupal.org/javascript where javascript improvements are discussed and more focused constructive discussion might be had?
Laura
pingVision, LLC
PINGV | Strategy • Design • Drupal Development
one other good reason - and how a message is delivered
Much as I like and respect jjeff, he doesn't set the policy. Gerhard does with the help and advice of community members. If you have an issue with a specific module, I suggest you file it in infrastructure queue and start it off with "Dear CVS Repository Manager Killes, a few projects came to my attention..." He generally appreciates it when people help him police contrib.
If you have forked TinyMCE (a small fork is still a fork) then that makes your version acceptable to be in the CVS repository AFAIK. But you'll have to be ready for people to disagree with that. Community means community input which isn't always easy to deal with...which brings me to...
I think that the way you are delivering your message about this meeting and jQuery is a bit harsh and even rude to Paul and Mike and whomever else presented. Throwing "I'm not trying to detract" on the end doesn't help when you spend a fair amount of two long posts detracting. I suggest that instead of saying that a meeting was disappointing (especially starting the discussion with that!) that you suggest ways to make the meeting work better.
Drupal User Groups have always had this struggle (at least everyone I've attended or heard about has) where there are the "hard core" people who want to talk about the benefits of some inane detail of Drupal and then there are people who can be summed up as "Drupal, sounds cool. I saw a job post for that. I think I'll go and see what it is." More of my thoughts on that here since I feel it's a broader topic deserving broader discussion.
And of course, if you feel some important piece is missing from the conversation - speak up! Unless the meetings have changed a lot in the last 6 months I don't think your point of view on this would be excluded.
--
Open Prediction Markets | Drupal Dashboard
knaddison blog | Morris Animal Foundation
I agree with what greggles
I agree with what greggles says here. However, I also want to add -- to clarify my previous comment -- that discussions on how the D/BUG meetings can be improved are most welcome. We're all volunteering and participating out of shared interests. That discussion has a place here, imho. I just believe that the part of the thread here on jQuery handling in Drupal, and CVS policies, might more productively be taken elsewhere.
Laura
pingVision, LLC
PINGV | Strategy • Design • Drupal Development
politics aside
Speaking as someone who has absolutely no idea about the politics of JQuery, I will pass on one bit of feedback regarding this past DBUG.
The JQuery topic was divided into two parts, last night: Mike introduced JQuery and then Pingpeople showed off some projects. I felt there was a fair gap between "what is JQuery" and "look at this really cool stuff we're doing."
Ideal flow:
Steps 1 and 3 were well presented, respectively, but I think step 2 was largely missed and left a disconnect.
My two apolitical cents.
bc
The Great Divide
I definitely agree with this, but the question is how many people are represented in that middle group? I think a lot of this goes back to the article Greg wrote on the the makeup of the attendees of these groups, which appears to center around two humps, the "What is Drupal, and how can I use it to help run my site" people and the "Thrombulating Widgitizers" (or whatever he referred to them as). I do think there could have been something to ease the gap between the "this is how you get the DOM element for a div" part of the talk and "lets track the positioning of a cursor inside this div to determine what percentage of the total width marker x sits at then make ajax calls to the server and update the vote tally on the fly". The being said, you also risk entering no mans land there, where you're above the heads of that first hump, and still not piquing the interest of the people on the second hump.
I honestly don't know if there's enough interest as a group to do this, but I for one would be really interested in seeing members of this group get together and do more coding or presentations geared towards more advanced topics. The Drupal 6 bug squashing session last time AjK was in town is a good example of this(which unfortunately I wasn't able to attend). I think there is a wealth of good Drupal developers in the area, and I think it would be great to see more collaboration on things. If there is interest in doing this I think we should consider scheduling some events that fit this mold. Because of the geographic diversity of this group, I'm not sure how feasible it would be to do that kind of thing on the same night as the regular meetings, but perhaps we could do in addition to the regularly scheduled meetings. I definitely think there's a value to meetings which are more accessible to everyone, and we should be careful not to close the gate on those people.
Just the new guys $0.02
-Brad
a non-humper
i'm one of those not represented in one of the two humps -- maybe not even really "in between"; i'm an experienced developer, not intimidated by languages i don't know (e.g. PHP and JavaScript); i'm not moving quickly with Drupal, but i have patience to wait for my modest time investment to mature; the get-togethers seem like one of the better places to put this time, and i most appreciate activities along the lines of code review and best technical practices; these are the kind of things that will help me toward the level i'm used to achieving with new tools
i also want to express appreciation for this little thread, which has illuminated for me some of the dynamics, challenges and strengths of the Drupal community
I'm really not interested in
I'm really not interested in investing more of my time in trying to solve the CVS/JQuery plugin/third party code problem. After talking to a number of people publicly and privately about this, I've just accepted that this is not something I can change. All I can do is make more people in the community aware of the problem and try to warn other Drupal users that building on JQuery Update and modules that roll JQuery plugins into the module will likely create conflicts down the line.
I've re-read what I've posted so far and I really don't find feel like I've insulted anyone... unless disagreeing is insulting.
I was simply trying to offer a word of caution to the "JQuery is cool!" message I felt the presenters left the people attending with. Since this is the group that most of the people attending belong to, it seemed like the appropriate place to post that information.
If the group wants to revisit JQuery at some point, I'd be glad to demonstrate how the average Drupal user can add some cool effects to a theme that only utilize the version of JQuery included in core. The effects won't be as cool as what PingV did onthe PopSci site, but they also won't have dependency on JQuery plugins taht have been rolled into specific modules you may not want to continue using in the future.
For what it's worth, the
For what it's worth, the VotingAPI widget I showed off at the meetup does not depend on any jQuery plugins and would run just fine on the jQuery version that comes with Drupal 5.6 by default. We do have jquery_update running on that site, but that doesn't mean all scripts on the site require it.