Part two of the TODO Manager article series is up - Database and Domain Design is available here, in which I don my gear and go exploring in the barren wastes of confusion and spite with only a one-page wiki spec as a map, seeking the one true design for my domain that will allow me to build an app atop it that meets the requirements in full.
Comments, as usual, live here.
TodoComment needs created_at (Score:1)
Reviewing your design, I think you might want a timestamp in the TodoComment class.
wow (Score:2)
Due to various real live issues (nothing tragic, just boring stuff like buying food...) I've only yet had time to review your Database and Domain Design.
The short story: Wow! You're putting a lot of effort into this.
And the details: At first, I had slight problems understanding the Class definitions, but apparently I'm not a complete moron, so I worked out their meaning. Still, I'm left with one question: Is this some Reaction/Moose syntax, or pseudocode?
User Management. Your design forces people to
Re: (Score:1)
Well, we need to be able to support people who don't have a login anywhere else they want to use so that's the part of the functionality that -has- to be implemented - plus we have to have the e-mail address pretty much no matter what for notification purposes. However I think we should probably auto-login PAUSE accounts [perl.org] if they provide an @cpan.org address and an appropriate password - I can handle that the same way rt.cpan does by doing a quick POST to PAUSE and checking the results (I can never decide wh