Hi devs,
As suggested by Vincent, it would be cool not to have a distinct API for
usage from velocity scripts, but pseudo-wrap the Java classes into a
scriptable API using some uberspectors/introspectors. I like this idea a
lot, as it is a bit hard to maintain two APIs (as the internal core is
an API, just that it isn't directly scriptable), and with the new
component architecture, the scriptable API would be completely unneeded.
To remind, introspectors are used for finding the right methods to be
called, given the target object, the method name, and the parameters;
uberspectors must use introspector's results to construct
velocity-specific objects for direct method calls
($something.methodCall()), getters (#set something = $object.getter),
setters (#set $object.setter = something) and iterators (#foreach
$iterator in something).
During the last few days I wrote a chaining uberspector, that allows
chaining several uberspectors, and a introspector chaining uberspector,
that allows chaining several introspectors (not committed yet). The idea
would be to have something like:
[(introspector <- ... <- introspector)>- IntrospectorChainingUberspector
<- Uberspector <- ... <- uberspector]>- ChainingUberspector
Introspectors are chained in order to find or to filter out requested
methods, then uberspectors use these methods to further enhance or
restrict the method retrieving & calling process.
So, a possible chain would be:
BaseIntropector - finds methods using reflection.
SecureIntrospector - filters out restricted objects/methods, like
reflection, classloaders, threads/synchronization and the System class.
ScriptableCheckIntrospector - blocks all direct calls to methods in the
org.xwiki package that don't have an @Scriptable annotation. Note that
it is possible to have calls to non-scriptable methods inside scriptable
methods, as that is java code already, outside scripting.
RightsCheckingIntrospector - uses the @Authorisation("accessright")
annotations placed on our methods to perform rights checking.
ProgrammingWrapIntrospector - not sure about this one, as I don't know
how it could be implemented, but it would be nice to mimic all
*WithProgrammingRights methods (like saveWithProgrammingRights), instead
of literally having them in the java classes.
ContextInjectionIntrospector - if no method was found, tries to find a
method with an extra XWikiContext parameter. I must find a way to pass
the request-specific XWikiContext (Vincent, any ideas?). This one is
needed because all current API methods hide a non-scriptable method with
almost the same signature, just an extra XWikiContext parameter at the
end. This might not be needed if we completely get rid of the
XWikiContext from the code before starting to use this chain.
DeprecatedCheckIntrospector - logs deprecated method calls.
IntrospectorChainingUberspector - calls the introspector chain and wraps
the resulting methods into velocity objects (VelMethod, VelPropertyGet,
VelPropertySet).
ExceptionCatchingUberspector - catches all exceptions and puts them in
the context (and logs them, too).
ChainingUberspector - just allows having the uberspectors chain.
I'm not sure if all those should be introspectors, or would be better as
uberspectors instead.
I didn't include the SecureUberspector in the chain, as besides the
filtering done by the SecureIntrospector, it only checks if the returned
iterator is restricted or not, and I don't think the iterators should
ever be restricted.
I don't know if the rights check should be left only to the introspector
or not. Currently, this check is done mostly in the API classes only,
suggesting that anything that happens in the java world is safe to
execute, regardless of the access rights. Groovy doesn't need access
rights check, as it requires programming rights from the start. XmlRpc
should be a little more secure, but right now it doesn't use rights
checks from the core classes anyway.
So, any method we would like to be callable from Velocity should have an
@Scriptable annotation. Rights checking could be performed entirely from
an introspector.
Any thoughts on this?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
