Re: [xwiki-devs] [Discussion] What direction to take the administration application.

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 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