-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature request: provide current resource path to model and resourceLoader #227
Comments
Sorry, but I don't quite understand. the resource inclusion is done via a resource resolver, which might create a new runtime for the included resource. so it's not really possible to track the hierarchy so easily. I suggest that the resource resolver implementation should track this accordingly, eg: also, there is no way to resolve the resources beforehand, even if they are not dynamic, since the hierarchy of the resources are not know. |
@tripodsan you are right it's runtime only. For the htlengine it is relatively easy to keep track of the current resource path as it can just forward the current resource path to its children and resource loaders. Both suggested changes are addressing only the runtime api. |
Here is another example which shows why we need not only the current resource id but also its parents: teasers.sly
teaserItem.sly
here a model would have to return different values for |
but the (generic) model is instantiated with the content: and the content is traversed with every resource include: |
During runtime resources can be loaded recursively.
Example
For example if we would have the following resource loading:
click here to expand markup example
main.htl
and in resourceItem you have
child.htl
grandchild.htl
Motivation
This resource path information is often used to return the according model data.
In the example above both
grandchild.htl
could render different data from the same model name.API
It would be most convenient if the resourcePath could be an array e.g.
['root', 'resourceItem', 'childResourceItem1']
and would be available at two locations:compiler.withModuleImportGenerator
Although the
resourcePath
is a runtime only value we could still provide it to the Model mapper e.g.:could be changed to:
runtime.withResourceLoader
Inside the runtime it would also be nice to provide this resourceParameter for resource loading:
The text was updated successfully, but these errors were encountered: