making PUR module more flexible

[Bert Leunis]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hello Magnolians,

 

I see that you are starting work on the PUR module. On this moment I work with PUR on one of our projects. The client will use PUR in a slightly different way than the intended scenario. I have two ideas that, when applied, can make the module more flexible. Thus the code will serve more different scenarios, with little effort.  I think this can be achieved very easily and will lead to less programming work when adapting/applying PUR, but instead configuration.

 

1.       Add a new method to info.magnolia.module.publicuserregistration.strategy.Mail: public void validateRegistration(User user, Map<String, Object> templateValues). This way the process using that class can add their templateValues themselves.

 

2.       When you need an extra strategy, you have to adapt the PublicUserRegistrationConfig class. Instead of having a fixed set of 3 strategies, a list of strategies could be present in the config. Probably a module class has to be created that loads the strategies in a Map<String, Strategy>. From the module instance the strategy can then be retrieved by name. (I created a sendPasswordStrategy).

 

Some other issue I have is with the tree Public Users. All folders appear twice, in two shades. I didn’t change the config of that. What’s wrong here?

 

 

 

If you’re interested I may apply a small patch for these changes.

 

Many regards, Bert

 

---

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[Philipp Bärfuss]

Best is to create jira tickets for each item in the PUR project, they will most likely be applied immediately. The nasty duplicated folder issue is already solved.

Thanks

- Philipp Bärfuss

On 06.10.2009, at 16:05, Bert Leunis wrote:

Hello Magnolians,

 

I see that you are starting work on the PUR module. On this moment I work with PUR on one of our projects. The client will use PUR in a slightly different way than the intended scenario. I have two ideas that, when applied, can make the module more flexible. Thus the code will serve more different scenarios, with little effort.  I think this can be achieved very easily and will lead to less programming work when adapting/applying PUR, but instead configuration.

 

1.       Add a new method to info.magnolia.module.publicuserregistration.strategy.Mail: public void validateRegistration(User user, Map<String, Object> templateValues). This way the process using that class can add their templateValues themselves.

 

2.       When you need an extra strategy, you have to adapt the PublicUserRegistrationConfig class. Instead of having a fixed set of 3 strategies, a list of strategies could be present in the config. Probably a module class has to be created that loads the strategies in a Map<String, Strategy>. From the module instance the strategy can then be retrieved by name. (I created a sendPasswordStrategy).

 

Some other issue I have is with the tree Public Users. All folders appear twice, in two shades. I didn’t change the config of that. What’s wrong here?

 

<image001.png>

 

 

If you’re interested I may apply a small patch for these changes.

 

Many regards, Bert

 

---

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

---

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[gregoryjoseph]

Hi Bert,

Before you open the jira issues, maybe a short discussion:

On Oct 6, 2009, at 4:05 PM, Bert Leunis wrote:

> Hello Magnolians,
>
> I see that you are starting work on the PUR module. On this moment I  
> work with PUR on one of our projects. The client will use PUR in a  
> slightly different way than the intended scenario. I have two ideas  
> that, when applied, can make the module more flexible. Thus the code  
> will serve more different scenarios, with little effort.  I think  
> this can be achieved very easily and will lead to less programming  
> work when adapting/applying PUR, but instead configuration.
>
> 1.       Add a new method to  
> info.magnolia.module.publicuserregistration.strategy.Mail: public  
> void validateRegistration(User user, Map<String, Object>  
> templateValues). This way the process using that class can add their  
> templateValues themselves.

It's the UserRegistrar which calls this method; if you need more  
parameters in your mail templates, you probably want to subclass  
i.m.m.pur.strategy.Mail anyway? Where do these parameters come from?  
Why would you allow arbitrary parameters to be passed there, what's  
the actual usecase? (as a side note, if this ends up being really  
necessary, i'd rather change the method than add one)

>
> 2.       When you need an extra strategy, you have to adapt the  
> PublicUserRegistrationConfig class.

Uh? How so? As far as I know, you only need to configure it in /
modules/pur/config/registrationStrategy or ../passwordRetrievalStrategy

> Instead of having a fixed set of 3 strategies, a list of strategies  
> could be present in the config.

Unless i missed something, it's not a fixed set and was indeed meant  
so that one can have their custom strategies

> Probably a module class has to be created that loads the strategies  
> in a Map<String, Strategy>. From the module instance the strategy  
> can then be retrieved by name. (I created a sendPasswordStrategy).

I'm not sure what you mean, but then again, see above comments.

>  Some other issue I have is with the tree Public Users. All folders  
> appear twice, in two shades. I didn’t change the config of that.  
> What’s wrong here?

Like Philipp said, this is something we know about and should be fixed  
by now.

> If you’re interested I may apply a small patch for these changes.


Still interesting, of course :)

Cheers,

-g
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[Bert Leunis]

Hi Grégory,

I already created the jira's as Philip suggested. Still some remarks from me here.

> -----Original Message-----
> From: dev-list-owner@... [mailto:dev-list-owner@magnolia-
> cms.com] On Behalf Of Grégory Joseph
> Sent: donderdag 8 oktober 2009 13:54
> To: Magnolia Dev-List
> Subject: Re: [magnolia-dev] making PUR module more flexible
>
>
> Hi Bert,
>
> Before you open the jira issues, maybe a short discussion:
>
> On Oct 6, 2009, at 4:05 PM, Bert Leunis wrote:
>
> > Hello Magnolians,
> >
> > I see that you are starting work on the PUR module. On this moment I
> > work with PUR on one of our projects. The client will use PUR in a
> > slightly different way than the intended scenario. I have two ideas
> > that, when applied, can make the module more flexible. Thus the code
> > will serve more different scenarios, with little effort.  I think
> > this can be achieved very easily and will lead to less programming
> > work when adapting/applying PUR, but instead configuration.
> >
> > 1.       Add a new method to
> > info.magnolia.module.publicuserregistration.strategy.Mail: public
> > void validateRegistration(User user, Map<String, Object>
> > templateValues). This way the process using that class can add their
> > templateValues themselves.
>
> It's the UserRegistrar which calls this method; if you need more
> parameters in your mail templates, you probably want to subclass
> i.m.m.pur.strategy.Mail anyway? Where do these parameters come from?
> Why would you allow arbitrary parameters to be passed there, what's
> the actual usecase? (as a side note, if this ends up being really
> necessary, i'd rather change the method than add one)

You can have extra parameters in your mail template, e.g. ${generatedPassword}. The EnableByUUID class will send the user a mail with that password, so that class adds all necessary params to the Map<String, Object>. No need to create your own strategy, all fields in Mail are oke, all I want is to fill the context with my own specific values.

>
> >
> > 2.       When you need an extra strategy, you have to adapt the
> > PublicUserRegistrationConfig class.
>
> Uh? How so? As far as I know, you only need to configure it in /
> modules/pur/config/registrationStrategy or ../passwordRetrievalStrategy
>
> > Instead of having a fixed set of 3 strategies, a list of strategies
> > could be present in the config.
>
> Unless i missed something, it's not a fixed set and was indeed meant
> so that one can have their custom strategies
>

My point is: I want to ADD another strategy (sendPasswordStrategy). The flow I need for my case here is different than the flow that is now 'dictated' by PUR. As far as I can see, it is a fixed set now. The class PublicUserRegistrationConfig has two strategies-properties. If they are stored in a map, I do not have to write any code, just add some config.


> > Probably a module class has to be created that loads the strategies
> > in a Map<String, Strategy>. From the module instance the strategy
> > can then be retrieved by name. (I created a sendPasswordStrategy).
>
> I'm not sure what you mean, but then again, see above comments.

I don't think the content2bean utils will convert a list of strategies in a Map<String, Strategy> automatically. That can be done in the module class (like it is done in  the DataModule).

>
> >  Some other issue I have is with the tree Public Users. All folders
> > appear twice, in two shades. I didn't change the config of that.
> > What's wrong here?
>
> Like Philipp said, this is something we know about and should be fixed
> by now.
>
> > If you're interested I may apply a small patch for these changes.
>
>
> Still interesting, of course :)
>
> Cheers,
>
> -g
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> ----------------------------------------------------------------

Hope this make my thoughts a bit more clear.

Best of luck, Bert

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[gregoryjoseph]

On Oct 8, 2009, at 3:05 PM, Bert Leunis wrote:

>>> 1.       Add a new method to
>>> info.magnolia.module.publicuserregistration.strategy.Mail: public
>>> void validateRegistration(User user, Map<String, Object>
>>> templateValues). This way the process using that class can add their
>>> templateValues themselves.
>>
>> It's the UserRegistrar which calls this method; if you need more
>> parameters in your mail templates, you probably want to subclass
>> i.m.m.pur.strategy.Mail anyway? Where do these parameters come from?
>> Why would you allow arbitrary parameters to be passed there, what's
>> the actual usecase? (as a side note, if this ends up being really
>> necessary, i'd rather change the method than add one)
>
> You can have extra parameters in your mail template, e.g. $
> {generatedPassword}. The EnableByUUID class will send the user a  
> mail with that password, so that class adds all necessary params to  
> the Map<String, Object>. No need to create your own strategy, all  
> fields in Mail are oke, all I want is to fill the context with my  
> own specific values.

What is "EnableByUUID" ? An implementation of  
info.magnolia.module.publicuserregistration.RegistrationStrategy ? So  
why can't it add the template values itself  in  
info
.magnolia
.module.publicuserregistration.strategy.Mail#validateRegistration ?  
(if that's what you're doing, of course we could extract a  
addTemplateContextValues() in there)

>>> 2.       When you need an extra strategy, you have to adapt the
>>> PublicUserRegistrationConfig class.
>>
>> Uh? How so? As far as I know, you only need to configure it in /
>> modules/pur/config/registrationStrategy or ../
>> passwordRetrievalStrategy
>>
>>> Instead of having a fixed set of 3 strategies, a list of strategies
>>> could be present in the config.
>>
>> Unless i missed something, it's not a fixed set and was indeed meant
>> so that one can have their custom strategies
>>
>
> My point is: I want to ADD another strategy (sendPasswordStrategy).  
> The flow I need for my case here is different than the flow that is  
> now 'dictated' by PUR. As far as I can see, it is a fixed set now.
> The class PublicUserRegistrationConfig has two strategies-
> properties. If they are stored in a map, I do not have to write any  
> code, just add some config.
>

But these 2 strategies are there for different purposes, and are used  
in different contexts ! They're different interfaces, too! Obviously,  
if you need another functionality (which is...?), you'll need to code  
stuff; which could be in a different module.

>
>>> Probably a module class has to be created that loads the strategies
>>> in a Map<String, Strategy>. From the module instance the strategy
>>> can then be retrieved by name. (I created a sendPasswordStrategy).
>>
>> I'm not sure what you mean, but then again, see above comments.
>
> I don't think the content2bean utils will convert a list of  
> strategies in a Map<String, Strategy> automatically. That can be  
> done in the module class (like it is done in  the DataModule).

Actually, content2bean will convert that, but I don't see the usecase.  
PUR provides two hooks: RegistrationStrategy(validation of a user's  
registration - customize if you want to prevent users to register on a  
sunday), and PasswordRetrievalStrategy (determines how users can  
retrieve their password - or have it changed).

Both interfaces can be swapped in configuration, so you can use your  
own implementations. We currently have a single impl for  
PasswordRetrievalStrategy, and 3 for RegistrationStrategy.

If you use your IDE to search for usages of these interfaces, you'll  
see they're used in totally different contexts. They're not "a"  
strategy. They're just two different pluggable components provided by  
this module. I'm tempted to rename these interfaces to  
PasswordRetrieval and RegistrationValidation if it's so confusing.

hth,

-g


----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[Bert Leunis]

Hi Grégory,

Thanks for the effort. Of course I can adapt and override code as much as I like. My whole point is, that I like to do more configuration instead of coding. And I hoped my suggestions would lead to a little improvement in that direction. But if you don't see the benefit (or I am not clear enough about them) let's just leave it as it is. You should delete the 2 jira's then (MGNLPUR-22 and -23).

Bye, Bert

> -----Original Message-----
> From: dev-list-owner@... [mailto:dev-list-owner@magnolia-
> cms.com] On Behalf Of Grégory Joseph
> Sent: donderdag 8 oktober 2009 18:22
> To: Magnolia Dev-List
> Subject: Re: [magnolia-dev] making PUR module more flexible
>
>
>
> On Oct 8, 2009, at 3:05 PM, Bert Leunis wrote:
> >>> 1.       Add a new method to
> >>> info.magnolia.module.publicuserregistration.strategy.Mail: public
> >>> void validateRegistration(User user, Map<String, Object>
> >>> templateValues). This way the process using that class can add
> their
> >>> templateValues themselves.
> >>
> >> It's the UserRegistrar which calls this method; if you need more
> >> parameters in your mail templates, you probably want to subclass
> >> i.m.m.pur.strategy.Mail anyway? Where do these parameters come from?
> >> Why would you allow arbitrary parameters to be passed there, what's
> >> the actual usecase? (as a side note, if this ends up being really
> >> necessary, i'd rather change the method than add one)
> >
> > You can have extra parameters in your mail template, e.g. $
> > {generatedPassword}. The EnableByUUID class will send the user a
> > mail with that password, so that class adds all necessary params to
> > the Map<String, Object>. No need to create your own strategy, all
> > fields in Mail are oke, all I want is to fill the context with my
> > own specific values.
>
> What is "EnableByUUID" ? An implementation of
> info.magnolia.module.publicuserregistration.RegistrationStrategy ? So
> why can't it add the template values itself  in
> info
> .magnolia
> .module.publicuserregistration.strategy.Mail#validateRegistration ?
> (if that's what you're doing, of course we could extract a
> addTemplateContextValues() in there)
>
>
> >>> 2.       When you need an extra strategy, you have to adapt the
> >>> PublicUserRegistrationConfig class.
> >>
> >> Uh? How so? As far as I know, you only need to configure it in /
> >> modules/pur/config/registrationStrategy or ../
> >> passwordRetrievalStrategy
> >>
> >>> Instead of having a fixed set of 3 strategies, a list of strategies
> >>> could be present in the config.
> >>
> >> Unless i missed something, it's not a fixed set and was indeed meant
> >> so that one can have their custom strategies
> >>
> >
> > My point is: I want to ADD another strategy (sendPasswordStrategy).
> > The flow I need for my case here is different than the flow that is
> > now 'dictated' by PUR. As far as I can see, it is a fixed set now.
> > The class PublicUserRegistrationConfig has two strategies-
> > properties. If they are stored in a map, I do not have to write any
> > code, just add some config.
> >
>
> But these 2 strategies are there for different purposes, and are used
> in different contexts ! They're different interfaces, too! Obviously,
> if you need another functionality (which is...?), you'll need to code
> stuff; which could be in a different module.
>
>
>
> >
> >>> Probably a module class has to be created that loads the strategies
> >>> in a Map<String, Strategy>. From the module instance the strategy
> >>> can then be retrieved by name. (I created a sendPasswordStrategy).
> >>
> >> I'm not sure what you mean, but then again, see above comments.
> >
> > I don't think the content2bean utils will convert a list of
> > strategies in a Map<String, Strategy> automatically. That can be
> > done in the module class (like it is done in  the DataModule).
>
> Actually, content2bean will convert that, but I don't see the usecase.
> PUR provides two hooks: RegistrationStrategy(validation of a user's
> registration - customize if you want to prevent users to register on a
> sunday), and PasswordRetrievalStrategy (determines how users can
> retrieve their password - or have it changed).
>
> Both interfaces can be swapped in configuration, so you can use your
> own implementations. We currently have a single impl for
> PasswordRetrievalStrategy, and 3 for RegistrationStrategy.
>
> If you use your IDE to search for usages of these interfaces, you'll
> see they're used in totally different contexts. They're not "a"
> strategy. They're just two different pluggable components provided by
> this module. I'm tempted to rename these interfaces to
> PasswordRetrieval and RegistrationValidation if it's so confusing.
>
> hth,
>
> -g
>
>
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> ----------------------------------------------------------------

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[gregoryjoseph]

On Oct 9, 2009, at 8:48 AM, Bert Leunis wrote:

>
> Hi Grégory,
>
> Thanks for the effort. Of course I can adapt and override code as  
> much as I like. My whole point is, that I like to do more  
> configuration instead of coding.


That's a valid point, but I still don't see what you're trying to  
achieve, concretely.

> And I hoped my suggestions would lead to a little improvement in  
> that direction. But if you don't see the benefit (or I am not clear  
> enough about them)

Most likely the latter; or I'm too thick;)

> let's just leave it as it is. You should delete the 2 jira's then  
> (MGNLPUR-22 and -23).
>
> Bye, Bert
>
>
>> -----Original Message-----
>> From: dev-list-owner@... [mailto:dev-list-
>> owner@magnolia-
>> cms.com] On Behalf Of Grégory Joseph
>> Sent: donderdag 8 oktober 2009 18:22
>> To: Magnolia Dev-List
>> Subject: Re: [magnolia-dev] making PUR module more flexible
>>
>>
>>
>> On Oct 8, 2009, at 3:05 PM, Bert Leunis wrote:
>>>>> 1.       Add a new method to
>>>>> info.magnolia.module.publicuserregistration.strategy.Mail: public
>>>>> void validateRegistration(User user, Map<String, Object>
>>>>> templateValues). This way the process using that class can add
>> their
>>>>> templateValues themselves.
>>>>
>>>> It's the UserRegistrar which calls this method; if you need more
>>>> parameters in your mail templates, you probably want to subclass
>>>> i.m.m.pur.strategy.Mail anyway? Where do these parameters come  
>>>> from?
>>>> Why would you allow arbitrary parameters to be passed there, what's
>>>> the actual usecase? (as a side note, if this ends up being really
>>>> necessary, i'd rather change the method than add one)
>>>
>>> You can have extra parameters in your mail template, e.g. $
>>> {generatedPassword}. The EnableByUUID class will send the user a
>>> mail with that password, so that class adds all necessary params to
>>> the Map<String, Object>. No need to create your own strategy, all
>>> fields in Mail are oke, all I want is to fill the context with my
>>> own specific values.
>>
>> What is "EnableByUUID" ? An implementation of
>> info.magnolia.module.publicuserregistration.RegistrationStrategy ? So
>> why can't it add the template values itself  in
>> info
>> .magnolia
>> .module.publicuserregistration.strategy.Mail#validateRegistration ?
>> (if that's what you're doing, of course we could extract a
>> addTemplateContextValues() in there)
>>
>>
>>>>> 2.       When you need an extra strategy, you have to adapt the
>>>>> PublicUserRegistrationConfig class.
>>>>
>>>> Uh? How so? As far as I know, you only need to configure it in /
>>>> modules/pur/config/registrationStrategy or ../
>>>> passwordRetrievalStrategy
>>>>
>>>>> Instead of having a fixed set of 3 strategies, a list of  
>>>>> strategies
>>>>> could be present in the config.
>>>>
>>>> Unless i missed something, it's not a fixed set and was indeed  
>>>> meant
>>>> so that one can have their custom strategies
>>>>
>>>
>>> My point is: I want to ADD another strategy (sendPasswordStrategy).
>>> The flow I need for my case here is different than the flow that is
>>> now 'dictated' by PUR. As far as I can see, it is a fixed set now.
>>> The class PublicUserRegistrationConfig has two strategies-
>>> properties. If they are stored in a map, I do not have to write any
>>> code, just add some config.
>>>
>>
>> But these 2 strategies are there for different purposes, and are used
>> in different contexts ! They're different interfaces, too! Obviously,
>> if you need another functionality (which is...?), you'll need to code
>> stuff; which could be in a different module.
>>
>>
>>
>>>
>>>>> Probably a module class has to be created that loads the  
>>>>> strategies
>>>>> in a Map<String, Strategy>. From the module instance the strategy
>>>>> can then be retrieved by name. (I created a sendPasswordStrategy).
>>>>
>>>> I'm not sure what you mean, but then again, see above comments.
>>>
>>> I don't think the content2bean utils will convert a list of
>>> strategies in a Map<String, Strategy> automatically. That can be
>>> done in the module class (like it is done in  the DataModule).
>>
>> Actually, content2bean will convert that, but I don't see the  
>> usecase.
>> PUR provides two hooks: RegistrationStrategy(validation of a user's
>> registration - customize if you want to prevent users to register  
>> on a
>> sunday), and PasswordRetrievalStrategy (determines how users can
>> retrieve their password - or have it changed).
>>
>> Both interfaces can be swapped in configuration, so you can use your
>> own implementations. We currently have a single impl for
>> PasswordRetrievalStrategy, and 3 for RegistrationStrategy.
>>
>> If you use your IDE to search for usages of these interfaces, you'll
>> see they're used in totally different contexts. They're not "a"
>> strategy. They're just two different pluggable components provided by
>> this module. I'm tempted to rename these interfaces to
>> PasswordRetrieval and RegistrationValidation if it's so confusing.
>>
>> hth,
>>
>> -g
>>
>>
>> ----------------------------------------------------------------
>> For list details see
>> http://www.magnolia-cms.com/home/community/mailing-lists.html
>> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
>> ----------------------------------------------------------------
>
>
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> ----------------------------------------------------------------

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[Bert Leunis]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hello,

 

I checked out PUR again, but the tree has still the same duplicated folder issue. Is the code for that error not in SVN yet? I couldn’t find a jira ticket for that. I am clearly missing something L

 

Bye, Bert

 

From: dev-list-owner@... [mailto:dev-list-owner@...] On Behalf Of Philipp Bärfuss
Sent: donderdag 8 oktober 2009 10:05
To: Magnolia Dev-List
Subject: Re: [magnolia-dev] making PUR module more flexible

 

Best is to create jira tickets for each item in the PUR project, they will most likely be applied immediately. The nasty duplicated folder issue is already solved.

 

Thanks

 

- Philipp Bärfuss

 

 

 

 

On 06.10.2009, at 16:05, Bert Leunis wrote:

Hello Magnolians,

 

I see that you are starting work on the PUR module. On this moment I work with PUR on one of our projects. The client will use PUR in a slightly different way than the intended scenario. I have two ideas that, when applied, can make the module more flexible. Thus the code will serve more different scenarios, with little effort.  I think this can be achieved very easily and will lead to less programming work when adapting/applying PUR, but instead configuration.

 

1.       Add a new method to info.magnolia.module.publicuserregistration.strategy.Mail: public void validateRegistration(User user, Map<String, Object> templateValues). This way the process using that class can add their templateValues themselves.

 

2.       When you need an extra strategy, you have to adapt the PublicUserRegistrationConfig class. Instead of having a fixed set of 3 strategies, a list of strategies could be present in the config. Probably a module class has to be created that loads the strategies in a Map<String, Strategy>. From the module instance the strategy can then be retrieved by name. (I created a sendPasswordStrategy).

 

Some other issue I have is with the tree Public Users. All folders appear twice, in two shades. I didn’t change the config of that. What’s wrong here?

 

<image001.png>

 

 

If you’re interested I may apply a small patch for these changes.

 

Many regards, Bert

 

 

---

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

 

 

---

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

---

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[Zdenek Skodik]

Hi Bert,

afaik it's not fixed yet.
I expect that this bug occurs due the fact
that the initialization method of AbstractProfilePage
is called twice.
Otherwise it have to be fixed for the next release,
I'll get in touch with Gregory about that.

-  
Best regards,

Zdenek Skodik
Magnolia International Ltd.

Magnolia®  - Simple Open-Source Content Management


On Pá, 2009-10-16 at 11:40 +0200, Bert Leunis wrote:

> Hello,
>
>  
>
> I checked out PUR again, but the tree has still the same duplicated
> folder issue. Is the code for that error not in SVN yet? I couldn’t
> find a jira ticket for that. I am clearly missing something L
>
>  
>
> Bye, Bert
>
>
>  
>
> From:dev-list-owner@...
> [mailto:dev-list-owner@...] On Behalf Of Philipp Bärfuss
> Sent: donderdag 8 oktober 2009 10:05
> To: Magnolia Dev-List
> Subject: Re: [magnolia-dev] making PUR module more flexible
>
>
>  
>
> Best is to create jira tickets for each item in the PUR project, they
> will most likely be applied immediately. The nasty duplicated folder
> issue is already solved.
>
>  
>
>
> Thanks
>
>
>  
>
> - Philipp Bärfuss
>
>
>  
>
>
>  
>
>
>  
>
>
>  
>
> On 06.10.2009, at 16:05, Bert Leunis wrote:
>
>
>
>
> Hello Magnolians,
>
>
>  
>
>
> I see that you are starting work on the PUR module. On this moment I
> work with PUR on one of our projects. The client will use PUR in a
> slightly different way than the intended scenario. I have two ideas
> that, when applied, can make the module more flexible. Thus the code
> will serve more different scenarios, with little effort.  I think this
> can be achieved very easily and will lead to less programming work
> when adapting/applying PUR, but instead configuration.
>
>
>  
>
>
> 1.       Add a new method to
> info.magnolia.module.publicuserregistration.strategy.Mail: public void validateRegistration(User user, Map<String, Object> templateValues). This way the process using that class can add their templateValues themselves.
>
>
>  
>
>
> 2.       When you need an extra strategy, you have to adapt the
> PublicUserRegistrationConfig class. Instead of having a fixed set of 3
> strategies, a list of strategies could be present in the config.
> Probably a module class has to be created that loads the strategies in
> a Map<String, Strategy>. From the module instance the strategy can
> then be retrieved by name. (I created a sendPasswordStrategy).
>
>
>  
>
>
> Some other issue I have is with the tree Public Users. All folders
> appear twice, in two shades. I didn’t change the config of that.
> What’s wrong here?
>
>
>  
>
>
> <image001.png>
>
>
>  
>
>
>  
>
>
> If you’re interested I may apply a small patch for these changes.
>
>
>  
>
>
> Many regards, Bert
>
>
>  
>
>
>  
>
>                                    
> ______________________________________________________________________
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> ----------------------------------------------------------------
>
>
>  
>
>
>  
>
>                                    
> ______________________________________________________________________
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> ----------------------------------------------------------------
>
>
>
>
>
> ______________________________________________________________________
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> ----------------------------------------------------------------

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[Jan Haderka-2]

Hyia,

As you might have seen from SVN commits, I've just begin preparation for
4.2-m1 milestone release. I hope to get it out of the door before the
end of the week and we will start second Sprint on Monday.

That being said, I suggest if anybody has patches, improvements or new
features you would like to see in Magnolia 4.2, please try to provide
your contributions over the next 2 weeks to avoid last minute changes
and leave enough room for review and testing of possible side effects of
the changes.

Thanks in advance.

-  
Best regards,

Jan Haderka
Magnolia International Ltd.

Meet us at the Magnolia Conference
http:/www.magnolia-cms.com/conference

Magnolia®  - Simple Open Source Content Management


On Fri, 2009-10-16 at 11:56 +0200, Zdenek Skodik wrote:

> Hi Bert,
>
> afaik it's not fixed yet.
> I expect that this bug occurs due the fact
> that the initialization method of AbstractProfilePage
> is called twice.
> Otherwise it have to be fixed for the next release,
> I'll get in touch with Gregory about that.
>
> -  
> Best regards,
>
> Zdenek Skodik
> Magnolia International Ltd.
>
> Magnolia®  - Simple Open-Source Content Management
>
>
> On Pá, 2009-10-16 at 11:40 +0200, Bert Leunis wrote:
> > Hello,
> >
> >  
> >
> > I checked out PUR again, but the tree has still the same duplicated
> > folder issue. Is the code for that error not in SVN yet? I couldn’t
> > find a jira ticket for that. I am clearly missing something L
> >
> >  
> >
> > Bye, Bert
> >
> >
> >  
> >
> > From:dev-list-owner@...
> > [mailto:dev-list-owner@...] On Behalf Of Philipp Bärfuss
> > Sent: donderdag 8 oktober 2009 10:05
> > To: Magnolia Dev-List
> > Subject: Re: [magnolia-dev] making PUR module more flexible
> >
> >
> >  
> >
> > Best is to create jira tickets for each item in the PUR project, they
> > will most likely be applied immediately. The nasty duplicated folder
> > issue is already solved.
> >
> >  
> >
> >
> > Thanks
> >
> >
> >  
> >
> > - Philipp Bärfuss
> >
> >
> >  
> >
> >
> >  
> >
> >
> >  
> >
> >
> >  
> >
> > On 06.10.2009, at 16:05, Bert Leunis wrote:
> >
> >
> >
> >
> > Hello Magnolians,
> >
> >
> >  
> >
> >
> > I see that you are starting work on the PUR module. On this moment I
> > work with PUR on one of our projects. The client will use PUR in a
> > slightly different way than the intended scenario. I have two ideas
> > that, when applied, can make the module more flexible. Thus the code
> > will serve more different scenarios, with little effort.  I think this
> > can be achieved very easily and will lead to less programming work
> > when adapting/applying PUR, but instead configuration.
> >
> >
> >  
> >
> >
> > 1.       Add a new method to
> > info.magnolia.module.publicuserregistration.strategy.Mail: public void validateRegistration(User user, Map<String, Object> templateValues). This way the process using that class can add their templateValues themselves.
> >
> >
> >  
> >
> >
> > 2.       When you need an extra strategy, you have to adapt the
> > PublicUserRegistrationConfig class. Instead of having a fixed set of 3
> > strategies, a list of strategies could be present in the config.
> > Probably a module class has to be created that loads the strategies in
> > a Map<String, Strategy>. From the module instance the strategy can
> > then be retrieved by name. (I created a sendPasswordStrategy).
> >
> >
> >  
> >
> >
> > Some other issue I have is with the tree Public Users. All folders
> > appear twice, in two shades. I didn’t change the config of that.
> > What’s wrong here?
> >
> >
> >  
> >
> >
> > <image001.png>
> >
> >
> >  
> >
> >
> >  
> >
> >
> > If you’re interested I may apply a small patch for these changes.
> >
> >
> >  
> >
> >
> > Many regards, Bert
> >
> >
> >  
> >
> >
> >  
> >
> >                                    
> > ______________________________________________________________________
> > ----------------------------------------------------------------
> > For list details see
> > http://www.magnolia-cms.com/home/community/mailing-lists.html
> > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> > ----------------------------------------------------------------
> >
> >
> >  
> >
> >
> >  
> >
> >                                    
> > ______________________________________________________________________
> > ----------------------------------------------------------------
> > For list details see
> > http://www.magnolia-cms.com/home/community/mailing-lists.html
> > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> > ----------------------------------------------------------------
> >
> >
> >
> >
> >
> > ______________________________________________________________________
> > ----------------------------------------------------------------
> > For list details see
> > http://www.magnolia-cms.com/home/community/mailing-lists.html
> > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> > ----------------------------------------------------------------
>
>
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> ----------------------------------------------------------------

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[Bert Leunis]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hello Grégory (and others),

 

I will give it one more go to see if I can get my points across!

 

Our client will use PUR in a slightly different way than the standard scenario that PUR presumes/implies. When adapting the different scenario I saw two points in the code that can make PUR more flexible quite easily. With more flexible I mean: it does not hinder the standard scenario but it helps you when your scenario is different (like mine).

 

This is the new scenario we use:

 

1. The webeditor will register the Public User, it wil not be the User itself. (a Public User is created, and a node in the datamodule to store the users data).

2. The User gets an e-mail with its user name and a validation link.

3. The User clicks on the link to validate himself. (The Public User is enabled).

4. The User gets an e-mail with a generated password and a link to the login page.

 

I need some changes in PUR to make this possible. Next to the registrationStrategy and the passwordRetrievalStrategy I need a new sendPasswordStrategy. I can store that at config/modules/public-user-registration/config next to the other two, no problem at all. But, if I want to retrieve that strategy in my code, I cannot use the info.magnolia.module.publicuserregistration.PublicUserRegistrationConfig, because it doesn't have a private field and getters/setters to store my new strategy. Now I need to change the code of that class. And here is my proposal: if all strategies were stored in the config and in the PublicUserRegistrationConfig class in a list or Map, then everybody who wants to add strategies of their own can add them, without having to change the code. Config instead of coding. See the picture to get my idea:

 

You would get the strategy you want by its name.

 

Second idea comes from the wish to send a slightly different e-mail than the ones that are used in a standard situation. The class info.magnolia.module.publicuserregistration.strategy.Mail is used to send the e-mail. This class has all the properties you need to send an e-mail (fromName, fromEmail, subject, emailTemplate etc). Unfortunately, in the emailTemplate you can only use one variable, which is “pagePath”. The method validateRegistration(User user) sets only that one variable. Now, if there was an extra method with this signature: public void validateRegistration(User user, Map<String, Object> templateValues), then every strategy wanting to send e-mails to the Public User would be able to apply all the variables they wanted. A very easy change of the code, which makes it much more usable.

 

Happy to apply any patch, if you can see the benefit.

 

Lots of regards, Bert

 

 

 

> -----Original Message-----

> From: dev-list-owner@... [mailto:dev-list-owner@magnolia-

> cms.com] On Behalf Of Grégory Joseph

> Sent: vrijdag 9 oktober 2009 14:39

> To: Magnolia Dev-List

> Subject: Re: [magnolia-dev] making PUR module more flexible

>

>

>

> On Oct 9, 2009, at 8:48 AM, Bert Leunis wrote:

>

> >

> > Hi Grégory,

> >

> > Thanks for the effort. Of course I can adapt and override code as

> > much as I like. My whole point is, that I like to do more

> > configuration instead of coding.

>

>

> That's a valid point, but I still don't see what you're trying to

> achieve, concretely.

>

> > And I hoped my suggestions would lead to a little improvement in

> > that direction. But if you don't see the benefit (or I am not clear

> > enough about them)

>

> Most likely the latter; or I'm too thick;)

>

>

> > let's just leave it as it is. You should delete the 2 jira's then

> > (MGNLPUR-22 and -23).

> >

> > Bye, Bert

> >

> >

> >> -----Original Message-----

> >> From: dev-list-owner@... [mailto:dev-list-

> >> owner@magnolia-

> >> cms.com] On Behalf Of Grégory Joseph

> >> Sent: donderdag 8 oktober 2009 18:22

> >> To: Magnolia Dev-List

> >> Subject: Re: [magnolia-dev] making PUR module more flexible

> >>

> >>

> >>

> >> On Oct 8, 2009, at 3:05 PM, Bert Leunis wrote:

> >>>>> 1.       Add a new method to

> >>>>> info.magnolia.module.publicuserregistration.strategy.Mail: public

> >>>>> void validateRegistration(User user, Map<String, Object>

> >>>>> templateValues). This way the process using that class can add

> >> their

> >>>>> templateValues themselves.

> >>>>

> >>>> It's the UserRegistrar which calls this method; if you need more

> >>>> parameters in your mail templates, you probably want to subclass

> >>>> i.m.m.pur.strategy.Mail anyway? Where do these parameters come

> >>>> from?

> >>>> Why would you allow arbitrary parameters to be passed there,

> what's

> >>>> the actual usecase? (as a side note, if this ends up being really

> >>>> necessary, i'd rather change the method than add one)

> >>>

> >>> You can have extra parameters in your mail template, e.g. $

> >>> {generatedPassword}. The EnableByUUID class will send the user a

> >>> mail with that password, so that class adds all necessary params to

> >>> the Map<String, Object>. No need to create your own strategy, all

> >>> fields in Mail are oke, all I want is to fill the context with my

> >>> own specific values.

> >>

> >> What is "EnableByUUID" ? An implementation of

> >> info.magnolia.module.publicuserregistration.RegistrationStrategy ?

> So

> >> why can't it add the template values itself  in

> >> info

> >> .magnolia

> >> .module.publicuserregistration.strategy.Mail#validateRegistration ?

> >> (if that's what you're doing, of course we could extract a

> >> addTemplateContextValues() in there)

> >>

> >>

> >>>>> 2.       When you need an extra strategy, you have to adapt the

> >>>>> PublicUserRegistrationConfig class.

> >>>>

> >>>> Uh? How so? As far as I know, you only need to configure it in /

> >>>> modules/pur/config/registrationStrategy or ../

> >>>> passwordRetrievalStrategy

> >>>>

> >>>>> Instead of having a fixed set of 3 strategies, a list of

> >>>>> strategies

> >>>>> could be present in the config.

> >>>>

> >>>> Unless i missed something, it's not a fixed set and was indeed

> >>>> meant

> >>>> so that one can have their custom strategies

> >>>>

> >>>

> >>> My point is: I want to ADD another strategy (sendPasswordStrategy).

> >>> The flow I need for my case here is different than the flow that is

> >>> now 'dictated' by PUR. As far as I can see, it is a fixed set now.

> >>> The class PublicUserRegistrationConfig has two strategies-

> >>> properties. If they are stored in a map, I do not have to write any

> >>> code, just add some config.

> >>>

> >>

> >> But these 2 strategies are there for different purposes, and are

> used

> >> in different contexts ! They're different interfaces, too!

> Obviously,

> >> if you need another functionality (which is...?), you'll need to

> code

> >> stuff; which could be in a different module.

> >>

> >>

> >>

> >>>

> >>>>> Probably a module class has to be created that loads the

> >>>>> strategies

> >>>>> in a Map<String, Strategy>. From the module instance the strategy

> >>>>> can then be retrieved by name. (I created a

> sendPasswordStrategy).

> >>>>

> >>>> I'm not sure what you mean, but then again, see above comments.

> >>>

> >>> I don't think the content2bean utils will convert a list of

> >>> strategies in a Map<String, Strategy> automatically. That can be

> >>> done in the module class (like it is done in  the DataModule).

> >>

> >> Actually, content2bean will convert that, but I don't see the

> >> usecase.

> >> PUR provides two hooks: RegistrationStrategy(validation of a user's

> >> registration - customize if you want to prevent users to register

> >> on a

> >> sunday), and PasswordRetrievalStrategy (determines how users can

> >> retrieve their password - or have it changed).

> >>

> >> Both interfaces can be swapped in configuration, so you can use your

> >> own implementations. We currently have a single impl for

> >> PasswordRetrievalStrategy, and 3 for RegistrationStrategy.

> >>

> >> If you use your IDE to search for usages of these interfaces, you'll

> >> see they're used in totally different contexts. They're not "a"

> >> strategy. They're just two different pluggable components provided

> by

> >> this module. I'm tempted to rename these interfaces to

> >> PasswordRetrieval and RegistrationValidation if it's so confusing.

> >>

> >> hth,

> >>

> >> -g

> >>

> >>

> >> ----------------------------------------------------------------

> >> For list details see

> >> http://www.magnolia-cms.com/home/community/mailing-lists.html

> >> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>

> >> ----------------------------------------------------------------

> >

> >

> > ----------------------------------------------------------------

> > For list details see

> > http://www.magnolia-cms.com/home/community/mailing-lists.html

> > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>

> > ----------------------------------------------------------------

>

>

> ----------------------------------------------------------------

> For list details see

> http://www.magnolia-cms.com/home/community/mailing-lists.html

> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>

> ----------------------------------------------------------------

 

---

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[Zdenek Skodik]

Hi Bert,

please comment on MGNLPUR-22/23 to raise the discussion.
Thanks.

-  
Best regards,

Zdenek Skodik
Magnolia International Ltd.

Magnolia®  - Simple Open-Source Content Management


On Pá, 2009-11-06 at 10:40 +0100, Bert Leunis wrote:

> Hello Grégory (and others),
>
>  
>
> I will give it one more go to see if I can get my points across!
>
>  
>
> Our client will use PUR in a slightly different way than the standard
> scenario that PUR presumes/implies. When adapting the different
> scenario I saw two points in the code that can make PUR more flexible
> quite easily. With more flexible I mean: it does not hinder the
> standard scenario but it helps you when your scenario is different
> (like mine).
>
>  
>
> This is the new scenario we use:
>
>  
>
> 1. The webeditor will register the Public User, it wil not be the User
> itself. (a Public User is created, and a node in the datamodule to
> store the users data).
>
> 2. The User gets an e-mail with its user name and a validation link.
>
> 3. The User clicks on the link to validate himself. (The Public User
> is enabled).
>
> 4. The User gets an e-mail with a generated password and a link to the
> login page.
>
>  
>
> I need some changes in PUR to make this possible. Next to the
> registrationStrategy and the passwordRetrievalStrategy I need a new
> sendPasswordStrategy. I can store that at
> config/modules/public-user-registration/config next to the other two,
> no problem at all. But, if I want to retrieve that strategy in my
> code, I cannot use the
> info.magnolia.module.publicuserregistration.PublicUserRegistrationConfig, because it doesn't have a private field and getters/setters to store my new strategy. Now I need to change the code of that class. And here is my proposal: if all strategies were stored in the config and in the PublicUserRegistrationConfig class in a list or Map, then everybody who wants to add strategies of their own can add them, without having to change the code. Config instead of coding. See the picture to get my idea:
>
>  
>
>
>
> You would get the strategy you want by its name.
>
>  
>
> Second idea comes from the wish to send a slightly different e-mail
> than the ones that are used in a standard situation. The class
> info.magnolia.module.publicuserregistration.strategy.Mail is used to
> send the e-mail. This class has all the properties you need to send an
> e-mail (fromName, fromEmail, subject, emailTemplate etc).
> Unfortunately, in the emailTemplate you can only use one variable,
> which is “pagePath”. The method validateRegistration(User user) sets
> only that one variable. Now, if there was an extra method with this
> signature: public void validateRegistration(User user, Map<String,
> Object> templateValues), then every strategy wanting to send e-mails
> to the Public User would be able to apply all the variables they
> wanted. A very easy change of the code, which makes it much more
> usable.
>
>  
>
> Happy to apply any patch, if you can see the benefit.
>
>  
>
> Lots of regards, Bert
>
>  
>
>  
>
>  
>
> > -----Original Message-----
>
> > From: dev-list-owner@...
> [mailto:dev-list-owner@magnolia-
>
> > cms.com] On Behalf Of Grégory Joseph
>
> > Sent: vrijdag 9 oktober 2009 14:39
>
> > To: Magnolia Dev-List
>
> > Subject: Re: [magnolia-dev] making PUR module more flexible
>
> >
>
> >
>
> >
>
> > On Oct 9, 2009, at 8:48 AM, Bert Leunis wrote:
>
> >
>
> > >
>
> > > Hi Grégory,
>
> > >
>
> > > Thanks for the effort. Of course I can adapt and override code as
>
> > > much as I like. My whole point is, that I like to do more
>
> > > configuration instead of coding.
>
> >
>
> >
>
> > That's a valid point, but I still don't see what you're trying to
>
> > achieve, concretely.
>
> >
>
> > > And I hoped my suggestions would lead to a little improvement in
>
> > > that direction. But if you don't see the benefit (or I am not
> clear
>
> > > enough about them)
>
> >
>
> > Most likely the latter; or I'm too thick;)
>
> >
>
> >
>
> > > let's just leave it as it is. You should delete the 2 jira's then
>
> > > (MGNLPUR-22 and -23).
>
> > >
>
> > > Bye, Bert
>
> > >
>
> > >
>
> > >> -----Original Message-----
>
> > >> From: dev-list-owner@... [mailto:dev-list-
>
> > >> owner@magnolia-
>
> > >> cms.com] On Behalf Of Grégory Joseph
>
> > >> Sent: donderdag 8 oktober 2009 18:22
>
> > >> To: Magnolia Dev-List
>
> > >> Subject: Re: [magnolia-dev] making PUR module more flexible
>
> > >>
>
> > >>
>
> > >>
>
> > >> On Oct 8, 2009, at 3:05 PM, Bert Leunis wrote:
>
> > >>>>> 1.       Add a new method to
>
> > >>>>> info.magnolia.module.publicuserregistration.strategy.Mail:
> public
>
> > >>>>> void validateRegistration(User user, Map<String, Object>
>
> > >>>>> templateValues). This way the process using that class can add
>
> > >> their
>
> > >>>>> templateValues themselves.
>
> > >>>>
>
> > >>>> It's the UserRegistrar which calls this method; if you need
> more
>
> > >>>> parameters in your mail templates, you probably want to
> subclass
>
> > >>>> i.m.m.pur.strategy.Mail anyway? Where do these parameters come
>
> > >>>> from?
>
> > >>>> Why would you allow arbitrary parameters to be passed there,
>
> > what's
>
> > >>>> the actual usecase? (as a side note, if this ends up being
> really
>
> > >>>> necessary, i'd rather change the method than add one)
>
> > >>>
>
> > >>> You can have extra parameters in your mail template, e.g. $
>
> > >>> {generatedPassword}. The EnableByUUID class will send the user a
>
> > >>> mail with that password, so that class adds all necessary params
> to
>
> > >>> the Map<String, Object>. No need to create your own strategy,
> all
>
> > >>> fields in Mail are oke, all I want is to fill the context with
> my
>
> > >>> own specific values.
>
> > >>
>
> > >> What is "EnableByUUID" ? An implementation of
>
> > >>
> info.magnolia.module.publicuserregistration.RegistrationStrategy ?
>
> > So
>
> > >> why can't it add the template values itself  in
>
> > >> info
>
> > >> .magnolia
>
> >
> >> .module.publicuserregistration.strategy.Mail#validateRegistration ?
>
> > >> (if that's what you're doing, of course we could extract a
>
> > >> addTemplateContextValues() in there)
>
> > >>
>
> > >>
>
> > >>>>> 2.       When you need an extra strategy, you have to adapt
> the
>
> > >>>>> PublicUserRegistrationConfig class.
>
> > >>>>
>
> > >>>> Uh? How so? As far as I know, you only need to configure it
> in /
>
> > >>>> modules/pur/config/registrationStrategy or ../
>
> > >>>> passwordRetrievalStrategy
>
> > >>>>
>
> > >>>>> Instead of having a fixed set of 3 strategies, a list of
>
> > >>>>> strategies
>
> > >>>>> could be present in the config.
>
> > >>>>
>
> > >>>> Unless i missed something, it's not a fixed set and was indeed
>
> > >>>> meant
>
> > >>>> so that one can have their custom strategies
>
> > >>>>
>
> > >>>
>
> > >>> My point is: I want to ADD another strategy
> (sendPasswordStrategy).
>
> > >>> The flow I need for my case here is different than the flow that
> is
>
> > >>> now 'dictated' by PUR. As far as I can see, it is a fixed set
> now.
>
> > >>> The class PublicUserRegistrationConfig has two strategies-
>
> > >>> properties. If they are stored in a map, I do not have to write
> any
>
> > >>> code, just add some config.
>
> > >>>
>
> > >>
>
> > >> But these 2 strategies are there for different purposes, and are
>
> > used
>
> > >> in different contexts ! They're different interfaces, too!
>
> > Obviously,
>
> > >> if you need another functionality (which is...?), you'll need to
>
> > code
>
> > >> stuff; which could be in a different module.
>
> > >>
>
> > >>
>
> > >>
>
> > >>>
>
> > >>>>> Probably a module class has to be created that loads the
>
> > >>>>> strategies
>
> > >>>>> in a Map<String, Strategy>. From the module instance the
> strategy
>
> > >>>>> can then be retrieved by name. (I created a
>
> > sendPasswordStrategy).
>
> > >>>>
>
> > >>>> I'm not sure what you mean, but then again, see above comments.
>
> > >>>
>
> > >>> I don't think the content2bean utils will convert a list of
>
> > >>> strategies in a Map<String, Strategy> automatically. That can be
>
> > >>> done in the module class (like it is done in  the DataModule).
>
> > >>
>
> > >> Actually, content2bean will convert that, but I don't see the
>
> > >> usecase.
>
> > >> PUR provides two hooks: RegistrationStrategy(validation of a
> user's
>
> > >> registration - customize if you want to prevent users to register
>
> > >> on a
>
> > >> sunday), and PasswordRetrievalStrategy (determines how users can
>
> > >> retrieve their password - or have it changed).
>
> > >>
>
> > >> Both interfaces can be swapped in configuration, so you can use
> your
>
> > >> own implementations. We currently have a single impl for
>
> > >> PasswordRetrievalStrategy, and 3 for RegistrationStrategy.
>
> > >>
>
> > >> If you use your IDE to search for usages of these interfaces,
> you'll
>
> > >> see they're used in totally different contexts. They're not "a"
>
> > >> strategy. They're just two different pluggable components
> provided
>
> > by
>
> > >> this module. I'm tempted to rename these interfaces to
>
> > >> PasswordRetrieval and RegistrationValidation if it's so
> confusing.
>
> > >>
>
> > >> hth,
>
> > >>
>
> > >> -g
>
> > >>
>
> > >>
>
> > >> ----------------------------------------------------------------
>
> > >> For list details see
>
> > >> http://www.magnolia-cms.com/home/community/mailing-lists.html
>
> > >> To unsubscribe, E-mail to:
> <dev-list-unsubscribe@...>
>
> > >> ----------------------------------------------------------------
>
> > >
>
> > >
>
> > > ----------------------------------------------------------------
>
> > > For list details see
>
> > > http://www.magnolia-cms.com/home/community/mailing-lists.html
>
> > > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
>
> > > ----------------------------------------------------------------
>
> >
>
> >
>
> > ----------------------------------------------------------------
>
> > For list details see
>
> > http://www.magnolia-cms.com/home/community/mailing-lists.html
>
> > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
>
> > ----------------------------------------------------------------
>
>  
>
>
>
>
>
> ______________________________________________________________________
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> ----------------------------------------------------------------

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[gregoryjoseph]

Hi Bert,

Thanks for the taking the time to write this! Now I think I understand  
your requests! ;)

On Nov 6, 2009, at 10:40 AM, Bert Leunis wrote:

> Hello Grégory (and others),
>
> I will give it one more go to see if I can get my points across!
>
> Our client will use PUR in a slightly different way than the  
> standard scenario that PUR presumes/implies. When adapting the  
> different scenario I saw two points in the code that can make PUR  
> more flexible quite easily. With more flexible I mean: it does not  
> hinder the standard scenario but it helps you when your scenario is  
> different (like mine).
>
> This is the new scenario we use:
>
> 1. The webeditor will register the Public User, it wil not be the  
> User itself. (a Public User is created, and a node in the datamodule  
> to store the users data).
> 2. The User gets an e-mail with its user name and a validation link.
> 3. The User clicks on the link to validate himself. (The Public User  
> is enabled).
> 4. The User gets an e-mail with a generated password and a link to  
> the login page.

In your scenario, is the "self registration" *also* needed?

>  I need some changes in PUR to make this possible. Next to the  
> registrationStrategy and the passwordRetrievalStrategy I need a new  
> sendPasswordStrategy. I can store that at config/modules/public-user-
> registration/config next to the other two, no problem at all. But,  
> if I want to retrieve that strategy in my code, I cannot use the  
> info
> .magnolia
> .module.publicuserregistration.PublicUserRegistrationConfig, because  
> it doesn't have a private field and getters/setters to store my new  
> strategy. Now I need to change the code of that class. And here is  
> my proposal: if all strategies were stored in the config and in the  
> PublicUserRegistrationConfig class in a list or Map, then everybody  
> who wants to add strategies of their own can add them, without  
> having to change the code. Config instead of coding. See the picture  
> to get my idea:
>
> <image002.jpg>
> You would get the strategy you want by its name.

They're different interfaces with different use-cases; if multiple  
implementations of either are needed, we could imagine something like  
this but with a map for each (i.e they're not "two strategies" they  
are "one PasswordRetrievalStrategy" (impl of the mechanism for users  
to retrieve their passwords) and "one RegistrationStrategy" (impl of  
the mechanism used to register and validate users)

>  Second idea comes from the wish to send a slightly different e-mail  
> than the ones that are used in a standard situation. The class  
> info.magnolia.module.publicuserregistration.strategy.Mail is used to  
> send the e-mail. This class has all the properties you need to send  
> an e-mail (fromName, fromEmail, subject, emailTemplate etc).  
> Unfortunately, in the emailTemplate you can only use one variable,  
> which is “pagePath”. The method validateRegistration(User user) sets  
> only that one variable. Now, if there was an extra method with this  
> signature: public void validateRegistration(User user, Map<String,  
> Object> templateValues), then every strategy wanting to send e-mails  
> to the Public User would be able to apply all the variables they  
> wanted. A very easy change of the code, which makes it much more  
> usable.

Where would these values come from, who (what code) would set them ?

Cheers,

-g

>
> Happy to apply any patch, if you can see the benefit.
>
> Lots of regards, Bert
>
>
>
> > -----Original Message-----
> > From: dev-list-owner@... [mailto:dev-list-owner@magnolia-
> > cms.com] On Behalf Of Grégory Joseph
> > Sent: vrijdag 9 oktober 2009 14:39
> > To: Magnolia Dev-List
> > Subject: Re: [magnolia-dev] making PUR module more flexible
> >
> >
> >
> > On Oct 9, 2009, at 8:48 AM, Bert Leunis wrote:
> >
> > >
> > > Hi Grégory,
> > >
> > > Thanks for the effort. Of course I can adapt and override code as
> > > much as I like. My whole point is, that I like to do more
> > > configuration instead of coding.
> >
> >
> > That's a valid point, but I still don't see what you're trying to
> > achieve, concretely.
> >
> > > And I hoped my suggestions would lead to a little improvement in
> > > that direction. But if you don't see the benefit (or I am not  
> clear
> > > enough about them)
> >
> > Most likely the latter; or I'm too thick;)
> >
> >
> > > let's just leave it as it is. You should delete the 2 jira's then
> > > (MGNLPUR-22 and -23).
> > >
> > > Bye, Bert
> > >
> > >
> > >> -----Original Message-----
> > >> From: dev-list-owner@... [mailto:dev-list-
> > >> owner@magnolia-
> > >> cms.com] On Behalf Of Grégory Joseph
> > >> Sent: donderdag 8 oktober 2009 18:22
> > >> To: Magnolia Dev-List
> > >> Subject: Re: [magnolia-dev] making PUR module more flexible
> > >>
> > >>
> > >>
> > >> On Oct 8, 2009, at 3:05 PM, Bert Leunis wrote:
> > >>>>> 1.       Add a new method to
> > >>>>> info.magnolia.module.publicuserregistration.strategy.Mail:  
> public
> > >>>>> void validateRegistration(User user, Map<String, Object>
> > >>>>> templateValues). This way the process using that class can add
> > >> their
> > >>>>> templateValues themselves.
> > >>>>
> > >>>> It's the UserRegistrar which calls this method; if you need  
> more
> > >>>> parameters in your mail templates, you probably want to  
> subclass
> > >>>> i.m.m.pur.strategy.Mail anyway? Where do these parameters come
> > >>>> from?
> > >>>> Why would you allow arbitrary parameters to be passed there,
> > what's
> > >>>> the actual usecase? (as a side note, if this ends up being  
> really
> > >>>> necessary, i'd rather change the method than add one)
> > >>>
> > >>> You can have extra parameters in your mail template, e.g. $
> > >>> {generatedPassword}. The EnableByUUID class will send the user a
> > >>> mail with that password, so that class adds all necessary  
> params to
> > >>> the Map<String, Object>. No need to create your own strategy,  
> all
> > >>> fields in Mail are oke, all I want is to fill the context with  
> my
> > >>> own specific values.
> > >>
> > >> What is "EnableByUUID" ? An implementation of
> > >>  
> info.magnolia.module.publicuserregistration.RegistrationStrategy ?
> > So
> > >> why can't it add the template values itself  in
> > >> info
> > >> .magnolia
> >  
> >> .module.publicuserregistration.strategy.Mail#validateRegistration ?
> > >> (if that's what you're doing, of course we could extract a
> > >> addTemplateContextValues() in there)
> > >>
> > >>
> > >>>>> 2.       When you need an extra strategy, you have to adapt  
> the
> > >>>>> PublicUserRegistrationConfig class.
> > >>>>
> > >>>> Uh? How so? As far as I know, you only need to configure it  
> in /
> > >>>> modules/pur/config/registrationStrategy or ../
> > >>>> passwordRetrievalStrategy
> > >>>>
> > >>>>> Instead of having a fixed set of 3 strategies, a list of
> > >>>>> strategies
> > >>>>> could be present in the config.
> > >>>>
> > >>>> Unless i missed something, it's not a fixed set and was indeed
> > >>>> meant
> > >>>> so that one can have their custom strategies
> > >>>>
> > >>>
> > >>> My point is: I want to ADD another strategy  
> (sendPasswordStrategy).
> > >>> The flow I need for my case here is different than the flow  
> that is
> > >>> now 'dictated' by PUR. As far as I can see, it is a fixed set  
> now.
> > >>> The class PublicUserRegistrationConfig has two strategies-
> > >>> properties. If they are stored in a map, I do not have to  
> write any
> > >>> code, just add some config.
> > >>>
> > >>
> > >> But these 2 strategies are there for different purposes, and are
> > used
> > >> in different contexts ! They're different interfaces, too!
> > Obviously,
> > >> if you need another functionality (which is...?), you'll need to
> > code
> > >> stuff; which could be in a different module.
> > >>
> > >>
> > >>
> > >>>
> > >>>>> Probably a module class has to be created that loads the
> > >>>>> strategies
> > >>>>> in a Map<String, Strategy>. From the module instance the  
> strategy
> > >>>>> can then be retrieved by name. (I created a
> > sendPasswordStrategy).
> > >>>>
> > >>>> I'm not sure what you mean, but then again, see above comments.
> > >>>
> > >>> I don't think the content2bean utils will convert a list of
> > >>> strategies in a Map<String, Strategy> automatically. That can be
> > >>> done in the module class (like it is done in  the DataModule).
> > >>
> > >> Actually, content2bean will convert that, but I don't see the
> > >> usecase.
> > >> PUR provides two hooks: RegistrationStrategy(validation of a  
> user's
> > >> registration - customize if you want to prevent users to register
> > >> on a
> > >> sunday), and PasswordRetrievalStrategy (determines how users can
> > >> retrieve their password - or have it changed).
> > >>
> > >> Both interfaces can be swapped in configuration, so you can use  
> your
> > >> own implementations. We currently have a single impl for
> > >> PasswordRetrievalStrategy, and 3 for RegistrationStrategy.
> > >>
> > >> If you use your IDE to search for usages of these interfaces,  
> you'll
> > >> see they're used in totally different contexts. They're not "a"
> > >> strategy. They're just two different pluggable components  
> provided
> > by
> > >> this module. I'm tempted to rename these interfaces to
> > >> PasswordRetrieval and RegistrationValidation if it's so  
> confusing.
> > >>
> > >> hth,
> > >>
> > >> -g
> > >>
> > >>
> > >> ----------------------------------------------------------------
> > >> For list details see
> > >> http://www.magnolia-cms.com/home/community/mailing-lists.html
> > >> To unsubscribe, E-mail to: <dev-list-unsubscribe@magnolia-
> cms.com>
> > >> ----------------------------------------------------------------
> > >
> > >
> > > ----------------------------------------------------------------
> > > For list details see
> > > http://www.magnolia-cms.com/home/community/mailing-lists.html
> > > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> > > ----------------------------------------------------------------
> >
> >
> > ----------------------------------------------------------------
> > For list details see
> > http://www.magnolia-cms.com/home/community/mailing-lists.html
> > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> > ----------------------------------------------------------------
>
>
>
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> ----------------------------------------------------------------

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[Bert Leunis]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Thanks Grégory! See my answers below. If you can see any advantage in my idea’s I’m happy to help with some code, but if not, no problem either. We would spend too much time on a matter that is not interesting for you.

 

Regards, Bert

 

> -----Original Message-----

> From: dev-list-owner@... [mailto:dev-list-owner@magnolia-

> cms.com] On Behalf Of Grégory Joseph

> Sent: vrijdag 6 november 2009 16:16

> To: Magnolia Dev-List

> Subject: Re: [magnolia-dev] making PUR module more flexible

>

>

> Hi Bert,

>

> Thanks for the taking the time to write this! Now I think I understand

> your requests! ;)

>

> On Nov 6, 2009, at 10:40 AM, Bert Leunis wrote:

>

> > Hello Grégory (and others),

> >

> > I will give it one more go to see if I can get my points across!

> >

> > Our client will use PUR in a slightly different way than the

> > standard scenario that PUR presumes/implies. When adapting the

> > different scenario I saw two points in the code that can make PUR

> > more flexible quite easily. With more flexible I mean: it does not

> > hinder the standard scenario but it helps you when your scenario is

> > different (like mine).

> >

> > This is the new scenario we use:

> >

> > 1. The webeditor will register the Public User, it wil not be the

> > User itself. (a Public User is created, and a node in the datamodule

> > to store the users data).

> > 2. The User gets an e-mail with its user name and a validation link.

> > 3. The User clicks on the link to validate himself. (The Public User

> > is enabled).

> > 4. The User gets an e-mail with a generated password and a link to

> > the login page.

>

> In your scenario, is the "self registration" *also* needed?

 

No, the users in our case will never register themselves. To keep them in a specific group as Public Users soots us very much, as well as the 'forgot your password' service.

 

>

> >  I need some changes in PUR to make this possible. Next to the

> > registrationStrategy and the passwordRetrievalStrategy I need a new

> > sendPasswordStrategy. I can store that at config/modules/public-user-

> > registration/config next to the other two, no problem at all. But,

> > if I want to retrieve that strategy in my code, I cannot use the

> > info

> > .magnolia

> > .module.publicuserregistration.PublicUserRegistrationConfig, because

> > it doesn't have a private field and getters/setters to store my new

> > strategy. Now I need to change the code of that class. And here is

> > my proposal: if all strategies were stored in the config and in the

> > PublicUserRegistrationConfig class in a list or Map, then everybody

> > who wants to add strategies of their own can add them, without

> > having to change the code. Config instead of coding. See the picture

> > to get my idea:

> >

> > <image002.jpg>

> > You would get the strategy you want by its name.

>

> They're different interfaces with different use-cases; if multiple

> implementations of either are needed, we could imagine something like

> this but with a map for each (i.e they're not "two strategies" they

> are "one PasswordRetrievalStrategy" (impl of the mechanism for users

> to retrieve their passwords) and "one RegistrationStrategy" (impl of

> the mechanism used to register and validate users)

 

I see. To me their all 'actions to perform in regard to the Public User', and as such can be grouped together.

 

>

> >  Second idea comes from the wish to send a slightly different e-mail

> > than the ones that are used in a standard situation. The class

> > info.magnolia.module.publicuserregistration.strategy.Mail is used to

> > send the e-mail. This class has all the properties you need to send

> > an e-mail (fromName, fromEmail, subject, emailTemplate etc).

> > Unfortunately, in the emailTemplate you can only use one variable,

> > which is “pagePath”. The method validateRegistration(User user) sets

> > only that one variable. Now, if there was an extra method with this

> > signature: public void validateRegistration(User user, Map<String,

> > Object> templateValues), then every strategy wanting to send e-mails

> > to the Public User would be able to apply all the variables they

> > wanted. A very easy change of the code, which makes it much more

> > usable.

>

> Where would these values come from, who (what code) would set them ?

 

In the PUR module there's the class info.magnolia.module.publicuserregistration.frontend.EnableByUuid. I created my own version of that, because except enableing the Public User, we have to send him a password too. Here I use my sendPasswordStrategy:

 

>

> Cheers,

>

> -g

>

>

> >

> > Happy to apply any patch, if you can see the benefit.

> >

> > Lots of regards, Bert

> >

> >

> >

> > > -----Original Message-----

> > > From: dev-list-owner@... [mailto:dev-list-

> owner@magnolia-

> > > cms.com] On Behalf Of Grégory Joseph

> > > Sent: vrijdag 9 oktober 2009 14:39

> > > To: Magnolia Dev-List

> > > Subject: Re: [magnolia-dev] making PUR module more flexible

> > >

> > >

> > >

> > > On Oct 9, 2009, at 8:48 AM, Bert Leunis wrote:

> > >

> > > >

> > > > Hi Grégory,

> > > >

> > > > Thanks for the effort. Of course I can adapt and override code as

> > > > much as I like. My whole point is, that I like to do more

> > > > configuration instead of coding.

> > >

> > >

> > > That's a valid point, but I still don't see what you're trying to

> > > achieve, concretely.

> > >

> > > > And I hoped my suggestions would lead to a little improvement in

> > > > that direction. But if you don't see the benefit (or I am not

> > clear

> > > > enough about them)

> > >

> > > Most likely the latter; or I'm too thick;)

> > >

> > >

> > > > let's just leave it as it is. You should delete the 2 jira's then

> > > > (MGNLPUR-22 and -23).

> > > >

> > > > Bye, Bert

> > > >

> > > >

> > > >> -----Original Message-----

> > > >> From: dev-list-owner@... [mailto:dev-list-

> > > >> owner@magnolia-

> > > >> cms.com] On Behalf Of Grégory Joseph

> > > >> Sent: donderdag 8 oktober 2009 18:22

> > > >> To: Magnolia Dev-List

> > > >> Subject: Re: [magnolia-dev] making PUR module more flexible

> > > >>

> > > >>

> > > >>

> > > >> On Oct 8, 2009, at 3:05 PM, Bert Leunis wrote:

> > > >>>>> 1.       Add a new method to

> > > >>>>> info.magnolia.module.publicuserregistration.strategy.Mail:

> > public

> > > >>>>> void validateRegistration(User user, Map<String, Object>

> > > >>>>> templateValues). This way the process using that class can

> add

> > > >> their

> > > >>>>> templateValues themselves.

> > > >>>>

> > > >>>> It's the UserRegistrar which calls this method; if you need

> > more

> > > >>>> parameters in your mail templates, you probably want to

> > subclass

> > > >>>> i.m.m.pur.strategy.Mail anyway? Where do these parameters come

> > > >>>> from?

> > > >>>> Why would you allow arbitrary parameters to be passed there,

> > > what's

> > > >>>> the actual usecase? (as a side note, if this ends up being

> > really

> > > >>>> necessary, i'd rather change the method than add one)

> > > >>>

> > > >>> You can have extra parameters in your mail template, e.g. $

> > > >>> {generatedPassword}. The EnableByUUID class will send the user

> a

> > > >>> mail with that password, so that class adds all necessary

> > params to

> > > >>> the Map<String, Object>. No need to create your own strategy,

> > all

> > > >>> fields in Mail are oke, all I want is to fill the context with

> > my

> > > >>> own specific values.

> > > >>

> > > >> What is "EnableByUUID" ? An implementation of

> > > >>

> > info.magnolia.module.publicuserregistration.RegistrationStrategy ?

> > > So

> > > >> why can't it add the template values itself  in

> > > >> info

> > > >> .magnolia

> > >

> > >> .module.publicuserregistration.strategy.Mail#validateRegistration

> ?

> > > >> (if that's what you're doing, of course we could extract a

> > > >> addTemplateContextValues() in there)

> > > >>

> > > >>

> > > >>>>> 2.       When you need an extra strategy, you have to adapt

> > the

> > > >>>>> PublicUserRegistrationConfig class.

> > > >>>>

> > > >>>> Uh? How so? As far as I know, you only need to configure it

> > in /

> > > >>>> modules/pur/config/registrationStrategy or ../

> > > >>>> passwordRetrievalStrategy

> > > >>>>

> > > >>>>> Instead of having a fixed set of 3 strategies, a list of

> > > >>>>> strategies

> > > >>>>> could be present in the config.

> > > >>>>

> > > >>>> Unless i missed something, it's not a fixed set and was indeed

> > > >>>> meant

> > > >>>> so that one can have their custom strategies

> > > >>>>

> > > >>>

> > > >>> My point is: I want to ADD another strategy

> > (sendPasswordStrategy).

> > > >>> The flow I need for my case here is different than the flow

> > that is

> > > >>> now 'dictated' by PUR. As far as I can see, it is a fixed set

> > now.

> > > >>> The class PublicUserRegistrationConfig has two strategies-

> > > >>> properties. If they are stored in a map, I do not have to

> > write any

> > > >>> code, just add some config.

> > > >>>

> > > >>

> > > >> But these 2 strategies are there for different purposes, and are

> > > used

> > > >> in different contexts ! They're different interfaces, too!

> > > Obviously,

> > > >> if you need another functionality (which is...?), you'll need to

> > > code

> > > >> stuff; which could be in a different module.

> > > >>

> > > >>

> > > >>

> > > >>>

> > > >>>>> Probably a module class has to be created that loads the

> > > >>>>> strategies

> > > >>>>> in a Map<String, Strategy>. From the module instance the

> > strategy

> > > >>>>> can then be retrieved by name. (I created a

> > > sendPasswordStrategy).

> > > >>>>

> > > >>>> I'm not sure what you mean, but then again, see above

> comments.

> > > >>>

> > > >>> I don't think the content2bean utils will convert a list of

> > > >>> strategies in a Map<String, Strategy> automatically. That can

> be

> > > >>> done in the module class (like it is done in  the DataModule).

> > > >>

> > > >> Actually, content2bean will convert that, but I don't see the

> > > >> usecase.

> > > >> PUR provides two hooks: RegistrationStrategy(validation of a

> > user's

> > > >> registration - customize if you want to prevent users to

> register

> > > >> on a

> > > >> sunday), and PasswordRetrievalStrategy (determines how users can

> > > >> retrieve their password - or have it changed).

> > > >>

> > > >> Both interfaces can be swapped in configuration, so you can use

> > your

> > > >> own implementations. We currently have a single impl for

> > > >> PasswordRetrievalStrategy, and 3 for RegistrationStrategy.

> > > >>

> > > >> If you use your IDE to search for usages of these interfaces,

> > you'll

> > > >> see they're used in totally different contexts. They're not "a"

> > > >> strategy. They're just two different pluggable components

> > provided

> > > by

> > > >> this module. I'm tempted to rename these interfaces to

> > > >> PasswordRetrieval and RegistrationValidation if it's so

> > confusing.

> > > >>

> > > >> hth,

> > > >>

> > > >> -g

> > > >>

> > > >>

> > > >> ----------------------------------------------------------------

> > > >> For list details see

> > > >> http://www.magnolia-cms.com/home/community/mailing-lists.html

> > > >> To unsubscribe, E-mail to: <dev-list-unsubscribe@magnolia-

> > cms.com>

> > > >> ----------------------------------------------------------------

> > > >

> > > >

> > > > ----------------------------------------------------------------

> > > > For list details see

> > > > http://www.magnolia-cms.com/home/community/mailing-lists.html

> > > > To unsubscribe, E-mail to: <dev-list-unsubscribe@magnolia-

> cms.com>

> > > > ----------------------------------------------------------------

> > >

> > >

> > > ----------------------------------------------------------------

> > > For list details see

> > > http://www.magnolia-cms.com/home/community/mailing-lists.html

> > > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>

> > > ----------------------------------------------------------------

> >

> >

> >

> > ----------------------------------------------------------------

> > For list details see

> > http://www.magnolia-cms.com/home/community/mailing-lists.html

> > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>

> > ----------------------------------------------------------------

>

>

> ----------------------------------------------------------------

> For list details see

> http://www.magnolia-cms.com/home/community/mailing-lists.html

> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>

> ----------------------------------------------------------------

 

---

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[Ruben Reusser]

Just on a side note - instead of using the whole magnolia PUR process to
register users, we opted for our own process outside of PUR and then
just use some callbacks into PUR to create the account. That made the
whole process a bit easier, allowes us to log users in with
username/password or email address/password, etc. Works nice and makes
it way more customizable.

Ruben

Bert Leunis wrote:

>
> Thanks Grégory! See my answers below. If you can see any advantage in
> my idea’s I’m happy to help with some code, but if not, no problem
> either. We would spend too much time on a matter that is not
> interesting for you.
>
> Regards, Bert
>
> > -----Original Message-----
>
> > From: dev-list-owner@... [mailto:dev-list-owner@magnolia-
>
> > cms.com] On Behalf Of Grégory Joseph
>
> > Sent: vrijdag 6 november 2009 16:16
>
> > To: Magnolia Dev-List
>
> > Subject: Re: [magnolia-dev] making PUR module more flexible
>
> >
>
> >
>
> > Hi Bert,
>
> >
>
> > Thanks for the taking the time to write this! Now I think I understand
>
> > your requests! ;)
>
> >
>
> > On Nov 6, 2009, at 10:40 AM, Bert Leunis wrote:
>
> >
>
> > > Hello Grégory (and others),
>
> > >
>
> > > I will give it one more go to see if I can get my points across!
>
> > >
>
> > > Our client will use PUR in a slightly different way than the
>
> > > standard scenario that PUR presumes/implies. When adapting the
>
> > > different scenario I saw two points in the code that can make PUR
>
> > > more flexible quite easily. With more flexible I mean: it does not
>
> > > hinder the standard scenario but it helps you when your scenario is
>
> > > different (like mine).
>
> > >
>
> > > This is the new scenario we use:
>
> > >
>
> > > 1. The webeditor will register the Public User, it wil not be the
>
> > > User itself. (a Public User is created, and a node in the datamodule
>
> > > to store the users data).
>
> > > 2. The User gets an e-mail with its user name and a validation link.
>
> > > 3. The User clicks on the link to validate himself. (The Public User
>
> > > is enabled).
>
> > > 4. The User gets an e-mail with a generated password and a link to
>
> > > the login page.
>
> >
>
> > In your scenario, is the "self registration" *also* needed?
>
> No, the users in our case will never register themselves. To keep them
> in a specific group as Public Users soots us very much, as well as the
> 'forgot your password' service.
>
> >
>
> > > I need some changes in PUR to make this possible. Next to the
>
> > > registrationStrategy and the passwordRetrievalStrategy I need a new
>
> > > sendPasswordStrategy. I can store that at config/modules/public-user-
>
> > > registration/config next to the other two, no problem at all. But,
>
> > > if I want to retrieve that strategy in my code, I cannot use the
>
> > > info
>
> > > .magnolia
>
> > > .module.publicuserregistration.PublicUserRegistrationConfig, because
>
> > > it doesn't have a private field and getters/setters to store my new
>
> > > strategy. Now I need to change the code of that class. And here is
>
> > > my proposal: if all strategies were stored in the config and in the
>
> > > PublicUserRegistrationConfig class in a list or Map, then everybody
>
> > > who wants to add strategies of their own can add them, without
>
> > > having to change the code. Config instead of coding. See the picture
>
> > > to get my idea:
>
> > >
>
> > > <image002.jpg>
>
> > > You would get the strategy you want by its name.
>
> >
>
> > They're different interfaces with different use-cases; if multiple
>
> > implementations of either are needed, we could imagine something like
>
> > this but with a map for each (i.e they're not "two strategies" they
>
> > are "one PasswordRetrievalStrategy" (impl of the mechanism for users
>
> > to retrieve their passwords) and "one RegistrationStrategy" (impl of
>
> > the mechanism used to register and validate users)
>
> I see. To me their all 'actions to perform in regard to the Public
> User', and as such can be grouped together.
>
> >
>
> > > Second idea comes from the wish to send a slightly different e-mail
>
> > > than the ones that are used in a standard situation. The class
>
> > > info.magnolia.module.publicuserregistration.strategy.Mail is used to
>
> > > send the e-mail. This class has all the properties you need to send
>
> > > an e-mail (fromName, fromEmail, subject, emailTemplate etc).
>
> > > Unfortunately, in the emailTemplate you can only use one variable,
>
> > > which is “pagePath”. The method validateRegistration(User user) sets
>
> > > only that one variable. Now, if there was an extra method with this
>
> > > signature: public void validateRegistration(User user, Map<String,
>
> > > Object> templateValues), then every strategy wanting to send e-mails
>
> > > to the Public User would be able to apply all the variables they
>
> > > wanted. A very easy change of the code, which makes it much more
>
> > > usable.
>
> >
>
> > Where would these values come from, who (what code) would set them ?
>
> In the PUR module there's the class
> info.magnolia.module.publicuserregistration.frontend.EnableByUuid. I
> created my own version of that, because except enableing the Public
> User, we have to send him a password too. Here I use my
> sendPasswordStrategy:
>
> >
>
> > Cheers,
>
> >
>
> > -g
>
> >
>
> >
>
> > >
>
> > > Happy to apply any patch, if you can see the benefit.
>
> > >
>
> > > Lots of regards, Bert
>
> > >
>
> > >
>
> > >
>
> > > > -----Original Message-----
>
> > > > From: dev-list-owner@... [mailto:dev-list-
>
> > owner@magnolia-
>
> > > > cms.com] On Behalf Of Grégory Joseph
>
> > > > Sent: vrijdag 9 oktober 2009 14:39
>
> > > > To: Magnolia Dev-List
>
> > > > Subject: Re: [magnolia-dev] making PUR module more flexible
>
> > > >
>
> > > >
>
> > > >
>
> > > > On Oct 9, 2009, at 8:48 AM, Bert Leunis wrote:
>
> > > >
>
> > > > >
>
> > > > > Hi Grégory,
>
> > > > >
>
> > > > > Thanks for the effort. Of course I can adapt and override code as
>
> > > > > much as I like. My whole point is, that I like to do more
>
> > > > > configuration instead of coding.
>
> > > >
>
> > > >
>
> > > > That's a valid point, but I still don't see what you're trying to
>
> > > > achieve, concretely.
>
> > > >
>
> > > > > And I hoped my suggestions would lead to a little improvement in
>
> > > > > that direction. But if you don't see the benefit (or I am not
>
> > > clear
>
> > > > > enough about them)
>
> > > >
>
> > > > Most likely the latter; or I'm too thick;)
>
> > > >
>
> > > >
>
> > > > > let's just leave it as it is. You should delete the 2 jira's then
>
> > > > > (MGNLPUR-22 and -23).
>
> > > > >
>
> > > > > Bye, Bert
>
> > > > >
>
> > > > >
>
> > > > >> -----Original Message-----
>
> > > > >> From: dev-list-owner@... [mailto:dev-list-
>
> > > > >> owner@magnolia-
>
> > > > >> cms.com] On Behalf Of Grégory Joseph
>
> > > > >> Sent: donderdag 8 oktober 2009 18:22
>
> > > > >> To: Magnolia Dev-List
>
> > > > >> Subject: Re: [magnolia-dev] making PUR module more flexible
>
> > > > >>
>
> > > > >>
>
> > > > >>
>
> > > > >> On Oct 8, 2009, at 3:05 PM, Bert Leunis wrote:
>
> > > > >>>>> 1. Add a new method to
>
> > > > >>>>> info.magnolia.module.publicuserregistration.strategy.Mail:
>
> > > public
>
> > > > >>>>> void validateRegistration(User user, Map<String, Object>
>
> > > > >>>>> templateValues). This way the process using that class can
>
> > add
>
> > > > >> their
>
> > > > >>>>> templateValues themselves.
>
> > > > >>>>
>
> > > > >>>> It's the UserRegistrar which calls this method; if you need
>
> > > more
>
> > > > >>>> parameters in your mail templates, you probably want to
>
> > > subclass
>
> > > > >>>> i.m.m.pur.strategy.Mail anyway? Where do these parameters come
>
> > > > >>>> from?
>
> > > > >>>> Why would you allow arbitrary parameters to be passed there,
>
> > > > what's
>
> > > > >>>> the actual usecase? (as a side note, if this ends up being
>
> > > really
>
> > > > >>>> necessary, i'd rather change the method than add one)
>
> > > > >>>
>
> > > > >>> You can have extra parameters in your mail template, e.g. $
>
> > > > >>> {generatedPassword}. The EnableByUUID class will send the user
>
> > a
>
> > > > >>> mail with that password, so that class adds all necessary
>
> > > params to
>
> > > > >>> the Map<String, Object>. No need to create your own strategy,
>
> > > all
>
> > > > >>> fields in Mail are oke, all I want is to fill the context with
>
> > > my
>
> > > > >>> own specific values.
>
> > > > >>
>
> > > > >> What is "EnableByUUID" ? An implementation of
>
> > > > >>
>
> > > info.magnolia.module.publicuserregistration.RegistrationStrategy ?
>
> > > > So
>
> > > > >> why can't it add the template values itself in
>
> > > > >> info
>
> > > > >> .magnolia
>
> > > >
>
> > > >> .module.publicuserregistration.strategy.Mail#validateRegistration
>
> > ?
>
> > > > >> (if that's what you're doing, of course we could extract a
>
> > > > >> addTemplateContextValues() in there)
>
> > > > >>
>
> > > > >>
>
> > > > >>>>> 2. When you need an extra strategy, you have to adapt
>
> > > the
>
> > > > >>>>> PublicUserRegistrationConfig class.
>
> > > > >>>>
>
> > > > >>>> Uh? How so? As far as I know, you only need to configure it
>
> > > in /
>
> > > > >>>> modules/pur/config/registrationStrategy or ../
>
> > > > >>>> passwordRetrievalStrategy
>
> > > > >>>>
>
> > > > >>>>> Instead of having a fixed set of 3 strategies, a list of
>
> > > > >>>>> strategies
>
> > > > >>>>> could be present in the config.
>
> > > > >>>>
>
> > > > >>>> Unless i missed something, it's not a fixed set and was indeed
>
> > > > >>>> meant
>
> > > > >>>> so that one can have their custom strategies
>
> > > > >>>>
>
> > > > >>>
>
> > > > >>> My point is: I want to ADD another strategy
>
> > > (sendPasswordStrategy).
>
> > > > >>> The flow I need for my case here is different than the flow
>
> > > that is
>
> > > > >>> now 'dictated' by PUR. As far as I can see, it is a fixed set
>
> > > now.
>
> > > > >>> The class PublicUserRegistrationConfig has two strategies-
>
> > > > >>> properties. If they are stored in a map, I do not have to
>
> > > write any
>
> > > > >>> code, just add some config.
>
> > > > >>>
>
> > > > >>
>
> > > > >> But these 2 strategies are there for different purposes, and are
>
> > > > used
>
> > > > >> in different contexts ! They're different interfaces, too!
>
> > > > Obviously,
>
> > > > >> if you need another functionality (which is...?), you'll need to
>
> > > > code
>
> > > > >> stuff; which could be in a different module.
>
> > > > >>
>
> > > > >>
>
> > > > >>
>
> > > > >>>
>
> > > > >>>>> Probably a module class has to be created that loads the
>
> > > > >>>>> strategies
>
> > > > >>>>> in a Map<String, Strategy>. From the module instance the
>
> > > strategy
>
> > > > >>>>> can then be retrieved by name. (I created a
>
> > > > sendPasswordStrategy).
>
> > > > >>>>
>
> > > > >>>> I'm not sure what you mean, but then again, see above
>
> > comments.
>
> > > > >>>
>
> > > > >>> I don't think the content2bean utils will convert a list of
>
> > > > >>> strategies in a Map<String, Strategy> automatically. That can
>
> > be
>
> > > > >>> done in the module class (like it is done in the DataModule).
>
> > > > >>
>
> > > > >> Actually, content2bean will convert that, but I don't see the
>
> > > > >> usecase.
>
> > > > >> PUR provides two hooks: RegistrationStrategy(validation of a
>
> > > user's
>
> > > > >> registration - customize if you want to prevent users to
>
> > register
>
> > > > >> on a
>
> > > > >> sunday), and PasswordRetrievalStrategy (determines how users can
>
> > > > >> retrieve their password - or have it changed).
>
> > > > >>
>
> > > > >> Both interfaces can be swapped in configuration, so you can use
>
> > > your
>
> > > > >> own implementations. We currently have a single impl for
>
> > > > >> PasswordRetrievalStrategy, and 3 for RegistrationStrategy.
>
> > > > >>
>
> > > > >> If you use your IDE to search for usages of these interfaces,
>
> > > you'll
>
> > > > >> see they're used in totally different contexts. They're not "a"
>
> > > > >> strategy. They're just two different pluggable components
>
> > > provided
>
> > > > by
>
> > > > >> this module. I'm tempted to rename these interfaces to
>
> > > > >> PasswordRetrieval and RegistrationValidation if it's so
>
> > > confusing.
>
> > > > >>
>
> > > > >> hth,
>
> > > > >>
>
> > > > >> -g
>
> > > > >>
>
> > > > >>
>
> > > > >> ----------------------------------------------------------------
>
> > > > >> For list details see
>
> > > > >> http://www.magnolia-cms.com/home/community/mailing-lists.html
>
> > > > >> To unsubscribe, E-mail to: <dev-list-unsubscribe@magnolia-
>
> > > cms.com>
>
> > > > >> ----------------------------------------------------------------
>
> > > > >
>
> > > > >
>
> > > > > ----------------------------------------------------------------
>
> > > > > For list details see
>
> > > > > http://www.magnolia-cms.com/home/community/mailing-lists.html
>
> > > > > To unsubscribe, E-mail to: <dev-list-unsubscribe@magnolia-
>
> > cms.com>
>
> > > > > ----------------------------------------------------------------
>
> > > >
>
> > > >
>
> > > > ----------------------------------------------------------------
>
> > > > For list details see
>
> > > > http://www.magnolia-cms.com/home/community/mailing-lists.html
>
> > > > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
>
> > > > ----------------------------------------------------------------
>
> > >
>
> > >
>
> > >
>
> > > ----------------------------------------------------------------
>
> > > For list details see
>
> > > http://www.magnolia-cms.com/home/community/mailing-lists.html
>
> > > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
>
> > > ----------------------------------------------------------------
>
> >
>
> >
>
> > ----------------------------------------------------------------
>
> > For list details see
>
> > http://www.magnolia-cms.com/home/community/mailing-lists.html
>
> > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
>
> > ----------------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> ----------------------------------------------------------------

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[Bert Leunis]

Thanks for your input Ruben.

Of course it is very well possible to write custom code to satisfy your own needs. My main point here is that I do NOT want to do that. With the changes suggested it should be possible to write less code yourself.

Bert

> -----Original Message-----
> From: dev-list-owner@... [mailto:dev-list-owner@magnolia-
> cms.com] On Behalf Of Ruben Reusser
> Sent: maandag 9 november 2009 16:00
> To: Magnolia Dev-List
> Subject: Re: [magnolia-dev] making PUR module more flexible
>
>
> Just on a side note - instead of using the whole magnolia PUR process
> to
> register users, we opted for our own process outside of PUR and then
> just use some callbacks into PUR to create the account. That made the
> whole process a bit easier, allowes us to log users in with
> username/password or email address/password, etc. Works nice and makes
> it way more customizable.
>
> Ruben
>
> Bert Leunis wrote:
> >
> > Thanks Grégory! See my answers below. If you can see any advantage in
> > my idea's I'm happy to help with some code, but if not, no problem
> > either. We would spend too much time on a matter that is not
> > interesting for you.
> >
> > Regards, Bert
> >
> > > -----Original Message-----
> >
> > > From: dev-list-owner@... [mailto:dev-list-
> owner@magnolia-
> >
> > > cms.com] On Behalf Of Grégory Joseph
> >
> > > Sent: vrijdag 6 november 2009 16:16
> >
> > > To: Magnolia Dev-List
> >
> > > Subject: Re: [magnolia-dev] making PUR module more flexible
> >
> > >
> >
> > >
> >
> > > Hi Bert,
> >
> > >
> >
> > > Thanks for the taking the time to write this! Now I think I
> understand
> >
> > > your requests! ;)
> >
> > >
> >
> > > On Nov 6, 2009, at 10:40 AM, Bert Leunis wrote:
> >
> > >
> >
> > > > Hello Grégory (and others),
> >
> > > >
> >
> > > > I will give it one more go to see if I can get my points across!
> >
> > > >
> >
> > > > Our client will use PUR in a slightly different way than the
> >
> > > > standard scenario that PUR presumes/implies. When adapting the
> >
> > > > different scenario I saw two points in the code that can make PUR
> >
> > > > more flexible quite easily. With more flexible I mean: it does
> not
> >
> > > > hinder the standard scenario but it helps you when your scenario
> is
> >
> > > > different (like mine).
> >
> > > >
> >
> > > > This is the new scenario we use:
> >
> > > >
> >
> > > > 1. The webeditor will register the Public User, it wil not be the
> >
> > > > User itself. (a Public User is created, and a node in the
> datamodule
> >
> > > > to store the users data).
> >
> > > > 2. The User gets an e-mail with its user name and a validation
> link.
> >
> > > > 3. The User clicks on the link to validate himself. (The Public
> User
> >
> > > > is enabled).
> >
> > > > 4. The User gets an e-mail with a generated password and a link
> to
> >
> > > > the login page.
> >
> > >
> >
> > > In your scenario, is the "self registration" *also* needed?
> >
> > No, the users in our case will never register themselves. To keep
> them
> > in a specific group as Public Users soots us very much, as well as
> the
> > 'forgot your password' service.
> >
> > >
> >
> > > > I need some changes in PUR to make this possible. Next to the
> >
> > > > registrationStrategy and the passwordRetrievalStrategy I need a
> new
> >
> > > > sendPasswordStrategy. I can store that at config/modules/public-
> user-
> >
> > > > registration/config next to the other two, no problem at all.
> But,
> >
> > > > if I want to retrieve that strategy in my code, I cannot use the
> >
> > > > info
> >
> > > > .magnolia
> >
> > > > .module.publicuserregistration.PublicUserRegistrationConfig,
> because
> >
> > > > it doesn't have a private field and getters/setters to store my
> new
> >
> > > > strategy. Now I need to change the code of that class. And here
> is
> >
> > > > my proposal: if all strategies were stored in the config and in
> the
> >
> > > > PublicUserRegistrationConfig class in a list or Map, then
> everybody
> >
> > > > who wants to add strategies of their own can add them, without
> >
> > > > having to change the code. Config instead of coding. See the
> picture
> >
> > > > to get my idea:
> >
> > > >
> >
> > > > <image002.jpg>
> >
> > > > You would get the strategy you want by its name.
> >
> > >
> >
> > > They're different interfaces with different use-cases; if multiple
> >
> > > implementations of either are needed, we could imagine something
> like
> >
> > > this but with a map for each (i.e they're not "two strategies" they
> >
> > > are "one PasswordRetrievalStrategy" (impl of the mechanism for
> users
> >
> > > to retrieve their passwords) and "one RegistrationStrategy" (impl
> of
> >
> > > the mechanism used to register and validate users)
> >
> > I see. To me their all 'actions to perform in regard to the Public
> > User', and as such can be grouped together.
> >
> > >
> >
> > > > Second idea comes from the wish to send a slightly different e-
> mail
> >
> > > > than the ones that are used in a standard situation. The class
> >
> > > > info.magnolia.module.publicuserregistration.strategy.Mail is used
> to
> >
> > > > send the e-mail. This class has all the properties you need to
> send
> >
> > > > an e-mail (fromName, fromEmail, subject, emailTemplate etc).
> >
> > > > Unfortunately, in the emailTemplate you can only use one
> variable,
> >
> > > > which is "pagePath". The method validateRegistration(User user)
> sets
> >
> > > > only that one variable. Now, if there was an extra method with
> this
> >
> > > > signature: public void validateRegistration(User user,
> Map<String,
> >
> > > > Object> templateValues), then every strategy wanting to send e-
> mails
> >
> > > > to the Public User would be able to apply all the variables they
> >
> > > > wanted. A very easy change of the code, which makes it much more
> >
> > > > usable.
> >
> > >
> >
> > > Where would these values come from, who (what code) would set them
> ?
> >
> > In the PUR module there's the class
> > info.magnolia.module.publicuserregistration.frontend.EnableByUuid. I
> > created my own version of that, because except enableing the Public
> > User, we have to send him a password too. Here I use my
> > sendPasswordStrategy:
> >
> > >
> >
> > > Cheers,
> >
> > >
> >
> > > -g
> >
> > >
> >
> > >
> >
> > > >
> >
> > > > Happy to apply any patch, if you can see the benefit.
> >
> > > >
> >
> > > > Lots of regards, Bert
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > > -----Original Message-----
> >
> > > > > From: dev-list-owner@... [mailto:dev-list-
> >
> > > owner@magnolia-
> >
> > > > > cms.com] On Behalf Of Grégory Joseph
> >
> > > > > Sent: vrijdag 9 oktober 2009 14:39
> >
> > > > > To: Magnolia Dev-List
> >
> > > > > Subject: Re: [magnolia-dev] making PUR module more flexible
> >
> > > > >
> >
> > > > >
> >
> > > > >
> >
> > > > > On Oct 9, 2009, at 8:48 AM, Bert Leunis wrote:
> >
> > > > >
> >
> > > > > >
> >
> > > > > > Hi Grégory,
> >
> > > > > >
> >
> > > > > > Thanks for the effort. Of course I can adapt and override
> code as
> >
> > > > > > much as I like. My whole point is, that I like to do more
> >
> > > > > > configuration instead of coding.
> >
> > > > >
> >
> > > > >
> >
> > > > > That's a valid point, but I still don't see what you're trying
> to
> >
> > > > > achieve, concretely.
> >
> > > > >
> >
> > > > > > And I hoped my suggestions would lead to a little improvement
> in
> >
> > > > > > that direction. But if you don't see the benefit (or I am not
> >
> > > > clear
> >
> > > > > > enough about them)
> >
> > > > >
> >
> > > > > Most likely the latter; or I'm too thick;)
> >
> > > > >
> >
> > > > >
> >
> > > > > > let's just leave it as it is. You should delete the 2 jira's
> then
> >
> > > > > > (MGNLPUR-22 and -23).
> >
> > > > > >
> >
> > > > > > Bye, Bert
> >
> > > > > >
> >
> > > > > >
> >
> > > > > >> -----Original Message-----
> >
> > > > > >> From: dev-list-owner@... [mailto:dev-list-
> >
> > > > > >> owner@magnolia-
> >
> > > > > >> cms.com] On Behalf Of Grégory Joseph
> >
> > > > > >> Sent: donderdag 8 oktober 2009 18:22
> >
> > > > > >> To: Magnolia Dev-List
> >
> > > > > >> Subject: Re: [magnolia-dev] making PUR module more flexible
> >
> > > > > >>
> >
> > > > > >>
> >
> > > > > >>
> >
> > > > > >> On Oct 8, 2009, at 3:05 PM, Bert Leunis wrote:
> >
> > > > > >>>>> 1. Add a new method to
> >
> > > > > >>>>>
> info.magnolia.module.publicuserregistration.strategy.Mail:
> >
> > > > public
> >
> > > > > >>>>> void validateRegistration(User user, Map<String, Object>
> >
> > > > > >>>>> templateValues). This way the process using that class
> can
> >
> > > add
> >
> > > > > >> their
> >
> > > > > >>>>> templateValues themselves.
> >
> > > > > >>>>
> >
> > > > > >>>> It's the UserRegistrar which calls this method; if you
> need
> >
> > > > more
> >
> > > > > >>>> parameters in your mail templates, you probably want to
> >
> > > > subclass
> >
> > > > > >>>> i.m.m.pur.strategy.Mail anyway? Where do these parameters
> come
> >
> > > > > >>>> from?
> >
> > > > > >>>> Why would you allow arbitrary parameters to be passed
> there,
> >
> > > > > what's
> >
> > > > > >>>> the actual usecase? (as a side note, if this ends up being
> >
> > > > really
> >
> > > > > >>>> necessary, i'd rather change the method than add one)
> >
> > > > > >>>
> >
> > > > > >>> You can have extra parameters in your mail template, e.g. $
> >
> > > > > >>> {generatedPassword}. The EnableByUUID class will send the
> user
> >
> > > a
> >
> > > > > >>> mail with that password, so that class adds all necessary
> >
> > > > params to
> >
> > > > > >>> the Map<String, Object>. No need to create your own
> strategy,
> >
> > > > all
> >
> > > > > >>> fields in Mail are oke, all I want is to fill the context
> with
> >
> > > > my
> >
> > > > > >>> own specific values.
> >
> > > > > >>
> >
> > > > > >> What is "EnableByUUID" ? An implementation of
> >
> > > > > >>
> >
> > > > info.magnolia.module.publicuserregistration.RegistrationStrategy
> ?
> >
> > > > > So
> >
> > > > > >> why can't it add the template values itself in
> >
> > > > > >> info
> >
> > > > > >> .magnolia
> >
> > > > >
> >
> > > > >>
> .module.publicuserregistration.strategy.Mail#validateRegistration
> >
> > > ?
> >
> > > > > >> (if that's what you're doing, of course we could extract a
> >
> > > > > >> addTemplateContextValues() in there)
> >
> > > > > >>
> >
> > > > > >>
> >
> > > > > >>>>> 2. When you need an extra strategy, you have to adapt
> >
> > > > the
> >
> > > > > >>>>> PublicUserRegistrationConfig class.
> >
> > > > > >>>>
> >
> > > > > >>>> Uh? How so? As far as I know, you only need to configure
> it
> >
> > > > in /
> >
> > > > > >>>> modules/pur/config/registrationStrategy or ../
> >
> > > > > >>>> passwordRetrievalStrategy
> >
> > > > > >>>>
> >
> > > > > >>>>> Instead of having a fixed set of 3 strategies, a list of
> >
> > > > > >>>>> strategies
> >
> > > > > >>>>> could be present in the config.
> >
> > > > > >>>>
> >
> > > > > >>>> Unless i missed something, it's not a fixed set and was
> indeed
> >
> > > > > >>>> meant
> >
> > > > > >>>> so that one can have their custom strategies
> >
> > > > > >>>>
> >
> > > > > >>>
> >
> > > > > >>> My point is: I want to ADD another strategy
> >
> > > > (sendPasswordStrategy).
> >
> > > > > >>> The flow I need for my case here is different than the flow
> >
> > > > that is
> >
> > > > > >>> now 'dictated' by PUR. As far as I can see, it is a fixed
> set
> >
> > > > now.
> >
> > > > > >>> The class PublicUserRegistrationConfig has two strategies-
> >
> > > > > >>> properties. If they are stored in a map, I do not have to
> >
> > > > write any
> >
> > > > > >>> code, just add some config.
> >
> > > > > >>>
> >
> > > > > >>
> >
> > > > > >> But these 2 strategies are there for different purposes, and
> are
> >
> > > > > used
> >
> > > > > >> in different contexts ! They're different interfaces, too!
> >
> > > > > Obviously,
> >
> > > > > >> if you need another functionality (which is...?), you'll
> need to
> >
> > > > > code
> >
> > > > > >> stuff; which could be in a different module.
> >
> > > > > >>
> >
> > > > > >>
> >
> > > > > >>
> >
> > > > > >>>
> >
> > > > > >>>>> Probably a module class has to be created that loads the
> >
> > > > > >>>>> strategies
> >
> > > > > >>>>> in a Map<String, Strategy>. From the module instance the
> >
> > > > strategy
> >
> > > > > >>>>> can then be retrieved by name. (I created a
> >
> > > > > sendPasswordStrategy).
> >
> > > > > >>>>
> >
> > > > > >>>> I'm not sure what you mean, but then again, see above
> >
> > > comments.
> >
> > > > > >>>
> >
> > > > > >>> I don't think the content2bean utils will convert a list of
> >
> > > > > >>> strategies in a Map<String, Strategy> automatically. That
> can
> >
> > > be
> >
> > > > > >>> done in the module class (like it is done in the
> DataModule).
> >
> > > > > >>
> >
> > > > > >> Actually, content2bean will convert that, but I don't see
> the
> >
> > > > > >> usecase.
> >
> > > > > >> PUR provides two hooks: RegistrationStrategy(validation of a
> >
> > > > user's
> >
> > > > > >> registration - customize if you want to prevent users to
> >
> > > register
> >
> > > > > >> on a
> >
> > > > > >> sunday), and PasswordRetrievalStrategy (determines how users
> can
> >
> > > > > >> retrieve their password - or have it changed).
> >
> > > > > >>
> >
> > > > > >> Both interfaces can be swapped in configuration, so you can
> use
> >
> > > > your
> >
> > > > > >> own implementations. We currently have a single impl for
> >
> > > > > >> PasswordRetrievalStrategy, and 3 for RegistrationStrategy.
> >
> > > > > >>
> >
> > > > > >> If you use your IDE to search for usages of these
> interfaces,
> >
> > > > you'll
> >
> > > > > >> see they're used in totally different contexts. They're not
> "a"
> >
> > > > > >> strategy. They're just two different pluggable components
> >
> > > > provided
> >
> > > > > by
> >
> > > > > >> this module. I'm tempted to rename these interfaces to
> >
> > > > > >> PasswordRetrieval and RegistrationValidation if it's so
> >
> > > > confusing.
> >
> > > > > >>
> >
> > > > > >> hth,
> >
> > > > > >>
> >
> > > > > >> -g
> >
> > > > > >>
> >
> > > > > >>
> >
> > > > > >> ------------------------------------------------------------
> ----
> >
> > > > > >> For list details see
> >
> > > > > >> http://www.magnolia-cms.com/home/community/mailing-
> lists.html
> >
> > > > > >> To unsubscribe, E-mail to: <dev-list-unsubscribe@magnolia-
> >
> > > > cms.com>
> >
> > > > > >> ------------------------------------------------------------
> ----
> >
> > > > > >
> >
> > > > > >
> >
> > > > > > -------------------------------------------------------------
> ---
> >
> > > > > > For list details see
> >
> > > > > > http://www.magnolia-cms.com/home/community/mailing-lists.html
> >
> > > > > > To unsubscribe, E-mail to: <dev-list-unsubscribe@magnolia-
> >
> > > cms.com>
> >
> > > > > > -------------------------------------------------------------
> ---
> >
> > > > >
> >
> > > > >
> >
> > > > > ---------------------------------------------------------------
> -
> >
> > > > > For list details see
> >
> > > > > http://www.magnolia-cms.com/home/community/mailing-lists.html
> >
> > > > > To unsubscribe, E-mail to: <dev-list-unsubscribe@magnolia-
> cms.com>
> >
> > > > > ---------------------------------------------------------------
> -
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > ----------------------------------------------------------------
> >
> > > > For list details see
> >
> > > > http://www.magnolia-cms.com/home/community/mailing-lists.html
> >
> > > > To unsubscribe, E-mail to: <dev-list-unsubscribe@magnolia-
> cms.com>
> >
> > > > ----------------------------------------------------------------
> >
> > >
> >
> > >
> >
> > > ----------------------------------------------------------------
> >
> > > For list details see
> >
> > > http://www.magnolia-cms.com/home/community/mailing-lists.html
> >
> > > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> >
> > > ----------------------------------------------------------------
> >
> >
> >
> > ---------------------------------------------------------------------
> ---
> > ----------------------------------------------------------------
> > For list details see
> > http://www.magnolia-cms.com/home/community/mailing-lists.html
> > To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> > ----------------------------------------------------------------
>
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
> ----------------------------------------------------------------

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[Erik Alphenaar]

Good afternoon,

We have been experimenting with all kinds of Spring integration in the
past, to enable a seamless integration between Magnolia and external
services.

By seamless I mean that I can use the Magnolia Module structure to
expose any Spring services/beans it may have, and use those services in,
for example, ParagraphRenderers etc. without the services having to know
anything of Magnolia.


We have actually created a nice integration as such.






----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[Erik Alphenaar]

That was the wrong button, accidentally sent my message :) .

To finalize my text:

I was recently looking into the Blossom project, which seems to use the
ContextLoaderServlet which is deprecated, and even gone in Spring 3.

We have created a module that takes advantage of the ContextListener.
Magnolia modules that have a Spring context, can configure this in their
config node in the Magnolia Admincentral. Even Spring beans can be
configured in the config node. This may be useful for properties that
this service may need, like smtp server host, Solr server url, or some
remote invocation URL, etc, etc. By using default Spring functionality
the Services are injected into the Magnolia module

The configuration of the contexts and beans are observed by our Spring
module. The module then loads all of these contexts and beans in the
root Spring WebContext. So, after a config change, the context is
updated runtime (no restart needed) !!

In this way the configured context is available for every component that
has access to the webContext.

For example: we are using the
org.springframework.web.servlet.DispatcherServlet
in /server/filters/servlets to host some Spring RESTful services. These
controllers can have direct access to this context in this way.

In my opinion, this module would be a great base-integration of Spring
contexts and configurable Spring beans, that other modules can use.



Best regards,

Erik Alphenaar,
Net Effect Holding B.V.


On Tue, 2009-11-10 at 17:13 +0100, Erik Alphenaar wrote:

> Good afternoon,
>
> We have been experimenting with all kinds of Spring integration in the
> past, to enable a seamless integration between Magnolia and external
> services.
>
> By seamless I mean that I can use the Magnolia Module structure to
> expose any Spring services/beans it may have, and use those services in,
> for example, ParagraphRenderers etc. without the services having to know
> anything of Magnolia.
>
>
> We have actually created a nice integration as such.
>
>
>
>

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------