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

On Mon, Jan 18, 2010 at 09:25, Caleb James DeLisle <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne