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