+1 to :) First of all you may want to check into CQ5 [0] and Adobes new Digital Enterprise Platform [1] and their customers. [2] Day built jackrabbit/felix/sling as the backend to their product, so seeing how they use it may provide some context for why sling is designed the way it is. Day could have kept their work behind close doors, but they decided to donate it to the open source community. The product is very standards focused so when they wanted an extremely dynamic environment they decided to go with the osgi standard [3]. It's not necessary but a design choice.
If you feel your process is inefficient, feel free to give details and maybe someone will have some ideas to help. [0] http://www.day.com/day/en/products.html [1] http://www.adobe.com/solutions/customer-experience/enterprise-platform.html [2] http://www.day.com/day/en/customers.html [3] http://en.wikipedia.org/wiki/OSGi -----Original Message----- From: Carsten Ziegeler [mailto:[email protected]] Sent: Mon 9/19/2011 3:25 PM To: [email protected] Subject: Re: Improvement ideas for sling :) Carsten 2011/9/19 sam " <[email protected]>: > 1. I haven't seen a properly configured Sling in production. Would you > provide examples of Sling used in production? > 2. With my tools and workflows, storing code in repository just adds extra > step for deployment and version control. > 3. I just don't like developing in Java. With other languages, I haven't > encountered *need* for _module system_ such as OSGi. > > On Mon, Sep 19, 2011 at 2:06 PM, Carsten Ziegeler <[email protected]>wrote: > >> Hi, >> >> when shipping a default configuration for a framework you have >> basically two options, make it developer friendly, make it production >> ready. As a system has to be tweaked for production anyway, the >> default config of Sling tends more to make the developers life easier. >> Therefore anonymous access is allowed. >> But this is known, should be changed for production (or not depending >> on your use case!) and doesn't really pose a problem. A system should >> always be checked for production! >> >> Storing scripts in the repository has some advantages depending on the >> tooling and workflow you use. But to be more precise, scripts are >> stored in the resource tree, so it's up to the users of Sling to >> choose the repository for there scripts, bundle resources or the file >> system, All of this is possible and even works in combination, so you >> have the flexibility of choice. >> >> My personal opinion is that a large software system should be >> developed modular and the best solution for this is OSGi. Therefore >> for me it makes totally sense to put most of the code in bundles to >> benefit from OSGi and use JSP just as the thin rendering layer. But >> ymmv and you're free to use any scripting and modularity approach you >> want. >> >> Regards >> Carsten >> >> 2011/9/19 sam " <[email protected]>: >> > Exactly. >> > >> > But, why not make Sling sane like "other frameworks"? >> > What's rationale for expose all resources by default? >> > What's rationale for storing code (scripts) in the repository? >> > What's rationale for OSGi bundle + JSP? >> > >> > On Mon, Sep 19, 2011 at 12:07 PM, Sarwar Bhuiyan >> > <[email protected]>wrote: >> > >> >> 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 >> >> > > >> >> > >> >> >> > >> >> >> >> -- >> Carsten Ziegeler >> [email protected] >> > -- Carsten Ziegeler [email protected]
