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