> Example usage: I need to use a different servlet for export. I'd then > configure a ServletResolver that looks for an ?export=true request > parameter and returns the export servlet.
wouldn't that be just a request to another resource type? eg: instead of requesting /foo/bar.html you request /foo/bar.xml which then uses the export script to export the contents of /foo/bar ? > Another example is if I > need to print debug information while coding. I'd then configure a > ServletResolver that looks for ?Debug=true parameters and returns the > debug servlet. for this use case if would setup a filter that changes the log level to debug (if there are loggers bound to a request?) for such request. having an extra debug servlet would just duplicate the code. > 2. Generalise the "Servlet" into a sort of "View" component. The best > analogy is probably Struts' ActionForward class. Wouldn't it be > appropriate to use a JSP as a view component for a Resource? no. i think the idea was for microsling to not have JSP support at all, and for sling to use the eclipse JSP compiler (which is way faster (and works with OSGI) than for example japser). regards, toby -- -----------------------------------------< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 -----------------------------------------------< http://www.day.com >---
