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
