On Mar 23, 2006, at 11:02 AM, Henning Kulander wrote:
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).
I was not necessarily suggesting you use email address. I was
referring to the general idea of encoding domain in the username to
allow users with the same username in different domains.
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.
Can you explain a little more why you feel it necessary to extend
PageServlet? If its sole purpose is to pass domain to the business
logic tier I think using Filter/ThreadLocal approach would be much
cleaner.
This seems to work, but the links on the page all go
back to the original roller website in /page/mywebsitehandle
You make a good point here. What we could do here is to modify
PageModel view helper class (or extend it) so that current 'domain'
value is available to Velocity templates. That class is actually a
well-known extension point in Roller configurable via
roller.properties so that should be pretty easy to extend. I guess
that means we would also have to go through Velocity macros to format
URLs using domain value (if it's not empty, of course). Not sure the
extend of that effort.
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.
How do you see them being used though? In order for Roller to use a
POJO subclass, for example, you would have to modify a ton of code in
Manager classes.
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.
We did not have this requirement but I could see how it would be
useful. This definitely complicates things as we now also need a way
to map a domain handle to the physical blog handle. Could we maybe
write a custom URL rewriting filter which could do the mapping based
on a database lookup? I just hate messing with Roller presentation
code and think we should avoid that as much as possible.
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?
Well, we didn't want to touch the original codebase so we had to copy
over some code (like SearchServlet) because the methods we needed to
override were private. But, essentially, yes, that's how we did it.
Basically, it's just the matter of adding domain property associated
with each entry to Lucene s and appending it to queries behind the
scenes when a search is performed.
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.
My only problem with this is that you are requiring users to
explicitly choose which domains their blogs should appear on. This
may not always be desirable and in some cases forbidden. For example,
an ASP hosting blogs for multiple clients where you certainly don't
want any kind of cross-domain publishing and users in different
domains should be able to create websites with the same handle. For
this reason, I still think it might be better to have "owner" domain
assigned to each weblog and use an association table to "publish"
that weblog to a different domain under potentially different handle.
Max
