I just completed a Drupal project that was more an application than it was a website. The program pretty much centered on a custom node type that we created, and instances of this type could be accessed by users depending on their roles. The main node type linked to other nodes and had fields that were user or taxonomy references. The purpose of the site, or in this case the application, was to integrate and manage tasks for the users, to make things easier for them to synchronize their schedules. These are some of the contributed modules that our team used:
Admin_menu – This was included to allow for easier navigation of the Drupal core menu items. I found it useful since I am, as of yet, memorizing the urls of all the Drupal components. It also gives the clients who are not regular Drupal users a simple way to navigate the admin menus. I recommend this module for the “mouse” type developers like me who prefer clicking as opposed to typing.
Location – Using this saved us a lot of time because the address fields that the client wanted, were all already built into this module.
Multiselect – One of the client’s requirements was to have a main list of users and then be able to create a different, shorter list of users by picking from the main list. This module had the form elements already built and it allowed us to integrate it in multiple places.
Views_bonus – I personally had a lot of fun with the Views module, I was able to customize the output (overriding the tpl’s) change the actual sql statement (hook_query_alter), allow the columns to be shown/hidden (template.php preprocessing), or limit the view to certain users (access field in the view), among others. The standard module (Views) itself is very robust and can do almost anything you need it to do in terms of summarizing/tabulating nodes or data. What I found that it couldn't do was to export the results of the table. This is where the views_bonus module came in; it allowed you to save the results of the view into a .csv type file to be viewed externally. It also exports into different formats and due to time constraints, I was not able to experiment with the full extent of its capabilities. The module itself is still in early stages of development but this one is something to keep an eye out for. We also made use of the standard modules, Views, CCK, date, content_profile, webform etc., but these were the “non-standard” ones that allowed the project to come full circle. Because this was more of a web application, it allowed me to comfortably transition into Drupal from a desktop app development environment. I have experienced the power of Drupal first-hand and I think it was a baptism of fire so to speak. People have called it a framework and I don’t disagree with that label. The project was successful, though not without bugs. Looking forward, I think markets will transition to predominant usage of web apps because of their accessibility regardless of machine or location. My next project looks to be a straight-forward information website, which might even prove to be more challenging than this one was. Thankfully I will be able to use Views again, which is turning out to be my favourite Drupal component to date.