On Sep 19, 2011, at 5:46 PM, Alexander Klimetschek wrote:
On 19.09.11 21:51, "Dan Check" <[email protected]> wrote:
<snip>
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.
Thinking about this more, the script bindings are fine -- it's more that the
enterprise-y parts of the system don't really play well with the scripting
languages. As I mentioned, the maven scr plugin doesn't pick up annotations on
groovy class files (or, if it does, I can't figure out how to do it). For my
project, most of the jobs we run involve REST API consumption and XML or HTTP
parsing, which are both high points of Groovy.
We're moving to CQ5 with a team that's more familiar with Django, XSLT, Grails
and Drupal, and every team member is dissatisfied with JSPs. While reliance on
JSPs is common enough in enterprise environments, that commonality has, I
think, lost Java a lot of ground to scripting languages with easier templating.
One of the things that I really like about Sling is precisely that you could
get to better, script-based templating system. It just requires some
additional upfront development to get that templating in (rather than just the
scripting supporting itself).
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="{Š..}".
On the first point, while adding request attributes is common practice, I think
it breaks the scope and pollutes the request. We're doing it that way as well,
and I'm sure that at some point there's going to be an optional attribute for
some component that's set in scope during the inclusion of some other jsp, with
odd, difficult to trace results.
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
Great! Glad to hear it -- I just didn't see it while writing my adaptables.
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.
Right.
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.
Carsten's proposal, as is generally the case, seems pretty spot on. For CQ
forms, beyond the Javadocs, I'm having trouble finding documentation for this
on the Adode/Day site...
Regards,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
