Not sure If I would call these production-ready: http://www.day.com/day/en/products.qu%65ry.js%6Fn?statement=//* http://www.adobe.com/etc/pagetables/feed_proxies.tidy.-34.json?hello http://www.day.com/day/en/customers.are.idiots.html
On Mon, Sep 19, 2011 at 5:08 PM, Mark Herman <[email protected]> wrote: > +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] > >
