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: [cid:[email protected]] 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: [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: <[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]> ----------------------------------------------------------------
<<inline: image002.jpg>>
