Karoly Negyesi wrote:

Start from http://drupal.org/node/33338 there are lots to read.

Upload the code somewhere where we can read (drupal.pastebin.com works for short code) and you may get some actual help :)

NK

Thanks for the reply. I've uploaded my _submit function to drupal.pastebin.com. http://drupal.pastebin.com/717633 (seems to be running a little slow right now....) The problem I'm having is determining when I should be doing an update instead of an insert. The insert part works great. The update never fires. the suggested documentation is a great resource if I want to know how a particular function works. Where I'm having problems is understanding how all the parts of the framework are related. It took me two days to figure out that I needed the "name" part of the drupal_get_form function, and then could use that name in relation to my other functions (name_subit for example). And my usual troubleshooting techniques of dumping variable values, and using "I'm here" type entries do not work in the validation or submit functions. My traditional approach to handling inserts/updates is to check the ID value for my record. If it's not set (zero), then it's an insert, otherwise it's an update. Is there a different/better approach to use in modules? Thanks for any tips. Shawn

I'm an experienced developer and enjoy well documented APIs. Drupal's is a good resource - for those who understand WHY things are the way they are. The approach to building a module or a form requires a certain mindset. This mindset is not documented, and this is the part that Fouad is referring to I think. For instance, in my case, I don't really want a new node type. But I want some of the features a new node buys (like a known fixed path when working with the module). Of course you do this with the menu methods. But how would that be obvious to someone who has not done enough work to figure this out by trial and error? The detail is hinted at in a few places, but it is subtle enough to be overlooked easily. (of course now I'm doing a merge of node_hooks, page_hooks, menu_hooks, and form_hooks). Don't get me wrong - what documentation does exist is great, and thanks are given to all the contributors. What is lacking (unless I haven't found it yet) is what I consider the "hand holding" type of documents to get from zero knowledge about Drupal code to creating the average types of modules. An average module would have database tables and forms to create/update data, as well as pure content management type routines. The current Module Developers Guide is a great start. But misses some of the details that make everything "click" for a new Drupal coder. I don't mean to be whining, but judging from the responses I received to my original message, there does seem to be room for improvement (isn't there always? :) ) and I'm hoping that discussing it might help. Thanks for listening... :) Shawn Fouad Riaz Bajwa wrote:

Reference to Shawn's query, There is no roadmap designed to facilitate developers design 1. Themes 2. Modules These are the two main components of the Drupal Framework that have huge loads of documentations available but no simple steps or tutorials that makes Drupal design for short-period development deadlines troublesome. I got a job task for 5 days for quite some income that could have helped me out a lot but I lost it because the user design was complex and there was no simple means or if not simple, for that matter, a straight forward method to design a theme based on personal design requirements. Second for the module, there should be a straight forward set of "module templates" or "module framework skeletons" that one can pick up and design their requirements.

Let me give you an example of the most most most common custom Modules (forms style) that almost every developer has to design: 1. Master Detail Forms, Insertion Forms, Deletion Forms, Modification Forms 2. Calculator Forms etc.

The developers of Drupal are not considering that Drupal is not only for CMS and Web Application developers, it is for a much wider community that needs a lot of functionality support.

Regards ----------------------- Fouad Riaz Bajwa

sime wrote:

Hi Shawn There is at least one document that is quite good. How to enact change in the drupal community. ;-) http://drupal.org/node/36602

Noted. Sorry, I only JUST getting more involved with the Drupal project (though I've been using Drupal since 4.3). So, I'm still learning the "ins and outs" of the community. Shawn

- when you are going insane, go to #drupal-support RSS and talk it through.

oops, that should be "IRC" :-P

Dries Buytaert wrote:

That's valuable feedback! Best if you could turn that into documentation, or help improve the existing documentation. Like that, we might save hours of development time, and we could get more people on board.

And that's the catch 22. I am trying to find the info so that I *could* write such a document one day. I want to do a write up on my blog for this, but I'm much too early in my learning to attempt to tackle this. If I could just figure out why my update isn't working, I'd be well on my way to getting there. If it helps, I've posted my work in progress at http://grover.open2space.com/files/issues_module.php (it really is a work in progress - I haven't yet cleaned out troubleshooting code and such). Oh, and I had to rename the file as .module files are not allowed to be downloaded. Be gentle.. :) Shawn

Karoly Negyesi wrote:

...

http://grover.open2space.com/files/issues_module.php

Some obvious wrongs:

$sql = 'select * from issues_projects where project_id = '. $pid; $dbresult = db_query($sql);

this is the biggest no-no

$sql = 'select * from issues_projects where project_id = %d'; $dbresult = db_query($sql, $pid);

(yes there is a is_numeric check -- that's at least something, but then you are reinventing the wheel... and what you will do when you work with strings? better if you get used to placeholders)

$form['projectid'] = array('#type' => 'hidden', '#value' => $prj->project_id);

you are much more secure with

$form['projectid'] = array('#type' => 'value', '#value' => $prj->project_id);

I would simply echo (or more nifty, watchdog) that $prj->project_id in here -- are you sure the problem is with form API?

Anyways, this is much better suited for a forum topic...

Thanks for the feedback. I'll open a form posting. As for the echo - no joy in the _submit or _validate functions (I think it has to do with included files being processed then an ob_clear() being called). the watchdog function sounds promising, I'll look into it. The likely culprit is my code, not the form api per se. But I'm struggling trying to figure out why my code is not raising errors, but not working. Anyways, thanks again, I'll move this to the forums. Shawn

Jeremy Epstein wrote:

In the Drupal handbook, there is a great resource called "Creating modules - a tutorial":

http://drupal.org/node/17914

Needs to be updated in places (was written for 4.5), but despite this, it still does an excellent job of teaching you the basics of Drupal module development. Grokking the menu callback system, and its central role as the foundation of almost any page request in Drupal, is probably the biggest challenge for new developers. Also a challenge is getting your head around the "hook magic", and how all of that actually works, and then understanding a few of the more important hooks in detail (e.g. hook_block, hook_help, hook_nodeapi). This tutorial will help you to at least begin to overcome these challenges. :-)

Cheers, Jaza.

Thanks. That document was my first stop, even before posting here. It IS a good introduction. Unfortunately, I'm jumping in with both feet, and immediately had a need beyond what the tutorial covered. But it did help me get my initial shell in place, which is getting better as I learn tidbits in my journeys (like using the db_next_id() function instead of auto_increment fields). and you're right about understanding how the hooks work. For me it's more of a matter of figuring out which hooks to use when. Thanks again. Shawn

On Sun, 18 Jun 2006 18:24:34 +0200, Fouad Riaz Bajwa <bajwa@fossfp.org> wrote:

Reference to Shawn's query, There is no roadmap designed to facilitate developers design 1. Themes 2. Modules

Not sure what you mean exactly, but there a theme system overhaul in progress, that should easy theme development. The current theme docs have also been targeted as needing work by some members of the documentation team. You're welcome to help out. Heine