On Fri, Jan 04, 2008 at 09:09:30AM +0100, Bart van der Schans wrote: > I see a lot of hard coded node(type) names in the hippo namespace, like > hippo:usersettings. I would like to keep all the node names / paths, > nodetype names and item names in one (or maybe two) central places. The > obvious place to do this now is in HippoNodeType.java. > > As a first step to improve the situation I would like to propose the > following: > 1. Never use hard coded hippo:* things, always put them in HippoNodeType > 2. Keep HippoNodeType organized by type groups and alphabetical order > 3. Use hippo namespace for "repository" things and hippocms for "cms" > things (like preferences)
Or "hipposample" for things which are just sample/demo related, such as sample content and document model. > 4. Use consistent names in HippoNodeType, we now have *_PATH, NT_* and > HIPPO_*. (something like HIPPO_PATH_*, HIPPO_NT_*, HIPPO_ITEM_* ?) The HIPPO_ prefix is useless and just makes code that much larger (I like smaller code). The constants are already in a class that starts with Hippo, so it is already clear enough. I.e. HippoNodeType.NT_DOCUMENT iso. HippoNodeType.HIPPO_NT_DOCUMENT. The change for HIPPO_* to ITEM_* is a good one probably, but is the seperations between ITEM_ PATH_ is not really really there, there both path (segments). > 5. Use javadoc to document *all* entries in HippoNodeType. > 6. Slap anybody around with a big large trout who still hard codes > hippo:* ;) I don't think hipposample should be there, and the hippocms is probably not the right place for them too, as it is specific to a front-end application, not to the whole model. I don't thing hipposample namespace should need to occur anywhere in code. The hippocms should probably have its own class with definitions. However we discussed this earlier; there is namely a problem that if you really want customizability and independent add-on plugin development, then this common definition file for node types is in fact a problem. Plugins cannot fully be developed independently if they need to update a shared class and require a release of that shared class (ie. the whole CMS). What we need, instead of the current wild-growth of definitions, is a common generic definition, which is able to encapsulate 90% of that we need to be configurable in node types. These should go into the common shared file, as they will be more-or-less fixed. This means that the bulk of plugin development can go without adding new node types. And those rare instances where you do need this, you probably end-up with a node type that does not need to go into a specific definition file, can be kept local to that plugin. So we probably need a step to goggle up all the wildgrowth we're making now. \Berry -- Berry A.W. van Halderen [EMAIL PROTECTED] / [EMAIL PROTECTED] Disclaimer: the above is the author's personal opinion and is not the opinion or policy of his employer or of the little green men that have been following him all day. ******************************************** Hippocms-dev: Hippo CMS development public mailinglist
