So, instead of seeing the warnings at compile
time, since I know it??™s safe to do so, this annotation suppresses them. You??™ll see this on a
number of methods in these classes, but they all serve the same basic purpose, owing to the
same underlying cause, so consider this part of that generic stuff I won??™t be mentioning again!
Next we see a Map of tokens being created that will be used to replace the dynamic tokens
in the SQL query. Included in this Map is a username element. Now, when this method is
called when a user isn??™t logged in, no username is passed. In that case, a dummy value of
_DUMMY_USERNAME_ is used. This is done so that the query won??™t be broken by a null username.
Unless someone explicitly adds a user with that username, the result will be that the query
won??™t find any matches based on username, but it will still find matches for all users, so things
work as expected this way.
Finally, the query is executed and the returned List is iterated over. For each item
returned, we construct a string in the form xxx~~yyy, where xxx is the name of the report and
yyy is the description, and we add that string to a List, which is returned. We previously saw
how the UI uses this string, so now the picture is complete.
Pages:
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685