Question: Is it feasible to add prefix support to the page inject
specification?
Short answer: No. Too many prefixes do not make sense in this context.
And it'd be ugly.
Long answer: I really, really don't like the approach one has to take to
make this work. It is possible to add prefix support. Or just OGNL
support, since that's really all we need. (At least, I can't see a use
for any other prefixes.) But the implementation is ugly. VERY ugly.
It's so ugly that I can't even guarantee it'll keep working. So I'd
rather just scrap it. (In fact, I already did.)
Now, the InjectPageWorker is actually creating a method with this body:
getPage().getRequestCycle().getPage(pageName);
Would it work for you to just do this:
String pageName = com.package.PageConstants.FOO_PAGE;
getPage().getRequestCycle().getPage(pageName);
Instead of having an annotation? The above could be put inside a method
in a common base class or provided as a lookup service.
That's my best answer I guess. To a question that I made up myself.
Twisted. Or maybe it's because I haven't had any coffee. Who knows.
-Filip
Mike Snare skrev:
Would it work to first 'try' to assume it's an ognl expression, or
would that just puke since no method exists? Worse yet, what if the
method *does* exist but has nothing to do with the desired page?
That's a subtle bug that would throw some people against the wall for
a bit.
In the event the method doesn't exist and the attempt to get the value
of the assumed ognl binding fails with an exception, you'd need to
catch that exception and try the literal. Then you're using exceptions
for control flow.
I think it would be fine to set the default binding prefix to literal
for this in 4.0.2, add the binding functionality and leave it at that.
That would be transparently backward compatible AND let me use an
ognl prefix to provide the name.
Only in the next release where backwards incompatibility is already
planned should the default go to ognl.
That's my 2 cents, but if you're willing to fix it I'm willing to take
whatever you'll give. It's unusable to me now, so anything is an
improvement.
Thanks again,
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
