25 Mar
2010
25 Mar
'10
10:10 p.m.
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=ob…
In fact admin action is not even necessary to use the Administration Application
see: https://localhost:8443/xwikiTrunk/bin/inline/XWiki/XWikiPreferences?xpage=a…
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
26 Mar
26 Mar
10:29 a.m.
New subject: [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
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
2:01 p.m.
New subject: [xwiki-devs] [Discussion] What direction to take the administration application.
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
28 Mar
28 Mar
12:12 a.m.
New subject: [xwiki-devs] [Discussion] What direction to take the administration application.
Hi Caleb,
My answers are interspersed below.
On Fri, Mar 26, 2010 at 14:01, Caleb James DeLisle <calebdelisle(a)lavabit.com
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.
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 ?
For sure, but this could be done really progressively...
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.
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
wrote:
Denis Gervalle wrote:
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.
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.
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
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.
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.
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%20wit…
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:38 a.m.
New subject: [xwiki-devs] [Discussion] What direction to take the administration application.
Denis Gervalle wrote:
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.
For sure, but this could be done really progressively...
This sounds like a proposal, maybe you could
send an email detailing the API
functions and UI changes?
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.
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
Hi Caleb,
My answers are interspersed below.
On Fri, Mar 26, 2010 at 14:01, Caleb James DeLisle <calebdelisle(a)lavabit.com
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?
wrote:
Denis Gervalle wrote:
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 ? 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 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…
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.
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.
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.
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
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). 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.
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.
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%20wit…
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
29 Mar
29 Mar
8:55 p.m.
New subject: [xwiki-devs] [Discussion] What direction to take the administration application.
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
5 Apr
5 Apr
11:01 a.m.
New subject: [xwiki-devs] [Discussion] What direction to take the administration application.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5270
days inactive
5281
days old
6 comments
2 participants
participants (2)
-
Caleb James DeLisle -
Denis Gervalle