[xwiki-devs] [Discussion] What direction to take the administration application.
When I was trying to figure out how to cleanly configure the registration page, I wrote a piece of code to handle it. The code is at XWiki.ConfigurableClass and it displays configuration for applications which contain objects of the same class. Documentation is here: http://code.xwiki.org/xwiki/bin/view/Applications/AdministrationApplication#... In adding this I made a few assumptions which may not be the direction which the community wants to go. #1 I added a document called XWiki.RegistrationHelp to the default XE package which explains how to configure the registration page. In the Registration section of the administration interface, I made the labels for the input fields into links to the relevant sections of the help page (I like links :) ) Vincent has suggested that instead of links we were to use popups or tooltips because they would not allow the user to leave the administration interface. The currently existing links could have click handlers added to show a popup and block the click so that they still work for users without Javascript. The other and more major issue in my mind is that I can't think of a way to show only information for the item clicked on while keeping the help page a single unit which can be read (and edited) easily. Another option would be to remove the help page and links but I found myself reading code to figure out what some of the parameters meant so I don't think that is a realistic option. I am in favor of continuing with the method which I started because I feel that popups are an attack on my browser and I see no way to keep tooltips centralized for reading beginning to end and for easily updating when things change. #2 When I added configuration for the registration page, I did not want to add it to XWikiPreferences. This is not only because I want to keep my code modular but I want to put myself in the position of an application developer so I can see the API from their point of view. This has lead to configuration for XWiki.Registration residing in XWiki.RegistrationConfig. It has been pointed out to me that this will make upgrading more difficult and I agree but I don't think adding properties to XWikiPreferences class for each and every application is reasonable and since third party developers cannot do that I see this as a deficiency in our API. The options I can see are to add a "Document Type" which defines a particular document as a configuration document which should never be upgraded but I think this is wrong because even configuration needs to be upgraded, it is the values which need to remain. Also I am not a fan of separating configuration to a document different than the code because the code needs to handle the case where the configuration is unavailable and I think code making static references to a document name is an antipattern. My proposal is to create another class just like ConfigurableClass except it will be UpgradableClass. A document may have an object of UpgradableClass and that object can either A. Point to another object in the same class which should have it's values loaded in on upgrade or B. Add some code which should be run on upgrade. It is important to understand that the document can be changed but the upgradable objects will load the values from the old object and set them in the new object. #3 Because the configuration for the registration page is seperate, it cannot be saved along with XWikiPreferences in a single save operation and because there is configuration for the registration page in XWikiPreferences and in RegistrationConfig, they are both specified to be displayed in the "Registration" section of the administration interface. XWiki.ConfigurableClass handles this situation by creating two forms with two save buttons and a heading in the middle saying "Configure XWiki.RegistrationConfig" It would be easy to override this with another message and it would be possible to make a single button for users who have Javascript enabled but it introduces the question do we want third party applications to anonymously add parameters to a section of the administration interface. I suppose the best answer would be to separate all of the parameters having to do with registration from XWikiPreferences (and stop referring to them in the core). I can think of no better solutions to this at the moment. #4 (No hasty changes here, just a proposal) The administration application uses the "admin" struts action which calls the AdminAction class. From my looking at AdminAction class I think it can be removed entirely and struts can be redirected to the InlineClass (Unproven claim). This brings up a point about permissions: admin permission must be had in order to use the admin action but only edit access to XWikiPreferences is required to do the things offered by the administration action. see: https://localhost:8443/xwikiTrunk/bin/edit/XWiki/XWikiPreferences?editor=obj... In fact admin action is not even necessary to use the Administration Application see: https://localhost:8443/xwikiTrunk/bin/inline/XWiki/XWikiPreferences?xpage=ad... I think the myth that admin access is necessary to do the administrative functions is dangerous for administrators who may leave security holes as a result. My proposal is that we try removing AdminAction to sandbox and redirect /admin/ in struts to InlineAction. I also think we ought to redefine admin access perhaps as the combination of view, edit, and delete which cannot be denied at a lower level (so a space admin can delete a page even if it denies them access.) I have made XWiki.ConfigurableClass with the idea that it should be able to do all of the functions of the administration application (meaning XWikiPreferences would have a ConfigurableClass object for each section in the administration application). I am always happy to hear when somebody wants to use ConfigurableClass but I don't think porting XWikiPreferences over is a good idea until ConfigurationClass has had some time in the field and we are sure that we don't want to change any of it's behavior. Sorry for the long email, I had a lot to discuss and didn't want to spam the list with 4 emails about the administration application. Caleb
Hi Caleb, #1 I know you dislike JS, but on the other side, I completely agree with Vincent that having information right at hand in a popup, is better, quicker and easier for most users that having to switch back and forth in a page with documentation. This especially true when you fill-up forms since you should also avoid losing already filled fields. So, your click handler proposal is a nice idea. To only get the part of the documentation you really need, I wonder if the document section mechanism that is used for editing could not be reused here ? I hope it could do the tricks... I agree that Popups are attacks, but not ToolTips. This should be AJAX based. Even a properly delayed mouseover handler could be nice. #2
From the application developer point of view, I see two situations:
a) there is only one global configuration for my application, or one configuration per Spaces b) there could be multiple configuration for my application, not dependent on Spaces For b), configuration should be stored in any documents, and used by reference to it. For a), my feeling is that the configuration object, that will have its own custom configuration XClass, like you have done, should be stored in a centralized document, either at the wiki level or the space level. Currently these centralized documents are XWiki.XWikiPreferences and WebPreferences. There is a very annoying issue currently with XWiki.XWikiPreferences because both the XClass and the XObject are stored in the same document. This made the upgrade of the XClass really difficult. I propose to change that by stopping any upgrade of this XClass, and deprecating it in favour of specialized XClasses, that will store their XObjects in XWiki.XWikiPreferences. The rationale is that XWiki.XWikiPreferences document should never be upgraded, and that we still be able to upgrade individual configuration XClasses since upgrading XClasses properly does not break existing XObjects. There is just a remaining issue, maybe why you choose not to store your configuration outside of XWikiPreferences, which is to have a default configuration when no instance are available in XWiki.XWikiPreferences (or WebPreferences). I suggest that a default XObject be stored in the XClass document, and that the wiki provide 2 standard mechanisms, one that allow creating a new XObject from that default one in the API and the UI (general mechanism for any XClasses), and another that allow interrogating the preferences with a fallback to that default XObject when no XObject has been found in XWiki.XWikiPreferences. WDYT ? #3 This would be solved with my proposal in #2 #4 I mostly agree with you on that point. It should also be noted that with the Colibri skin, when a fields from the preferences is missing from the admin interface, it is very difficult to switch to the object editor, something really easy in Toucan. This had to be solved as well, since Admins should be able to pass over the admin UI when required, and typing URL is not funny. #offTopic (I know it's bad) I was really impressed by your work but... If you mix of the Registration page and the RegistrationConfig, you covers most part of the features we have develop on our side (in our Groovy API) to support any kind of forms that create new objects and documents. You even goes one steps further in some domains, and I really wonder if all these stuffs could be improved to be more general than your initial purposes. However, I am little bit puzzled by some overlap you have introduced as well. Native XObject as already an existing labelling, validation and error message mechanism based on informations store in the XClass. Not perfect solution, it should be improved to be usable. Why do you have choose to externalize that information (improved also, but made more technically expressed using JSON) for the registration form ? I know there is some peculiarities in the registration form, and some fields, like the username and the password are somewhat not real fields, but such situation also append in any application that use forms. So why being so specific, since this is a requirement for any kind of forms. Doesn't your own configuration forms could benefit of a validation mechanism ? I really like to see a more integrated and user friendly way to provide these features for any objects, but maybe this as to wait the new model ? Not sure that your single mail option was better than separate ones, this makes also my answer quite long :\ I feel sorry as well. Denis
Denis Gervalle wrote:
Hi Caleb,
#1
I know you dislike JS, but on the other side, I completely agree with Vincent that having information right at hand in a popup, is better, quicker and easier for most users that having to switch back and forth in a page with documentation. This especially true when you fill-up forms since you should also avoid losing already filled fields. So, your click handler proposal is a nice idea. To only get the part of the documentation you really need, I wonder if the document section mechanism that is used for editing could not be reused here ? I hope it could do the tricks...
I agree that Popups are attacks, but not ToolTips. This should be AJAX based. Even a properly delayed mouseover handler could be nice.
Ahh, mouseover handlers have me reaching for the noscript button instantly. I suppose if it waits ~3 seconds it won't be accidentally fired. We need to figure out how to display only a section of the help page (regarding the part the user viewed) instead of the entire help page when a user clicks on a help link. I am -1 for tooltips until I can see a way to store the information in a single place.
#2
From the application developer point of view, I see two situations:
a) there is only one global configuration for my application, or one configuration per Spaces
Taken from http://code.xwiki.org/xwiki/bin/view/Applications/AdministrationApplication#... "configureGlobally (boolean) - Set this true if your application should be configured in the global administration page and false if it should be configured in the administration page for the space which the application resides in."
b) there could be multiple configuration for my application, not dependent on Spaces
See: What happens if I add more than one ConfigurableClass object? http://code.xwiki.org/xwiki/bin/view/Applications/AdministrationApplication#...
For b), configuration should be stored in any documents, and used by reference to it. For a), my feeling is that the configuration object, that will have its own custom configuration XClass, like you have done, should be stored in a centralized document, either at the wiki level or the space level. Currently these centralized documents are XWiki.XWikiPreferences and WebPreferences. There is a very annoying issue currently with XWiki.XWikiPreferences because both the XClass and the XObject are stored in the same document. This made the upgrade of the XClass really difficult. I propose to change that by stopping any upgrade of this XClass, and deprecating it in favour of specialized XClasses, that will store their XObjects in XWiki.XWikiPreferences. The rationale is that XWiki.XWikiPreferences document should never be upgraded, and that we still be able to upgrade individual configuration XClasses since upgrading XClasses properly does not break existing XObjects.
Interesting proposal I have thought the same, this will break a lot of core code though. Also I'm not sure if save access on XWikiPreferences should be required to add a configurable application. Finally, I think making the users (admins) save out anything per upgrade is an ugly hack, when I upgrade software on my RedHat box I don't have to save the configuration out, the very notion is absurd.
There is just a remaining issue, maybe why you choose not to store your configuration outside of XWikiPreferences, which is to have a default configuration when no instance are available in XWiki.XWikiPreferences (or WebPreferences). I suggest that a default XObject be stored in the XClass document, and that the wiki provide 2 standard mechanisms, one that allow creating a new XObject from that default one in the API and the UI (general mechanism for any XClasses), and another that allow interrogating the preferences with a fallback to that default XObject when no XObject has been found in XWiki.XWikiPreferences. WDYT ?
I have a hard time understanding this part but I assert that upgrading must be mad automatic.
#3
This would be solved with my proposal in #2
#4
I mostly agree with you on that point. It should also be noted that with the Colibri skin, when a fields from the preferences is missing from the admin interface, it is very difficult to switch to the object editor, something really easy in Toucan. This had to be solved as well, since Admins should be able to pass over the admin UI when required, and typing URL is not funny.
#offTopic (I know it's bad)
I was really impressed by your work but... If you mix of the Registration page and the RegistrationConfig, you covers most part of the features we have develop on our side (in our Groovy API) to support any kind of forms that create new objects and documents. You even goes one steps further in some domains, and I really wonder if all these stuffs could be improved to be more general than your initial purposes. However, I am little bit puzzled by some overlap you have introduced as well. Native XObject as already an existing labelling, validation and error message mechanism based on informations store in the XClass. Not perfect solution, it should be improved to be usable.
My problem was that I am not creating an XObject. The user fills out a form, they pass it to the registration page, the registration page decides if it's good and passes it on to the core which creates the object and by then it's out of my hands. The other problem is I had to synchronize behavior of my validation with LiveValidation Javascript library. If we are to consider changing object validation, we must ask ourselves is an XClass the right place to put validation? java.lang.Class has no type of validation and I like to imagine we are making XClass an analog of java Class. I also tend to think if it can be done with script (without PR) then it should be done with script to keep the amount of dangerous code minimal (in the long term I think we need to think about java code existing in the database alongside script and without having PR.)
Why do you have choose to externalize that information (improved also, but made more technically expressed using JSON) for the registration form ? I know there is some peculiarities in the registration form, and some fields, like the username and the password are somewhat not real fields, but such situation also append in any application that use forms. So why being so specific, since this is a requirement for any kind of forms. Doesn't your own configuration forms could benefit of a validation mechanism ?
I have thought that the code in the registration page could be made more portable and I have a form field class sitting on my hard disk waiting until I get the time to patch it in to the registration page, then it will be a matter of adding field objects and creating validation constraints rather than changing the registration page content itself.
I really like to see a more integrated and user friendly way to provide these features for any objects, but maybe this as to wait the new model ?
Not sure that your single mail option was better than separate ones, this makes also my answer quite long :\
I feel sorry as well.
Denis _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Caleb, My answers are interspersed below. On Fri, Mar 26, 2010 at 14:01, Caleb James DeLisle <[email protected]
wrote:
Denis Gervalle wrote:
Hi Caleb,
#1
I know you dislike JS, but on the other side, I completely agree with Vincent that having information right at hand in a popup, is better, quicker and easier for most users that having to switch back and forth in a page with documentation. This especially true when you fill-up forms since you should also avoid losing already filled fields. So, your click handler proposal is a nice idea. To only get the part of the documentation you really need, I wonder if the document section mechanism that is used for editing could not be reused here ? I hope it could do the tricks...
I agree that Popups are attacks, but not ToolTips. This should be AJAX based. Even a properly delayed mouseover handler could be nice.
Ahh, mouseover handlers have me reaching for the noscript button instantly. I suppose if it waits ~3 seconds it won't be accidentally fired.
We need to figure out how to display only a section of the help page (regarding the part the user viewed) instead of the entire help page when a user clicks on a help link. I am -1 for tooltips until I can see a way to store the information in a single place.
#2
From the application developer point of view, I see two situations:
a) there is only one global configuration for my application, or one configuration per Spaces
Taken from
http://code.xwiki.org/xwiki/bin/view/Applications/AdministrationApplication#... "configureGlobally (boolean) - Set this true if your application should be configured in the global administration page and false if it should be configured in the administration page for the space which the application resides in."
You are missing a case with that boolean. Opposed to what have been done for the blog application, my habits where to put the application code in its own separate spaces, and application data in an other one. If there is a need in the data space of application code, I usually practice with inclusion. There have been debate on Application design, and AFAIK, this as never been a final conclusion. Separating application code helps exporting data and upgrading application independently. Therefore, configuring the application in the space it reside is not really meaningful to me, what does it means really ? And anyway, we should be able to configure application at the space level for any spaces without having any application code in that space, just think about global application with space customization.
b) there could be multiple configuration for my application, not dependent on Spaces
See: What happens if I add more than one ConfigurableClass object?
http://code.xwiki.org/xwiki/bin/view/Applications/AdministrationApplication#...
This is very nice and should be kept, but have nothing to do with what I am talking about. Case b) is for application that could have several configuration in a single space or do not want to be bound by the space organization of XWiki. These applications would usually require explicit reference to their configuration on usage and I am not sure we should really take care of them here.
For b), configuration should be stored in any documents, and used by reference to it. For a), my feeling is that the configuration object,
that
will have its own custom configuration XClass, like you have done, should be stored in a centralized document, either at the wiki level or the space level. Currently these centralized documents are XWiki.XWikiPreferences and
Do we agree on the idea to centralize configuration object on some central document ? If not, what is the argument and how does fit with my previous remarks ?
WebPreferences. There is a very annoying issue currently with XWiki.XWikiPreferences because both the XClass and the XObject are stored in the same document. This made the upgrade of the XClass really difficult. I propose to change that by stopping any upgrade of this XClass, and deprecating it in favour of specialized XClasses, that will store their XObjects in XWiki.XWikiPreferences. The rationale is that XWiki.XWikiPreferences document should never be upgraded, and that we still be able to upgrade individual configuration XClasses since upgrading XClasses properly does not break existing XObjects.
Interesting proposal I have thought the same, this will break a lot of core code though.
For sure, but this could be done really progressively...
Also I'm not sure if save access on XWikiPreferences should be required to add a configurable application.
This is not require, this is why I propose a solution where an application does not have to store its first default configuration into XWikiPreferences. Adding an application does not means adding to XWikiPreference in my mind, it just means providing one or more custom configuration XClass, and one or more ConfigurableClass describing them, and no more.
Finally, I think making the users (admins) save out anything per upgrade is an ugly hack, when I upgrade software on my RedHat box I don't have to save the configuration out, the very notion is absurd.
Never said that. In my explanation above, the XClasses are not stored in XWikiPreferences, only XObjects are. Upgrading an application should not require any change to XWikiPreferences or anywhere outside the Application space. And default configuration will be there wish is the purpose of my next paragraph.
There is just a
remaining issue, maybe why you choose not to store your configuration outside of XWikiPreferences, which is to have a default configuration when no instance are available in XWiki.XWikiPreferences (or WebPreferences). I suggest that a default XObject be stored in the XClass document, and that the wiki provide 2 standard mechanisms, one that allow creating a new XObject from that default one in the API and the UI (general mechanism for any XClasses), and another that allow interrogating the preferences with a fallback to that default XObject when no XObject has been found in XWiki.XWikiPreferences. WDYT ?
I have a hard time understanding this part but I assert that upgrading must be mad automatic.
Sorry, and I am not sure you have get it. So I will try again taking your registration application as an example. In XWiki.RegistrationConfig, you will both define the XClass for the configuration and a default XObject of that XClass containing a minimal default configuration for making your application works. In the UI, and the API, functions should be available allowing to add a copy of your default XObject located in XWiki.RegistrationConfig, anywhere else when we want to create a new object of that XClass (a general feature, also interesting for any kind of classes). When the Registration application get their configuration, it will ask the API for properties of its RegistrationConfig class. The API will ckeck for an XObject of RegistrationConfig XClass in the XWikiPreferences. If none is found, it will fallback to the default XObject instance store in RegistrationConfig. The API may be design to allow that even if the application does not have read access XWikiPreferences, checking only access on the default object. This could isolate configuration access while allowing global storage. In the Administration Application, when you have to display the configuration of the Registration application based on the ConfigurableClass, you will end up to check if an XObject of the RegistrationConfig XClass exist in XWikiPreferences, and you will create a new one copying the default one in XWiki.RegistrationConfig when needed to reflect the way API respond to the application. Once the admin really change something, you will obviously save the customized configuration in the XWikiPreferences document, not in the XWiki.RegistrationConfig class. You may also provide the Admin with a "reset to factory settings" that will delete the customized XObject in XWikiPreferences. When the Registration application is upgraded, you just have to upgrade the RegistrationConfig document with an upgraded XClass and a default XObject. This will not break the XObject in XWikiPreferences, since XObject support XClass upgrade. In the worse case, release notes may mention that the admin should ensure proper additional configuration on upgrade when new mandatory properties is added. Hope you have better understand my idea now. This could surely be improved further and the modalities adjusted but the general ideas are: 1) separate XClass definition from XObject instances 2) centralize global and space preferences in single documents simplifying backups, and security for admins (here are the special document ;) 3) allows applications access based on their access to their default configuration, making this transparent for the application, global and local preferences override defaults and there is no requirement to put a customized config anywhere. 4) progressively apply this to all the current properties of XWikiPrefences XClass putting them in specialized one If there is still some obscure points, you know where you can reach me ;) As a side note, I am not happy with the configuration XClass being in XWiki.Registration and this is why I have choosen to put it in XWiki.RegistrationConfig. The reason is that before 2.2, the XWiki.Registration page should be overridden to configure registration, and that doing so now, will destroy your XClass definition.
#3
This would be solved with my proposal in #2
#4
I mostly agree with you on that point. It should also be noted that with the Colibri skin, when a fields from the preferences is missing from the admin interface, it is very difficult to switch to the object editor, something really easy in Toucan. This had to be solved as well, since Admins should be able to pass over the admin UI when required, and typing URL is not funny.
#offTopic (I know it's bad)
I was really impressed by your work but... If you mix of the Registration page and the RegistrationConfig, you covers most part of the features we have develop on our side (in our Groovy API) to support any kind of forms that create new objects and documents. You even goes one steps further in some domains, and I really wonder if all these stuffs could be improved to be more general than your initial purposes. However, I am little bit puzzled by some overlap you have introduced as well. Native XObject as already an existing labelling, validation and error message mechanism based on informations store in the XClass. Not perfect solution, it should be improved to be usable.
My problem was that I am not creating an XObject. The user fills out a form, they pass it to the registration page, the registration page decides if it's good and passes it on to the core which creates the object and by then it's out of my hands.
Just do done that on my side, in Groovy, by creating an XObject not store anywhere, and using its validation capability. I know, there is some peculiarities with registration, since some of the fields are not real XClass fields: Password check and wikiname. But these are mostly always required and could deserve something special.
The other problem is I had to synchronize behavior of my validation with LiveValidation Javascript library.
This does not prevent the required information to be stored in XClass.
If we are to consider changing object validation, we must ask ourselves is an XClass the right place to put validation? java.lang.Class has no type of validation and I like to imagine we are making XClass an analog of java Class.
Well I do not consider changing anything. I am just saying that there is a validation mechanism in place in XClass currently, and that what you have done is a completely different implementation that have some interesting features. I do not feel we need several ways to do the same thing, and that we should consider merging them in a single, more generic solution.
I also tend to think if it can be done with script (without PR) then it should be done with script to keep the amount of dangerous code minimal (in the long term I think we need to think about java code existing in the database alongside script and without having PR.)
The validation implementation in XClass is callable from script without PR. It is available since 1.5M2 in standard and usable since 1.3. There is a tutorial here: http://platform.xwiki.org/xwiki/bin/view/DevGuide/Creating%20a%20form%20with...
Why do you have choose to externalize that information (improved also, but made more technically expressed using JSON) for the registration form ? I know there is some peculiarities in the registration form, and some fields, like the username and the password are somewhat not real fields, but such situation also append in any application that use forms. So why being so specific, since this is a requirement for any kind of forms. Doesn't your own configuration forms could benefit of a validation mechanism ?
I have thought that the code in the registration page could be made more portable and I have a form field class sitting on my hard disk waiting until I get the time to patch it in to the registration page, then it will be a matter of adding field objects and creating validation constraints rather than changing the registration page content itself.
I really like to see a more integrated and user friendly way to provide these features for any objects, but maybe this as to wait the new model ?
Not sure that your single mail option was better than separate ones, this makes also my answer quite long :\
I feel sorry as well.
Denis _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
Denis Gervalle wrote:
Hi Caleb,
My answers are interspersed below.
On Fri, Mar 26, 2010 at 14:01, Caleb James DeLisle <[email protected]
wrote:
Denis Gervalle wrote:
Hi Caleb,
#1
I know you dislike JS, but on the other side, I completely agree with Vincent that having information right at hand in a popup, is better, quicker and easier for most users that having to switch back and forth in a page with documentation. This especially true when you fill-up forms since you should also avoid losing already filled fields. So, your click handler proposal is a nice idea. To only get the part of the documentation you really need, I wonder if the document section mechanism that is used for editing could not be reused here ? I hope it could do the tricks...
I agree that Popups are attacks, but not ToolTips. This should be AJAX based. Even a properly delayed mouseover handler could be nice. Ahh, mouseover handlers have me reaching for the noscript button instantly. I suppose if it waits ~3 seconds it won't be accidentally fired.
We need to figure out how to display only a section of the help page (regarding the part the user viewed) instead of the entire help page when a user clicks on a help link. I am -1 for tooltips until I can see a way to store the information in a single place.
#2
From the application developer point of view, I see two situations:
a) there is only one global configuration for my application, or one configuration per Spaces Taken from
http://code.xwiki.org/xwiki/bin/view/Applications/AdministrationApplication#... "configureGlobally (boolean) - Set this true if your application should be configured in the global administration page and false if it should be configured in the administration page for the space which the application resides in."
You are missing a case with that boolean. Opposed to what have been done for the blog application, my habits where to put the application code in its own separate spaces, and application data in an other one. If there is a need in the data space of application code, I usually practice with inclusion. There have been debate on Application design, and AFAIK, this as never been a final conclusion. Separating application code helps exporting data and upgrading application independently. Therefore, configuring the application in the space it reside is not really meaningful to me, what does it means really ? The application can be configured in any space you like, the only requirement is that the configuration itself reside in the space where the configuration will be configured. XWiki.RegistrationConfig could be moved to Main.RegistrationConfig and could be set to configure locally.
If we were to allow a configuration to reside on one space and be configured in another then what happens if a nonexistent space is specified? What happens if a space is specified which is later deleted?
And anyway, we should be able to configure application at the space level for any spaces without having any application code in that space, just think about global application with space customization. You could have your application programmatically add a configuration document to each space. Supposing we were to allow one configurable object to manage configuration for many spaces, would you have a custom configuration object per space? How would you map a given space to a configuration object? What happens if a space is deleted? Or if a new one is created?
b) there could be multiple configuration for my application, not dependent on Spaces See: What happens if I add more than one ConfigurableClass object?
http://code.xwiki.org/xwiki/bin/view/Applications/AdministrationApplication#...
This is very nice and should be kept, but have nothing to do with what I am talking about. Case b) is for application that could have several configuration in a single space or do not want to be bound by the space organization of XWiki.
It is bound to the space organization because it is displayed in WebPreferences.
These applications would usually require explicit reference to their configuration on usage and I am not sure we should really take care of them here.
For b), configuration should be stored in any documents, and used by reference to it. For a), my feeling is that the configuration object, that will have its own custom configuration XClass, like you have done, should be stored in a centralized document, either at the wiki level or the space level. Currently these centralized documents are XWiki.XWikiPreferences and
Do we agree on the idea to centralize configuration object on some central document ? If not, what is the argument and how does fit with my previous remarks ? If you can show me how an application packaged as an XAR can be imported and bring it's configuration into this centralized object and how it will be removed when the application is deleted then I will agree.
WebPreferences. There is a very annoying issue currently with XWiki.XWikiPreferences because both the XClass and the XObject are stored in the same document. This made the upgrade of the XClass really difficult. I propose to change that by stopping any upgrade of this XClass, and deprecating it in favour of specialized XClasses, that will store their XObjects in XWiki.XWikiPreferences. The rationale is that XWiki.XWikiPreferences document should never be upgraded, and that we still be able to upgrade individual configuration XClasses since upgrading XClasses properly does not break existing XObjects. Interesting proposal I have thought the same, this will break a lot of core code though.
For sure, but this could be done really progressively...
Also I'm not sure if save access on XWikiPreferences should be required to add a configurable application.
This is not require, this is why I propose a solution where an application does not have to store its first default configuration into XWikiPreferences. Adding an application does not means adding to XWikiPreference in my mind, it just means providing one or more custom configuration XClass, and one or more ConfigurableClass describing them, and no more.
Finally, I think making the users (admins) save out anything per upgrade is an ugly hack, when I upgrade software on my RedHat box I don't have to save the configuration out, the very notion is absurd.
Never said that. In my explanation above, the XClasses are not stored in XWikiPreferences, only XObjects are. Upgrading an application should not require any change to XWikiPreferences or anywhere outside the Application space. And default configuration will be there wish is the purpose of my next paragraph.
There is just a
remaining issue, maybe why you choose not to store your configuration outside of XWikiPreferences, which is to have a default configuration when no instance are available in XWiki.XWikiPreferences (or WebPreferences). I suggest that a default XObject be stored in the XClass document, and that the wiki provide 2 standard mechanisms, one that allow creating a new XObject from that default one in the API and the UI (general mechanism for any XClasses), and another that allow interrogating the preferences with a fallback to that default XObject when no XObject has been found in XWiki.XWikiPreferences. WDYT ? I have a hard time understanding this part but I assert that upgrading must be mad automatic.
Sorry, and I am not sure you have get it. So I will try again taking your registration application as an example.
In XWiki.RegistrationConfig, you will both define the XClass for the configuration and a default XObject of that XClass containing a minimal default configuration for making your application works. In the UI, and the API, functions should be available allowing to add a copy of your default XObject located in XWiki.RegistrationConfig, anywhere else when we want to create a new object of that XClass (a general feature, also interesting for any kind of classes).
This sounds like a proposal, maybe you could send an email detailing the API functions and UI changes?
When the Registration application get their configuration, it will ask the API for properties of its RegistrationConfig class. The API will ckeck for an XObject of RegistrationConfig XClass in the XWikiPreferences. If none is found, it will fallback to the default XObject instance store in RegistrationConfig. The API may be design to allow that even if the application does not have read access XWikiPreferences, checking only access on the default object. This could isolate configuration access while allowing global storage.
In the Administration Application, when you have to display the configuration of the Registration application based on the ConfigurableClass, you will end up to check if an XObject of the RegistrationConfig XClass exist in XWikiPreferences, and you will create a new one copying the default one in XWiki.RegistrationConfig when needed to reflect the way API respond to the application. Once the admin really change something, you will obviously save the customized configuration in the XWikiPreferences document, not in the XWiki.RegistrationConfig class.
Note: RegistrationConfig is not an XClass, it is a document containing an XObject of the Registration XClass and one of the ConfigurableClass XClass.
You may also provide the Admin with a "reset to factory settings" that will delete the customized XObject in XWikiPreferences. Lets suppose that the admin wanted to delete Registration and RegistrationConfig what happens to XWikiPreferences Registration XObject?
When the Registration application is upgraded, you just have to upgrade the RegistrationConfig document with an upgraded XClass and a default XObject. This will not break the XObject in XWikiPreferences, since XObject support XClass upgrade. In the worse case, release notes may mention that the admin should ensure proper additional configuration on upgrade when new mandatory properties is added.
Hope you have better understand my idea now. This could surely be improved further and the modalities adjusted but the general ideas are: 1) separate XClass definition from XObject instances 2) centralize global and space preferences in single documents simplifying backups, and security for admins (here are the special document ;)
What happens when a space is deleted/created?
3) allows applications access based on their access to their default configuration, making this transparent for the application, global and local preferences override defaults and there is no requirement to put a customized config anywhere. 4) progressively apply this to all the current properties of XWikiPrefences XClass putting them in specialized one I think xpn.xwiki.XWiki.getXWikiPreference will need to be changed. Some properties needed by the core and allowing them to be pulled from a class other than XWikiPreferences XClass will introduce numerous potential security issues (changing preferences without permission.) Anyway this looks like it should be a separate proposal, do you agree?
If there is still some obscure points, you know where you can reach me ;)
As a side note, I am not happy with the configuration XClass being in XWiki.Registration and this is why I have choosen to put it in XWiki.RegistrationConfig.
Unless the object is moved as well won't we be mixing the class and object in the same document again?
The reason is that before 2.2, the XWiki.Registration page should be overridden to configure registration, and that doing so now, will destroy your XClass definition. But if Registration is overridden what does it matter if there is no class def? The application is not being used. Am I wrong?
#3
This would be solved with my proposal in #2
#4
I mostly agree with you on that point. It should also be noted that with the Colibri skin, when a fields from the preferences is missing from the admin interface, it is very difficult to switch to the object editor, something really easy in Toucan. This had to be solved as well, since Admins should be able to pass over the admin UI when required, and typing URL is not funny.
#offTopic (I know it's bad)
I was really impressed by your work but... If you mix of the Registration page and the RegistrationConfig, you covers most part of the features we have develop on our side (in our Groovy API) to support any kind of forms that create new objects and documents. You even goes one steps further in some domains, and I really wonder if all these stuffs could be improved to be more general than your initial purposes. However, I am little bit puzzled by some overlap you have introduced as well. Native XObject as already an existing labelling, validation and error message mechanism based on informations store in the XClass. Not perfect solution, it should be improved to be usable. My problem was that I am not creating an XObject. The user fills out a form, they pass it to the registration page, the registration page decides if it's good and passes it on to the core which creates the object and by then it's out of my hands.
Just do done that on my side, in Groovy, by creating an XObject not store anywhere, and using its validation capability. I know, there is some peculiarities with registration, since some of the fields are not real XClass fields: Password check and wikiname. But these are mostly always required and could deserve something special.
The other problem is I had to synchronize behavior of my validation with LiveValidation Javascript library.
This does not prevent the required information to be stored in XClass.
If we are to consider changing object validation, we must ask ourselves is an XClass the right place to put validation? java.lang.Class has no type of validation and I like to imagine we are making XClass an analog of java Class.
Well I do not consider changing anything. I am just saying that there is a validation mechanism in place in XClass currently, and that what you have done is a completely different implementation that have some interesting features. I do not feel we need several ways to do the same thing, and that we should consider merging them in a single, more generic solution.
I also tend to think if it can be done with script (without PR) then it should be done with script to keep the amount of dangerous code minimal (in the long term I think we need to think about java code existing in the database alongside script and without having PR.)
The validation implementation in XClass is callable from script without PR. It is available since 1.5M2 in standard and usable since 1.3. There is a tutorial here: http://platform.xwiki.org/xwiki/bin/view/DevGuide/Creating%20a%20form%20with...
I see no information about making the validation messages multilingual. Is this possible? You are suggesting we create another user class and make the registration page break if it does not exist? Can you point to a place where this is used in XE or platform so I can see the code in action? I am having trouble understanding your English and I think this problem is compounded by the fact that we are speaking over email discussing many different topics at once. I think it would be easier to discuss these issues separately via chat. Caleb
Why do you have choose to externalize that information (improved also, but made more technically expressed using JSON) for the registration form ? I know there is some peculiarities in the registration form, and some fields, like the username and the password are somewhat not real fields, but such situation also append in any application that use forms. So why being so specific, since this is a requirement for any kind of forms. Doesn't your own configuration forms could benefit of a validation mechanism ? I have thought that the code in the registration page could be made more portable and I have a form field class sitting on my hard disk waiting until I get the time to patch it in to the registration page, then it will be a matter of adding field objects and creating validation constraints rather than changing the registration page content itself.
I really like to see a more integrated and user friendly way to provide these features for any objects, but maybe this as to wait the new model ?
Not sure that your single mail option was better than separate ones, this makes also my answer quite long :\
I feel sorry as well.
Denis _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Changes I plan to make based on feedback: 1. Heading ("Configure XWiki.Registration") will not be shown unless there are multiple save buttons. If heading parameter is set for first configurable object, it will override default heading. 2. Javascript snippet will hide multiple buttons and add a single button to submit all forms at once. 3. Javascript snippet will hook information links to a popup. They will popup if javascript is enabled and act as they do currently if it is disabled. WDYT? Caleb
Here is what I have at the moment. Caleb James DeLisle wrote:
Changes I plan to make based on feedback:
1. Heading ("Configure XWiki.Registration") will not be shown unless there are multiple save buttons. If heading parameter is set for first configurable object, it will override default heading. No headings are shown unless there are going to be multiple save buttons or if a section cannot be displayed and an error message must be shown instead. Javascript code removes headings when it merges buttons (unless there is an error message.)
2. Javascript snippet will hide multiple buttons and add a single button to submit all forms at once.
Javascript hides buttons and places a single button at the bottom to save everything.
3. Javascript snippet will hook information links to a popup. They will popup if javascript is enabled and act as they do currently if it is disabled.
Couldn't find a way to display a page in colibri skin which respects window width so a popup cannot be used without having a special page or writing a new stylesheet. I would like to table this idea for now since I see it as more of a priority to document the still undocumented config parameters before perfecting the documentation user interface. WDYT? Caleb
WDYT?
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (2)
-
Caleb James DeLisle -
Denis Gervalle