January 2007 - Development - lists.drupal.org

Drag and Drop UI standards
by Ken Rickard 26 Jan '07

26 Jan '07

All- Now that we have jQuery in Drupal, there are all sorts of drag-and-drop interface possibilities. Questions, too, by the look of http://drupal.org/search/node/drag+and+drop. I've been working on one for my project, using the interface jQuery plug-in, and have a two simple questions: 1) Do we have any best-practice guidelines on using drag-and-drop? 2) Specifically, if the action requires saving the state change, should that save be automatic (on-drop) or user initiated (extra button or link on-click)? - Ken Rickard agentrickard

12 17

Database schema abstraction and *reflection* (was: Referential integrity -- finally?)
by Barry Jaspan 26 Jan '07

26 Jan '07

I raised the issue of database schema abstraction last summer, and I know that other people raised it before me. The arguments this time seem to be the same as the used to be (though apparently Dries is closer to being persuaded :-). I would like to elaborate on my primary reason for supporting a database schema abstraction layer (not for data manipulation (SELECT, etc.), just for CREATE TABLE, ALTER, etc): database schema reflection. Schema reflection will provide Drupal the ability to understand and manipulate its own data schema (in the flavor of the Forms API). Every table's structure will be defined in a data structure (just like a form), indicating its columns and data types, keys, etc. I envision something like this (I wrote a perl script to automatically generate this structure by parsing 4.7's database.4.0.mysql. Other methods are possible, but it only has to be done once): function system_install() { // // Table structure for table 'access' // $tables['access'] = array ('#cols' => array (array('aid', 'tinyint', NOT_NULL, '#disp_width' => 10), array('mask', 'varchar(255)', NOT_NULL, '#default' => ''), array('type', 'varchar(255)', NOT_NULL, '#default' => ''), array('status', 'tinyint', NOT_NULL, '#disp_width' => 2, '#default' => '0')), '#keys' => array (array('', 'aid', 'PRIMARY'))); // // other tables defined here // return $tables; } Every column has a name, type, and NULL/NOT NULL setting, so those array elements are positional, and any additional/optional attributes are set with #name elements (this is to save space and typing, though all elements could obviously all be keyed to mimic Forms API). Similarly, all keys have a name, column list, and index type, with possible optional attributes. Every module, including system, can return an array like this. When _install hooks are called, the caller merges the result and hands the array off to a DBMS engine driver that translates the schema into appropriate CREATE TABLE, ALTER, etc. statements. I believe this is much better than db_create_table(), db_alter_table(), etc. for the same reason that the Forms API is better than pre-4.7's form_button(), form_checkbox(), etc. A data-driven approach will prove a better design than a procedural approach. Nothing prevents db_create_table() etc. from existing, of course; in fact they probably will, but usually only be called by the DBMS driver. Any module author that does not want to play the game just continues to call db_query('CREATE TABLE') in hook_install(); it is not like we can prevent it. Similarly, _update_n() functions can remain unchanged. If they don't return a structured array, they won't be involved in the abstraction layer. This is not a least-common-denominator approach. Nothing prevents DBMS-specific settings: $tables['some_table'] = array ('#mssql_proprietary_setting' => 'value', ...); Schema version updates, at least the normal cases (add, rename, remove columns) can be handled just by adding version info into the table. For example: $tables['some_table'] = array ('#version' => 2, '#cols' => array (// all the original columns would be here, and now ... array('newcol', 'int', NOT_NULL, '#version_added' => 2), For version updates that require custom code, we can add $tables['some_table'] = array ('#version' => 4, '#version_custom_updates' => array(2, 6), ...); so when the schema updates from 1 to 2 or 5 to 6, module_update_some_table_2 or _6 is called. (As I write this, I think I realize that the #version keys should be in $tables, not $tables['some_table'].) What does this buy us? - Several modules (e.g. Views) already need schema reflection, this just centralizes the information. It makes it much easier to create new modules that need reflection. A module that wants to support Views or other similar modules can hang any necessary data off its primary $tables array. In fact, many modules will probably not have to do anything more to support such reflection-modules. - Code size reduction and elimination of duplicate code. My automatically-generated schema for core (with all comments) is 110% the size of database.4.0.mysql, but it obsoletes database.4.1.mysql, database.psql, etc. The same reduction would happen in 5.0's system_install(). - A DBMS driver can use inspection statements (SHOW TABLES, SHOW COLUMNS) to actually validate the database layout against Drupal's internal schema, reporting errors. - It is a huge step towards enabling partial data migration across Drupal systems (this is a whole other topic). - hook_table_alter. - The Forms API made all kinds of things possible that weren't before, not all of them foreseen. This will, too. Yes, this is somewhat more complicated than writing a single MySQL CREATE TABLE statement. Supporting Views is extra effort, too, but has a big payoff for module developers; so will this. I assert that it is easier to create a structure like this once than it is to write AND MAINTAIN separate statements for MySQL, Postgres, Oracle, Sybase, MS SQL Server, and god knows what else. And module authors can keep using CREATE TABLE if they really want to. Anyway, that's my $.02. Thanks, Barry

7 9

Re: [development] Drag and Drop UI standards
by Ken Rickard 26 Jan '07

26 Jan '07

Let me redirect a little back to the original post. Any discussion other than UI expectations is premature. The original question is still primarily about user expectations, not the code used to implement. Using Interface for jQuery seems a logical start, but is not a requirement. (And the dual MIT/GPL license of Interface issue is noted here: http://groups.drupal.org/node/2512) It seems that we may have a significant number of contrib modules (and some core) that would benefit from a Drag-and-Drop UI. Given that, it seems wise to have some common guideliness, so that users don't face different UI for each implementation. Personally, I like Drag-and-Drop-and-Save (automated), but I don't want to implement that if Panels or Menus or Blocks uses Drag-and-Drop-and-Click-to-Save. Once we have common guidelines, we can build a best-case code module (or .js file). And that (eventually) might move to core. - Ken Rickard agentrickard

3 2

Validation for GD toolkit
by Darren Oh 26 Jan '07

26 Jan '07

This patch has been delayed because the Drupal 5 code had changed by the time Drumm got to it. Would someone please confirm that it now applies correctly before the code changes again? http://drupal.org/node/102987

1 0

Database schema abstraction and *reflection* (was: Referential integrity -- finally?)
by Peter Wolanin 26 Jan '07

26 Jan '07

Yes, I'm really behind this idea- I just didn't know what it was called before! This seems top be a requirement for being able to write generic drupal_load(), drupal_save(), etc. functions to reduce the total codebase and handle almost any type of object in drupal. http://drupal.org/node/79684#comment-184791 -Peter --- From: Barry Jaspan <barry(a)jaspan.org> To: development(a)drupal.org Date: Thu, 25 Jan 2007 19:03:12 -0500 Subject: [development] Database schema abstraction and *reflection* (was: Referential integrity -- finally?) I raised the issue of database schema abstraction last summer, and I know that other people raised it before me. The arguments this time seem to be the same as the used to be (though apparently Dries is closer to being persuaded :-). I would like to elaborate on my primary reason for supporting a database schema abstraction layer (not for data manipulation (SELECT, etc.), just for CREATE TABLE, ALTER, etc): database schema reflection. Schema reflection will provide Drupal the ability to understand and manipulate its own data schema (in the flavor of the Forms API). Every table's structure will be defined in a data structure (just like a form), indicating its columns and data types, keys, etc. I envision something like this (I wrote a perl script to automatically generate this structure by parsing 4.7's database.4.0.mysql. Other methods are possible, but it only has to be done once):

1 0

New maintainer for Gallery Module
by Kieran Parsons 26 Jan '07

26 Jan '07

Hi all, Unfortunately, I am looking for a new maintainer for the Gallery module (Gallery2 integration into Drupal). I can no longer spend sufficient time to update, fix and support the module as well as it needs. The module has been one of the most popular drupal modules (>2000 downloads/month in the last stats released). Gallery module is reasonably complex and some knowledge of Gallery2 internals would be useful (but I had none to start with). There are 4.6, 4.7and 5.x versions available and all work reasonably well. There are a couple of known issues which apply to all versions and some minor bugs. There are also many new potential features that could be fun. I will support as needed. Please let me know if you are interested. Thanks, Kieran (kiz_0987)

1 0

Unexpected behavior with user registration
by Dan Robinson 26 Jan '07

26 Jan '07

Could someone take a look at: http://drupal.org/node/110874 and tell me if I'm off base here? Thanks, Dan

2 2

hook_menu split is inevitable
by Karoly Negyesi 25 Jan '07

25 Jan '07

Hi, The current menu patch does work well. You see a navigation block and you can click links, the menu expands, you can visit pages and they load. All is well. Try this: give administer comments permission to anonymous (no other admin perms) and log out . Observe the comments link in the navigation block on the home page in the Navigation block for Drupal 5. The new patch will not even consider admin/content/comment for display. To do so, it would need to access check every single visible item in the menu table. As the new system does access checking on run time via callbacks, this will lead to slowdowns. We could attack this with various caching strategies but that's not the solution. The simple fact is that hook_menu need and hook_router should not use the same permission system. hook_menu should only do permissions, after http://drupal.org/node/73874#comment-116054 this patch is done it will be just a JOIN. This way, in a sense, hook_menu indeed can access check every single menu item. We will give the permissions a numeric ID and the JOIn can happen over menu_links, permissions_roles, user_roles -- a three table JOIN over numeric keys. Likely to be reasonably fast. So, what will happen eventually is that you are displayed a tree of links that you have permission to see. When you click on an item you might end up with a 403. The 403 comes from hook_router which will be able to use access callback/arguments for access checking because we need to do this only once per page so it wil not be slow. Note that in Drupal 5 no access check is performed on custom items, so for example if you put a node into the menu that the user can't access then the user will see the link but clicking on it will give her a 403. Even if the user has no access content permission, this will happen with Drupal 5. The new menu system will at least check access content, if not node_access. But this makes the split absolutely ineviatable. There are other fun problems with visible links and router items mingled into one: if foo is not defnied, foo/bar is not visible but foo/bar/this is visible and again foo/bar/this/that is not visible then how should we sort these paths? For inheritance purposes, the order I listed them is a must, but visibility purposes foo/bar/this actually appears on the first level. This is another sure sign that menu and router structures are very much not the same. I still propose to get the patch in as it stands. Before the navigation block was added back it was actually hook_router and it was pretty much without problems. Accept that the navigation block I added back yesterday is just a development tool and not the Real McCoy yet -- eventually the quirks above will be smoothed out. It's sheer impossible to do all changes at once. Regards NK

6 9

E_ALL mode
by Dries Buytaert 25 Jan '07

25 Jan '07

Hello world, I just committed http://drupal.org/node/99625 -- this means that E_ALL mode is now enabled in Drupal HEAD. We might want to disable this when we freeze Drupal 6, but for the duration of the development cycle it is a good idea to turn this on. It makes for better code. -- Dries Buytaert :: http://www.buytaert.net/

8 7

Eliminate hooks entirely in Drupal 6
by Earl Miles 25 Jan '07

25 Jan '07

After some discussion this morning, I am putting up a proposal to eliminate hooks entirely (though not the concept of hooks) and replace them with officially registered callbacks. I have identified several areas where this will improve Drupal (primarily in terms of probable performance gains). There are 2 parts to this. Part 1: drupal_register_callback function drupal_register_callback($callback, $function = NULL, $file = NULL) This function is only called from a particular location; ideally in its own separate .register file that only needs to be loaded when the callback registry is being rebuilt. However, it could also be a function within the .module file. There are some questions here, primarily balancing ease of use for the developer versus performance for the system. When it is called, the system should already know which module context is being used. This function would register a given callback (examples: nodeapi, form_alter, etc) with the Drupal system. The registry would replace the logic module_implements uses to determine which module implements which hook. The $function would be what's called. In today's world the function would be called mymodule_nodeapi; and it would likely not change, but we should allow registration to specify the function used. If left blank, the default function name would be constructed. (i.e, modulename_hookname). The $file would be a file that should live in the same directory as the .module file and tells the system which file to conditionally load when that callback is invoked. This is one of the things that creates a big advantage in this system: We could move callbacks into conditionally loaded files, allowing Drupal's minimum per-page codesize to be smaller. The 'nodeapi' hook is not run for every page load, but because hooks are anonymous right now, that code *must* be present. When you can conditionally load, however, the required size of the .module becomes very small. (in fact you would only keep items in that file that are called on every or nearly every page load. Currently that's hook_init and hook_menu but with changes to hook_menu that one may well be eliminated from every-page-load calls, and the .module file itself may not even need to be loaded for every page). Invoking a callback would still be the same: module_invoke('callback', arguments...); Part 2: function drupal_register_theme($theme, $args, $function = NULL, $file = NULL) This works very similarly to callbacks, but it registers a theming function that can be overridden by the theme. The only difference in is the $args argument, which is an array that tells the function how to translate function arguments into the $vars array, for use in .tpl.php files. For example, let's say I have the following theme function: function theme_foo($node, $bar, $baz); The $args array would be: array('node', 'bar', 'baz'). Themes would also have a similar registry; we may need to make it slightly more complex so that it could work with the theme engine to automatically register a template. Which means we might want to find a way to make it simpler for themers to register the templates they're using (for example, a directory scan could find well-named template files and automatically register them based upon already known registered info). This entire system (callbacks and functions) would be cached, so information would only need to be re-read when modules and theme settings are updated. A 'development' mode might be necessary that re-reads this information every page load. There would probably be some way for devel.module to expose this setting and automatically disable development mode when devel.module is enabled. Overall benefits to this system: 1) Some execution time is saved looking up module hooks. I don't believe this is a great deal of execution time, but it is definitely some. 2) A great deal of code can be loaded conditionally, reducing Drupal's footprint. I believe this could be a *very* significant boost to Drupal and could vastly reduce the amount of code that is loaded, making Drupal far, far friendlier to hosts that cannot use an opcode cache. 3) Certain namespace collisions will be avoided. Developers will no longer be penalized for forgetting that mymodule_user() is the user hook. 4) Theme functions will no longer have to hunt around for their function; they will not have to test the file-system to see if templates exist. They will know exactly where to go when the time is right. 5) Theme template files will be easier to include in modules. In fact, if implemented properly, modules could actually include .tpl.php files, make the proper registration, and no theme code will be harmed by being in the .module file *at all*. 6) phptemplate.engine can have much of its code removed to core, making it easier to implement alternative template engines. 7) As an interesting side effect, themes could be made to implement hook_form_alter, if we coded it that way. There is a value to this, and also an argument why this might not be a good thing. Overall cons: 1) Having to register a callback is less convenient than simply naming a function. It's even more inconvenient to have a .register file. However, using the existing naming convention, the module_builder.module *could* be made to scan a module and produce a .register file or a register function. 2) Having to register theme functions is similarly inconvenient but I think it's no worse than we have now. 3) Having to reregister upon making changes is very inconvenient; a development mode would be a must. Thoughts?

17 29