Hi david! I have answered your questions below.
On Wed, 2006-04-05 at 08:51 -0400, David M Johnson wrote: > > So now I have a version of Roller where roller is running under tomcat > > on port 8080, if I access localhost:8080/roller/, I get the old > > functionality, nothing is changed (in theory at least). In front of > > tomcat I have an apache-server with mod_rewrite. Apache is > > listening to > > a virtual domain (blog.testdomain.com), and translating URLs to this > > domain into the form > > localhost/roller/domain/(service)blog.testdomain.com/(handle). So > > blog.testdomain.com/page/testblog would is tranlated to > > localhost/roller/domain/page/blog.testdomain.com/testblog. > > Do users ever see the localhost/roller/domain/(service) > blog.testdomain.com/(handle) form of URL or is that hidden? No, this form is hidden from the user using UrlRewriteFilter, so the user sees blog.testdomain.com/handle instead of the long domain-form. This is of course a requirement, as the long form would be incredibly ugly.. :) > > So far, there has been little need to change existing Roller-code. > > I had > > to create a DomainManager to handle the new database tables and their > > pojo-implementations. The DomainManager needed to be added to > > RollerManager so it can be used like the other managers, and that's > > about it actually. But unfortunately the URLs generated throughout > > Roller are never sent through encodeURL, so they are not picked up by > > the wrappers. This resulted in quite a few changes in velocity macros. > > All these changes consists in sending the URL through > > pageHelper.strutsUrlHelper(). This in turn calls the encodeURL > > method in > > the wrapper. In addition, SearchServlet and *WeblogCalendarModel > > needed > > to be changed. SearchServlet needs to use another context > > initializer so > > the pageHelper object is available in the velocity scripts, > > WeblogCalendarModel needs to call encodeURL on the URLs they create. > > This enables all URLs to be rewritten to the > > form /roller/domain/(service)/(domain)/(handle) on the way out, so the > > user still thinks he is on the domain. In addition, these changes > > enables the use of UrlRewriteFilter in Roller, so you can do whatever > > magic this can do. I use UrlRewriteFilter to rewrite > > the /roller/domain/(service)/(domain)(handle) URLs to the more user > > friendly form of http://(domain)/(service)/(handle). > > Why do you need URLs to pass through encodeURL? Is that the "hook" > you use to transform URLs? Yes, the only way I have found to do URL-translation is to use encodeURL, this seems to be a standard way, and it is what UrlRewriteFilter uses. The problem with translation is that you need to know what's a URL, and what's not a URL. You could parse the generated HTML and try to figure it out, but it's a lot cleaner to call encodeURL and just override that method. > Now that you are calling encodeURL for all URLs, are you seeing a > jsessionid on every URL created by Roller? Nope, just on some of them. I haven't seen anything that leads me to think that it appears more or less often than before. Doing a quick check on a rendered page here only shows this on the login link... > > What doesn't work? > > Everything domain specific except the features listed above. > > - Logging in sends the user to the global roller domain (ie. / > > roller/*) > > - There is no way to add domains, add websites to a domain except > > hacking directly in (my)SQL. > > > > What next? > > The features we have now is the bare minimum needed to present > > blogs to > > web surfers and have them believe that they are browsing different > > domains when they are actually only browsing on one server. This is > > useful to us in it self, but we also need a way to configure this > > without hacking the database directly, and we need a way to let the > > user > > log in on one domain, and administer his websites on that domain. The > > most important thing here is the ability to edit and write entries. > > > > So that leaves these priorities. > > - Adding a user interface where the administrator can add domains, and > > put websites into different domains. > > - Figure out how to enable login on one domain, and not redirect the > > user to the global roller domain. > > - At a minimum, enable editing and creation of entries on a domain. > > - Enable domain wide search. > > > > We are still very interested in getting these changes upstream > > eventually, and we are working hard not to break existing > > functionality > > or add complexity. We are thankful for the feedback we have got so > > far. > > > > If anybody is interested, I can make my patches available. We are > > currently working on Roller 2.1 stable. Once 2.2 is available we will > > upgrade our patches to 2.2. > > > How are you managing the new code you've added? Are you using he > custom/*.xmlf mechanism or just adding new code into the Roller > source tree? This far I have added things in the source tree, and made the above mentioned changes in the existing files. If you have any suggestions on how to do things otherwise, I am willing to consider other ways of doing it. What's the story behind the custom/*xmlf mechanism? -- Regards, Henning Kulander System consultant Linpro AS - Norway's #1 Linux company
