that is used to provide the WYSIWYG editing is implemented by the browser rendering engine and not javascript. Raj From drupal-devel at webchick.net Wed May 27 05:23:43 2009 From: drupal-devel at webchick.net (Angela Byron) Date: Wed, 27 May 2009 01:23:43 -0400 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-7 Message-ID: Bonsoir, devel list! It's been a *stupidly* long time since our last interim Drupal 7 unstable release. Sorry about that! I'm going to go ahead and blame this on taxes. And traveling. And a general lack of delicious ice cream in my freezer. It's a tragedy, really. But the *good* news is that DRUPAL-7-0-UNSTABLE-7 is jam packed full of awesomeness! That's right! JAM packed! The complete commit log is attached. There's also a full list of API changes in UNSTABLE-7 at http://drupal.org/node/224333#UNSTABLE-7 We are just about at the *three-month mark* until code freeze. That means the time to make your wildest Drupal dreams come true is RIGHT NOW. Check out the Drupal core initiatives page at http://drupal.org/community-initiatives/drupal-core to see what folks are tackling now if you're looking for a place to jump in. Or, feel free to add your own! Ok. Here we go! Changes for developers: ======================= - A spangly new Job Queue API which allows for batch processing of items. See http://api.drupal.org/api/group/queue/7 for more info. - Some nice performance improvements: o SimpleTest module no longer has to instantiate every test class in order to simply read its metadata. $memory_usage--; o There's now a taxonomy_vocabulary_load_multiple(), user_delete_multiple() to improve performance around massive amounts of these types of data. o Drupal now serves more sensible headrs for reverse proxies. o Core now defaults to using MySQL's InnoDB storage engine rather than MyISAM. - A new centralized static caching mechanism, so we don't need to litter $reset parameters all over the dang place. - New hooks hook_node_access_records_alter() and hook_node_grants_alter() to allow for complex interactions between multiple node access modules. - Field API improvements, including a pluggable storage mechanism, increased test coverage, and de-coupling from Form API. - Lots of DBTNG conversions. Less than 10 more to go! http://bit.ly/DBTNG_Conversion Yeehaw!! - Tests for OpenID module. We actually got a lot of tests, but these were *extra* awesome (and sorely needed), so I wanted to mention them specially here. ;) Changes for themers: ==================== - There are now nice extra body classes added to match a page's template suggestions. So for example node/1/edit would give you classes of page-node, page-node-edit, and page-node-1. The Zen theme offers this too in Drupal 6. - box.tpl.php is DEAD. DEAD, my friends! In its place are far more sensible theme_comment_form_box() and theme_search_results_listing(). That's right. There was absolutely nothing about box.tpl.php that had anything to do with block.module. Go figure. - A whole gaggle of formerly "special" things are now just regular old blocks. Footer message, feature-specific help text, mission statement, and even $content! This means they can be more precisely positioned and have the same configurable visibility as other blocks in the system. Changes for users: ================== - Those tired and ugly collapsed fieldsets on the node form have now become nice looking and useful Vertical Tabs! See http://buytaert.net/drupal-7-usability-update for a screeshot. - The horrible frankenstein "dumping ground of random crap" monster that is the default "Navigation" menu has now been split up into: o User menu: Contains "My account" and "Logout" links. This is positioned in the upper-right corner. o Management menu: Contains "Add new content" (formerly "Create content") and "Administer" links. Think of this as the "do stuff" menu. o Navigation menu: The same as before, but now at least with fewer links! :D - There's a slick new input format selector. Goodbye, 3-foot long collapsed fieldset with radios showing every godforsaken option known to mankind, hello compact, JS-ified select box! - There's a new top-level "International" administration menu for any localization/translation-related modules to put their stuff and a "Development" administration menu for developer tools. - On the permissions page, permissions checked for authenticated users will auto-check the same permissions for all other roles on the client side. This helps make it more obvious to people what checking that box actually does. - Removed Clean URL choice from installer. Seriously, are you ever going to opt *not* to have Clean URLs? If so, there's a settings page for that. :P - Some security improvements: o A watchdog event is now fired whenever modules are enabled/ disabled. o PHP module is now the "global killswitch" for whether users can use PHP anywhere in the system. Catch you next month, Drupalistas! :D -Angie -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: DRUPAL-7-0-UNSTABLE-7.txt URL: -------------- next part -------------- From m at ooh.dk Wed May 27 10:16:09 2009 From: m at ooh.dk (=?UTF-8?B?TWlra2VsIEjDuGdo?=) Date: Wed, 27 May 2009 12:16:09 +0200 Subject: [development] Status update: WYSIWYG support in Drupal core In-Reply-To: <4A1C11BB.9000104@garfieldtech.com> References: <074101c9db71$8b539d70$0200a8c0@structworks.com> <4e983be00905240619v9076e99kdd0a0798e1a2b97b@mail.gmail.com> <4A19920D.6@cmsreport.com> <4A19AA41.5050705@funnymonkey.com> <7e270cea0905241712s43dede3cw1555d71765d10667@mail.gmail.com> <7e270cea0905241733i7903e6fhfc9e3c4d0ded4ea8@mail.gmail.com> <5A208C59-85D6-403C-ADD2-44AD76B07356@standoutdesign.nl> <4A1AB403.5070000@funnymonkey.com> <3adc77210905250825x4840869ew63cb4d5a5cde8da2@mail.gmail.com> <4A1C11BB.9000104@garfieldtech.com> Message-ID: <52d800cd0905270316q908924an88d32516a9eeb0ef@mail.gmail.com> On Tue, May 26, 2009 at 5:58 PM, larry at garfieldtech.com wrote: > Yours is not the only use case or workflow that Drupal needs to support. > ?Whoever you are or whatever your use case, that statement still holds true. > > --Larry Garfield I think that is spot on, and perhaps should be promoted to the official motto of this list. For the record, I do not think that having WYSIWYG in core is the way to go. I'm quite comfortable with being able to tack on Markdown, with or without helpful buttons, WYSIWYG with HTMLawed or just use plain text based on customer preference. I think having the WYSIWYG API in core would be encouraging a specific workflow that core has no business encouraging. More importantly, I think the default response to any sort of "add x to core" shoud be a loud and resounding "NO". In my opinion, core should be as slim and lean as possible. We might consider having more distributions, like "Drupal ready to go with WYSIWYG, blog and image gallery", but adding that to the code weight being dragged around across thousands of servers would be wasteful. Saying "no" to adding more stuff to core would actually be a great way to reduce your carbon emissions ;) -- Kind regards, Mikkel H?gh From syscrusher at 4th.com Wed May 27 12:47:05 2009 From: syscrusher at 4th.com (Syscrusher) Date: Wed, 27 May 2009 08:47:05 -0400 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-7 In-Reply-To: (sfid-20090527_012449_428150_2E7E7B88) References: (sfid-20090527_012449_428150_2E7E7B88) Message-ID: <1243428425.7643.54.camel@marcus> On Wed, 2009-05-27 at 01:23 -0400, Angela Byron wrote: > - Those tired and ugly collapsed fieldsets on the node form have now > become nice looking and useful Vertical Tabs! See > http://buytaert.net/drupal-7-usability-update > for a screeshot. I like this a lot for the standard node authoring, publishing info, and so on, but I have a question. Will contrib modules still have a way to generate the old-style full-width fieldset? I have a couple of modules that I maintain whose node dialogs won't fit very well into the narrower space. Again, I'm not criticizing the new design, which I like very much, just trying to figure out my best option for adapting my modules. Thanks! Scott -- Syscrusher From drewish at katherinehouse.com Wed May 27 15:56:01 2009 From: drewish at katherinehouse.com (andrew morton) Date: Wed, 27 May 2009 11:56:01 -0400 Subject: [development] Status update: WYSIWYG support in Drupal core In-Reply-To: <52d800cd0905270316q908924an88d32516a9eeb0ef@mail.gmail.com> References: <074101c9db71$8b539d70$0200a8c0@structworks.com> <4A19920D.6@cmsreport.com> <4A19AA41.5050705@funnymonkey.com> <7e270cea0905241712s43dede3cw1555d71765d10667@mail.gmail.com> <7e270cea0905241733i7903e6fhfc9e3c4d0ded4ea8@mail.gmail.com> <5A208C59-85D6-403C-ADD2-44AD76B07356@standoutdesign.nl> <4A1AB403.5070000@funnymonkey.com> <3adc77210905250825x4840869ew63cb4d5a5cde8da2@mail.gmail.com> <4A1C11BB.9000104@garfieldtech.com> <52d800cd0905270316q908924an88d32516a9eeb0ef@mail.gmail.com> Message-ID: On Wed, May 27, 2009 at 6:16 AM, Mikkel H?gh wrote: > More importantly, I think the default response to any sort of "add x > to core" shoud be a loud and resounding "NO". In my opinion, core > should be as slim and lean as possible. We might consider having more > distributions, like "Drupal ready to go with WYSIWYG, blog and image > gallery", but adding that to the code weight being dragged around > across thousands of servers would be wasteful. Not to pick on you specifically but I think this kind of a rigid, absolute thinking is actually as harmful to the project as the idea that core should be all things to all people. In my mind core should be about providing APIs that enable contrib. So while I'd agree that Drupal core should probably not ship with a WYSIWYG editor, it should provide APIs to make it easy to add them in contrib--the subject of this thread is WYSIWYG support after all. Any time you have 5-10 modules doing roughly the same thing in incompatible ways it's time to look at creating core APIs to allow them to work together and not duplicate the same functionality. The successful examples that come to my mind are node access modules from 4.7 to 5 and file modules from 6 to 7 (though it remains to be seen how well the file API works in practice). andrew From dmitrig01 at gmail.com Thu May 28 01:52:09 2009 From: dmitrig01 at gmail.com (Dmitri G) Date: Wed, 27 May 2009 18:52:09 -0700 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-7 In-Reply-To: <1243428425.7643.54.camel@marcus> References: <1243428425.7643.54.camel@marcus> Message-ID: <9d2095ce0905271852q114be17dub94d7914216c22ed@mail.gmail.com> Yep, either works. It'd be nicer to have it in the vertical tabs, so I think you should try it first. Dmitri On Wed, May 27, 2009 at 5:47 AM, Syscrusher wrote: > On Wed, 2009-05-27 at 01:23 -0400, Angela Byron wrote: > > - Those tired and ugly collapsed fieldsets on the node form have now > > become nice looking and useful Vertical Tabs! See > > http://buytaert.net/drupal-7-usability-update > > for a screeshot. > > > I like this a lot for the standard node authoring, publishing info, and > so on, but I have a question. Will contrib modules still have a way to > generate the old-style full-width fieldset? I have a couple of modules > that I maintain whose node dialogs won't fit very well into the narrower > space. > > Again, I'm not criticizing the new design, which I like very much, just > trying to figure out my best option for adapting my modules. Thanks! > > Scott > -- > Syscrusher > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From caleb at caleboconnell.com Thu May 28 03:28:14 2009 From: caleb at caleboconnell.com (Caleb O'Connell) Date: Wed, 27 May 2009 23:28:14 -0400 Subject: [development] noderefernace cck Message-ID: <200905272328.14404.caleb@caleboconnell.com> I am looking to get info about the cck module in drupal. I've been trying to write a cck module that will basically do the exact same as nodereference but with two free entry text fields to go along with it. Basically, one field to be the noderef lookup and two to add prices to associate to the referred field. I wasn't sure who I could get in touch with in the cck development who is familiar with this so I can ask some questions about where to put the code I want in place to make the custom module I was looking for. Thanks again in advance. -- -- Caleb Dylan O'Connell -- caleb at caleboconnell.com -- 207.319.4746 -- http://blog.caleboconnell.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewberry at sentex.net Thu May 28 03:55:03 2009 From: andrewberry at sentex.net (Andrew Berry) Date: Wed, 27 May 2009 23:55:03 -0400 Subject: [development] noderefernace cck In-Reply-To: <200905272328.14404.caleb@caleboconnell.com> References: <200905272328.14404.caleb@caleboconnell.com> Message-ID: Take a look at filefield and imagefield. You should be able to extend nodereference in the same way. On 27-May-09, at 11:28 PM, "Caleb O'Connell" wrote: > I am looking to get info about the cck module in drupal. I've been > trying to write a cck module that will basically do the exact same > as nodereference but with two free entry text fields to go along > with it. Basically, one field to be the noderef lookup and two to > add prices to associate to the referred field. I wasn't sure who I > could get in touch with in the cck development who is familiar with > this so I can ask some questions about where to put the code I want > in place to make the custom module I was looking for. Thanks again > in advance. > > -- > -- Caleb Dylan O'Connell > -- caleb at caleboconnell.com > -- 207.319.4746 > -- http://blog.caleboconnell.com From ernst.pluess at gmail.com Thu May 28 07:30:47 2009 From: ernst.pluess at gmail.com (=?ISO-8859-1?Q?Ernst_Pl=FCss?=) Date: Thu, 28 May 2009 09:30:47 +0200 Subject: [development] preprocess page doesn't take all variables Message-ID: <27c534c90905280030m33e5b653ya2cd5555913fa90f@mail.gmail.com> Hi I'm trying to do a simple thing in D6: Add a variable to the page template. Unfortunately it seams, that it gets lost in theme_render_template. This is my code in the template.php: function ylt_preprocess_page(&$vars) { $vars['rabarber'] = 'rabarber'; } theme_render_template looks like this: function theme_render_template($template_file, $variables) { extract($variables, EXTR_SKIP); // Extract the variables to a local namespace ob_start(); // Start output buffering include "./$template_file"; // Include the template file $contents = ob_get_contents(); // Get the contents of the buffer ob_end_clean(); // End buffering and discard return $contents; // Return the contents } I can see rabarber in $variables, but it never ends up beeing extracted. Actually $variables contains about 47 entries but only about 12 of them get extracted. Is this a bug or am I doing something wrong? Best Regards Ernst -------------- next part -------------- An HTML attachment was scrubbed... URL: From syscrusher at 4th.com Thu May 28 12:53:21 2009 From: syscrusher at 4th.com (Syscrusher) Date: Thu, 28 May 2009 08:53:21 -0400 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-7 In-Reply-To: <9d2095ce0905271852q114be17dub94d7914216c22ed@mail.gmail.com> (sfid-20090527_215244_917198_25190668) References: <1243428425.7643.54.camel@marcus> <9d2095ce0905271852q114be17dub94d7914216c22ed@mail.gmail.com> (sfid-20090527_215244_917198_25190668) Message-ID: <1243515201.7643.69.camel@marcus> On Wed, 2009-05-27 at 18:52 -0700, Dmitri G wrote: > Yep, either works. It'd be nicer to have it in the vertical tabs, so I > think you should try it first. I intend to, but I'm not sure it will fit, especially into fixed-width themes. Thanks for the info! Scott -- Syscrusher From Peter at attiks.com Thu May 28 13:44:12 2009 From: Peter at attiks.com (Peter Droogmans) Date: Thu, 28 May 2009 15:44:12 +0200 Subject: [development] SPAM --- Re: noderefernace cck In-Reply-To: References: <200905272328.14404.caleb@caleboconnell.com> Message-ID: You can also have a look at the combo field, see http://drupal.org/node/119102 and http://groups.drupal.org/node/14009 I tried the patch last week but you may run into problems if files get removed, see the comments at the end of the thread. Cheers, Peter Droogmans 32 497 44 44 77 -----Original Message----- From: development-bounces at drupal.org [mailto:development-bounces at drupal.org] On Behalf Of Andrew Berry Sent: donderdag 28 mei 2009 05:55 To: development at drupal.org; caleb at caleboconnell.com Subject: SPAM --- Re: [development] noderefernace cck Take a look at filefield and imagefield. You should be able to extend nodereference in the same way. On 27-May-09, at 11:28 PM, "Caleb O'Connell" wrote: > I am looking to get info about the cck module in drupal. I've been > trying to write a cck module that will basically do the exact same > as nodereference but with two free entry text fields to go along > with it. Basically, one field to be the noderef lookup and two to > add prices to associate to the referred field. I wasn't sure who I > could get in touch with in the cck development who is familiar with > this so I can ask some questions about where to put the code I want > in place to make the custom module I was looking for. Thanks again > in advance. > > -- > -- Caleb Dylan O'Connell > -- caleb at caleboconnell.com > -- 207.319.4746 > -- http://blog.caleboconnell.com From caleb at caleboconnell.com Thu May 28 15:12:52 2009 From: caleb at caleboconnell.com (Caleb O'Connell) Date: Thu, 28 May 2009 11:12:52 -0400 Subject: [development] noderefernace cck References: <200905272328.14404.caleb@caleboconnell.com> Message-ID: <20090528152002.77F0FA00CA@hemlock.osuosl.org> The following is from the noderefernce widget function which looks to be the best place to put in my code for adding two free entry text fields. I changed the name to beerlist throughout for my module purposes. The other place would be under nodereference_element, but I am not sure which would be best, and if a simple for each would work to create my fields. switch ($field['widget']['type']) { case 'beerlist_select': $element = array( '#type' => 'beerlist_select', '#default_value' => $items, ); break; case 'beerlist_buttons': $element = array( '#type' => 'beerlist_buttons', '#default_value' => $items, ); break; case 'beerlist_autocomplete': $element = array( '#type' => 'beerlist_autocomplete', '#default_value' => isset($items[$delta]) ? $items[$delta] : NULL, '#value_callback' => 'beerlist_autocomplete_value', ); break; } return $element; } Caleb O'Connell wrote: > I am looking to get info about the cck module in drupal. I've been trying > to write a cck module that will basically do the exact same as > nodereference but with two free > entry text fields to go along with it. Basically, one field to be the > noderef lookup > and two to add prices to associate to the referred field. I wasn't sure > who I could get in touch with in the cck development who is familiar with > this so I can ask some questions about where to put the code I want in > place to make the custom module I was > looking for. Thanks again in advance. > -- -- Caleb O'Connell -- Portlandtaps.com From marco.carbone at gmail.com Thu May 28 15:41:26 2009 From: marco.carbone at gmail.com (Marco Carbone) Date: Thu, 28 May 2009 08:41:26 -0700 Subject: [development] noderefernace cck In-Reply-To: <20090528152002.77F0FA00CA@hemlock.osuosl.org> References: <200905272328.14404.caleb@caleboconnell.com> <20090528152002.77F0FA00CA@hemlock.osuosl.org> Message-ID: <93bcb5e50905280841t6bf142bcw16ce8a0a899ac7e2@mail.gmail.com> Try the experimental content_multigroup module that comes with the latest CCK release on Drupal 6. Since it's experimental, you'll have to add a .info file to enable it. I have it working right now with a noderef + checkbox and it is mostly functional. (There are a few annoyances that still need to be worked out, such as the inability to remove empty instances when you allow multiple fields.) More here: http://drupal.org/node/119102 -marco On Thu, May 28, 2009 at 8:12 AM, Caleb O'Connell wrote: > The following is from the noderefernce widget function which looks to be the > best place to put in my code for adding two free entry text fields. ?I > changed the name to beerlist throughout for my module purposes. ?The other > place would be under nodereference_element, but I am not sure which would be > best, and if a simple for each would work to create my fields. > > > ?switch ($field['widget']['type']) { > ? ?case 'beerlist_select': > ? ? ?$element = array( > ? ? ? ?'#type' => 'beerlist_select', > ? ? ? ?'#default_value' => $items, > ? ? ?); > ? ? ?break; > > ? ?case 'beerlist_buttons': > ? ? ?$element = array( > ? ? ? ?'#type' => 'beerlist_buttons', > ? ? ? ?'#default_value' => $items, > ? ? ?); > ? ? ?break; > > ? ?case 'beerlist_autocomplete': > ? ? ?$element = array( > ? ? ? ?'#type' => 'beerlist_autocomplete', > ? ? ? ?'#default_value' => isset($items[$delta]) ? $items[$delta] : NULL, > ? ? ? ?'#value_callback' => 'beerlist_autocomplete_value', > ? ? ?); > ? ? ?break; > ?} > ?return $element; > } > > > Caleb O'Connell wrote: > >> I am looking to get info about the cck module in drupal. ?I've been trying >> to write a cck module that will basically do the exact same as >> nodereference but with two free >> entry text fields to go along with it. ?Basically, one field to be the >> noderef lookup >> and two to add prices to associate to the referred field. ?I wasn't sure >> who I could get in touch with in the cck development who is familiar with >> this so I can ask some questions about where to put the code I want in >> place to make the custom module I was >> looking for. ?Thanks again in advance. >> > > -- > -- Caleb O'Connell > -- Portlandtaps.com > From caleb at caleboconnell.com Thu May 28 15:50:56 2009 From: caleb at caleboconnell.com (Caleb O'Connell) Date: Thu, 28 May 2009 11:50:56 -0400 Subject: [development] noderefernace cck In-Reply-To: <93bcb5e50905280841t6bf142bcw16ce8a0a899ac7e2@mail.gmail.com> References: <200905272328.14404.caleb@caleboconnell.com> <20090528152002.77F0FA00CA@hemlock.osuosl.org> <93bcb5e50905280841t6bf142bcw16ce8a0a899ac7e2@mail.gmail.com> Message-ID: <200905281150.56325.caleb@caleboconnell.com> Using content multigroup, does it allow me to get that data back out of the database? do you have a sample .install file, just so I can see what requirements you're using. I have been doing a lot to work on this and if I can get this to work initially, I'd love to start working more on this. -- -- Caleb Dylan O'Connell -- caleb at caleboconnell.com -- 207.319.4746 -- http://blog.caleboconnell.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.carbone at gmail.com Thu May 28 16:14:10 2009 From: marco.carbone at gmail.com (Marco Carbone) Date: Thu, 28 May 2009 09:14:10 -0700 Subject: [development] noderefernace cck In-Reply-To: <200905281150.56325.caleb@caleboconnell.com> References: <200905272328.14404.caleb@caleboconnell.com> <20090528152002.77F0FA00CA@hemlock.osuosl.org> <93bcb5e50905280841t6bf142bcw16ce8a0a899ac7e2@mail.gmail.com> <200905281150.56325.caleb@caleboconnell.com> Message-ID: <93bcb5e50905280914n641a7b0fw5d77ec9676b1e38b@mail.gmail.com> Just create content_multigroup.info and put it into cck/module/content_multigroup with these contents: name = Content Multigroup description = Combine multiple CCK fields into repeating field collections that work in unison. This module is experimental and not ready for production. dependencies[] = content dependencies[] = fieldgroup package = CCK core = 6.x This is explained in the README.txt that comes with the module. "does it allow me to get that data back out of the database" I'm not sure what you mean here -- yes, the data gets added to the database and can be retrieved as normal. In general, content multigroup just bundles up multiple fields and then it acts like a normal CCK field. On Thu, May 28, 2009 at 8:50 AM, Caleb O'Connell wrote: > Using content multigroup, does it allow me to get that data back out of the > database? do you have a sample .install file, just so I can see what > requirements you're using. I have been doing a lot to work on this and if I > can get this to work initially, I'd love to start working more on this. > -- > -- Caleb Dylan O'Connell > -- caleb at caleboconnell.com > -- 207.319.4746 > -- http://blog.caleboconnell.com From weitzman at tejasa.com Thu May 28 19:28:11 2009 From: weitzman at tejasa.com (Moshe Weitzman) Date: Thu, 28 May 2009 15:28:11 -0400 Subject: [development] preprocess page doesn't take all variables In-Reply-To: <27c534c90905280030m33e5b653ya2cd5555913fa90f@mail.gmail.com> References: <27c534c90905280030m33e5b653ya2cd5555913fa90f@mail.gmail.com> Message-ID: <6117a7500905281228g2ab15194ob86bfb3fec7e1b0a@mail.gmail.com> That sounds like a bug in extract(). Perhaps upgrade to latest release of php? On Thu, May 28, 2009 at 3:30 AM, Ernst Pl?ss wrote: > Hi > > I'm trying to do a simple thing in D6: Add a variable to the page template. > Unfortunately it seams, that it gets lost in theme_render_template. > > This is my code in the template.php: > > function ylt_preprocess_page(&$vars) { > $vars['rabarber'] = 'rabarber'; > } > > theme_render_template looks like this: > > function theme_render_template($template_file, $variables) { > extract($variables, EXTR_SKIP); // Extract the variables to a local > namespace > ob_start(); // Start output buffering > include "./$template_file"; // Include the template file > $contents = ob_get_contents(); // Get the contents of the buffer > ob_end_clean(); // End buffering and discard > return $contents; // Return the contents > } > > I can see rabarber in $variables, but it never ends up beeing extracted. > Actually $variables contains about 47 entries but only about 12 of them get > extracted. > > Is this a bug or am I doing something wrong? > > Best Regards > Ernst > > > From drupal at dave-cohen.com Fri May 29 17:36:20 2009 From: drupal at dave-cohen.com (David Cohen) Date: Fri, 29 May 2009 10:36:20 -0700 Subject: [development] behaviors context Message-ID: <1243618580.22144.1317852215@webmail.messagingengine.com> I'm trying to implement a Drupal.behavior. I realize my behavior function is passed a "context". But it's unclear to me what that context will be. If I understand correctly, when the behavior is first invoked, it is passed document, a variable built into javascript. Later, when some module's javascript adds content to the page, my behavior will be invoked again. This time, context could be anything. The module which added the content can pass whatever. So for example in ahah.js, Drupal.attachBehaviors() is passed a jquery object representing the new content. While in modules/views/js/ajax.js, Drupal.attachBehaviors() is passed a string or id, either of which could be used in a jquery selector. Do I have this right? What I need is the javascript element (not jquery object) that is the added content. Does anyone have a snippet of code which returns this, given a context? Thanks, -Dave From matt at aleph-null.tv Fri May 29 17:46:17 2009 From: matt at aleph-null.tv (Matt) Date: Fri, 29 May 2009 12:46:17 -0500 Subject: [development] behaviors context In-Reply-To: <1243618580.22144.1317852215@webmail.messagingengine.com> References: <1243618580.22144.1317852215@webmail.messagingengine.com> Message-ID: <70fbbb000905291046j7a32be2di89572cfb0509ddf4@mail.gmail.com> As far as the context goes, yes -- you are at the mercy of whatever called Drupal.attachBehaviors(). So it's not all that reliable. Typically, the whole CSS :not() pseudo-class combined with a 'processed-' class is used to help you find segments that have not been processed already. There are ample examples of this inside of Drupal's JS libraries. Matt On Fri, May 29, 2009 at 12:36 PM, David Cohen wrote: > I'm trying to implement a Drupal.behavior. ?I realize my behavior > function is passed a "context". ?But it's unclear to me what that > context will be. > > If I understand correctly, when the behavior is first invoked, it is > passed document, a variable built into javascript. > > Later, when some module's javascript adds content to the page, my > behavior will be invoked again. ?This time, context could be anything. > The module which added the content can pass whatever. ?So for example in > ahah.js, Drupal.attachBehaviors() is passed a jquery object representing > the new content. ?While in modules/views/js/ajax.js, > Drupal.attachBehaviors() is passed a string or id, either of which could > be used in a jquery selector. > > Do I have this right? > > What I need is the javascript element (not jquery object) that is the > added content. ?Does anyone have a snippet of code which returns this, > given a context? > > Thanks, -Dave > > -- http://technosophos.com http://querypath.org From nedjo at islandnet.com Fri May 29 17:54:51 2009 From: nedjo at islandnet.com (Nedjo Rogers) Date: Fri, 29 May 2009 11:54:51 -0600 Subject: [development] behaviors context In-Reply-To: <1243618580.22144.1317852215@webmail.messagingengine.com> References: <1243618580.22144.1317852215@webmail.messagingengine.com> Message-ID: <4A20216B.6080904@islandnet.com> David Cohen wrote: > I'm trying to implement a Drupal.behavior. I realize my behavior > function is passed a "context". But it's unclear to me what that > context will be. The context is supposed to be the element to be processed--not a jQuery object but the page element. See the 5 - 6 upgrade notes: http://drupal.org/node/114774#javascript-behaviors However, this fact may have been lost along the way. From news at unleashedmind.com Fri May 29 17:59:01 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Fri, 29 May 2009 19:59:01 +0200 Subject: [development] behaviors context In-Reply-To: <1243618580.22144.1317852215@webmail.messagingengine.com> Message-ID: <16a801c9e087$2604def0$0200a8c0@structworks.com> > What I need is the javascript element (not jquery object) > that is the added content. Does anyone have a snippet of > code which returns this, given a context? If I'm not mistaken: var new_content = $(context).get(0); sun From news at unleashedmind.com Fri May 29 18:04:51 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Fri, 29 May 2009 20:04:51 +0200 Subject: [development] behaviors context In-Reply-To: <4A20216B.6080904@islandnet.com> Message-ID: <16b801c9e087$f69f6da0$0200a8c0@structworks.com> > The context is supposed to be the element to be > processed--not a jQuery object but the page element. See the > 5 - 6 upgrade notes: > http://drupal.org/node/114774#javascript-behaviors > > However, this fact may have been lost along the way. Note that even misc/ahah.js passes an jQuery object: if (new_content.parents('html').length > 0) { Drupal.attachBehaviors(new_content); } However, passing a string as context sounds a bit wrong. Behaviors usually expect a DOM element. sun From matt at aleph-null.tv Fri May 29 18:14:21 2009 From: matt at aleph-null.tv (Matt) Date: Fri, 29 May 2009 13:14:21 -0500 Subject: [development] behaviors context In-Reply-To: <16b801c9e087$f69f6da0$0200a8c0@structworks.com> References: <4A20216B.6080904@islandnet.com> <16b801c9e087$f69f6da0$0200a8c0@structworks.com> Message-ID: <70fbbb000905291114i6bc9fce8y67d02402a9284172@mail.gmail.com> Thus my original claim: You are at the mercy of whatever calls Drupal.attachBehaviors(). Unless you are absolutely positive you can account for all use cases (and thus all callings of Drupal.attach()), you're better off ignoring context. Matt On Fri, May 29, 2009 at 1:04 PM, Daniel F. Kudwien wrote: >> The context is supposed to be the element to be >> processed--not a jQuery object but the page element. See the >> 5 - 6 upgrade notes: >> http://drupal.org/node/114774#javascript-behaviors >> >> However, this fact may have been lost along the way. > > Note that even misc/ahah.js passes an jQuery object: > > ?if (new_content.parents('html').length > 0) { > ? ?Drupal.attachBehaviors(new_content); > ?} > > > However, passing a string as context sounds a bit wrong. ?Behaviors usually > expect a DOM element. > > sun > > -- http://technosophos.com http://querypath.org From merlin at logrus.com Fri May 29 18:44:23 2009 From: merlin at logrus.com (Earl Miles) Date: Fri, 29 May 2009 11:44:23 -0700 Subject: [development] behaviors context In-Reply-To: <70fbbb000905291114i6bc9fce8y67d02402a9284172@mail.gmail.com> References: <4A20216B.6080904@islandnet.com> <16b801c9e087$f69f6da0$0200a8c0@structworks.com> <70fbbb000905291114i6bc9fce8y67d02402a9284172@mail.gmail.com> Message-ID: <4A202D07.5070002@logrus.com> Matt wrote: > Thus my original claim: You are at the mercy of whatever calls > Drupal.attachBehaviors(). Unless you are absolutely positive you can > account for all use cases (and thus all callings of Drupal.attach()), > you're better off ignoring context. I totally disagree. It's either a jquery object or something you can easily make into a jquery object. Using $(context) should always work and you can get a DOM element using $(context).get(0). Ignoring context will lead to poor performance. From drupal at dave-cohen.com Fri May 29 19:03:37 2009 From: drupal at dave-cohen.com (David Cohen) Date: Fri, 29 May 2009 12:03:37 -0700 Subject: [development] behaviors context In-Reply-To: <4A202D07.5070002@logrus.com> References: <4A20216B.6080904@islandnet.com> <16b801c9e087$f69f6da0$0200a8c0@structworks.com><70fbbb000905291114i6bc9fce8y67d02402a9284172@mail.gmail.com> <4A202D07.5070002@logrus.com> Message-ID: <1243623817.7047.1317866581@webmail.messagingengine.com> So just to clarify, will the context always refer to a single element? In other words should my code be: $elem = $(context).get(0); do_my_behavior($elem); or, more like: $(context).each(function () { $elem = $(this).get(0); do_my_behavior($elem); }); And in the first invocation, when context == document, will $(document).get(0) return the document? Thanks everyone for helping me understand. -Dave On Fri, 29 May 2009 11:44 -0700, "Earl Miles" wrote: > I totally disagree. It's either a jquery object or something you can > easily make into a jquery object. Using $(context) should always work > and you can get a DOM element using $(context).get(0). Ignoring context > will lead to poor performance. From matt at aleph-null.tv Fri May 29 19:34:19 2009 From: matt at aleph-null.tv (Matt) Date: Fri, 29 May 2009 14:34:19 -0500 Subject: [development] behaviors context In-Reply-To: <4A202D07.5070002@logrus.com> References: <4A20216B.6080904@islandnet.com> <16b801c9e087$f69f6da0$0200a8c0@structworks.com> <70fbbb000905291114i6bc9fce8y67d02402a9284172@mail.gmail.com> <4A202D07.5070002@logrus.com> Message-ID: <70fbbb000905291234s4de92a1cu3df6413034051d6b@mail.gmail.com> The other issue with using context is that it is unreliable for a second reason: behaviors may actually misbehave when focusing on only a small portion of the DOM. Example: context contains several rows of a table, and you are adding odd/even classes to a table in a behavior. If a behavior is fed just the modified rows, this may lead to unexpected behavior (Reason: there may be other rows not fed into the context, thus throwing off odd/even counts). That's a basic example. In the JS book I wrote, I provided a more elaborate examples of contexts causing problems. And there are still others -- like cases where AHAH content has its own JS which may modify your DOM further. But the basic principle is the same: Assuming that the attachBehaviors call is passing you what you need is not a good assumption. And since attachBehaviors can be called from anywhere (not just in AHAH/AJAX callbacks) and for any reason, it's dangerous to presume you know what you're getting. re: performance... in most cases you are talking a negligible difference. DOM optimization in mainstream browsers is good enough that a search through an entire document is almost always "fast enough". Shaving 10 msecs off of that time isn't going to make much of a difference (assuming you could actually shave that much from the search time). There are two patterns in Drupal JS to "prevent" the same behavior from processing the same data twice. One is the :not(processed-X) pattern, which seems to be pretty reliable, and is pretty much entirely in the hands of the author of the behavior (barring a misanthrope who decides to remove your processed classes). The other is the context, which requires that both the caller of attachBehavior() and the behavior have the same set of assumptions about what is being passed in and what needs operating on. This is not always the case, and there are easy-to-reproduce gotchas (like zebra striping, AHAH'd JavaScript that alters the DOM, and so on). Matt On Fri, May 29, 2009 at 1:44 PM, Earl Miles wrote: > Matt wrote: >> >> Thus my original claim: You are at the mercy of whatever calls >> Drupal.attachBehaviors(). Unless you are absolutely positive you can >> account for all use cases (and thus all callings of Drupal.attach()), >> you're better off ignoring context. > > I totally disagree. It's either a jquery object or something you can easily > make into a jquery object. Using $(context) should always work and you can > get a DOM element using $(context).get(0). Ignoring context will lead to > poor performance. > -- http://technosophos.com http://querypath.org From matt at aleph-null.tv Fri May 29 19:36:28 2009 From: matt at aleph-null.tv (Matt) Date: Fri, 29 May 2009 14:36:28 -0500 Subject: [development] behaviors context In-Reply-To: <1243623817.7047.1317866581@webmail.messagingengine.com> References: <4A20216B.6080904@islandnet.com> <16b801c9e087$f69f6da0$0200a8c0@structworks.com> <70fbbb000905291114i6bc9fce8y67d02402a9284172@mail.gmail.com> <4A202D07.5070002@logrus.com> <1243623817.7047.1317866581@webmail.messagingengine.com> Message-ID: <70fbbb000905291236q24066246m6a9dcb5e2fd71d95@mail.gmail.com> No -- the context will refer to whatever is passed into Drupal.attachBehaviors(). In Drupal core, that will be a DOM Element or a jQuery object. I know of no guarantee that the jQuery will always point to one DOM element (though I know of no place in Drupal core where more than one is passed in). For contributed modules... I suppose you are at the liberty of the contrib developers. Matt On Fri, May 29, 2009 at 2:03 PM, David Cohen wrote: > So just to clarify, will the context always refer to a single element? > In other words should my code be: > > $elem = $(context).get(0); > do_my_behavior($elem); > > or, more like: > > $(context).each(function () { > ?$elem = $(this).get(0); > ?do_my_behavior($elem); > }); > > > And in the first invocation, when context == document, will > $(document).get(0) return the document? > > Thanks everyone for helping me understand. > > -Dave > > > On Fri, 29 May 2009 11:44 -0700, "Earl Miles" wrote: >> I totally disagree. It's either a jquery object or something you can >> easily make into a jquery object. Using $(context) should always work >> and you can get a DOM element using $(context).get(0). Ignoring context >> will lead to poor performance. > -- http://technosophos.com http://querypath.org From drupal at dave-cohen.com Fri May 29 19:52:56 2009 From: drupal at dave-cohen.com (David Cohen) Date: Fri, 29 May 2009 12:52:56 -0700 Subject: [development] Fwd: Re: behaviors context Message-ID: <1243626776.17100.1317873929@webmail.messagingengine.com> I think I get what you're writing about. It makes sense when you're behavior affects, say, all elements of a certain class. And you can update the class after the behavior acts. But in my case, I need to operate over all elements. So to do what you're talking about I'd need to add classes all over the place. Specifically, I'm working with Facebook Connect. And I need to tell facebook's javascript to parse any markup added to a page. They provide methods to do this, http://wiki.developers.facebook.com/index.php/JS_API_T_FB.XFBML.Host. One method parses the whole dom tree, another limits the parse to specific elements. For performance reasons I prefer to use the more limited method, but I'll resort to the other if I really have to. -Dave On Fri, 29 May 2009 14:34 -0500, "Matt" wrote: > There are two patterns in Drupal JS to "prevent" the same behavior > from processing the same data twice. One is the :not(processed-X) > pattern, which seems to be pretty reliable, and is pretty much > entirely in the hands of the author of the behavior (barring a > misanthrope who decides to remove your processed classes). > > From news at unleashedmind.com Fri May 29 19:59:29 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Fri, 29 May 2009 21:59:29 +0200 Subject: [development] behaviors context In-Reply-To: <70fbbb000905291234s4de92a1cu3df6413034051d6b@mail.gmail.com> Message-ID: <16d801c9e097$fa5de1f0$0200a8c0@structworks.com> > re: performance... in most cases you are talking a negligible > difference. DOM optimization in mainstream browsers is good > enough that a search through an entire document is almost > always "fast enough". Shaving 10 msecs off of that time isn't > going to make much of a difference (assuming you could > actually shave that much from the search time). Now, you do the math: 10 ms * ~20+ behaviors = 200+ ms With each module/behavior you add, the performance gets worse. > There are two patterns in Drupal JS to "prevent" the same > behavior from processing the same data twice. One is the > :not(processed-X) pattern, which seems to be pretty reliable, > and is pretty much entirely in the hands of the author of the > behavior (barring a misanthrope who decides to remove your > processed classes). ...which equally cannot solve your trivial zebra-striping table row example. Once your table :is(.processed), your behavior can't (shouldn't) process it again. sun From recidive at gmail.com Fri May 29 20:13:39 2009 From: recidive at gmail.com (Henrique Recidive) Date: Fri, 29 May 2009 17:13:39 -0300 Subject: [development] behaviors context In-Reply-To: <1243623817.7047.1317866581@webmail.messagingengine.com> References: <4A20216B.6080904@islandnet.com> <16b801c9e087$f69f6da0$0200a8c0@structworks.com> <70fbbb000905291114i6bc9fce8y67d02402a9284172@mail.gmail.com> <4A202D07.5070002@logrus.com> <1243623817.7047.1317866581@webmail.messagingengine.com> Message-ID: <841684fe0905291313t2773a29akd9e9b0451b3d0dda@mail.gmail.com> 2009/5/29 David Cohen : > So just to clarify, will the context always refer to a single element? > In other words should my code be: > > $elem = $(context).get(0); > do_my_behavior($elem); > > or, more like: > > $(context).each(function () { > ?$elem = $(this).get(0); > ?do_my_behavior($elem); > }); It should be more like this: Drupal.behaviors.myBehavior = function(context) { $(context).each(function () { // 'this' is a DOM Element. do_my_behavior(this); }); }; or you can include your selector and use context as it is supposed to be used: Drupal.behaviors.myBehavior = function(context) { $('.my-behavior-class:not(.my-behavior-processed)', context).each(function () { // 'this' is a DOM Element. do_my_behavior(this); $(this).addClass('my-behavior-processed'); }); }; Henrique > > > And in the first invocation, when context == document, will > $(document).get(0) return the document? > > Thanks everyone for helping me understand. > > -Dave > > > On Fri, 29 May 2009 11:44 -0700, "Earl Miles" wrote: >> I totally disagree. It's either a jquery object or something you can >> easily make into a jquery object. Using $(context) should always work >> and you can get a DOM element using $(context).get(0). Ignoring context >> will lead to poor performance. > From matt at aleph-null.tv Fri May 29 20:30:29 2009 From: matt at aleph-null.tv (Matt) Date: Fri, 29 May 2009 15:30:29 -0500 Subject: [development] behaviors context In-Reply-To: <16d801c9e097$fa5de1f0$0200a8c0@structworks.com> References: <70fbbb000905291234s4de92a1cu3df6413034051d6b@mail.gmail.com> <16d801c9e097$fa5de1f0$0200a8c0@structworks.com> Message-ID: <70fbbb000905291330j5115615am8a913b579510acf@mail.gmail.com> On Fri, May 29, 2009 at 2:59 PM, Daniel F. Kudwien wrote: > Now, you do the math: > > 10 ms * ~20+ behaviors = 200+ ms Actually, I was figuring 10ms for LOTS of behaviors. Not PER behavior. A selector should clearly take well under 10ms. Any additional overhead for a behavior is going to be the same regardless of whether you use context or selectors. >> There are two patterns in Drupal JS to "prevent" the same >> behavior from processing the same data twice. One is the >> :not(processed-X) pattern, which seems to be pretty reliable, >> and is pretty much entirely in the hands of the author of the >> behavior (barring a misanthrope who decides to remove your >> processed classes). > > ...which equally cannot solve your trivial zebra-striping table row example. > Once your table :is(.processed), your behavior can't (shouldn't) process it > again. Oh, come on... you wouldn't drop a zebra stripe processed class on the table, would you? You'd drop it on the row. And if you found rows in a table without striping, you'd re-process the entire table. The problem occurs only when you assume the context is passing sufficient information for your behavior. The context may in fact be providing less information than you need, and you are at the liberty of whatever called attachBehavior() in the first place (which may not be something in core -- there's no way to tell). Consequently, it's better to rely on the document itself, not just the context. Matt -- http://technosophos.com http://querypath.org