On Tue, 2006-03-21 at 17:42 -0500, Max Rudman wrote:
> Answers/comments below....
> 
> On Mar 21, 2006, at 7:45 AM, Henning Kulander wrote:
> 
> >  In the final version, we
> > imagine a system where a user can register on one domain, using his
> > email as username, and the system will automatically see that this  
> > user
> > is registered in the central Roller-system.
> 
> Well, if you are using email address as username you are in essence  
> encoding domain in the username (the part after @). It's not domain  
> in DNS sense but same idea. I think that will work just fine, BTW.  
> Again, we did this work on Roller 1.x where there was no handle --  
> username was it.

Well, the email here cannot be used to map to a specific domain, as the
email will be an existing address, not necessarily related to the blog
domain (for example an existing gmail.com address). 

> > So my suggestion here is to keep the existing handle in website,  
> > and add
> > a domain-handle in the association table between domain and website
> > (domainwebsite). So when a user request /page/handle, the handle in
> > website is used, when the user requests /page/domain/handle, the  
> > handle
> > in domainwebsite is used,
> 
> How would this actually work without touching Roller presentation  
> code? If I understand you correctly, '/domain/handle' is a virtual  
> URL which would be rewritten to /page/<handle> format. Having handle  
> spread across two tables would seem to complicate things as we'd have  
> to modify several methods in UserManager to pull it together. I think  
> easier options are to:

You're right, in my design, we will need a different presentation mode
that is aware of the domain model. I have experimented with making a
DomainPageServlet as a subclass of PageServlet, and make this answer
to /domain/page, and then having /mydomain/myhandle as a key to finding
the right website. This seems to work, but the links on the page all go
back to the original roller website in /page/mywebsitehandle 

The changes I have made this far does not affect the way Roller works
per default, I have only added new classes (DomainData,
DomainWebsiteData and DomainUserData) and subclasses for PageServlet and
RollerRequest. 

> 1) Prepend domain to website handles, so it becomes something like  
> "domain + <separator> + handle". Set up URL rewrite rule to redirect / 
> domain/handle to /page/domain + <separator> + handle. The down side  
> is we'd have to "decode" the handle everywhere it appears in the UI  
> -- website edit form, URL links, etc.
> 
> 2) Add new, nullable property to WebsiteData to keep track of domain.  
> All we have to do then is override UserManager.getWebsiteByHandle 
> (String,boolean) to (optionally) add 'domain' to the query and  
> UserManager.createWebsite() to assign domain on creation.
> 
> In both cases, I see 'domain' being extracted from URL and/or request  
> parameter and/or session attribute by a filter and stashed in a  
> ThreadLocal variable for use by code down the call stack such as  
> UserManager.

The problem I se with this approach is that it is not possible to have
the same website available on more than one domain, this is a feature we
will need. One blogger must be able to write an entry in one blog, and
have that entry appear on several domains, and maybe even with different
handles on different domains. So page/theboss is the same blog as
domain/page/blog.domain1.no/sjefblogg and
domain/page/blog.domain2.com/companyleader. 

> > I had completely forgotten this. Did you solve this in your version?
> > This would probably be much the same now, wouldn't it?
> 
> We had to overwrite a few search-related classes. However, if we add  
> 'domain' property to WebsiteData it should be literally a matter of  
> adding a new constant to SearchConstants and a few lines to a couple  
> of XXXOperation classes.

Was this how you solved this problem the last time?

> > Excellent! Do you have any idea how much of your existing code we  
> > could
> > reuse? Did you make administration interfaces for this as well?  What
> > about documentation, do you have anything we could take a peek at?
> 
> Probably not much as it was written to Roller 1.x codebase which is  
> fairly different. In terms of admin interface, do you mean something  
> to manage domains? My job was to integrate Roller into the existing  
> platform which already had UI to manage domains. So, no, I didn't  
> have anything. In terms of documentation, let me talk to my client  
> and see what they feel comfortable disclosing.

OK. The way I see it, we will need the following new administration
interfaces:
1. An interface where the Roller-administrator can enable/dissable
domain support, and add/remove domains and set administrators for the
domains.
2. An interface where a domain-administrator can add users and websites
to a domain and set which themes should be available etc. 
3. An interface where a user can select on what domains one of his
websites should be available. The user should also be able to select
theme, handle and maybe some other settings per domain. 
4. An interface where a domain-administrator can add subscriptions to a
domain planet. 


-- 
Regards,
Henning Kulander
System consultant
Linpro AS - Norway's #1 Linux company

Reply via email to