Just wanted to keep this discussion going. It seems like the discussion is whether: - To separate out this code, since it is functionally different than the existing tag and introduces more complexity. VS - Keeping a single bundle to avoid the work required for downstream implementers to import both sets of tags and since resource access is part of the core functionality of Sling.
Personally, I'd tend to come down on the side of keeping a single Bundle/TLD. If implementers don't want the added complexity, they can utilize the older versions of the TLD which does not expose the new tags. Obviously, not a binding opinion, just wanted to keep the discussion going and get to a decision, so this functionality can be made available for use. Regards, Dan -----Original Message----- From: Alexander Klimetschek [mailto:aklim...@adobe.com] Sent: Monday, March 04, 2013 11:01 AM To: dev@sling.apache.org Subject: Re: Resource Access Tags On 04.03.2013, at 16:26, Justin Edelson <jus...@justinedelson.com> wrote: >> The new tags are around accessing resources - hence not really >> directly related to request processing logic. >> > But including and forwarding *resources* and *scripts* both of which I > would consider to be core Sling. The new tags are not related to inclusion or forwarding, right? They simply allow to use resource and value map objects with the JSTL, and IMHO in a way more complex than plain java code. Thus I would still consider this experimental/contribution... Hence +1 for a separate taglib (non-committer vote). Cheers, Alex ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2899 / Virus Database: 2641/6146 - Release Date: 03/03/13
