26 Mar
2010
26 Mar
'10
1:01 p.m.
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
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."
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
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs