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: [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]> ----------------------------------------------------------------
