Hi, in the spirit of the "Future of Sling" talk given by Carsten on the adaptTo conference I want to add some ideas where we think sling can be improved. They are not meant as a critique but as a possible input for future development. And of course these points are highly subjective and centered around our use cases:
1) Intermediate render format Ever tried to get an XML listing from the usermanagement servlet? Json and xml output creation in sling are two separated things. For XML creation there is even no support build in the framework as it normally just streams the repositories xml to the client. We often find ourselves writing custom GET servlets that need to render both, JSON (for the browser) and XML (for other systems). It would be quite handy to get support for creating both views based on an intermediate format. Similar like Jax-RS allows to render both formats (the rendition could probably be based on a custom Resource or valuemap?). 2) Security It's not easy to get an installation of sling secure. The default GET servlets expose just too much information to the outside world while the clients have quite a lot of power with typehints and the "best-practice" unstructured nodetype. While I understand that limiting these abilities is not desired as it makes the rapid prototyping harder, it would be nice to offer some tools to the developer to make it easier to secure the application: - Validation Every webframework I know has an approach to input validation. Sling has not. There are hooks to do it (Filter or Postprocessor) but that still leaves all the implementation work to the developer. It would really be nice to have a ValidationPostProcessor/Filter and a generic way to describe the validation rules. - Path specific servlet configuration E.g. the "max nr of returned json objects" in the GET servlet. There are paths where it makes sense to allow a lot of returned objects (e.g. fetching a country list for a drop down selection box) but there are other paths in the repository where the amount of returned objects must be limited (user data). The same is true for the infinity and the depth selectors. - Property filters Instead of creating custom servlets it would be nice to have an easy way to configure/describe which properties of a Resource should be rendered. This is even more practical if it allows to also specify some transformation (like output escaping) on certain properties. 3) Allow to modify the input parameter map All the default operations use the SlingHttpServletRequest and the RequestParameters as input for their actions. It would be quite handy to be able to add parameters to the request to complement client data. However the request and the parameter handling is locked down and I couldn't find an easy way to add new parameters (apart from wrappers and quite a number of custom implementations of interfaces). 4) Cache settings Proper handling of last-modified and etag headers should be build into the framework. 5) Minified & concatenated javascript/css CQ has it, but having this in sling as well would be great. That's it for now. I know sling is open source and eventually we will tackle these issues but for now I just want to write them down, so they don't get lost. Regards, Markus
