You can't assume that HttpResponse is always available, e.g. when
embedding. In fact I think that using that goes completely contrary
to the idea of separating rendering from the core.
We've got a lot of "non-separation" already: for example, lots of URL
generation helper code in WikiEngine. And there are other places in
the code where callers go out and grab the URLConstructor reference
and generate URLs directly. And there are other places where core
functions and user-tier issues are mixed. Filters, for example, can
also generate their own redirects.
It may not sound like we agree on the idea of separating rendering
from the core. I suspect we do, but are coming at things from
different directions.
BTW, with respect to HttpResponse's availability, we could always use
a lazily-initialized mock response. The Stripes MockHttpResponse is a
pretty implementation...
However, it might make sense to provide URL rewriting method in the
WikiContext, which would, if the response were available, would call
encodeURL().
This is a good idea. I agree. That's more or less what I've done in my
local builds. The logic for URL generation is in
WikiActionBeanContext, though, rather that in the WikiContext
(ActionBean) itself. The URL generation method does not necessarily
imply re-writing, but if it had access to the HttpResponse, a filter
could easily re-write it. I think when you see the code, you'll like
what I've done.
But, considering that JSPWiki is very link-intensive anyway, I would
much rather get the URLs right the first time, instead of rewriting
them on the fly all the time.
Agreed. I'd like to funnel responsibility for this through
WikiActionBeanContext.
Let's table this until I get my 3.0 code checked in & we can discuss
in more detail.
I agree, I think groups and account management should be per-
WikiEngine and per-property -file, common to all Spaces which are
running under this Engine.
Not sure what you mean here. What would define the "namespace" for
each WikiEngine or property file? How would you distinguish them?
And how would we explain that this is somehow different from a
"space"? (I am trying to visualize the policy file: explaining that
the *:* for PagePermission means <space>:<page>, but the * in
GroupPermission means <wikiengine-or-propertyfile>.)
Sorry, I was being a bit vague. No, what I meant that a single
WikiEngine should have a single UserDatabase and a single
GroupDatabase. However, in the policy file the GroupPermission "*"
would mean the space.
Your last two sentences conflict. Not sure how you can store Groups on
a WikiEngine-wide basis, but make permissions apply to just a single
space, unless the Groups are stored on a space-by-space basis.
For example:
grant principal com.ecyrd.jspwiki.auth.authorize.Role "Authenticated" {
permission com.ecyrd.jspwiki.auth.permissions.GroupPermission
"*:Foo", "edit";
}
The group permission here is granted to the authenticated Role.
Clearly, those roles apply to the scope of the WikiEngine (or more
precisely, to the scope of the UserDatabase the WikiEngine is
configured to use). The target Group "Foo" to which the permission
applies also applies to the scope of the WikiEngine (really, the
GroupDatbase it uses).
So, my question is, what's the "*" do going forward? I think that it
does nothing. :) Unless we assign Groups within spaces, so that Group
space1:Foo is different from space2:Foo. Group *:Foo would imply both.
Thoughts?
