Chapter 2 - Taking Baby Steps

Creating an initial development environment, whipping up the initial prototype of the on-line Literary Workshop (website application to be developed chapter by chapter right through the book.

Install modules via CVS?

Aside from my question in Ch. 4's user stories, I also wonder why you did not suggest installing modules by CVS in your book? I'm kinda surprised that you didn't even mention the pros & cons. Would you mind sharing with us your thoughts on that? Thanks.

The policy in the book is to use drush and SVN

In the book I reject using CVS for the snapshot of the website application, since CVS is an outmoded and obsolete method for managing a project. I hope people will use drush and have drush automatically enter the modules into SVN version control, and update in accordance with that project level SVN version control. I don't want to tell people to use CVS at all.

It is still the easiest way to deal with Drupal core install and update, though.

However, if you are interested in pursuing the installation of modules via CVS, check out Tim Millwood's "Streamline Drupal CVS Checkout" at http://millwoodonline.co.uk/streamline-drupal-cvs-checkout . He has some nice bash functions you can place in your .profile or similar.

CCK form vs. default registration forms with content profile

Hi Victor!
I was wondering, why you have made anonymous users that want to subscribe to the Literary Workshop site, to fill in a CCK node form, instead of adding cck fields to the default "register" form of the user creation?
You can do that using Content Profile in Drupal 6.x (but there were other similar options in Drupal 5.x too).
That way, I think it would be easier to manage new users that are queued in moderation, until the admin checks them out, and activate their accounts.
Regards,
Rosamunda

Because we need to persist the application

As always, a great question, Rosamunda.

First of all, even though we use Drupal to prototype Drupal, we mustn't confuse Drupal's "roles" with the "roles" we are working with in our Agile approach. That is, an anonymous user role simply means unauthenticated in Drupal; however, a "role" (i.e. "workshop member") is the user in user story, and there may be several who are anonymous users in the Drupal sense, but pertain to different roles; in the case of the on-line literary workshop the example would be the following two:

  • I want to become a member of the community
  • I am a publisher and I want to publish on on-line magazine in the community

The needs and objectives of each of these users lead to different sets of user stories, and, as a result, to varying functionality, and not the same functionality that can be reduced to modifying the default register form. It would be very complicated, because there are different classes of "new users" and they need different things, and we need to persist that data right from the start and it needs a workflow and...

That is the discussion.