yes, that is a good observation Martin. The only way to work around
that would be to setup some kind of SSO implementation and set your SSO
cookie at the roller.tld domain. That way the cookie is available to
all hosts under that domain.
you should be able to hack something like that via Acegi, but I don't
have any details because I've never tried.
-- Allen
Martin Giljohann wrote:
I have a question now which is related to the topic of having role based
information on the blog templates (edit links, in-line menu) and the proposal
for the new URL implementation
http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_NewUrlImplementation
The proposal says that url mapping to blogger-style subdomains like myblog.roller.tld will be possible through the RequestMapper interface. The problem I see is that although the url mapping itself should work fine, the subdomain myblog.roller.tld and the main www.roller.tld are treated as different domains, according to the servlet spec.
This means that the user's role based information are usually lost, if the user
logs in at www.roller.tld and tries to access the information via the links at
myblog.roller.tld . Is there any possibility of working around this? (I tried
it, but I reckon that I'm far away from keeping the sessions persistent between
domains ...)
Regards
Martin
Dave Johnson wrote:
-1 on removing edit links and in-line menu.
I use them many times a day and conside them extremely useful.
- Dave
On 6/29/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
I would agree with your point that the little "edit" links on entries is
the less useful element, but I still consider that little editor menu to
be a bit out of context.
The menu itself is nice and I suggest we continue using it, however it
makes way more sense to me for that to be part of the authoring
interface rather than on *all* weblog pages. I can see a little menu
like that being on the main menu page.
I am also yet to understand why it makes any sense for a weblog page to
be knowledgeable about the login status of a user. You login to the
authoring interface, not a weblog. To me the rendered weblog pages are
a completely separate system from the authoring system (which is
basically the case in the code as well) and they shouldn't be tied together.
-- Allen
Martin Giljohann wrote:
I like the idea of simplifying the blog UIs and from my point of view the edit
link is somewhat unnecessary.
However I disagree with the general idea of not considering authorization for
the blog templates, because I regard e.g. the navigation menu as being pretty
useful in terms of having a shortcut for the author for posting new entries and
manage the settings. This is a usability feature which I would personally
weight higher than speeding up the caching.
Regards
Martin
Allen Gilliland wrote:
I know I have brought this up before and I don't remember how it was received,
but in any case I'm going to bring it up again. Would anyone be opposed to the
idea of removing the set of edit links that we embed into weblog pages? I
think the reasons to do this are many ...
1. It would *significantly* simplify the page rendering process to not have to
deal the issue of rendering things differently if the weblog owner is logged
in. I believe there is a fair amount of logic that goes into the
models/macros/rendering to deal with this situation which could all be removed.
2. I consider this feature minimally useful. I don't see why a weblog author would
browser their site to look for things to edit rather than just logging into the
"editing" interface and doing their work their.
3. This feature is only ever of benefit to a single person, the weblog author.
We add a fair amount of extra logic just so that these pages can be rendered to
benefit a single person :/
4. This would never work in a statically rendered site.
As far as I am concerned this feature requires way more overhead than it's
worth. If we rip it out we simplify a number of things ...
1. we can remove all elements of models and macros which perform any logic
based on a users login status. this would simplify a number of models and
macros.
2. we can simplify our caching because the cache no longer needs to know if the
user is logged in or not and render/cache those pages separately. this reduces
the size of the cache (possibly significantly on large sites) and eliminates
unnecessary redundancy.
So, my opinion is pretty obvious. I think this is a feature which can safely
be removed and will do some very good things to simplify a number of aspects of
weblog rendering.
Thoughts? Opinions?
-- Allen