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