May 2008 - Development - lists.drupal.org

Re: [development] RFC: info hook standardization
by Darrel O'Pry 20 May '08

20 May '08

I just think it wold be cool to support both options, as some items may be user specific. I'm not excluding normal cache_set/cache_get. I'm still think in terms of a more general cacheable module_invoke_all and not specifically hook_*_info. -----Original Message----- From: Larry Garfield <larry(a)garfieldtech.com> Sent: May 19, 2008 8:31 PM To: development(a)drupal.org Subject: Re: [development] RFC: info hook standardization On Monday 19 May 2008, Darrel O'Pry wrote: > > Ah, indeed! Make that 2 more attributes of an info hook: > > > > - It has a commonly-named rebuild function: > > drupal_rebuild_$singularNoun() (or something). > > - drupal_rebuild_$singularNoun() is called as part of the master cache > > reset function. > > > > --Larry Garfield > > but this wouldn't be able to reset a static cache variable? would it? > unless we had something like. I really like to two stage cache for things > that might possibly only want to be cached per request... > > function module_invoke_all_cached() { > static $cache = array(); > > $args = func_get_args(); > $hook = $args[0]; > unset($args[0]); > if (!is_string($hook)) { > $cache = array(); > } > } I think you're misunderstanding what I mean by cached. For an info hook, I mean cached to the database (either cache_set() or something like {menu_router}) so that it never gets called again except in unusual circumstances. A static cache only lasts for the duration of the request, and is not what I mean by caching here. Think hook_menu(), not hook_forms(). -- Larry Garfield AIM: LOLG42 larry(a)garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

2 4

support request for "Ajax Table"
by Lluís 20 May '08

20 May '08

I submited a "support request" for "ajax table" (http://drupal.org/node/257481) but seeing there is no answer from the mantainer I ask here if somebody knows how to solve my problem. Is there a way to use parameters in a table? For example if I want to list all the nodes in a project using a link "index.php?q=table/project/4" Thanks PS: Project and nodes are code by me, so any change is possible -- *Si tu fas una foto a una vaca, la vaca no et diu re. *Envellim quan els records superen les esperances. *Als llocs desconeguts només s'hi arriba per camins desconeguts. *Abans d'imprimir aquest missatge, pensa en el medi ambient.

1 0

RFC: info hook standardization
by Larry Garfield 20 May '08

20 May '08

Unlike the IETF, I am actually looking for comments and feedback at this point. :-) In recent versions, Drupal has developed an increasing number of registry-style hooks. By "registry style", I mean a hook that serves to build a ginormous (technical term) associative array and return it, and does nothing else. hook_menu(), hook_theme(), hook_node_info(), those are just a few of such hooks. CCK has one for formatters and another for widgets. Views has hook_views_default_views() and, in Views 2, a couple of others as well. There's an issue[1] to convert hook_blocks() over to that format, too, for a variety of reasons. In most cases, these hooks are called rarely and then cached, either in the cache table or in a dedicated table such as menu_router, or they aren't but easily could be and probably should be. However, it is not always readily apparent which is the case. For instance, hook_forms() is not a registry hook in that it is contextual, and cannot be cached that way in its current implementation. (Perhaps it should be, but that's not what I'm getting at.) Some such hooks have a corresponding _alter hook, others do not. I therefore am going to propose a conventional standard for such registry-style hooks. I will dub them "info hooks", because about half of such hooks currently end in _info() already. An info hook would be defined as follows: - It has a name of the form hook_$singularNoun_info(). - It takes no parameters. - It returns a nested associative array of arbitrary complexity (case-specific). - it has a corresponding _alter hook (vis, hook_$singularNoun_info_alter()). - It is structured in such a way that its results can and are cached (either in the cache table or a dedicated table, depending on the use case). - That cache is permanent, so under normal operation the hook never needs to be called again. - The new registry system knows to never pre-load the file in which an info hook resides, or rather to never flag a file included for an info hook for pre-caching. (We don't want to inadvertently flush the cache and then trigger a rebuild of those hooks on a node view page, because then we end up loading thousands of unnecessary lines.) Thus, any hook that ends in _info() you can reliably know exhibits those properties (and possibly others), and a hook that does not end in _info() does not exhibit all of those properties (although it may certainly exhibit some of them, c.f. hook_form_alter()). This has a number of advantages: - Clarity. Right now, when you see a hook you don't know inherently if it's cached or not, if it has an alter hook, etc. This way, you know that if it ends in _info(), it either does all of the above or it's a bug. - Consistency. Consistent APIs are good APIs. - Ease of development. When developing a new hook, a developer can say to himself "Ah, this is starting to look like an info hook, which means I don't need to guess what features I should add; I should just go ahead and make a full info hook out of it." You never know when that alter hook will be useful to someone. :-) - Encourages declarative programming. Eh? Declarative programming in PHP? Just so! Declarative programming is harder to make obscure, stupid bugs in (assuming you know the syntax), because most bugs are either syntax errors or blatantly obvious. Yes there are exceptions (some of the more complex SQL queries I've written come to mind), but in general you're less likely to get subtle bugs with an associative array. - Encourages generic engines. A generic engine that relies on declarative input is flexible, because you can then program it via a declarative syntax. Solving the generic problem may be more difficult in the short term, but in the long-term it buys you a great deal of flexibility. - Easier to document. Drupal's APIs are admittedly sometimes wacky and obscure. By separating the engine from the declarative interface to it, we can put a lot of power into the hands of hook authors with a very simple, easy to document syntax. We also have a clearly documented behavior for how an info hook is supposed to behave. Parameter orders also then are not a problem, since array key orders don't matter. The array keys also then serve as a form of self-documentation. - Backward compatibility. Yes, the unholy words! Just like one of the advantages of XML is that you can arbitrarily add new tags and existing well-written code won't automatically choke, you can add new keys to an associative array and as long as there is a sane default, existing code doesn't have to change unless it needs to. - Less executable code. The key goal of the Drupal 7 code registry is to load less code. Well, if we move more power into tightly written engines that are controlled by run-once hooks that we no longer need to load, that's less code, and more less code the more modules you have. Take every module's hook_menu, hook_theme, hook_node_info, hook_views_default_views, hook_block, etc. and simply remove them from the common case. Good bye several thousand lines of code. Naturally not everything can or should be a registry hook, and we shouldn't try to shoe-horn Drupal into being just an array-processor. However, this is a trend I have observed in Drupal development that it would behoove us to embrace and standardize and (dare I say!) extend the use of. Implementation: Implementing this plan would involve documenting it, of course. We would then rename hook_theme() to hook_theme_info(), hook_menu() to hook_menu_info(), etc. At that point we could investigate other subsystems that it would make sense to turn into info hooks. I suspect we will find a couple besides the block system(hook_block_info() anyone)? In the process, we may discover places where "obvious" flexibility is missing. Excuse me while I go get my flame-retardant suit. [1] http://drupal.org/node/257032 -- Larry Garfield AIM: LOLG42 larry(a)garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

8 14

Re: [development] RFC: info hook standardization
by Larry Garfield 19 May '08

19 May '08

On Mon, 19 May 2008 14:30:30 -0400, "Darrel O'Pry" <darrel.opry(a)gmail.com> wrote: >> Themes get a special HOOK_theme() that is exactly like the module > version, >> but they do not get a corresponding alter. >> > > That makes more sense. I'm a proponent of ignoring that special case for > now > since it's doing it's own caching and just implementing a caching version > of > module_invoke_all.... > > although I don't think we need to add the logic for caching in > module_invoke_all itself since it is a called my many other modules, just > extend what we have with a wrapper that implements the caching. I didn't suggest that the caching happen inside module_invoke_all(), just that if a hook is named hook_foo_info() then there is caching. It probably should not happen inside module_invoke_all() itself. If hook_theme() takes parameters, though, how does it get cached? --Larry Garfield

3 2

JavaScript Coding Standards
by Stella Power 19 May '08

19 May '08

Heya, More and more contrib modules are including JavaScript files, so I want to add the ability to review JavaScript files to the Coder<http://drupal.org/project/coder>module. However, step 1 is we need to agree on what coding standards we should be using for JavaScript. At present we have the Coding standards for JS files<http://drupal.org/node/172169>doc which has one or two ideas but isn't complete. We also have the main Coding Standards <http://drupal.org/coding-standards> doc, and while most are transferable to JavaScript, not all are. So I've put some suggestions together at http://drupal.org/node/260140 A fair few of them come from the standards used by JSLint so there shouldn't be many surprises. I'd really appreciate a discussion/debate on this and hopefully we can agree on the coding standards we want to use. Cheers, Stella

3 2

Compiling Drupal statistics
by Angela Byron 18 May '08

18 May '08

As tends to happen every 6 months or so, I got asked to compile some statistics about Drupal: number of active installations, number of users on drupal.org, stuff like that. Each time I try to figure this out it's a time-sink of hours and hours and hours. :( And I think most of us get asked to compile this information from time to time as well, either on behalf of our bosses or because we're giving a presentation somewhere, or whatever. So this time, I threw all the queries I was running into a .php file @ tricks/drupal_org_statistics. Per killes, I did not create a new permanent PHP page for these statistics on drupal.org, but I did run this in a PHP node preview and it came up with the following: http://cvs.drupal.org/viewvc.py/drupal/contributions/tricks/drupal_org_stat… NOTE: There's a bug in the "# of active Drupal installations" query... the query that's giving me the list of most used modules reports about 486,000 active Drupal installations. Feel free to fix it if you figure out what the bug is. If you want to help improve this script, grab a copy of the drupal.org testing installation profile (http://drupal.org/project/drupalorg_testing) and commit any additional queries that you feel would be helpful for admins to compile on a semi-regular basis (SELECTs only, naturally :P). Incidentally, the module/Drupal usage stats will become publicly visible as soon as http://drupal.org/node/165380 has been reviewed and committed. Anyone who wants to become the next Drupal hero might want to jump on that. -Angie

2 2

Knight Drupal Initiative chat
by Ken Rickard 18 May '08

18 May '08

All- As part of the launch of the Knight Drupal Initiative, I would like to moderate a live chat on one of the Drupal IRC channels next week. Do we have any standards for setting up chat events? -- Ken Rickard agentrickard(a)gmail.com http://ken.therickards.com

1 0

OpenOffice.org
by Louis Suarez-Potts 17 May '08

17 May '08

[This is a re-send of a message I sent originally to the infrastructure list.] Hello all! Allow me to introduce myself: I'm the community manager of OpenOffice.org, a role I've held for the last 7.5 years. My interest here is to see if there is interest in developing an OpenDocument Format filter for Drupal or (better yet) some ways of integrating or at least linking OOo to Drupal. The reason? Lots, including both public and private enterprises, want a CMS + productivity suite (such as OOo) combo. Drupal has huge market share and is flourishing; so does and is OOo. How is integration imagined? It could be close or it could be even something as simple as an extension. We have now many extensions, and there is no reason why everything has to be a single package--this is the Internet age, not the isolated desktop age. If people are interested, let's talk. My guess is that an obstacle to good intentions is reality: shortage of resources. But I also am relentlessly optimistic and hopeful, and believe if we can present a good case then companies may want to allocate those resources, which is to say, people and money. Ciao, Louis -- Louis Suarez-Potts, PhD Community Manager, Sun Microsystems, Inc. OpenOffice.org

17 23

the time of $op is over?
by Gábor Hojtsy 15 May '08

15 May '08

Hello, Now that the registry patch landed, it looks like the time of $op might be over. General hooks implementing different branches with $op will always be loaded regardless of the exact need for them. Larry already suggests using the more granular *_preprocess_hookname() type of callbacks instead of the generic *_preprocess() callbacks for theme stuff, so that only those needed will be loaded. Take nodeapi for example. Code for loading nodes might often be needed, but not code for updating or deleting them, right? Those could easily be admin.inc stuff. So what do you think about $op? Should we evaluate on a case-by-case basis to make function level callbacks out of $op's or just do it wholesale (no, I am not volunteering for a patch) to get an overall consistent API. Gabor

18 21

Performance Testing with a Big Test Database
by Doug Green 15 May '08

15 May '08

One product of the search sprint is this large database for testing... http://civicactions.s3.amazonaws.com/drupal6_100k.mysql.gz I will keep the link available indefinitely. I created the database using devel module (with http://drupal.org/node/177722) and the reindex module. If you want to read more about the search sprint, there are several blogs to choose from: http://www.workhabit.org/minnesota-search-sprint http://www.civicactions.com/blog/search_sprint_conclusion http://www.davidlesieur.com/en-direct-du-minnesota (in French) http://blog.lib.umn.edu/fenne035/academe2.0/ http://www.civicactions.com/blog/search_sprint_day_one http://acquia.com/blog/drupal-search-how-indexing-works And I'm sure that Robert will write the "mother of all search blogs," but these things take time. -- Doug Green douggreen(a)douggreenconsulting.com 904-583-3342 Bringing Ideas to Life with Software Artistry and Invention...

5 6