Hi,
Tobias Bocanegra schrieb:
...
- yes, "replaceSelector" alters the set of selectors. But this is the name
of the game and how it works. If you would want to continue including
without selectors you just replace them again...
this does not work, since i don't know what they were before (unless i
remember them in the request).
i think it would be sufficient if i could set a temporary selector
that takes precedence from the "real" ones during script resolution of
"this" include. in a way that a request...getSelectors() in the
included request does still show the ones present outside of the
include.
This of course could technically be possible in that we for example we
add tags to specify selector addition/replacement just for a single
include and revert back to the previous ones for further includes....
I am a bit weary of such a feature, though, because it might lead to
hard-to-trace issues. But given some logging (most notably
RequestProgressTracker) this might somewhat be releived.
You are welcome to JIRA this ;-)
Now, maybe you are not even referring to the include tag (jsp:include) but
to the include directive <[EMAIL PROTECTED]> ?
no, but this would be another interesting option...
In this case, I am not sure, whether
and how we could do something. Maybe we would have to hackup the Jsp
Compiler's handling of this directive ...
maybe. but i think would imply a lot of invalidation problems. or does
jasper remember the 'included' resources and invalidates the classes
accordingly ?
if yes, that would be cool, of course.
Looking at the Jasper Code, it seems that these includes are used to
verify the requirement for recompilation.
We should probably not follow up on this for now .... ;-)
Regards
Felix
