18 Jan
2010
18 Jan
'10
9:25 a.m.
Hello all,
I am working on refactoring the registration page. I have a mockup which uses the view
action so that the register action is not needed, I'm not sure if it makes more sense
to
remain a template or be moved to an application, any thoughts on this?
There are a few apis which would make this job a lot easier and cleaner.
I would like to provide Velocity access to ConfigurationSource. There would be a
configuration parameter which a list of configuration parameters that Velocity
is allowed to read. I think it makes the most sense to add a VelocityContextInitializer
to the default Configuration implementation which injects a ConfigurationSource wrapper.
Perhaps name it $configurationsource
Currently (in my mockup) there is no way to tell the guest who is registering that their
chosen user name is taken or is invalid if the captcha is wrong, this is because the
username
is checked by $xwiki.createUser after the captcha is verified. If we add the following
two
apis then all of the checking can be done on the Velocity side.
$xwiki.isUsernameAvailable(String name)
This will check if the name is the name of the superuser then check if a document
exists by that name. Should I be using an EntityReference? I lean toward string because
that is what the user types in.
$util.compilePattern(String regex)
Returns a Pattern or null if regex is invalid because Perl5Util methods all throw
exceptions which Velocity can't catch.
I appreciate any thoughts/advice you have to offer.
Thanks,
Caleb
18 Jan
18 Jan
9:32 a.m.
New subject: [xwiki-devs] [Proposal] Refactoring registration page and add some apis
Hi Caleb,
On Jan 18, 2010, at 9:25 AM, Caleb James DeLisle wrote:
Hello all,
I am working on refactoring the registration page. I have a mockup which uses the view
action so that the register action is not needed, I'm not sure if it makes more sense
to
remain a template or be moved to an application, any thoughts on this?
Registration is definitely a template IMO. The reason is that XE should work even with an
empty database (ie no default XAR imported). So you must be able to register a new user
with an empty database.
There are a few apis which would make this job a lot
easier and cleaner.
I would like to provide Velocity access to ConfigurationSource. There would be a
configuration parameter which a list of configuration parameters that Velocity
is allowed to read. I think it makes the most sense to add a VelocityContextInitializer
to the default Configuration implementation which injects a ConfigurationSource wrapper.
Perhaps name it $configurationsource
-1 to that in general. So far, we've resisted adding it. The reason is that no code
should access the configuration source exception for configuration components. Each module
must have one or more configuration component responsible to deliver typed configuration
data. Those components can be made available to Velocity.
Now I haven't understood why you'd need to have access to Configuration Source
directly from Velocity. Maybe you have a valid use case I haven't thought about?
Currently (in my mockup) there is no way to tell the
guest who is registering that their
chosen user name is taken or is invalid if the captcha is wrong, this is because the
username
is checked by $xwiki.createUser after the captcha is verified. If we add the following
two
apis then all of the checking can be done on the Velocity side.
$xwiki.isUsernameAvailable(String name)
Note that ideally this would go int he authorization module and be available as a service
through the upcoming velocity bridge (we really need to get going on that bridge - I can
work on it as soon as I finish the reference refactoring). Since the bridge isn't done
yet and since the authorization code is not yet a component-based module I guess fattening
the XWiki class is an option ;)
This will check if the name is the name of the
superuser then check if a document
exists by that name. Should I be using an EntityReference? I lean toward string because
that is what the user types in.
We haven't decided yet if we use String or Reference in velocity code, at least not
officially. I think Thomas and I are leaning towards keeping String but transforming them
in References automatically in the upcoming velocity bridge, using a current resolver.
I'll write a mail today on this to ensure we all agree.
$util.compilePattern(String regex)
Returns a Pattern or null if regex is invalid because Perl5Util methods all throw
exceptions which Velocity can't catch.
I've started a Velocity RegexTool already (it's in the xwiki-velocity module if
you want to check it). Maybe you could use it? BTW $util is mostly deprecated and
shouldn't be used as much as possible.
Thanks
-Vincent
1:44 p.m.
On 01/18/2010 09:25 AM, Caleb James DeLisle wrote:
Hello all,
I am working on refactoring the registration page. I have a mockup which uses the view
action so that the register action is not needed, I'm not sure if it makes more sense
to
remain a template or be moved to an application, any thoughts on this?
There are a few apis which would make this job a lot easier and cleaner.
I would like to provide Velocity access to ConfigurationSource. There would be a
configuration parameter which a list of configuration parameters that Velocity
is allowed to read. I think it makes the most sense to add a VelocityContextInitializer
to the default Configuration implementation which injects a ConfigurationSource wrapper.
Perhaps name it $configurationsource
Currently (in my mockup) there is no way to tell the guest who is registering that their
chosen user name is taken or is invalid if the captcha is wrong, this is because the
username
is checked by $xwiki.createUser after the captcha is verified. If we add the following
two
apis then all of the checking can be done on the Velocity side.
$xwiki.isUsernameAvailable(String name)
This will check if the name is the name of the superuser then check if a document
exists by that name. Should I be using an EntityReference? I lean toward string because
that is what the user types in.
This can be done as a velocity macro using $xwiki.exists and
$xwiki.getDocument(...).getObject('XWiki.XWikiUsers') for the moment.
$util.compilePattern(String regex)
Returns a Pattern or null if regex is invalid because Perl5Util methods all throw
exceptions which Velocity can't catch.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
19 Jan
19 Jan
11:50 a.m.
New subject: [xwiki-devs] [Proposal] Refactoring registration page and add some apis
On Mon, Jan 18, 2010 at 09:25, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
Hello all,
I am working on refactoring the registration page. I have a mockup which uses the view
action so that the register action is not needed, I'm not sure if it makes more sense
to
remain a template or be moved to an application, any thoughts on this?
There are a few apis which would make this job a lot easier and cleaner.
I would like to provide Velocity access to ConfigurationSource. There would be a
configuration parameter which a list of configuration parameters that Velocity
is allowed to read. I think it makes the most sense to add a VelocityContextInitializer
to the default Configuration implementation which injects a ConfigurationSource wrapper.
Perhaps name it $configurationsource
No one is supposed to directly use ConfigurationSource and instead
create MyCompnentConfiguration component with proper getters to cover
your needs that will take care of communicating with
ConfigurationSource component.
Currently (in my mockup) there is no way to tell the guest who is registering that their
chosen user name is taken or is invalid if the captcha is wrong, this is because the
username
is checked by $xwiki.createUser after the captcha is verified. If we add the following
two
apis then all of the checking can be done on the Velocity side.
$xwiki.isUsernameAvailable(String name)
This will check if the name is the name of the superuser then check if a document
exists by that name. Should I be using an EntityReference? I lean toward string because
that is what the user types in.
Note that this kind of api is supposed to go in rightsmanager plugin
and not in $xwiki
$util.compilePattern(String regex)
Returns a Pattern or null if regex is invalid because Perl5Util methods all throw
exceptions which Velocity can't catch.
I appreciate any thoughts/advice you have to offer.
Thanks,
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
5407
days inactive
5408
days old
3 comments
4 participants
participants (4)
-
Caleb James DeLisle -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol