Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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

    • by mst (6121) on 2008.01.03 10:16 (#59928) Homepage Journal

      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 whether I think that's hacky or elegant :).

      As for the states, the example of Class::Workflow will come when I write the code for it, and I the events that change states mostly have notes fields anyway. If you're making a transition that doesn't I'm hoping to make the UI such that you can make a comment on the same form, so while the two aren't linked in the DB they'll get the same timestamp and will appear in the event log for the todo next to each other.

      The "have we got enough approvals" part -is- going to be app-side, because I can see us wanting to tweak the approval approach quite a bit (notice you've already made one suggestion for a tweak ;) so I want to be able to achieve that with a quick code deployment. Plus it means when that gets changed the old data is still accurate. Perhaps we should simply enforce from the app that the submitter approves first and the vienna person second?

      I'm currently getting out from under a pile of backed-up-from-the-holiday work but will be implementing starting tomorrow.