28 Mar
2010
28 Mar
'10
7:38 a.m.
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