Posted by druroot on September 15, 2011 at 9:45pm
I wanted to create a place for us to post running session ideas so we know what people want to hear about and who may be available to talk about it. I posted a few ideas here mostly from the September meeting, but please leave a comment below if you have ideas on something cool that you'd like to hear about, or if you'd like to volunteer to talk about something posted here.
Tilemill - slotted for October Meeting [jonathanmd]
Javascript API - slotted for November meeting [druroot]
media module(s)
node.js
commerce
Comments
Titanium for Mobile
Great idea Andrew. My geeky friends that do serious mobile work think this is where they are headed: http://www.appcelerator.com/products/titanium-mobile-application-develop...
Susan | Better modules through revenue-share: Crafted, Curated, Contributed
Here's a couple of talks that I'd like to see
A talk that I could give is:
- Developing with your Debugger
Rich Yumul
Sage Tree Solutions
www.sagetree.net
Drupal Javascript!
I'd like to hear more about drupal behaviors and javascript in D7.
Drupal and JavaScript and Require/Common
Yes yes, me too. This is very much needed, I couldn't agree more.
Use the source
This seems to be the main entry point for the drupal.org Javascript docs: http://drupal.org/node/751740
Drupal does a lot for you in the area of AJAX on forms, but if you want to do something that somehow breaks the rules, you wind up having to write your own js. There is not a lot of good documentation that I've found.
Drupal gives you a lot less help with other javascript tasks. Behaviors are not complex at all. I used the following shell script to count the number of lines of actual javascript in drupal.js (blank lines and comments excluded):
sed '/^ **/d ; /^ *\//d ; /\S/! d' drupal.js | wc -lI got 148 lines. Reading all of that is a project for an afternoon. (For some reason one of the backslashes is getting eaten. There should be a backslash between the two stars in the first regex.)
Some of the best documentation is in the source code. These files all have extensive comments, as well as the actual code that makes it work:
includes/ajax.inc
misc/ajax.js
misc/drupal.js
You can probably get to the same source code comments somewhere on drupal.org, but it can be hard to find. You're probably better off just firing up a source code editor and starting at the top of those files.
The Examples module is also good for seeing an actual implementation that works.
Theming
I would love to give a talk on theming. I am not sure what people want to hear about...
One topic that I have wanted to talk about for awhile is building a theme from the ground up and avoiding as much bloat as possible. When I was new to drupal I would attend all of the theming talks but they always talked about using zen or skinnr which imo makes drupal even more bloated for not much benefit. But I am open to any topic the community wants to learn about...
I also second the comment about Drupal and Javascript. This seems to be a pretty poorly documented subject and I would love to learn more. Or if someone could point me to some documentation I could read up and speak about it.
-Rich
http://tragicmedia.com
Theming from the ground up
Theming from the ground up would be useful. Also theming "gotchas" like not forgetting to include $message in your theme page.tpl.php.
I would also focus more on theming for Drupal 7 and differences from 6 to 7. Things like how we now have to use the render function for our regions: render($page['content']).
Oh and since you've done some big sites and lots of themes, a good way to organize your theme directory such as grouping your theme tpls into a sub directory.
Nice, yea that all sounds
Nice, yea that all sounds really good! If this is something that people feel there will be an interest in, I am definitely down to put something together!
-Rich
http://tragicmedia.com
Omega theme
Andy mentioned the Omega theme at the meeting, and we got a fair bit of positive feedback during the "mixer" phase of the meeting. Sounds like an overview of Omega, perhaps in a collaborative format, would find lots of interest.
I've worked with Omega and can show a few little bits, but I am definitely not an expert, nor even a themer. But I am willing to work with someone to make an Omega talk happen.
--
Christoph Weber
We're building the SANDcamp
We're building the SANDcamp site on Omega. I'd be willing to work with you on the talk if no one else is up to it.
That would be awesome!
That would be awesome! gaslamp has also mentioned he'd contribute. I'll hit both of you up via email and we'll get this off the ground.
--
Christoph Weber
node.js
Node.js is a really cool technology. It's kind of hard to wrap your head around, but this presentation does probably as good a job as one can possibly do at laying the concepts bare:
http://www.yuiblog.com/blog/2010/05/20/video-dahl/
I think you need to have some fairly sophisticated knowledge of computer systems to really understand why it works so well and to have the "aha!" moment. Also some background in programming languages to see why it needed to be done in Javascript. It took some serious outside-the-box thinking to realize that the V8 Javascript interpreter had the potential to reinvent server programming.
Having had the "aha!" moment already, the presentation I'd like to see is about what actual node.js code looks like. It's not obvious that this topsy-turvy programming model is amenable to writing real servers. And for what kinds of projects should you be looking at creating your own server in node.js? Drupal programming treats the server as a black box. It's not obvious why Drupal developers need to care about something as low-level and apparently specialized as node.js.
but what about client side js common, require, jQ, moo etc ?
because interoperability between Drupal develped sites and js technologies elsewhere is a must, especially for developers wishing to enrich the D front end.
Did you turn down the idea of discussing js and Drupal for some reason? It looked like you said that. Saying, "just look at the code," to learn about javascript techniques and methods is kinda like flippin' the bird up a bit. Could you comment on that please?
Sorry, wrong context
Sorry about that. I think I meant that as a reply to tragic.rich's comment that "if someone could point me to some documentation I could read up and speak about it." I must have attached it to your post by mistake.
I read up on the
I read up on the documentation. A lot of it was focused around using js in a drupal custom module, particularly using drupal's AHAH functionality with the forms api. The best thing I could find was this page on javascript in drupal 7: http://drupal.org/node/756722
But I don't know that there is enough data there to create a talk focused on client-side scripting techniques...
-Rich
http://tragicmedia.com
Drupal javascript
The only significant documentation I've found on the basic Drupal javascript API is in the code comments in misc/drupal.js.
The major use I've found for behaviors is to put your startup code in the attach function, rather than in the page ready handler. To do this, you make up a name, let's say myBehaviors, and then:
Drupal.behaviors.myBehaviors = {attach: function(context, settings) { /* ... */ }
};
Attach gets called first on page load, and then every time new elements are loaded via ajax. The idea is to use the attach function to set up event handlers, apply css classes, etc, on document elements. Things that you normally do in the ready handler. The context argument is the root of whatever is new. So your jQuery selector should include the context:
(function($) {$('#someElement', context).append(...);
})(jQuery);
Apparently, even if you use the context properly, you're supposed to treat the attach() function as if it could run multiple times on the same element.
I think the settings argument is basically the same as Drupal.settings.
There is also a detach, but I have not yet found a use for it.
That's basically all there is to behaviors.
Programming in Drupal javascript is not like programming Drupal in PHP, where there is a complex system around you. It's 99% the same as javascript without Drupal. Except with ajax, which is a little bit more developed. There are a few interesting-looking utility functions in drupal.js, but I've only really had a use for Drupal.behaviors.attach. (Although I wish I'd known about that getSelection function. I think I unwittingly re-implemented that at one point.)
It would be interesting to know if there are any good uses for Drupal.theme(). It looks like there is only one default theme hook, which wraps em tags around your text.
Nice! Definitely worth
Nice! Definitely worth bringing up in a topic discussion, but I think that having a whole discussion on client-side js and Drupal would be a rather short. If someone wanted to speak about using javascript when building a custom module I think there is a lot more to discuss there. Specifically how to properly add js to your module and how to use AHAH with the forms api...but I do think it would be cool to touch on js best practices if we end up doing an advanced theming session of any sort.
-Rich
http://tragicmedia.com
Maybe a lightning talk?
Looking through the *.js files that are included with Drupal core, it looks like most of them are there to accomplish some narrow task in the UI. There are a couple things that you might be able to bend to your own purposes, like autocomplete or the progress bar. But I don't think there's much reason to prefer something in core versus bringing in an outside library.
I think the Drupal.behaviors
I think the Drupal.behaviors is definitely one of the most important Drupal/JS concepts, I think there are several lesser known JS features in Drupal and I'm really interested in learning about the lesser known features. Things such as Drupal.checkPlain, Drupal.t, Drupal.formatPlural, Drupal.theme, Drupal.freezeHeight, tabledrag, progressbar, verticaltabs, etc.
checkPlain, t, formatPlural,
checkPlain, t, formatPlural, and theme:
These are javascript versions of the similarly-named PHP functions in the server-side API.
This is freezeHeight:
<?php/**
* Freeze the current body height (as minimum height). Used to prevent
* unnecessary upwards scrolling when doing DOM manipulations.
*/
Drupal.freezeHeight = function () {
Drupal.unfreezeHeight();
$('<div id="freeze-height"></div>').css({
position: 'absolute',
top: '0px',
left: '0px',
width: '1px',
height: $('body').css('height')
}).appendTo('body');
};
?>
tabledrag, etc, are widgets used in the core UI. If you like them, you can use them in your app. But I don't think there's any reason to prefer them over widgets you can get elsewhere, which are probably better documented and more configurable.
While I am familiar with
While I am familiar with checkPlain, t, formatPlural, theme, etc. I think many people in the Drupal community may not be aware that those functions also exist in Javascript. Like you hint to the fact that the Javascript functionality built into Drupal may not be as well documented, I think this is the perfect opportunity to make this more known and documented in the community. With regards to using the built in widgets/functionality over functionality found elsewhere I disagree to some extent because I think there is some value in having consistent user experiences. While concepts such as drag and drop re-ordering are simple for us, some end users might be thrown off if each module used a slightly different interface. Also the only way for the existing JS functionality to get better is for more people to use it, find bugs and short comings, and contribute to it.
Points well taken.
Points well taken. However, I think most of the javascript widgets in core are used in the admin interfaces, so the users of your Drupal site will not necessarily be using them. One exception I can think of is the widget that allows you to add to and rearrange multiple-valued fields. Another is vertical tabs, which shows up by default at the bottom of node forms. Tabs that appear on top, though, like an old-fashioned filing cabinet, are equally, if not more, familiar to users, IMO. You can get that look with the jquery-ui library that comes with core.
I am curious to know if anyone is actually using things like Drupal.theme(). Are themes providing client-side theme hooks? There doesn't appear to be client-side versions of the theme hooks provided by core. I would definitely love to see a presentation from somebody who has actually put these functions to good use. That would imply that they are doing some pretty sophisticated things on the client.
It's a good topic
I'm sure that somebody could put together a worthwhile talk on the subject of client-side Drupal. Even talking about the things you need to implement yourself, because Drupal doesn't do them, could potentially be beneficial.
talking about things you need
Props and thanks NealB. I'm pleased to hear the DUG be willing to hear needs in addition to demo uses. I don't know where else would have such discussion :-) Can't wait to be there.
"Settings passed locally to Javascript behaviors"
From http://drupal.org/update/modules/6/7#local_settings_behaviors:
...interesting to me as I am just starting to understand Drupal.behaviors as I implement JS in Drupal.
Steve Oliver
I looked through the Drupal
I looked through the Drupal source code to investigate the local settings argument, and it looks like there won't be many cases where it differs from Drupal.settings. Modules can specify their own settings when they respond to ajax page requests, but I think they usually don't, and it defaults to Drupal.settings. I actually would rather use Drupal.settings if that's what I want, because it removes any uncertainty.
Javascript in drupal
I can't find a project for Scriptaculous, MooTools, SocketIO or any non jQuery modules.
But I should look before I leap; this was an announce to discuss javascript in Nov, not an up/down debate. Sorry.
I know that the nodejs module
I know that the nodejs module uses socket.io.
perhaps poorly named
it's integration is still in very early stages, and it's future development is unknown to me, but sockets will be nice to use that's a certainty
in the future a require.js and common.js architecture for front end libraries should either replace or extend whatever the D7 behaviors or Javascript API is (i don't know which, but then I don't know how much D7 has in it's architecture).
Maybe the node.js module would be the best place to start developing it.
Drupal's methods for AJAX behavior are NOT such an architecture in D6, or in D7 for node.js at least. It is a distinct back-end from the Drupal system so Dx nodes, menus, permissions, hooks and other structures aren't executed in any similar manner.
I would like to know what could be moving in this direction : http://requirejs.org/docs/api.html : and what modules will exist to offer capabilities and practices like that to Drupal, and when?
Thanks.
Not sure if that's client or server
Come to think of it, I'm not sure if the nodejs module uses socket.io on the client. I know the server uses it.
Looking for a Drupal Web Developer that loves soccer?
I am looking to meet a Drupal web developer that loves soccer for a potential partnership and business deal.
I'd be interested in talking
I'd be interested in talking about responsive themes and omega/delta in particular for Drupal 7.
Gaslamp Media - San Diego Drupal
Ideas from Feb 13, 2013 meeting
The SD DUG meeting on Feb 13, 2013 was focused on topics that we'll be interested in discussing in future meetings. A lot of good topics were suggested. This is a list of the ones I captured. My apologies for the ideas that I missed, but feel free to add them by replying to this comment.
1. Core Modules
2. Drupal 8 previews with emphasis on helping us plan ahead
3. Mollom and other spam solutions
4. Backup & Recovery
5. Test environments
6. Drush
7. Basics of MySQL, phpMyAdmin and other administrative tools
8. Administrative dashboards, with emphasis on Content Management
9. Discovery & Architecture
10. Brainstorming solutions for specific member problems
11. Experiences with Pantheon
12. Organic Groups
13. Performance Tools (including APC and Varnish)
14. Hosting (e.g., transition pathways from small to large sites, and shared hosting to managed hosting)
15. Solr
Other activities discussed:
1. Social activities such as Happy Hours, where people can informally share interesting topics and sites
2. Sprints. Sample sprints included (a) building a non-profit site, (b) fixing a web-site, and (c) Drupal core contributions
On Discovery and Architecture
Susan and I have been playing with the idea of training people on Discovery and Architecture using the Sandcamp website. Just an idea at the moment, but it would be nice to know if sddug members are interested.
Re: On Discovery and Architecture
I'm interested