- Development - lists.drupal.org

nodify.module idea: 'everything is a node'
by Nedjo Rogers 28 Jan '07

28 Jan '07

Hi folks, An idea I'm hoping for some feedback on before wading into coding. As Drupal devs we've often talked about how to give all Drupal objects (terms, vocabularies, users, nodes, etc.) all the features of nodes. Instead of relying on separate APIs and methods and access control etc. for each object type, we look for a single system that each of these could tap into. Instead of implementing separate ways of adding characteristics (e.g., user profiles), we look for all the benefits of a single, soundly developed one (content.module). I'm pondering a 'nodify' module that would accomplish these aims through attaching content.module content types to each object. Create a user/role/term/vocabulary and it gets all the characteristics of an admin-configurable content type. We already have similar implementations. One I've been looking at with interest is fago's usernode module. It's a node type module that attaches nodes to users. (The module can be manually edited to instead use a different, e.g., CCK, content type.) Basically we'd do the same thing, with two differences: 1. instead of doing so for just one Drupal object type (users), we'd construct a set of methods that could apply to all types. 2. instead of implementing a custom node type through a node module we'd use content.module to create a new, extensible node type (getting the advantages of being able to add fields). As a result, we'd be able to do things with non-node objects like: - attach anything implemented through nodeapi (e.g., mailing) - implement access control through node_access modules - add CCK field types - expose directly to views - control rendering through nodapi 'view' op - etc. Specifically, I'd see: 1. A core set of handlers and methods, like: - nodify_create_content_type() to create a content type with a name llike 'nodify_term' or'nodify_user'. - nodapi hook implementation - hook to load data on supported object types - custom hooks as needed to call methods in all supported object types. e.g. nodify_help() might call help in all support object types' .inc files for messages specific to that object type, e.g., a term. 2. For each module with a one or more supported object types, an include file (e.g., taxonomy.inc for terms and vocabularies, user.inc for users and roles) with specific methods: - hook implementation to describe available supported object types. E.g., taxonomy.inc would return something about supporting 'term' and 'vocabulary'. - custom hook implementations, e.g., of nodify_help. - hook implementations (user.inc implements hook_user(), taxonomy.inc implements hook_taxonomy) to attach - form alters: e.g., term editing form is altered to add the node edit form for 'nodify_term' content type. - views hooks Questions: - does this approach sound useful? - who's working on something similar? better? - pitfalls? - anyone wanting to work on this? Thanks, Nedjo

15 36

OSCON Portland
by Dries Buytaert 28 Jan '07

28 Jan '07

Hello, if someone wants to present Drupal at OSCON, Portland -- make sure to submit your proposal at: http://conferences.oreillynet.com/cs/os2007/create/e_sess The deadline is Frebruary 5th so don't wait too long with your proposals. -- Dries Buytaert :: http://www.buytaert.net/

1 0

Help saving our tribal initation
by Karoly Negyesi 27 Jan '07

27 Jan '07

Knowing the seven arguments of l is our tribal initation and with http://drupal.org/node/111347 we are about to lose it! Oh noes! I hereby behest everyone not to review/benchmark that or any carpetbagger will be able to write Drupal code.

4 3

Re: [development] Database schema abstraction and *reflection*(was: Referential integrity -- finally?)
by Metzler, David 27 Jan '07

27 Jan '07

I was wondering if the model code for the new forms API might be a good place to start for syntax. Wouldn't it be cool if the way we talked about data for the model portion of a form would be the same as the way we talked about data in the schema? Or does that seem silly? Anyway I love this idea, as it opens the door for much more postgres or other db support. The lowest common demoninator for DML is much easier to achieve than in the DDL in my experience. Dave

4 3

CONGRATULATIONS YOU ARE ONE OF OUR NEW YEAR WINNER!!!!!!!!!!!!!!
by drupal-devel＠drupal.org 27 Jan '07

27 Jan '07

GOVERNMENT ACCREDITED LICENSED!!! SALOTTERYONLINE INTERNATIONAL LOTTERY IS REGISTERED UNDER THE DATA PROTECTION ACT OF; (Registration SAE343556L). ................................ SANDTONWINNERS LOTTERY.ORG 220 RIVONIA ROAD, KWAZULU NATAL,SOUTH AFRICA CONGRATULATIONS!.... FROM: PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: ZAR/26244050/2007. BATCH: 34/432234/CK/SAP Att: The Owner of this Email Address Re: Award Notification of Final Notice We are pleased to inform you of the release on the 26TH JANUARY 2007,the Result of the SANDTONWINNERS WORLDWIDE LOTTO,SA promotion program held on the 25TH JANUARY 2007.Your email address attached to the ticket number 654-882409-470 with serial number 19-13-19-36-47-69,which consequently won the lottery in the 3rd category. You have therefore been awarded the lump sum of RANDS 30,000,000.00 in cash credited to file number ZAR/26244050/2007. Your funds are deposited with a security company, which will be insured In your name once you contact the security company. Due to a mix up of some names and numbers, we strongly recommend that you keep this award a top secret from the public notice until your claim have been processed and the money remitted to your account. This is a part of our security protocol to avoid double claiming and unwanted scams of this Program by other participants. All participants were selected through a computer ballot system drawn from 25,000 email addresses from all over the world as a part of our International promotional program, which is done twice annually. We hope that with a part of your prize, you will take part in our end of year high Stake #1.3bn lottery. To avoid fraud and scams, and to begin your claim,Please contact only your assigned agent,MR.TREVOR DLAMINI ; Foreign Service Manager of SANDTONWINNERS LOTTERY.ORG via email on (claims_department_agent(a)yahoo.co.uk)For processing and remittance of your money to a designated account of your choice. All prize money must be claimed not later than 14days from the date of this notice, as after this date, all funds will be returned to SANDTONWINNERS Worldwide LOTTO INTERNATIONAL as unclaimed. In order to avoid unnecessary delays and complications, You are advise to fill out the details required from you below and forward it to your claims officer. Congratulations once more for and on behalf of all members of my staff And thank you for being a part of our promotions program. Yours sincerely, MR.TREVOR DLAMINI CLAIMS MANAGER. TEL: +27-8375-44-098 Email: clearification002za(a)indiatimes.com Email:claims_department_agent@yahoo.co.uk SOUTH AFRICA NATIONAL LOTTERY : WINNING PRIZE CLIAMS- LOTTERYCLAIMS APPLICATION FORM-C (Prize Winning Receipt) ============================================================================================ 1.Full Name: 2.Full Address: 3.Marital Status: 4.Occupation: 5.Annual Income: 6.Age: 7.Sex: 8.Nationality: 9.Country Of Residence: 10.Telephone Number: 11.Fax Number: 12.Ticket Number(above): 13.Reference Number(above): 14.Batch Number(above): 15.Email Address: :::::::::::::::::::::::::::::::::::::::::::::::::::: CLAIMANTSIGNATORY DECLARATION ==================================== I,.....................................HEREBY DECLARE THAT I HAVE NEVER RECIEVED ANY SETTLEMENT FROM THE NATIONALLOTTERY PROMOTION PRIZE AWARDS WINNING NOR ANY MEMBER OF MY ? FILLED CLAIM ON MY BEHALF TO NATIONAL LOTTERY INTERNATIONAL PROMOTION. I, THEREFORE, SOUTH AFRICA NATIONAL LOTTERY PROMOTION PRIZE AWARDS WINNING PROMOTION TO ACT ON MY BEHALF IN THE PROCESSING AND TRANSFER MY PRIZE AS INSTRUCTED BY ME. ======================================================================================= Very Truly Yours, MR.JACK TUMELO Email:claims_agent1@enownow.com Zone Co-ordinator. NOTICE OF CONSOLATION PRIZE WINNING!!!!!!!!!! Material Copyright � 2006 The Lottery Co. Ltd

2 1

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