August 2007 - Development - lists.drupal.org

DRUPAL-6 tag
by Doug Green 13 Aug '07

13 Aug '07

When do we get a DRUPAL-6 tag? -- Doug Green douggreen(a)douggreenconsulting.com 904-583-3342 Bringing Ideas to Life with Software Artistry and Invention...

4 3

08/09 actions
by Karoly Negyesi 10 Aug '07

10 Aug '07

http://members.nowpublic.com/priest_nabbed_while_running_nude (good stuff) http://members.nowpublic.com/woman_gives_birth_rare_identical_triplets http://members.nowpublic.com/journalist_invades_privacy_candidates_underage… http://members.nowpublic.com/out_bushes http://members.nowpublic.com/america_under_surveillance http://members.nowpublic.com/science_outsells_harry_potter http://members.nowpublic.com/science_outsells_harry_potter_0 http://members.nowpublic.com/node/593633

3 3

New Module Ideas and Announcements
by John 10 Aug '07

10 Aug '07

Hi all, When a developer has an idea for a module, they are often not the only one with that idea. Currently, new modules are mostly invisible until they show up as a project. And IDEAS for new modules are / completely/ invisible unless they are discussed in the ephemeral IRC. As I'm sure you all know, this leads to code dupe. If we had a central location for announcing modules, we could: * Reduce module duplication. We can prevent two independent developers from writing separate, duplicate modules. * Increase developer collaboration. We can get interested developers working together at an early stage of development. * Improve module quality. Others can shape and improve the ideas, leading to a better module from the beginning (or, at the least, a better road map for future development.) Rather than cluttering up the drupal-devel list with module announcements, I created a Drupal Group: http://groups.drupal.org/ contributed-module-ideas (the name was chosen to be in-line with the contributed-module-status group.) If we can get enough buy-in to this idea, I think it would be a good idea to add a note to the "Maintaining a project on drupal.org" page ( http://drupal.org/node/7765 ) that modules should be announced on the Contributed Module Ideas group, in addition to requesting a CVS account. This might also help out CVS Administrators if more eyeballs were reviewing the modules associated with new CVS account requests. What does everyone think? If you have a specific criticisms or enhancements, reply to the list. If you simply have "+1" comment, why not just subscribe to the group? - John John Wilkins | Albin.Net | nickname: JohnAlbin

15 22

Minor tweak in Manage strings admin page
by Vasileios Lourdas 10 Aug '07

10 Aug '07

Hi, There is a number of strings that start or end (or both) in white spaces, for example: t(' (<span class="admin-disabled">disabled</span>)') [notice the space in front of the opening ( inside the string in t() ] The Manage strings admin page fails to visually display this string *correctly*, because the user cannot distinguish whether the string starts or ends in a white character. This is a UI issue and I suppose the interface should present strings such as this one above in a way that the user understands the existence of any white spaces at the start or/and end of it. One idea that came to mind is to present such strings in a different background color (eg. light grey) and also inform the user of this issue. Thoughts? -- # Vasileios Lourdas, # Informatics Engineer, Thessaloniki (Greece) # http://www.lourdas.name

1 0

Let's finally document our schema already!
by Angela Byron 09 Aug '07

09 Aug '07

Harry Slaughter, JonBob, myself, and others have tried countless times to come up with a workable solution for documenting our database schema. This either resulted in static images and so forth that were impossible to maintain, or trying to work around MySQL's comment length limitations. However, with the Schema API, the day is saved! Joy! Earl came up with this slick idea in the Views 2.0 schema to stick a 'description' attribute on each field in the schema file. Drupal will of course ignore this, having no knowledge of what a description is, but human beings (and probably eventually parsers) can read this information in order to determine what the various fields are for. Additionally, the documentation is *part of the source code*, which means we can deny schema additions until they have documentation associated, just as we deny new functions without PHPDoc. And finally, because the descriptions are stored in t() functions, that means the documentation is (potentially?) translatable to other languages. I've taken this idea a couple steps further (by adding table descriptions as well as field descriptions, and adding in foreign key information), and have started documenting all core schema files here: http://drupal.org/node/164983 I'd love help from: - Anyone at all who has some time on their hands and would like to learn Drupal's schema inside and out by helping to document the remainder of the files, using the existing patch as a guide. - Core committers, to give a thumbs up/thumbs down to this approach before we dump a bunch of time into it. ;) - Schema API folks, to give guidance, esp. on foreign key representation. - Experts on the lesser-used aspects of Drupal (aggregator module, for instance) who can clarify what some of the fields are for. - Testers, to make sure the patch doesn't horribly break things. ;) Thanks! -Angie

10 13

Theming documentation for developers
by Earl Miles 09 Aug '07

09 Aug '07

I finally got around to writing proper documentation for the new theming system from the perspective of a module developer. This doc has never really existed in the past and even with the simpler theming system in Drupal 5 and previous, it probably should have, since it helps to encourage best practices. Please see: http://drupal.org/node/165706

3 2

Re: [development] FAPI's future
by Karen Stevenson 08 Aug '07

08 Aug '07

>>This is a good case for hook_forms() being a requirement, not an >>optional mechanism. Right now, users can just call drupal_get_form >>('lovely_delicious_bacon') and FAPI will go about its business >>happily, checking for a lovely_delicious_bacon() function, then >>checkig hook_forms() to see if lovely_delicious_bacon was really >>mapped to my_module_bacon_form(). >>If we were to make even the simple forms require the use of hook_forms >>(), we would have a very simple transition and an easy place to put >>descriptive metadata. ("What kind of form is this? What module does >>it belong to?" Etc.) We also have many places where we have functions that create sub-form arrays of form elements that are re-used in various places. Well, we have those in contrib for sure, not sure about core. Anyway, I wonder if requiring hook_forms() for every form and sub-form array might be overkill. We really have a variety of things we might want to identify-- simple form elements, more complex collections of form elements that are used in multiple places, and complete forms that are made up of both simple and complex form elements. Don't we really just need something like hook_info() for forms where these things can announce themselves and provide some metadata? That is sort of what CCK uses to identify available widgets, and I was thinking that that kind of system (hook_info() for form elements) might be something that could be migrated to core. Karen

1 0

DrupalCon Barcelona: call for presentations
by Dries Buytaert 08 Aug '07

08 Aug '07

Hello all, as you know, DrupalCon Barcelona takes place next month! Yep, that's next month already. :) We have room for a big venue for 4 days with at least 3 parallel tracks. If we aim for 6 1-hour sessions per room per day, we can host 72 sessions in total. I believe we actually have the room to organize more than 3 parallel tracks. Anyway, on http://drupalcon.org there are currently 22 proposed presentations (see http://barcelona2007.drupalcon.org/sessions) which means we are about 50 presentations short. *gasp* Hence, I'd like to invite you to submit your presentation proposals -- login at drupalcon.org and go to the "create content" page. We'll probably communicate a deadline for such proposals relatively soon -- at one point we need to compile a conference program as it helps attract attendees. You know how this works. :) If you've never been to a DrupalCon before -- don't be afraid to present. Everyone is encouraged to participate and present, and all sorts of presentations are welcomed. These can include deeply technical presentations ("Drupal 6 menu system internals"), fun presentations ("How to trick Dries in committing your patch?", "A history lesson in Drupal flamewars"), tutorial style presentations ("How to contribute patches", "Theming Drupal", "Drupal in education"), beginner sessions ("An overview of the best Drupal modules"), brainstorm sessions ("How could we make Drupal easier to use?", "How could we make Drupal easier to theme?"), panel discussions ("How to run a successful Drupal company?"), showcases ("How we built site ABC for company DEF"), you name it. We'll have a mixed audience (prospects, beginners and experts) so we need to cater for all those people. So, give it some thought, and help us compile a compelling program. Feel free to swap ideas on the mailing list or to request certain presentations. Somewhere next week, I'll move this thread to drupal.org along with additional details. It would be great to have more than 22 presentations by then ... Thanks all, -- Dries Buytaert :: http://www.buytaert.net/

19 36

Re: [development] DrupalCon Barcelona: call for presentations
by Karen Stevenson 08 Aug '07

08 Aug '07

>> SchemaAPI and how it ties in to both CCK and Views is definitely an important issue. There's also the possibility of programmatically generating basic CRUD screens from SchemaAPI definitions; now that we can store table and column metadata, and are beginning to explore relationships, Ruby-esque auto-generation of CRUD scaffolding is within the realm of possibility. >> Next for Schema API is definitely relationships, from there we can have common queries built automatically which will lead to data API instead of CCK... I've been holding off scheduling anything until I knew for sure I was going to make it to Barcelona. I wanted to create a session where we can brainstorm about both CCK contrib in 6.x and directions for CCK both in core and whatever is left in contrib in 7.x. It sounds like there are a number of people with some vision of where they see it going, but I'm not sure I understand what those visions are and I'd like to hear their ideas and have a chance to flesh them out. Plus I agree that data API is definitely a necessary step in the evolution, but I'm not sure that is the end game. That is CCK for developers, maybe, but the beauty of CCK is that it makes it possible for anyone, developer or not, to customize things. So even with data API we still need something that provides a nice end-user UI for creating and maintaining their fields and widgets and some sort of catalog of custom fields and widgets that are available. And we still need custom formatters and maybe things like a custom validation library. And we still need to figure out what data API will look like :) Anyway, I hope we can get anyone with ideas into a room for a good CCK brainstorming session at Barcelona. Once I'm sure I'll be able to get to Barcelona I'll add a session for this. (Or anyone else who is interested can certainly do it). Karen

1 0

Re: [development] FAPI execution order cheat sheet
by Karen Stevenson 08 Aug '07

08 Aug '07

I took a stab at trying to create a FAPI flow chart at http://drupal.org/node/165104. It's not a complete flow chart of everything that happens. I was trying to identify the major hooks and callbacks, and their order, to see what opportunities are available to intervene. I tried to illustrate the 5.x process and mark places where 6.x changed. I have no idea if I've gotten it right. It badly needs to be looked over by one of the FAPI experts :) Karen ----- Original Message ---- From: Chris Johnson <cxjohnson(a)gmail.com> To: development(a)drupal.org Sent: Tuesday, July 24, 2007 5:30:08 AM Subject: Re: [development] FAPI execution order cheat sheet Karen, a FAPI flowchart and/or cheat sheet is a great idea. Hopefully one of the FAPI experts will be willing to proof read such a thing if others create a draft.

4 3