cubicweb #506878 rename schema/ and entities/ [open]
Strictly speaking, the schema is the drawing of the data model. We could rename the schema/ directory to model/. And the entities/ directory contains the logic/ of the application. That would get us to model/, logic/ and views/, which is even closer to something understandable without documentation. Maybe the contents of hooks/ could be moved to logic/ at the same time. Of course the old directories would be supported and warnings issued for the next two versions. | |
| priority | normal |
|---|---|
| type | enhancement |
| done in | <not specified> |
| load | 0.500 |
| load left | 0.500 |
| closed by | <not specified> |
similar entities
- Building my photos web site with CubicWeb part V: let's make it even more user friendly
- cubicweb #1768109 [migration] add_cube will create missing entities from unrelated cubes
- Using Facets in Cubicweb
- Building my photos web site with CubicWeb (Part I)
- cubicweb-addressbook address book component for the CubicWeb framework
[see all]
Comments
-
2010/04/22 07:14, written by sthenault
-
2010/08/06 10:38, written by nchauvat
- schema becomes model
- sobjects and hooks become server
- entities becomes logic
- views stays as it is
-
2010/11/15 09:27
-
2010/11/10 16:01, written by acampeas
- almost gratuitous, un-consensual breakage
- will yield ugly bw compat code
- transitioning all apps will cost a lot & take time
- the currently used terms look nice, adequate (to some people at least)
- "even closer to something understandable without documentation" may mean something to django/sa people, but there is life beyond these
-
2010/11/15 09:27
add commentimo: * keep hooks * sobjects merged with views * pre|post create files move to model
After discussing this further with sylvain, I realized that the actual separation depends on where the code runs. There is code that will run on the server side, code that will run on the ui side and code that will run on both (logic). Depending on where the code runs, imports are allowed or not. Importing cubicweb.web for example, is allowed only in the code that runs on the ui side, but not on the server side or both sides.
Taking this into account, I think we should rename things to have:
Then we add tests that enforce the import restrictions described above (and we document these restrictions).
a lot of logic happens in hooks in my experience.
strong -1
I agree with acampeas: please defer this to CW 4.0 (if you insist on renaming stuff).