Andrew Jaquith wrote:
Interesting thread! You guys had me at a disadvantage -- I was on a
plane from Latin America this morning, and have not been able to respond
until now.
I think I smell a resolution in the air. It is, indeed, to use Stripes
as the "backing technology" for short URLs. Doing this gets us
compatibility with all three current URLConstructors. Here's why:
First, let me state what I think I heard from Janne.
#1: we have to stay compatible with ShortURLConstructor
#2: we have to stay compatible with DefaultURLConstructor too
#3: Janne has no interest in coming up with a new scheme, but is happy
to let "others" (read: Murray) go crazy if they want to, outside of the
core distro
#4: despite restrictions 1, 2, and 3, the URL scheme needs to somehow
accommodate subpages and wiki spaces
#5: we assume that the delimiter for spaces and sub-pages is the same as
the one separating subpath in the URL (/)
Assumption #5 is dubious IMHO, but let's assume all of the others are
hard requirements.
I actually prefer using the '/' since it sideways fits into my existing
URL schema. My schema:
baseURL collectionHierarchy [objectId] action ['?' parameters]
Janne's scheme (from what I understand):
baseURL [collectionHierarchy/objectId] action ['?' parameters]
The resulting URL is the same in both cases but the schema different. If
we consider that the absolute oid is the combination of baseURL and
relative oid then it makes no difference. OTOH, if we consider that the
collection hierarchy can have an arbitrary depth but use a *different*
delimiter than '/' things might get problematic. But since Janne seems to
want '/' I think we're fine. In the end the Intellectual Entity needs to
be resolvable, which in this system means an absolute URL. If Stripes is
capable of parsing an arbitrary depth collection hierarchy (or directory
structure, if that's what we're essentially mirroring), then that's fine.
Even with these constraints, we can still use
@URLBindings for inbound parsing. Here's why:
[...]
So -- if we have 1) the DefaultURLConstructor covered via
stripes:useActionBean and 2) the ShortURLConstructor covered via
URLBindings, then by definition we also have 3) ShortViewURLConstructor
covered. Requirement #3 (other URL schemes) is not met, but there is
always mid_rewrite for those cases.
The wildcard here is what happens with wikispaces and nested pages. Best
case: Stripes does not care what is used as a delimiter, even a '/'.
Worst case: Stripes does care, so we use a different delimiter, like a
colon.
I really hope we don't have to use some ugly syntax for that. I don't
have a requirement for arbitrary depth at all, nor can I foresee that.
It's just too ugly and complicated for most users. Wikis have been flat
since their inception and I'm fine with them being flat. I can say I
have *no* requirement for hierarchy, and if there was one I'd hope it
only go one level (i.e., I'd really hate to see subpages of subpages
of subpages on a wiki, it would add complexity, kill interoperability
and confuse the hell out of most people). Most of the requirements for
subpages can be handled in other ways, such as facets, tags, categories,
etc.
But I don't want to enter to deep into discussion about this as it's
a black hole.
Now, this kind of throws out Murray's particular scenario, but it does
neatly give us, essentially, solid backwards compatibility and much
better request binding, and great forward compatibility. We would still
need an improved URL constructor class for the short URL case, which
would rely on the URLBindings for instructions on how to make the URLs.
I don't see how this doesn't work with my scenario; indeed it still seems
to fit. Since I *think* we see eye-to-eye on this please clarify.
We would effectively be trading code for annotations. Personally, I
think that is a good thing, because it makes it easier to create new
ActionBeans (features!)
It's really hard to imagine that annotations could be less flexible than
code. If we begin to rely on Stripes and then in the future decide to
dump it, as I mentioned before, the essential API contract is the URL
schema and the messaging passed back and forth between the URL handler
and the application. If in dumping Stripes we had to manually construct
what Stripes is doing with annotations that would simply be an exercise;
I don't see that as a barrier to adoption. And if we know we're going to
using Stripes in 3.0 I can't see any reason not to *begin* to use it now.
What Andrew has proposed seems almost completely plugin-and-play with
what is current in the code base. If not, then I'm not understanding
him correctly.
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
