You're talking about a framework that isn't sling. You're free to put any web framework on top of JCR to achieve the things you said. You don't have to use the sling API.
That being said, if you don't want to make use of osgi services, you don't need to import them in the JSP. In fact, you don't need to use JSP either. If you install the velocity scripting bundle for example, you can just print out the properties you need from the bindings. As for preventing access via HTTP by default, just set the ACL permissions for the anonymous user principal or the everyone group to deny for all privileges (read, write, etc) and you'll get 404 when the node accessed is not allowed to be accessed by anonymous. You can do this programatically via the jackrabbit extensions api or via some gui if available (e.g. User Administration screen in CRX). Sarwar On Mon, Sep 19, 2011 at 2:49 PM, sam ” <[email protected]> wrote: > I would like to see proper scripting support (so that one would develop an > application entirely in the language other than Java. No more OSGi bundles > + > JSP importing exported packages by the bundles). > > Also, I would like to have Sling expose ZERO resources over HTTP by > default. > DefaultGetServlet, Json Servlet, Post Servlet... returning 404 for all > resources except the ones that are specifically tagged as "visible". > > With proper scripting support, I doubt there's need for > sling:resourceSuperType and all funky script resolution business. > I just want requests to /some/resource (this is "visible" resource) to be > handled by some resourceType (a request handler). And, I manage > inheritance, > html template resolution... myself in the (scripting) language of choice. > > But then, I would rather use any web framework and access jackrabbit (or > any > other database) through remoting. > > > On Mon, Sep 19, 2011 at 9:12 AM, Markus Joschko <[email protected] > >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 > > >
