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.
Well, yes, we *do* need to generate URLs.
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.
Probably :-)
BTW, with respect to HttpResponse's availability, we could always
use a lazily-initialized mock response. The Stripes
MockHttpResponse is a pretty implementation...
True, but I'm still kinda iffy. That creates a dependency to a
particular J2EE version (if the HttpResponse/Request are ever
extended), so I would like to avoid that if possible.
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.
I guess the easy way would be just to encapsulate it all away in such
a way that the WikiActionBeanContext would call the URLConstructor
and, if the HttpResponse were available, would then call its encodeURL
().
Of course, that means that the URLConstructor should be
"privatized". Or that the URLConstructor would be smart enough to
call the HttpResponse, if available, in which case the WABC would be
just a simple pass-through.
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.
I'm still being vague, I see. What I thinks makes sense to have is
essentially a single sign-on across the entire farm, and a shared
group database (so that you don't have to recreate your groups when
you create a new wiki).
Then, the admin of each space could say "allow members of group Foo
to access space Bar", or "allow members of group Foo to access page
Xyzzy inside space Bar" (if you really want to), without having to
copy group Foo from some other space first.
/Janne
