We stopped using __toString as it is unable to handle exceptions - and
this makes sense. However, that's IMO not a good reason to completely
drop __toString. Especially when debugging, benchmarking and similar you
often need a quick way to "dump" an object.
In that case you are often not in a mood to figure out whether that
specific class prefers create(), dump(), render() or whatever. We should
not base our view scripts on __toString - at least unless we do not catch
Exceptions in __toString methods, eventually "forwarding" them as triggered
error where needed.
"Dynamic" is a more of a overstatement when describing this commit but
the current implementation is just the start. Once our ldap protocol stuff
supports our filter implementation this will be vastly improved.
refs #8365
This is needed because of exception handling. Exceptions can now bubble
up for default handling. Method render() was renamed to create() because
the method create a query. Adjust the test for method create().
refs #5536