From: "Ruben Reusser" <user-list@magnolia.info>
Received: from headwire.com ([24.249.242.56] verified)
  by mail.obinary.com (CommuniGate Pro SMTP 5.1.10)
  with ESMTP id 14577955 for user-list@magnolia.info; Wed, 23 Jul 2008 07:35:42 +0200
Received: from [192.168.42.103] (account rr HELO [10.0.0.2])
  by headwire.com (CommuniGate Pro SMTP 3.4.5)
  with ESMTP id 2793622 for user-list@magnolia.info; Tue, 22 Jul 2008 22:41:54 -0700
Message-ID: <4886C32B.3070005@headwire.com>
Date: Tue, 22 Jul 2008 22:35:39 -0700
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: user-list@magnolia.info
Subject: Re: [magnolia-user] PUR for multi domain setup
References: <list-14577850@mail.obinary.com>
In-Reply-To: <list-14577850@mail.obinary.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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