- Development - lists.drupal.org

Re: [development] Drupal - to use objects or arrays
by Larry Garfield 10 Jan '07

10 Jan '07

I think the general guideline is "use what makes semantic sense at the time". A single entity is an object. (Eg, nodes, users, etc.) A list of things is an array. A list of entities is an array of objects. When you get into really complex data structures, like FAPI, then I think deeply-nested arrays are easier to work with and more predictable (esp. between PHP 4 and PHP 5) than deeply-nested objects. You can have an object one of whose properties is a complex nested array (Nodes created with CCK, esp. in Drupal 5, do that). There's no hard rule, but I think "what makes semantic sense when writing it" is the guideline. Oh yes, and when iterating over records from a database where it really doesn't make a difference, using db_fetch_object() seems more common than db_fetch_array(), simply because there's fewer funky characters involved with objects than arrays. :-) On Tuesday 09 January 2007 3:57 pm, Doug Green wrote: > To use objects or arrays? What is the "Drupal way"? I'd rather write code > using objects (php's stdClass). But I've run into a ton of problems using > objects on php4. > > The CiviCRM folks have this handy guide for php5 -> php4: > > > > http://wiki.civicrm.org/confluence/display/CRM/Writing+PHP4+Compatible+code > > > > But even after using it, I'm having difficulties. I'm starting to conclude > that I should convert all my object references to arrays. I only see a > couple of object references in core, and none to anything complicated > (arrays of objects, objects pointing to objects, object elements of arrays > of objects, etc). > > > > Doug Green > > www.douggreenconsulting.com <http://www.douggreenconsulting.com/> > > www.civicactions.com > > > > Changing the world one node at a time! -- 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 10

Re: [development] Drupal - to use objects or arrays
by George Kappel 09 Jan '07

09 Jan '07

Based on what I have seen you are better off using non-objects for things you want to cache. As an example there is a lot less overhead when using APC with arrays vs objects To use objects or arrays? What is the "Drupal way"? I'd rather write code using objects (php's stdClass). But I've run into a ton of problems using objects on php4. The CiviCRM folks have this handy guide for php5 -> php4: http://wiki.civicrm.org/confluence/display/CRM/Writing+PHP4+Compatible+code But even after using it, I'm having difficulties. I'm starting to conclude that I should convert all my object references to arrays. I only see a couple of object references in core, and none to anything complicated (arrays of objects, objects pointing to objects, object elements of arrays of objects, etc). Doug Green www.douggreenconsulting.com <http://www.douggreenconsulting.com/> www.civicactions.com Changing the world one node at a time!

1 0

How to represent event organizers?
by Leo Burd 09 Jan '07

09 Jan '07

Hello there, I hope this is the best list to present my question... I wonder what is the best way to represent event organizers in Drupal. Ideally, I would like to be able to list all the events organized by a certain user and/or group. Has anyone already implemented this functionality somewhere? Suggestions would be very welcome!! Thanks in advance, .L.

1 0

Re: [development] Rename *_load and friends
by Metzler, David 09 Jan '07

09 Jan '07

I agree with James on this. There's something elegantly simple about hook_something turns into module_something. How many times something gets fired and for how many modules is something that part of the definition of an api subject to change. I don't see value in tying too much weight to what's called a hook and what's not called a hook. And I don't want to change my intro to teaching module development from "Writing drupal modules is as easy implementing the desired functions in the drupal api that begin with 'hook_'". I also want to see us set the example of having contributed apis start inventing new ways to describe hooks. I'd rather see us all channel the energy into updating the docs for the hooks to be more clear about when those events fire, and for what purpose they are for. Something like: hook_load - use this hook to define the database load event for implementing a new content type in a module. See hook_node_api if you're looking to extend an existing content type. hook_node_api - used to add value to a node implemented by another module. See hook_load ($op='load') if you're looking to define a new content type. We'd modify these docs by submitting core patches, yes? The docs for hook_nodeapi are really good about describing when they should be used. Perhaps we just need to clarify in hook_load* when they should be used. I'm done on this topic.... Dave -----Original Message----- From: development-bounces(a)drupal.org [mailto:development-bounces@drupal.org] On Behalf Of James Walker Sent: Saturday, January 06, 2007 8:08 AM To: development(a)drupal.org Subject: Re: [development] Rename *_load and friends On 1/6/07 1:22 AM, Karoly Negyesi wrote: > Hi, > > We have had a discussion about this already under a different subject. > > My opinion here is that hook_foo is something that gets implemented by N > modules and at call time these are called, one after the other. > hook_menu , hook_form_alter etc etc Note that 'hook' is always replaced > by the module name. > > Despite hook_load is called a hook, it's a different animal: at call > time, only one implementation is called. Not to mention that since we > have a node information hook, 'hook' is not necessarily replaced by the > module name. > > Larry Garfield suggested calling these method_load, method_view and so > on. This I find a good idea and now would like to get opinions on this > name. I'm not sure I know why they need different names, and I'm not sure where you draw the line. While I absolutely am +1 for keeping hook_load, etc in addition to hook_nodeapi - I don't know that calling some method_* vs. hook_* really brings all that much clarity. We use "hooks" for *lots* of different things - sometimes pass by reference sometimes by value, with all kinds of different expected return values and behaviours. I don't know how much this single distinction helps. Not to mention, I think we can disappear into a dark hole arguing the semantics (i.e. in OO & AO programming, they're all just called "methods" anyway). The nice thing about the 'hook' name (whether invented or otherwise) is it's easy to teach new developers how hooks relate to the code their looking at, and further that when you see module_foo() you can find full documentation on api.drupal.org by searching for hook_foo. I've done several training sessions now and have not run into a whole lot of confusion from the naming. Fact is, they're not really "methods" - reusing a name with a common, different meaning for most developers may well just add confusion. that's my $0.02 anyway. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net

5 6

Hook ordering
by Karoly Negyesi 09 Jan '07

09 Jan '07

Hi, Reading the hook_nodeapi thread... In Drupal 6 I would like to see a hook registry -- mostly autodiscovered, but if you want ordering, then you can say "my implementation of hook_nodeapi is to be run before module this,that,foor,bar". Available in my sandbox, weight.php . It's trivial to extend this capatibility to packages as well, so that if you ask to be run before !views then you will run before all modules that belong to the views package. All nice and dandy. But, the next step would be to request for "I want to be the first for hook_foo". What am I to do if two module asks for this? Die a horrible death? Disable the offending modules? This code, quite obviously will run on the modules page. Regards NK Ps. Extending hook registry to hook#op is also in the plans.

7 15

Request to be listed as provider of Drupal services
by Alexis Bellido 09 Jan '07

09 Jan '07

Hello, I'd like to be listed as a Drupal consultant in http://drupal.org/drupal-services , I've contributed the following projects: QuickFile: http://drupal.org/project/quickfile An ecommerce oriented module to sell digital download to users who don't need to have a Drupal account. Works with Paypal and Authorize.net and future versions will support other payment processors. Newsletter Checkbox: http://drupal.org/project/newsletter_checkbox A simple add-on to the contact page so that users can mark a checkbox and be added to a newsletter. It currently works with Campaign Monitor's API. This is my user profile: http://drupal.org/user/14007 If after reviewing my case you consider me in the list I'd like to use the following text for my page on the directory: =============================================== I'm a writer and long time peruvian web developer living in Lima, Peru. After running a local based web agency and crafting many websites I decided to incorporate Ventanazul LLC in Florida, United States, in 2004, and start working with customers all over the world. That same year I joined the Drupal community. You can visit my website at: http://www.ventanazul.com/webzine , where I frequently write about web development, technology and Drupal. Some of my Drupal related projects include: http://www.felafacs.org Community site for Federación Latinoamericana de Facultades de Comunicación Social, a Latin America based organization formed by communication faculties of public and private universities. http://www.mumobo.com Personal site with reviews about music, movies and books. http://www.teleworkpeople.com Articles and discussion forum for teleworkers, home of "Telework People", a book I wrote on the subject of working using the Internet. Spanish is my native tongue and I'm quite fluent in spoken and written English. I've recently published the ebook "Drupal en 15 gotas", in Spanish, and am about to finish the English version: "Drupal in 15 drops". The ebook is oriented to web developers and focuses on the installation and administration of Drupal 5. I've contributed two modules to the Drupal community: QuickFile: http://drupal.org/project/quickfile An ecommerce oriented module to sell digital download to users who don't need to have a Drupal account Newsletter Checkbox: http://drupal.org/project/newsletter_checkbox A simple add-on to the contact page that allows users to mark a checkbox and be added to a newsletter. It currently works with Campaign Monitor's API. Services offered: - Installation and configuration of Drupal. - Creation of custom Drupal modules or modification of existing ones. - Web graphics design and porting of your own designs to Drupal themes. - Web standards based design. - Usability consulting. - Internet businesses consulting. Contact: You can use the following contact form to get in touch and discuss your project: http://www.ventanazul.com/webzine/contact ============================================== Thanks! -- Alexis Bellido

1 0

Re: [development] QA: Consensus on comment formatting
by Metzler, David 08 Jan '07

08 Jan '07

IIRC: //* @TODO is also supported by doxygen. The extra * is what gets doxygen to parse it. -----Original Message----- From: development-bounces(a)drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Angela Byron Sent: Monday, January 08, 2007 11:33 AM To: development(a)drupal.org; dopry(a)thing.net Subject: Re: [development] QA: Consensus on comment formatting On 8-Jan-07, at 1:31 PM, Darrel O'Pry wrote: > for phpdoc // @todo wouldn't work... /** @todo would word */ OK. In that case, I'm going to need to -1 @todo. /** stuff **/ as inline comments sucks, because then you can't comment out large blocks of code easily, which is something essential to debugging. That coupled with everyone else saying that // TODO is supported in their editor of choice makes this a closed case, imo. -Angie

2 1

Re: [development] QA: Consensus on comment formatting
by Angela Byron 08 Jan '07

08 Jan '07

Excellent! Thanks for the summary, Derek!! > Here's a new draft of the conventions given everyone's input, my > votes above, and a few other suggestions: > > > * Comments should be written in English, with correct spelling[2], > punctuation, and grammar. > * Being concise is best, but never at the expense of clarity. > * Comments are capitalized and end in periods. They should be > complete sentences on their own line unless they are documenting > lists, or are describing a line of code that only needs a few extra > words to be clear. sentences are separated by a single space.[3] > * @file documentation begins with a sentence in present tense, and > has a blank line before any further comments. > * Function documentation begins with a single sentence in the form > "Do such and such." rather than "Does such and such.", and has a > blank line before any further comments. > * There is a blank line between @param and @return sections in > function documentation. > * Comments should not use all caps, e.g, NOTE. Instead, use @note, > @todo, @warning, @bug, etc. > * Any comment that refers to a variable should include the dollar- > sign in front of the $variable_name. > * Any comment that refers a database table should use {table_name} > to make it visually unique, not "table_name", 'table_name', etc. > * In general, URLs, code snippets, file names, etc, should not be > enclosed in quotation marks (") or inverted commas (') unless it > significantly enhances readability. Where necessary, inverted > commas should be used rather than quotation marks. > * No comment should be, or cause a line of code to become, wider > than 80 characters. > * In general, comments should not refer to issue node ids (for > example, "// This is crazy, and we fixed it in #12345."), since > that's what the CVS annotation and commit logs are for. However, > links to issues are allowed (recommended?) in a @todo or @bug. In > this case, a full URL should be used. For example: > // @todo These queries are very expensive, see http://drupal.org/ > node/105639. > Now, just one (technical) question. Does this: > // @todo These queries are very expensive, see http://drupal.org/ > node/105639. > ...actually work and get parsed by doxygen?? I thought doxygen only worked on function headers. This would make @todo less useful, imo, since: // TODO: this can be an expensive query. Perhaps only execute it every x minutes. Requires investigation into cache expiration. if ($user->uid) { db_query("UPDATE {users} SET access = %d WHERE uid = %d", time (), $user->uid); } Tells me that the queries immediately following that line are expensive, vs. /** * Reads a session variable. * * @todo the update query used here can be expensive.... */ function sess_read($key) { Anyone know? Also, as Robert brought up, // TODO, etc. have support in IDEs (Zend, etc.). Can someone check if @todo does as well? -Angie

6 6

Re: [development] QA: Consensus on comment formatting
by Karen Stevenson 08 Jan '07

08 Jan '07

Speaking as a developer who has probably violated every convention on the list, I think this idea makes a lot of sense, and I think this list nicely sums up all the issues being discussed. Looks like I have a lot of rework to do, so: +1 for being gentle with developers whose modules don't meet these standards : -) Karen ----- Original Message ---- From: Derek Wright <drupal(a)dwwright.net> To: development(a)drupal.org Sent: Monday, January 8, 2007 5:25:19 AM Subject: Re: [development] QA: Consensus on comment formatting +1 for for Angie and Nedjo calling for a standard. ;) +1 for standardizing on @todo, @note, etc as supported by phpdoc/ doxygen[1]. +1 for a newline between @param and @return. +1 for allowing // A little extra clarity. (as a "1-liner") +1 for formatting comments like sentences, but not requiring full sentence grammar on 1-liners. +1 for 80 chars wide if possible. +1 for always referring to DB table names as {foo}, not "foo", 'foo' or foo. Even though it's technically not required as a delimiter since the names can't have spaces, i find it adds a lot of clarity to quickly be able to tell if a comment is talking about the DB at all, and if so, which table(s). Here's a new draft of the conventions given everyone's input, my votes above, and a few other suggestions: * Comments should be written in English, with correct spelling[2], punctuation, and grammar. * Being concise is best, but never at the expense of clarity. * Comments are capitalized and end in periods. They should be complete sentences on their own line unless they are documenting lists, or are describing a line of code that only needs a few extra words to be clear. sentences are separated by a single space.[3] * @file documentation begins with a sentence in present tense, and has a blank line before any further comments. * Function documentation begins with a single sentence in the form "Do such and such." rather than "Does such and such.", and has a blank line before any further comments. * There is a blank line between @param and @return sections in function documentation. * Comments should not use all caps, e.g, NOTE. Instead, use @note, @todo, @warning, @bug, etc. * Any comment that refers to a variable should include the dollar- sign in front of the $variable_name. * Any comment that refers a database table should use {table_name} to make it visually unique, not "table_name", 'table_name', etc. * In general, URLs, code snippets, file names, etc, should not be enclosed in quotation marks (") or inverted commas (') unless it significantly enhances readability. Where necessary, inverted commas should be used rather than quotation marks. * No comment should be, or cause a line of code to become, wider than 80 characters. * In general, comments should not refer to issue node ids (for example, "// This is crazy, and we fixed it in #12345."), since that's what the CVS annotation and commit logs are for. However, links to issues are allowed (recommended?) in a @todo or @bug. In this case, a full URL should be used. For example: // @todo These queries are very expensive, see http://drupal.org/ node/105639. any final changes/editions/subtractions? ;) thanks, -derek [1] http://www.stack.nl/~dimitri/doxygen/commands.html [2] i really don't care about "american" vs. "british" spelling. english sux, but it's the best we've got. :( [3] personally, i find 2 spaces between sentences *way* more readable, but i've already lost that debate (at least a bunch of patches already went into core to force it to 1 space) so i don't intend to re-hash that decision. i'm now in favor of 1 space in comments, just for consistency and less work moving forward.

2 1

QA: Consensus on comment formatting
by Angela Byron 08 Jan '07

08 Jan '07

Hey, folks! In doing a bunch of last minute clean-up patches for the 5.x release tonight with the help of Doug Green's lovely Coder module (http:// drupal.org/project/coder) and ran into the area of comment conformity. Awhile back, Nedjo made a valiant attempt to bring order to the chaos of the way comments are written in Drupal (http://drupal.org/node/ 72240). He lays out some rules there which I think are great and awesome, and seem to fit the way we do things generally in Drupal. However, Dries posted (rightly) that we should come to consensus on this, and document it, before enforcing it. So! Anyone have a problem with these rules: * Comments are full sentences ending in periods. * There is space between %param and %return sections in function documentation (do we want this? sometimes we do it, sometimes not). * Function documentation begins with a single sentence in the form "Do such and such." rather than "Does such and such.", and has a space before any further comments. * Where we have a Note: it is not all caps. * Spelling, grammar, punctuation corrections. And if so, I'll bite you. ;P haha, j/k. No, if so, please make your case as to why one or more of these _shouldn't_ be the way Nedjo specifies here. I'll commit to rolling patches for fixing this, if not for 5.x then for 6.x. -Angie

13 16