A good technology often makes it easy to do the "right thing"
While the "right thing" is a highly controversial subject and conventional wisdom can often turn out wrong, and it can be unclear what "conventional wisdom" is on any given point...
I still wonder if Adobe has any responses to these specific issues:
1. plain old JSP has long been discouraged in favor of JSTL, yet all the examples in the documentation always show JSP. While it's not hard to use JSTL in CQ, the examples and geometrix all show jsp only. Does Adobe plan to convert these at any point? or does it espouse the view "plain JSP is not so bad"?
2. out-of-the box use of components stores all data in cq:Pages containing jcr:content as cq:PageContent. Except for DAM assets, this means most content naturally gets stored in property and subnodes of jcr:content. As non-trivial implementations of CQ might show... you end up needing to store data you want to reuse in those nodes. In which case, you really want your data, perhaps even most of your data in a less obfuscated location. That is, you want to be able to have nice sling-able access to your data, say /content/non-dam-reusable-data/my-domain-data, instead of /content/some-site-or-synthetic-structure/some-website-category-that-isnt-my-domain-heira rchy-but-just-view/.../jcr:content/some-containing-structure/... ; this seems to encourage poor/oddly-accessible/highly-view-and-data-coupled heirarchies from the get-go. I realize this would be challenging, but is there any chance Adobe will update this strategy to one supporting more user-defined domain-friendly heirarchies?
The underlying technologies CQ uses are quite elegant, and i'm guessing some of the implementation of CQ is too (if i could only see the source ). Don't get me wrong. I like the product.
But, I wonder, do others feel these interface points are valid criticisms? Does Adobe have any comment on these points?
Thanks for your consideration of this,
Ken