And since we're touching the
configuration part, I think we should completely rewrite this part, as
the current system is sooo bad (I mean the
XWiki#get[User/Web/XWiki]Preference[AsSomething] methods and the giant
XWikiPreferences class). This was supposed to be a Configuration
proposal that I was thinking about, but didn't have the time to write
until now. So here it is:
hmm... I thought I had already sent a configuration proposal but I
can't find it. It's possible that I started writing it and discarded
it... I think I was not fully happy with it. I had started
implementing it (I still have my code) but couldn't find a nice way of
doing some things and just pushed it back to later as a
consequence... ;)
However I do remember listing the characteristics that this
configuration component should have but I can't find it again.
I don't have the time to reply to the text below. I'll need to digest
it first and merge it with my proposal. My proposal was a very generic
proposal addressing all xwiki configuration needs but not going into
your level of details for the configuration done in xwiki pages.
Thanks
-Vincent
Requirements:
1. We should allow an application/component to be configured at the
farm, wiki, space, user and document level (the specificity can be
configured for each setting), with static values in the component's
xml
configuration and default values in the java class file or in the
template/wiki document using the configuration (depending on whether
there is a component/java/template part).
2. An application should be able to define its own customization
xclasses, the same class being usable for all levels of customization
(now, some settings go both in XWikiUsers class and XWikiPreferences
class). In fact, XWikiPreferences should disappear completely.
3. Global (farm) settings should go in
[mainwiki]:Admin/GlobalPreferences, wiki settings should go in
Admin/WikiPreferences, space settings should go in
<Space>/SpacePreferences, user settings should go in the user profile.
The current locations are inappropriate (WebPreferences??). [I'm not
sure if Preferences is a good name, as the list of blog categories is
not exactly "preferences", but more like "settings"]
4. The settings pages include an administration sheet, which later
lists
all customization pages in the wiki that are customizable at that
level
(for the moment, using an explicit search, later using Interface
Extensions).
5. The configuration should be accessible using a simple API, which
should find the right settings, internally taking care of all the
details: consider the lowest level for that setting (some settings are
valid only at the wiki level, or even global, so don't search or allow
settings at a lower level), security (some settings should only be
taken
into consideration if the author is trusted), in-wiki and in-file
settings. This means that the application should call one method, and
not have a complicated code combining getUserPreference,
getWebPreference, getXWikiPreference and Param.
6. All this should be done without changing the data model (meaning
that
we use the classic xclasses/xobjects for this).
How things work:
An application lists one or several wiki documents in its application
description as customization classes. Administration sheets (also from
the application) are then autoincluded in the global, wiki or space
Administration page, and in the user settings page. Such a sheet would
check if the class allows customization at the current level, and if
not, warns about this. If there is no instance of the target class, it
provides a link for creating one (doing it automatically is another
option, but I don't think it is a good idea, as this pollutes the wiki
with unused objects). The sheets should follow a common guideline, for
consistency. All options should be documented in the sheet.
The application code then calls the settings component API to check
the
settings that apply for the current document/user. Of course, all this
with lots of caching for good performance (this is not the case in the
current core, as a lot of time is spent cloning XWikiPreferences in
HibernateCacheStore).
The hard part is deciding how to configure these classes and sheets.
Since we shouldn't use different Property types, we can't add a
customizationLevel metaproperty. A feasible solution would be to
require
all properties in the same class to have the same level of
configuration, and either specify in the application description, or
use
a tag for that. The best would be to have a document property, but the
current data model does not have that.
Proposed API variant 1:
/* Gets the current setting for an application, from the specified
class. */
String getSetting(applicationName, className, settingName);
/* Same as above, when the application has only one settings class
defined. */
String getSetting(applicationName, settingName);
/* If the current document is known to belong to a certain
application,
get a setting for that application */
String getSetting(settingName);
/* Stops at a specified level, instead of the default one. */
String getSettingForLevel(applicationName, className, settingName,
maxLevel);
/* Returns the setting at a specified level, with no inheritance. */
String getSettingAtLevel(applicationName, className, settingName,
exactLevel);
Proposed API variant 2:
/* Search for the setting name in the attached objects. */
String getSetting(settingName);
/* Gets the current setting, from the specified class. */
String getSetting(settingName, className);
/* Stops at a specified level, instead of the default one. */
String getSettingForLevel(settingName, className, maxLevel);
/* Returns the setting at a specified level, with no inheritance. */
String getSettingAtLevel(settingName, className, exactLevel);
- I don't know if we need methods returning other types, like int or
double, since we can use velocity tools for converting the returned
string
- I don't know if we should have the applicationName in the parameter
list, or just the className; my take is that specifying the
application
name is a bit more semantical and less technical
- maxLevel should be an enum, but we need a custom introspector for
this
to work
- maxLevel assumes a fixed order of levels, which is an obvious one,
except for the User level. Where should that be in this order? Is the
user preference the most important one?
So, WDYT?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs