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: [email protected] [mailto:dev-list-ow...@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: [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: <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]> ----------------------------------------------------------------
