On 19.09.11 21:51, "Dan Check" <[email protected]> wrote:
>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.
Not sure what you mean exactly, but there are some integrations with other
scripting languages except jsp out there: javascript (esp), velocity and
groovy (which you mention).
Any java scripting language can be installed in Sling easily. But usually
you want to have some useful script bindings, which is where you need to
write a bitŠ so far interest in non-JSP scripting seems to be not very
high, AFAIK. (Might be because server-side enterprise development has most
of its resources on the Java/JSP side).
One (more long-term) note here might be that one of the JCR 2.1 spec goals
is simpler access for scripting language, and I think that would also
benefit Sling in some way.
>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.
I usually put things into the request attributes which also works nicely
if you pass something to a servletŠ or if you switch code from a JSP to a
servlet.
Internally, it would always have to be stored in the request attributes,
so adding a helper method doesn't bring any benefits other than hiding the
use of the servlet API.
However, an extension to sling:include that allows to set attributes
easily might be a bit shorter/more readable/elegant: attributes="{Š..}".
>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).
AdaptTo calls are generally cached for a while now:
https://issues.apache.org/jira/browse/SLING-1673
>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.
Yes, if JCR search performance is affected, it should be done in
Jackrabbit.
>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?
Since you mentioned you are using CQ: CQ forms does this.
For Sling, Carsten's proposal sounds interesting (IIUC)Š some generic
validation layer hooked into the Sling POST servlet could be useful.
Regards,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
