What we do have is a set of controls, together with measures which describe how to implement those controls. The very basic model is:
1 control <-> m measuresA set of controls can be packet together in a workbook (haven't found a better word for it), which then can be assigned to someone (e.g. infrastructure guys) to define the implementations and their respective fulfillment.
1 measure <-> m implementations
This is all kind of vague, and it will probably will remain to be vague and not 100% defined in a strict (relational) domain model. It might for example be possible that some controls have more attributes than others. This is of course possible to be modeled with object compositions, but this is always the point where ORM starts to produce to much friction heat...
And this vagueness is imho a indicator for the need of a kind of semi structured data model. And this again is a good sign for using the data first approach: use the hierarchy as structuring model, and, well, see to more structure later. Maybe :). Therefore JCR is the weapon of choice....
As for Sling: I am still completely indecisive regarding the right client technology. Therefore it makes sense to have a REST-full interface to the business domain.
And Sling is sexy. Want to use it. 'Nuff said.
Next steps would be to answer some questions regarding Sling development. Currently I am scouting the message boards and the (way too sparse) documentation...
- what's the best way to setup a Sling project? Use webdav for deployment?
- How to backup/restore work?
- How to design a JCR/Sling project? Top down? Paralell development of content model and functionality?
- OSGI Best Practises
- Which client-side technology to choose?
