[development] Forms API newbie guide?

sime info at urbits.com
Mon Jun 19 02:59:56 UTC 2006


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


Shawn wrote:

> 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
>
>
>
>
>
>


More information about the development mailing list