I'd also add: A defined path for migrations (in the rails sense). We've had to make a series of data changes prior to launch -- changes that would be sql updates or similar in a traditional RDBMS. Because there's no SQL UPDATE functionality, we've scripted these changes. For ease of deployment (across dev, test, stage, prod), it would be great to have a facility that would mimic some of the concepts here:
Rails: http://guides.rubyonrails.org/migrations.html Grails: http://grails.org/plugin/autobase Django: http://south.aeracode.org/ Dan On Sep 19, 2011, at 3:51 PM, Dan Check wrote: Hi, I've been using Sling for the past couple of months as part of CQ. I really like the resource resolution concepts, and the scripting support is really key. A couple of things that I'd like to see worked out at the Sling level are: 1. More of an embrace of JVM scripting languages like Groovy. Sling feels like an effort to make Java more scripting-friendly. I like that goal, but it requires two things: (a) java and jsps need to be able to to instantiate classes written in scripting languages; and (b) everything that is available to a jsp needs to be made available to a script as well. You can satisfy (a) by using the maven eclipse compiler, although the felix scr plugin for maven does not pick up annotations on groovy files. For (b), the best example of this that I've seen is the GSP implementation inside of Grails; jsp taglibs are still accessible inside of gsps. 2. True templating without taglibs is hampered by an inability to control the bindings a script receives when you call it. Let's say I'm printing a list of items -- I have the item printer separated out into a separate script, which I call from a script that handles the control loop. As I understand it, I can either (a) set item properties as page attributes, call the script, and have the script retrieve the page attributes; or (b) write a tag library that takes my attributes as named arguments. Far easier than either would be to be able to supply an arbitrary map of objects through sling:include and have them added to the binding of the template. It would look like: <sling:include resourceType="path/to/itemprinter" path="." additionalContext="{story: myStory, page: 2}"></sling:include> That would also prevent the pollution of the pageAttribute space with items that are really only meant for one template that's being called. 3. An easy mechanism for caching adaptTo calls -- I thought that I had read that this was implemented, but I don't think that it is. One of the time sucks that we have in our app is running the same adaptTo call at the head of every component since there doesn't seem to be a way to place another variable in the default context (we can work around by making it a pageAttribute, and pulling it out at the top of every jsp). 4. A pluggable second-level cache on top of JCR search with a default in-memory implementation. Although I suppose this a request for Apache Jackrabbit. And maybe it exists in the form of the CacheManager. 5. Basic validation. We all know how this works in other frameworks -- bean values are displayed on a form, and when the form is submitted, they're bound to a object on the server side, put through pre-validation, validated, put through post-validation, stored, and rendered on the page. Is there an equivalent process using sling? And if there isn't, do any of the off-the-shelf projects that offer this integrate well into sling? Best, Dan On Sep 19, 2011, at 9:12 AM, Markus Joschko wrote: 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
