Re: Script resolution newbie question
On 04.11.2013, at 14:06, Alessandro Bologna alessandro.bolo...@gmail.com wrote: Again, I fully understand that this is possibly a better approach with fewer contents and maybe if there variations on them, but in my use case (same exact contents, just different rendering) the approach of extending the script search path seems to be more reasonable. I would say that a virtual resource provider is cleaner. Most importantly because it allows to access your virtual separate trees on the server side as well without being forced to run within a http request context. Cheers, Alex
Re: Script resolution newbie question
Julian and Alex, thank you, those are good ideas. But the problem is that this kind of solution wouldn't scale in our case, as it would require at least N x A nodes, where A is the number of articles, and N is the number of apps that we could build. Say that we have 100,000 articles (and that's to start with) and each consists of maybe an average of 3 to 5 nodes. If we decide to use an approach where we clone the tree (minus the contents) to hold the new sling:resourceType values, we would have at least 100,000 extra nodes for each app. Any update to the position of a story, or a adding or deleting would also need to update the shadows. Again, I fully understand that this is possibly a better approach with fewer contents and maybe if there variations on them, but in my use case (same exact contents, just different rendering) the approach of extending the script search path seems to be more reasonable. Cheers, Alessandro On Mon, Nov 4, 2013 at 4:44 PM, Alexander Klimetschek aklim...@adobe.comwrote: On 02.11.2013, at 08:38, Alessandro Bologna alessandro.bolo...@gmail.com wrote: I am confused on how that could be implemented? How do you point a resource tree to another, and make the contents of the tree the same minus the resource type? I mean, that would be cool... I don't think the solution is shared nodes though... No, I meant a tree that would just include references (string path properties) to the original tree instead of copying everything. You still have to manage that tree yourself. It depends on how much custom management you have to do anyway in your business case (because of differences in the trees like ACLs, availability etc.) whether it makes sense to manage an active copy or a an automatic duplication via another resource provider (or other automatic solutions). Cheers, Alex
Re: Script resolution newbie question
Hi I have the impression this sounds like having „configurable“ (or dynamic) search paths on the ResourceResolver ? Currently the search path is fixed at a configuration value. It might be conceivable that we make this more dynamically configurable. Regards Felix — Felix Meschberger | Principal Scientist | Adobe Am 31.10.2013 um 15:28 schrieb Alessandro Bologna alessandro.bolo...@gmail.com: Hi, I am pretty sure that the answer is simple enough, but somehow I couldn't find it in the documentation. Say that I have a resource /content/shared/foo with sling:resourceType myapp/page, which will cause a request to invoke scripts at /apps/myapp/page. For requests that have a specific header, say Host:otherapp, I want instead to use scripts located at /apps/myotherapp/page. Short of duplicating the resource, what's the best practice to implement this? It doesn't seem that the mapping at[1] would help be because in the end I need to change the base path of the resourceType... Thanks Alessandro [1] https://cwiki.apache.org/confluence/display/SLING/Flexible+Resource+Resolution
Re: Script resolution newbie question
On Fri, Nov 1, 2013 at 3:26 PM, Felix Meschberger fmesc...@adobe.com wrote: ...I have the impression this sounds like having „configurable“ (or dynamic) search paths on the ResourceResolver ?... Yeah, rather dynamic, based on query attributes like Host header etc. But again, having some concrete use cases for a minimum viable product implementation would help. -Bertrand
Re: Script resolution newbie question
Hi Am 01.11.2013 um 15:32 schrieb Bertrand Delacretaz bdelacre...@apache.org: On Fri, Nov 1, 2013 at 3:26 PM, Felix Meschberger fmesc...@adobe.com wrote: ...I have the impression this sounds like having „configurable“ (or dynamic) search paths on the ResourceResolver ?... Yeah, rather dynamic, based on query attributes like Host header etc. But again, having some concrete use cases for a minimum viable product implementation would help. Yeah, sure. Just throwing around with an idea ;-) Regards Felix
Re: Script resolution newbie question
Justin, Felix and Bertrand, first of all thank you all for helping out. I think that for now the suggested idea of just wrapping the resource and (kindly) overriding the resource type based on the request will work, but, as Bertrand requested, I'll try to explain my use case. In my organization, we produce quite a lot of web/digital contents, and these contents are reused in multiple context, such as websites, mobile devices and so on. Often multiple teams, with different release schedules are in charge on these products that, again, share the same content (articles, galleries etc). They just reuse them in new products. While it's reasonable to define a resource type hierarchy and content structure that is common to all the applications, the code is of course different. Actually even the entire application bundle may be using different java components and other code, not just the scripts/jsp/templates. Being able to deploy different application bundles that use same the resource hierarchy differently would allow, at run time, Sling to dispatch a different JSPs and code based on either the http host header (for virtual hosting, say m.mysite.com/content/home.html), or even the resource path (say www.mysite.com/mobile/home.html, in turn resolving to the /content/home.html resource, but using the mobile bundle instead of the default one). The sling:resourceType property would be a relative path from /apps/appname/, and you could define a virtual host style mapping, with maybe a default application as fallback. I understand that this could be implemented segregating the code in different folders inside the same app and then using selectors and url rewriting rules, but I am afraid that the interdependencies that would be coming out of this approach may be complicating the process unnecessarily. Thanks again! Alessandro On Fri, Nov 1, 2013 at 10:34 AM, Felix Meschberger fmesc...@adobe.comwrote: Hi Am 01.11.2013 um 15:32 schrieb Bertrand Delacretaz bdelacre...@apache.org : On Fri, Nov 1, 2013 at 3:26 PM, Felix Meschberger fmesc...@adobe.com wrote: ...I have the impression this sounds like having „configurable“ (or dynamic) search paths on the ResourceResolver ?... Yeah, rather dynamic, based on query attributes like Host header etc. But again, having some concrete use cases for a minimum viable product implementation would help. Yeah, sure. Just throwing around with an idea ;-) Regards Felix
Re: Script resolution newbie question
Hi Alessandro, Trying to find a simplest thing that works scenario... Assume you have two content resources at /content/www.example.com/home and /content/m.example.com/home, both with resourceType=H When rendering www.example.com/home.html, Sling looks for scripts in the following folders, in order: /specific/www.example.com/H /apps/H /libs/H And if rendering com.example.m/home Sling looks under /specific/m.example.com/H, /apps/H and /libs/H You'd then have specific rendering scripts under /specific, and if needed common scripts under /apps and /libs There's a number of details to refine of course, but would that basically work for you? -Bertrand
Re: Script resolution newbie question
Those separate resource trees I mentioned could just point to the original
resources, so they don't need to duplicate them. Maybe the trees and/or the
selection of what gets used might look different than the original, so that can
be the only option.
OTOH if it is really automatic and applies to all resources (or the few
exceptions are trivial and based on existing flags on the original sources) I
agree, creating a separate tree might be difficult. In that case I could
imagine having a custom resource provider (I am not sure if that was proposed
already?) might be useful: say you hook it under /alternative2 and just wrap
the JCR resources from /some/foo, but changing the resource type. And the host
header would be used upfront in the webserver or sling mappings to get from
Host: myserver to /alternative2.
I would be careful with too much dynamic script or resource resolution based on
headers etc., since this becomes less transparent and is harder to debug.
Cheers,
Alex
On 01.11.2013, at 09:01, Alessandro Bologna alessandro.bolo...@gmail.com
wrote:
Yes, that's exactly the case. And to explain why using the resource path is
not an option for us, the fact is that if we could just duplicate the
resources in a new tree then we would just go ahead and change their
resource types as well, but with a few millions of those around it's a bit
painful to do so. And in general, even the tooling to inspect browse etc
etc that has to deal with them would be struggling a bit.
On Fri, Nov 1, 2013 at 11:54 AM, Bertrand Delacretaz bdelacre...@apache.org
wrote:
Hi,
On Fri, Nov 1, 2013 at 4:32 PM, Alessandro Bologna
alessandro.bolo...@gmail.com wrote:
we have *one* resource,
(meaning one jcr node if it's a jcr backed resource), at /content/home
with
sling:resourceType H
if a request is for http://www.example.com/home.html, H points to
/specific/www.example.com/H/html.jsp
if a request is for http://m.example.com/home.html, H points to
/specific/m.example.com/H/html.jsp
Ok got it - so our examples are similar, in that we build an
additional search path for scripts based on the current request.
In my case, that path is computed based on part of the path of the
resource that's been resolved.
In your case, that path is computed based on a request header.
So it looks like a service like follows might do the trick:
/** Instances of this service are taken into account by the servlet
resolver,
* to look for scripts in more places than just the default /apps and
/libs
* for the current request
*/
public interface ScriptSearchPathsProvider {
/** Return a list of paths that are added in front of the search
* path used to resolve scripts. */
SetString getAdditionalScriptSearchPaths(SlingHttpServletRequest
request);
}
WDYT?
One issue that comes to mind is handling the rendering servlet's
cache, as with this it won't be a straight resource type to servlet
mapping anymore...but if we agree on the basic needs we can look at
that when needed.
-Bertrand
Script resolution newbie question
Hi, I am pretty sure that the answer is simple enough, but somehow I couldn't find it in the documentation. Say that I have a resource /content/shared/foo with sling:resourceType myapp/page, which will cause a request to invoke scripts at /apps/myapp/page. For requests that have a specific header, say Host:otherapp, I want instead to use scripts located at /apps/myotherapp/page. Short of duplicating the resource, what's the best practice to implement this? It doesn't seem that the mapping at[1] would help be because in the end I need to change the base path of the resourceType... Thanks Alessandro [1] https://cwiki.apache.org/confluence/display/SLING/Flexible+Resource+Resolution
Re: Script resolution newbie question
Hi Alessandro, What you could also do is to have a ResourceDecorator which changes up the resource type. HOWEVER, you might be templted to use the two-argument method. This doesn't actually work (and now documented as such). So you'd need to combine this with some ThreadLocal-based filter to store the current request. HTH, Justin On Thu, Oct 31, 2013 at 11:53 AM, Alessandro Bologna alessandro.bolo...@gmail.com wrote: Thanks Paul and Bertrand, So, if I have two development teams working on two different presentation apps that I want to keep completely separate I would need to partition all the selectors space to that for instance /content/shared.team1.html uses /apps/myapp/team1/html.jsp /content/shared.team1.header.html uses /apps/myapp/team1/header/html.jsp and similarly for team2 etc How about the config folder, for logging, rewriters etc, wouldn't that have to be necessarily shared between the two teams? Thanks again, Alessandro On Thu, Oct 31, 2013 at 11:15 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Oct 31, 2013 at 4:07 PM, Paul McMahon oro...@yahoo.com wrote: ...You'd probably want to perhaps using a selector instead of a header value (or using a rewrite rule to turn the header value into a selector) and then use selector specific scripts to meet your requirements... I was going to suggest just that, and instead of an external rewrite rule you could also use a Sling Filter. -Bertrand
Re: Script resolution newbie question
Justin, thank you, I may very well go with your approach, which I guess would mean to override the getResourceType and getResourceSuperType in a MyAppResourceWrapper based on the current request (to which I have no access to in the my ResourceDecorator, when using the single decorate(Resource) method). Instead of using a ThreadLocal, could I implement a BindingsValuesProvider and get the request object from the bindings and inject them in the wrapped resource? Any major problem doing so? Thanks a lot to all. Alessandro On Thu, Oct 31, 2013 at 12:05 PM, Justin Edelson jus...@justinedelson.comwrote: Hi Alessandro, What you could also do is to have a ResourceDecorator which changes up the resource type. HOWEVER, you might be templted to use the two-argument method. This doesn't actually work (and now documented as such). So you'd need to combine this with some ThreadLocal-based filter to store the current request. HTH, Justin On Thu, Oct 31, 2013 at 11:53 AM, Alessandro Bologna alessandro.bolo...@gmail.com wrote: Thanks Paul and Bertrand, So, if I have two development teams working on two different presentation apps that I want to keep completely separate I would need to partition all the selectors space to that for instance /content/shared.team1.html uses /apps/myapp/team1/html.jsp /content/shared.team1.header.html uses /apps/myapp/team1/header/html.jsp and similarly for team2 etc How about the config folder, for logging, rewriters etc, wouldn't that have to be necessarily shared between the two teams? Thanks again, Alessandro On Thu, Oct 31, 2013 at 11:15 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Oct 31, 2013 at 4:07 PM, Paul McMahon oro...@yahoo.com wrote: ...You'd probably want to perhaps using a selector instead of a header value (or using a rewrite rule to turn the header value into a selector) and then use selector specific scripts to meet your requirements... I was going to suggest just that, and instead of an external rewrite rule you could also use a Sling Filter. -Bertrand
Re: Script resolution newbie question
Hi Alessandro, Unfortunately, no. BindingsValuesProvider are executed much too late for this. Whatever you do has to be done *before* the script/servlet is resolved. Justin On Thu, Oct 31, 2013 at 12:56 PM, Alessandro Bologna alessandro.bolo...@gmail.com wrote: Justin, thank you, I may very well go with your approach, which I guess would mean to override the getResourceType and getResourceSuperType in a MyAppResourceWrapper based on the current request (to which I have no access to in the my ResourceDecorator, when using the single decorate(Resource) method). Instead of using a ThreadLocal, could I implement a BindingsValuesProvider and get the request object from the bindings and inject them in the wrapped resource? Any major problem doing so? Thanks a lot to all. Alessandro On Thu, Oct 31, 2013 at 12:05 PM, Justin Edelson jus...@justinedelson.comwrote: Hi Alessandro, What you could also do is to have a ResourceDecorator which changes up the resource type. HOWEVER, you might be templted to use the two-argument method. This doesn't actually work (and now documented as such). So you'd need to combine this with some ThreadLocal-based filter to store the current request. HTH, Justin On Thu, Oct 31, 2013 at 11:53 AM, Alessandro Bologna alessandro.bolo...@gmail.com wrote: Thanks Paul and Bertrand, So, if I have two development teams working on two different presentation apps that I want to keep completely separate I would need to partition all the selectors space to that for instance /content/shared.team1.html uses /apps/myapp/team1/html.jsp /content/shared.team1.header.html uses /apps/myapp/team1/header/html.jsp and similarly for team2 etc How about the config folder, for logging, rewriters etc, wouldn't that have to be necessarily shared between the two teams? Thanks again, Alessandro On Thu, Oct 31, 2013 at 11:15 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Oct 31, 2013 at 4:07 PM, Paul McMahon oro...@yahoo.com wrote: ...You'd probably want to perhaps using a selector instead of a header value (or using a rewrite rule to turn the header value into a selector) and then use selector specific scripts to meet your requirements... I was going to suggest just that, and instead of an external rewrite rule you could also use a Sling Filter. -Bertrand
Re: Script resolution newbie question
Hi Alessandro! On 31.10.2013, at 07:28, Alessandro Bologna alessandro.bolo...@gmail.com wrote: For requests that have a specific header, say Host:otherapp, I want instead to use scripts located at /apps/myotherapp/page. Short of duplicating the resource, what's the best practice to implement this? I would say the best practice actually IS to have a separate resource tree for another host/tenant. As soon as ACLs or other little differences between hosts come into play, this is the best approach. Otherwise you'll start reimplementing a lot of what the repository and sling gives you already. Cheers, Alex
