Yeah, that is a similar approach we've taken for the new cache
configuration - you can have multiple cache configs, and the cache
filter is configured to use the appropriate one.
But you'll have to think about handling of duplicates etc. What if the
*same person* wants to register on siteX and siteY, how do you handle
that ? (because as it, it will just be rejected, saying this user
already exists, while what you want is probably add some roles or
groups to it)
Also: defaultBaseUrl is what it says it is - if you add this in public-
user-registration config it, you'll have to rename it. But at that
point, you'll probably want different emails anyway, so you could just
as well hardcode it in the email.
-g
On Jul 23, 2008, at 7:02 AM, 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/
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/
----------------------------------------------------------------
