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: [email protected] [mailto:dev-list-ow...@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: [email protected] [mailto:dev-list-
> ow...@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: [email protected] [mailto:dev-list-
> > > >> ow...@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-unsubscr...@magnolia-
> > cms.com>
> > > >> ----------------------------------------------------------------
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > > > For list details see
> > > > http://www.magnolia-cms.com/home/community/mailing-lists.html
> > > > To unsubscribe, E-mail to: <dev-list-unsubscr...@magnolia-
> cms.com>
> > > > ----------------------------------------------------------------
> > >
> > >
> > > ----------------------------------------------------------------
> > > For list details see
> > > http://www.magnolia-cms.com/home/community/mailing-lists.html
> > > To unsubscribe, E-mail to: <[email protected]>
> > > ----------------------------------------------------------------
> >
> >
> >
> > ----------------------------------------------------------------
> > For list details see
> > http://www.magnolia-cms.com/home/community/mailing-lists.html
> > To unsubscribe, E-mail to: <[email protected]>
> > ----------------------------------------------------------------
>
>
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <[email protected]>
> ----------------------------------------------------------------
------------------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
