:) 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]
