For a recent project, we were tasked to consume the client's internal data from a custom API. Now, this scenario was lucky for us, the API provides a total item count of about 5000, but when queried with a start date, it provides all revisions of items between then and now. The premise was that the data was to be downloaded at regular intervals, so that content editors didn't need to copy and past to keep product information up to date.
Marcus Bernal's Blog
Sometimes during development, a chicken and egg situation happens when business logic intersects with Drupal's mechanisms. For instance, a custom module,
client_business_logic, is built to handle some unique, abstract bit of logic which depends on a taxonomy vocabulary that has fields added to it.
Data protection is one of the primary advantages of Drupal, but sometimes there are exceptions to the rule and you might need to modify a field to account for some change in business needs. There are a few rule bends (read hacks) that can be done to circumvent Drupal's checks and still maintain data integrity. You should only perform this when extending a field or changing something reasonable that is allowed by the database server. For example, expanding a varchar length or changing unformatted string into a formatted text field.
Rather than provide a basic how-to tutorial on Drupal's form API #AJAX functionality, I decided to address a few pitfalls that often frustrate developers, both junior and senior alike. To me, it seems that most of the problems arise from the approach rather than the direct implementation of the individual elements.