Project and Project Management Design

@dcthomp Hmmm, I might need to recalibrate.

The notion of persistence is what I have been ascribing to resource::PersistentObject.

  • I am a big fan of designing public interfaces to be intuitive, or at least consistent with end users’ mental model.
  • I am not a big fan of reusing existing classes for convenience (alhough, yes, I do it…)

Agreed. But PersistentObject doesn’t specify how persistence is achieved, only the means by which it may be persistently addressed (UUID). Resource does say how persistence is achieved: in a “location()” (i.e., at a URL). Component also specifies how it attains persistence: via its parent Resource.

I agree about intuitive, but am not so sure about consistency with end users. As a population, end users have lots of different ideas coming in… they can’t all be right. What is important is to convey our organizational principle, which we choose for efficiency, to them. If there are pieces that are difficult to use but necessary for efficiency, that is an indication that a higher-level API is needed, not that the low-level API needs change.

We discussed the latter- change log for user changes to the project.
Initially I was thinking the user might edit, but something auto-generated may be useful as well.

I added the requirement - right now its to allow the user to enter why the project is being saved but could be refined later.

1 Like