Module API recommandations for better and more efficiant use of modules

I searched for "API recommandation" and some other combinations, but no results.

I would like to see a strong recommandation for module developers, where to put what in modules. We have 3 files which almost every module has. I would like to see a few more files, which idealy, are included automaticly by the core, if they exists. These are: MODULENAME.forms.inc and MODULENAME.api.inc.

Many modules are developed VERY good, they come with REAMMEs, API.txt and so forth, but in time of development the code moves on, the API.txt might not.
I started to put "public" API stuff from my modules into an extra file, so everyone of my follow devs have a sneak into that file and pretty muchs knows what they can do with my module. The *.module file will still have enough code for block display, pages other hooks and so forth.

The only thing I don't know is if there would be an huge impact on page load if there are a couple of more files to inlcude.

Btw. I know that some modules come with MODULENAME.api.php files already, but there is only dummycode in there and I *guess* that shall help IDEs such as ZEND to provide helpers for faster development. I never use those myself.

Do It With Drupal 2009

Lullabot is pleased to announce the second annual Do It With Drupal Seminar. This 3-day event is focused on the configuration, architecture, and processes behind building successful Drupal websites and communities.

The event is geared at attendees with a wide range of Drupal experience. For new site-builders and decision-makers, DIWD will offer a great introduction to Drupal and the Drupal community. For more experienced Drupalers, DIWD will offer a great chance to pick up tips and tricks straight from the module developers themselves and a chance to connect and socialize with other Drupal professionals.

The Do It With Drupal Seminar will feature the following highlights:

  • Examine and dissect successful Drupal sites
  • Discover new site-building strategies
  • Learn from Drupal's top developers
  • Hear from social media and social networking experts
  • Connect with other Drupal professionals
  • Expand your Drupal knowledge

This commercially produced event takes place at the Marriott Hotel in New Orleans' French Quarter, December 9, 10, 11, 2009 and features sessions by many "big names" from both inside and outside of the Drupal community (see list of current speaker list below).

The current list of speakers includes...

Module "Package' names - open for discussion

It would be useful to have one page somewhere where we could see all the package names used for various modules so that developers had some chance of consistency of package names.

Right now I see that most of my installed modules are under "Other", but I also get things like one under "Content display" and another under "Content displayed" or some other subtle difference that really shouldn't be there.

What style shhet do I edit?

I am new to Drupal, but catchin on rapidly. I am liking it. One area I am somewhat totally new too is CSS. I will dive in later, for the tme I can modify style code to get by. My question: which style sheet do I edit? All I want to do is center content in the block region. I am using the Garland theme. I opened it in Mozilla with developers tools installed. When I select the header reagion to edit I get 2 style sheets as targets:

Impact of the inclusion of PDO in D7 on module development (from a stylistic perspective)?

In your opinion, what changes in coding methods do you think will occur in light of the "Next Generation" of the Drupal DB layer in D7 (wrapped around PDO)?

The PDO library seems to be very "class oriented", and it allows the new DB API to be programmed in much more of an object-based manner than the old API.
For instance, we now have constructs like this:

  $result = db_query("SELECT id, title FROM {example_table}", array(), array('fetch' => 'ExampleClass',));

The above code passes the results of that query to the constructor of class 'ExampleClass', to create an instance of that object.

I have seen some, but not very much, object-oriented code in contrib modules (usually when they are a wrapper around something else, like the smtp auth module that wraps phpmailer); since Drupal has never been considered "classically" object-oriented (though it shares some of the core concepts), it has not encouraged this sort of programming except in a few specific ways (like the $node object, which IMO is just an easy way to serialize and make it easier to pass the node around - there are no methods, etc...).

Do you think we'll find that newer D7 contrib modules take advantage of this functionality, which IMO has not up to this point been part of "The Drupal Way"?

Pages

Subscribe with RSS Subscribe to RSS - Drupal 7.x