Well, that's not a bad idea. The "PublicUserRegistrationConfig"
contains all the config values. It seems like these values are filled
in at startup - I have not found the exact class / bit of code that is
actually doing this however. If the config structure would be changed
as you proposed, the PublicUserRegistrationConfig would then contain
the config values for all sites, e.g.
- config
- defaultRoles
- defaultGroups
- registrationStrategy
- passwordRetrievalStrategy
- realmName
- userProfileClasse
- defaultBaseUrl
- sites
- siteX
- defaultBaseUrl
- realmName
- siteY
- defaultBaseUrl
- registrationStrategy
- defaultRoles
- and so on...
Would that be a better approach?
will
On 23.07.2008, at 07:35, Ruben Reusser wrote:
wouldn't you want to have siteX underneath default to be able to use
parent inheritance for the properties?
Ruben
Will Scheidegger wrote:
A few days ago I have created an issue in the jira, because PUR
only works for one single domain, configured at config:/server/
defaultBaseUrl.
http://jira.magnolia.info/browse/MGNLPUR-17
In this issue, I suggested getting the base url from the request. I
thought about this the last few days and it would be a pain
forwarding the request object all the way to the mail class which
actually sends out the mails. On top, it's not only the base url
that is limiting the versatility of PUR. On could easily think of
situations where you would like to have different strategies and
most of all different templates, senders etc. used for each domain/
site. In addition, Gregory points out correctly, that sometimes you
don't have a request object or the info in the request object is
not useful.
But what if we would extend the configuration to incorporate sites?
I was thinking about a structure like this:
- /modules/public-user-registration/config
- sites
- default
- defaultRoles
- defaultGroups
- registrationStrategy
- passwordRetrievalStrategy
- realmName
- userProfileClasse
- defaultBaseUrl
- siteX
- defaultRoles
- defaultGroups
- registrationStrategy
- ...
- siteY - defaultRoles
- defaultGroups
- ...
And so on.
Then, when calling a page for registration, password retrieval or
whatever, either a site-specific configuration or the default
configuration will be used, depending on the page class being
called or on parameters being passed in.
What do you think: Could this work and be a valuable extension to
PUR? (Second opinions are always a plus.)
If you think that I'm not proposing anything stupid, I could try to
implement this extension.
will
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/
----------------------------------------------------------------
--
=================================================================
java consulting - swing, web UI, hibernate, cms, magnolia, jcr
flash consulting - openlaszlo, flex
headwire.com, inc ++1 949 595 4365
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/
----------------------------------------------------------------
