There are several separate needs and one needs to account for all of
them. At least the following (there might be others I'm not recalling
right now):
- Forming URLs in a page for CSS, etc.
- Forming permalinks -- in general stable URLs that might be persisted
in other places.
- There are a couple of places where, even in the absence of a request,
the server needs to know how to get back to it. The ping functionality
(which may no longer be useful) is one example, but there might be a
couple of others. This one is hard to handle without either requiring
configuration or picking one in something like the current manner.
There are also a couple of different situations in which these arise,
e.g. previews, and this adds some complexity.
In current trunk, the machinery that handles this is in the
implementations of URLStrategy that you can find by searching in the
source tree (for files of the form *URLStrategy.java) or through your
IDE. The normal one is called
org.apache.roller.weblogger.business.MultiWeblogURLStrategy under
weblogger-business/src/main/java. You could try to experiment with
some alternative proposals. I think the implementation is injectable,
so you should be able to copy and modify to create an alternative
implementation and run your modified version pretty easily.
--a.
On 10/18/11 7:44 AM, Edd Grant wrote:
Hi Anil,
Thanks for your response, it strikes me that many sites might want to
operate both with and without the 'www' sub-domain and may not wish to, or
be able to, perform the required redirect/ url re-writing configuration to
achieve this. Also, with the rising popularity of @font-face I wonder if it
might be sensible for roller to support being addressable at multiple URLs.
Do you have a feel for the complexity of making such a change? If there was
a desire from others to have it then I'd be happy to take a look and see if
I can make the change if someone could point me in the right initial
direction in terms of the code-base.
Cheers,
Edd
On 18 October 2011 14:33, Anil Gangolli<a...@busybuddha.org> wrote:
Yes. If you don't set an absolute one, it stores the one from the initial
request.
--a.
Sent from my iPhone
On Oct 18, 2011, at 2:11, Edd Grant<e...@eddgrant.com> wrote:
Hi All,
My blog is served through 2 URLs:
http://eddgrant.com/blog - for lazy typists :-)
and
http://www.eddgrant.com/blog
Note: I have not set any value in the 'server settings | Absolute URL'
property.
I recently noticed that whichever URL I hit first is then used by Roller
when generating URIs in templates through the use of
$url.resource(resource). This seems to happen until Roller is restarted
at
which point the first subsequently served URI is used again.
For example:
If I start my server up and hit http://eddgrant.com/blog first then this
is
used in subsequent calls to $url.resource(resource), conversely if I hit
http://www.eddgrant.com/blog first then this is the path that is used.
I wouldn't usually be too concerned about this however I recently updated
my
roller theme to use @font-face fonts, in doing so I have made a discovery
which I initially thought was a Firefox Bug: The issue being a same
origin
restriction for served font files where the font file MUST be served from
the same domain as the CSS file in which it is enclosed. This is a pain
since it means that Firefox will only retrieve and render the font files
on
one of my URLs at any moment in time, this of course makes my blog look
rather silly for visitors on the other URL :-(
Server related options seem to be reconfiguring my server to redirect
from
eddgrant.com to www.eddgrant.com, alternatively there is an
access-control-allow-origin header which I could set to remedy this.
However
I wondered if it might be more elegant if Roller could be modified to
dynamically generate the URL during calls to $url.resource() based on the
requested URL.
Anyone have any thoughts on this? If it would generally be considered a
useful requirement then shall I raise it as a feature request?
Cheers,
Edd
--
Web: http://www.eddgrant.com
Email: e...@eddgrant.com
Mobile: +44 (0) 7861 394 543