Felix, I agree with the package naming. For the short name of the TLD, should it be something like 'sling-resource' or something shorter, such as 'sr'? Personally I lean towards the shorter option. WDYT?
I'll create a patch for separating the Resource Access code into another directory. Should it be created under: http://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/jsp-resource-taglib or http://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/jsp-resource-taglib Thanks, Dan -----Original Message----- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: Tuesday, February 26, 2013 5:19 AM To: dev@sling.apache.org Subject: Re: Resource Access Tags Hi, Am 26.02.2013 um 05:04 schrieb Dan Klco: > Felix, > > I like the idea of creating a separate Resource API tag library. I think > there's enough functionality there to justify it and it may or may not be > something needed for every Sling installation and would reduce the number of > dependencies in the core Taglib. What would be a good namespace for the > Resource API tags? 'sr' or 'resource'? I would imagine that this would be a bundle like o.a.s.scripting.jsp.taglib.resource. WDYT ? Regards Felix > > Thanks, > Dan > > -----Original Message----- > From: Felix Meschberger [mailto:fmesc...@adobe.com] > Sent: Monday, February 25, 2013 12:03 PM > To: dev@sling.apache.org > Subject: Re: Resource Access Tags > > Hi Dan > > Thank you very much. Glancing over it, this looks fine -- a deeper review is > welcome. > > Yet, I wonder whether we should add those tags and EL functions to the > existing JSP taglib or whether we should create a Resource API specific tag > library ? > > WDYT ? > > Regards > Felix > > Am 22.02.2013 um 14:26 schrieb Dan Klco: > > All, > > I've made some additional contributions around the resource access tags, > based on SLING-1500<https://issues.apache.org/jira/browse/SLING-1500>, which > had some nice features including: > > * New FindResources tag, for invoking the > resourceResolver.findResources functionality > * Updated: GetResources tag, adds the ability to specify a base > resource under which to retrieve a relative resource > * New EL function adaptTo: adding the ability to adapt adaptables in > EL functions > * New EL function findResources: enable invoking the > resourceResolver.findResources functionality EL functions > * New EL function getRelativeResource: enables finding resources by a > relative path in EL functions > > The patch also contains jUnit tests for these new tags and functions. > > I was also looking through the old issues, and I believe > SLING-577<https://issues.apache.org/jira/browse/SLING-577> can be closed, as > Tobias points out you can bind a ValueMap to the page context and access > properties on it using EL functions, e.g.: > pageContext.setAttribute("myProps",aValueMap); > ${myProps.name} - ${myProps['sling:resourceType']} > > Finally, I was wondering what the process would be for getting Sling Taglib > 2.1.9 released? Is there anything else required before it gets released or > anything I can do to help the process? > > Thanks, > Dan > > From: Dan Klco > Sent: Wednesday, December 05, 2012 3:48 PM > To: dev@sling.apache.org<mailto:dev@sling.apache.org> > Subject: Resource Access Tags > > All, > > I was wondering if there was any interest in adding the Resource access tags > I provided into the Sling Taglib. The idea behind these tags is to provide a > faculty for accessing some of the most common functionality in the Sling > Resource API without having to use Scriplet. > > The tags include the following: > * getResource - get a resource by path > * listChildren - invoke the listChildren method, useful if SLING-2641 > is not in place > * adapt - adapts adaptables to other object types > * getProperty - allows you to get properties from ValueMaps with > defaults and object casting > > The patches for this functionality and a page describing the Sling TLDs, > including what tags are available in each version of the Sling TLD are on > this issue: > https://issues.apache.org/jira/browse/SLING-2648 > > Thanks, > > Dan Klco > Senior Staff Engineer, Adobe WEM / Day CQ5 San Ramon, CA / Dayton, OH > > <http://www.sixdimensions.com/> > Cell (937) 231-3050 > Office (937) 343-1326 > Fax (877) 510-5082 > LinkedIn<http://www.linkedin.com/in/klcodanr> | > @KlcoDanR<https://twitter.com/klcodanr> > > People. Deliver. Progress. > > > > -- > Felix Meschberger | Principal Scientist | Adobe > > > > > > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.2899 / Virus Database: 2641/6126 - Release Date: 02/23/13 > -- Felix Meschberger | Principal Scientist | Adobe ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2899 / Virus Database: 2641/6126 - Release Date: 02/23/13
