You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Christoph Papke <pa...@dig.de> on 2009/09/22 10:23:24 UTC
sling.include only follows one path
Hi folks,
we're having a strange problem with the "sling.include"-method in our
"esp"-templates.
At the moment we're trying to develop a flexible content model for a
newspaper company.
Here is a short extract of our repository structure:
------------------------------------------------
wall (sling:resourceType = "wall")
|
|--> brickgroup1 (sling:resourceType = "brickgroup")
| |
| |--> brick11 (sling:resourceType = "statichtmlbrick")
| |--> brick12 (sling:resourceType = "contentbrick")
| |--> brick13 (sling:resourceType = "contentbrick")
|
|--> brickgroup2 (sling:resourceType = "brickgroup")
|
|--> brick21 (sling:resourceType = "contentbrick")
|--> brick22 (sling:resourceType = "contentbrick")
|--> brick23 (sling:resourceType = "statichtmlbrick")
------------------------------------------------
And here are our main templates in the "apps"-directory (hint: we use an
OCM-framework to retrieve content from the repository):
------------------------------------------------
apps/wall/html.esp:
-------------------
...
// iterate over brick groups and include them
brickGroups = wall.getBrickGroups();
for (i = 0; i < brickGroups.size(); i++) {
sling.include(brickGroups.get(i).getPath());
}
...
apps/brickgroup/html.esp:
-------------------------
...
// iterate over bricks and include them
bricks = brickgroup.getBricks();
for (i = 0; i < bricks.size(); i++) {
sling.include(bricks.get(i).getPath());
}
...
apps/contentbrick/html.esp:
---------------------------
...
// include content item
sling.include(contentbrick.getContent().getPath());
...
apps/statichtmlbrick/html.esp:
------------------------------
...
<%= statichtmlbrick.getHtmlText() %>
...
------------------------------------------------
Now here is my problem. If "brick12" includes e.g. a referenced article,
which has includes to other content items, then "brick13" is never
reached in loop of the "brickgroup"-template.
It's the same with "brickgroup2", because "brickgroup1" also includes
other content items.
It seems that the "sling.include"-method only follows one include path.
Is this a bug or a feature or do I get something completely wrong here?
Thanks in advance,
Christoph
Re: sling.include only follows one path
Posted by Christoph Papke <pa...@dig.de>.
Felix Meschberger schrieb:
> Hi Christoph,
>
> Christoph Papke schrieb:
>
>> Hi folks,
>>
>> we're having a strange problem with the "sling.include"-method in our
>> "esp"-templates.
>>
>> At the moment we're trying to develop a flexible content model for a
>> newspaper company.
>> Here is a short extract of our repository structure:
>>
>>
>> ------------------------------------------------
>> wall (sling:resourceType = "wall")
>> |
>> |--> brickgroup1 (sling:resourceType = "brickgroup")
>> | |
>> | |--> brick11 (sling:resourceType = "statichtmlbrick")
>> | |--> brick12 (sling:resourceType = "contentbrick")
>> | |--> brick13 (sling:resourceType = "contentbrick")
>> |
>> |--> brickgroup2 (sling:resourceType = "brickgroup")
>> |
>> |--> brick21 (sling:resourceType = "contentbrick")
>> |--> brick22 (sling:resourceType = "contentbrick")
>> |--> brick23 (sling:resourceType = "statichtmlbrick")
>> ------------------------------------------------
>>
>>
>> And here are our main templates in the "apps"-directory (hint: we use an
>> OCM-framework to retrieve content from the repository):
>>
>>
>> ------------------------------------------------
>> apps/wall/html.esp:
>> -------------------
>> ...
>> // iterate over brick groups and include them
>> brickGroups = wall.getBrickGroups();
>> for (i = 0; i < brickGroups.size(); i++) {
>> sling.include(brickGroups.get(i).getPath());
>> }
>> ...
>>
>> apps/brickgroup/html.esp:
>> -------------------------
>> ...
>> // iterate over bricks and include them
>> bricks = brickgroup.getBricks();
>> for (i = 0; i < bricks.size(); i++) {
>> sling.include(bricks.get(i).getPath());
>> }
>> ...
>>
>> apps/contentbrick/html.esp:
>> ---------------------------
>> ...
>> // include content item
>> sling.include(contentbrick.getContent().getPath());
>> ...
>>
>> apps/statichtmlbrick/html.esp:
>> ------------------------------
>> ...
>> <%= statichtmlbrick.getHtmlText() %>
>> ...
>> ------------------------------------------------
>>
>> Now here is my problem. If "brick12" includes e.g. a referenced article,
>> which has includes to other content items, then "brick13" is never
>> reached in loop of the "brickgroup"-template.
>>
>
> Out of my belly, I would say above code should basically work unless
> there is an error while handling the include of the
> contentbrick.getContetn().getPath() in which case request processing may
> be aborted.
>
> You would find more information in the log file.
>
>
>> It's the same with "brickgroup2", because "brickgroup1" also includes
>> other content items.
>>
>> It seems that the "sling.include"-method only follows one include path.
>>
>
> That would be absolutely wrong and desasterous I would say. Also, you
> say the "abort" happens after handling brick12 -- but at that time
> brick11 and brick12 have already been handled, which makes two and not
> just a single one.
>
>
>> Is this a bug or a feature or do I get something completely wrong here?
>>
>
> I would assume that there is something wrong while trying to handle the
> brick12 include ...
>
> Regards
> Felix
>
Hi Felix,
thanks for your answer.
For testing purposes we've implemented the same logic in groovy
templates and the include mechanism seems to work fine.
Might there be a bug in the esp implementation?
Regards
Christoph
Re: Not-OT Re: OT: iterators/for-each loops (Re: sling.include only
follows one path)
Posted by Markus Pallo <pa...@dig.de>.
only indirect in the for loop.
i am wondering why the included script, which has also i in the for
loop, changes the value of the surrounding script.
I thought includes uses own scope.
Markus
Andreas Kuckartz wrote:
>> i before include is "1" and after include its "3".
>> So "i" of the wall is changed by having also "i" in brickgroup
>>
> template.....
>
>
>> for (i = 0; i < brickGroups.size(); i++) {
>>
>
> Where is 'i' declared? (Such problems are one of the reasons for
> for-each loops)
>
> Cheers,
> Andreas
>
>
--
------------------------------------------------------------------
DIG Digitale Medienberatungs-
und Produktions- GmbH
Neckarstr. 1/5
78727 Oberndorf a. N.
Amtsgericht Stuttgart HRB 480914
Geschäftsführer: Carsten Huber
------------------------------------------------------------------
Tel: +49 (0)7423 8750 60
Fax: +49 (0)7423 8750 23
Internet: http://www.dig.de
eMail: pallo@dig.de
Ein Unternehmen der Schwarzwälder Bote Mediengruppe
Not-OT Re: OT: iterators/for-each loops (Re: sling.include only follows
one path)
Posted by Andreas Kuckartz <A....@ping.de>.
> i before include is "1" and after include its "3".
> So "i" of the wall is changed by having also "i" in brickgroup
template.....
> for (i = 0; i < brickGroups.size(); i++) {
Where is 'i' declared? (Such problems are one of the reasons for
for-each loops)
Cheers,
Andreas
Re: OT: iterators/for-each loops (Re: sling.include only follows
one path)
Posted by Christoph Papke <pa...@dig.de>.
Bertrand Delacretaz schrieb:
> Hi,
>
> On Thu, Sep 24, 2009 at 7:06 AM, Markus Pallo <pa...@dig.de> wrote:
>
>
>> ...I made a test and changed wall/html.esp as seen below.
>> i before include is "1" and after include its "3".
>> So "i" of the wall is changed by having also "i" in brickgroup template.....
>>
>>
>>
>> ---------------------------
>> brickGroups = wall.getBrickGroups();
>> for (i = 0; i < brickGroups.size(); i++) {
>> %>
>> i before include <%= i %><br/>
>> <%
>> sling.include(brickGroups.get(i).getPath());
>> %>
>> i after include <%= i %><br/>
>> <%
>> }
>> -----------------------
>>
>
> Could you check if the http://issues.apache.org/jira/browse/SLING-1111
> patch makes a difference?
>
> Apart from that it's certainly a bug if the script called by
> sling.include changes variables in the calling scope...thanks for
> catching that, and if you can create a JIRA issue that would be great.
>
> -Bertrand
>
Hi Bertrand,
the patch submitted in SLING-1111 didn't solve the problem of the shared
variable scopes in esp templates. I think it would make sense to create
a new JIRA issue for this bug.
Christoph
Re: OT: iterators/for-each loops (Re: sling.include only follows one
path)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Sep 24, 2009 at 7:06 AM, Markus Pallo <pa...@dig.de> wrote:
> ...I made a test and changed wall/html.esp as seen below.
> i before include is "1" and after include its "3".
> So "i" of the wall is changed by having also "i" in brickgroup template.....
>
>
>
> ---------------------------
> brickGroups = wall.getBrickGroups();
> for (i = 0; i < brickGroups.size(); i++) {
> %>
> i before include <%= i %><br/>
> <%
> sling.include(brickGroups.get(i).getPath());
> %>
> i after include <%= i %><br/>
> <%
> }
> -----------------------
Could you check if the http://issues.apache.org/jira/browse/SLING-1111
patch makes a difference?
Apart from that it's certainly a bug if the script called by
sling.include changes variables in the calling scope...thanks for
catching that, and if you can create a JIRA issue that would be great.
-Bertrand
ScriptHelper and syntheticResources
Posted by Markus Pallo <pa...@dig.de>.
Hi,
as described we are using sling with an object mapper.
------------------------------------------------
wall (sling:resourceType = "wall")
|
|--> brickgroup1 (sling:resourceType = "brickgroup")
| |
| |--> brick11 (sling:resourceType = "statichtmlbrick")
| |--> brick12 (sling:resourceType = "contentbrick")
| |--> brick13 (sling:resourceType = "contentbrick")
|
|--> brickgroup2 (sling:resourceType = "brickgroup")
|
|--> brick21 (sling:resourceType = "contentbrick")
|--> brick22 (sling:resourceType = "contentbrick")
|--> brick23 (sling:resourceType = "statichtmlbrick")
------------------------------------------------
If we include other scripts to a script, we always use
----
sling.include(brickgroup.getPath());
----
inside the script, we adapt resource to our class with an AdapterFactory.
This means, the node has always to be retrieved and mapped again by the
OR mapper.
So i am wondering if it could be useful to have a new include method on
SlingHelper to handle
public void include(Resource resource, RequestDispatcherOptions options) {
// doing similar than other includes, but with resource
}
And than i could create a PojoSyntheticResource and include directly in
the script. Benefit its already resolved and mapped....
example:
sling.include(new PojoSyntheticResource(brickgroup));
-------------------------
public class PojoSyntheticResource extends SyntheticResource {
Base base;
public PojoSyntheticResource(ResourceResolver resourceResolver, Base
base) {
this(resourceResolver, base.getPath(), base.getResourceType());
this.base = base;
}
/**
* Creates a synthetic resource with the given <code>path</code> and
* <code>resourceType</code>.
*/
protected PojoSyntheticResource(ResourceResolver resourceResolver,
String path, String resourceType) {
super(resourceResolver, path, resourceType);
}
@Override
public <Type> Type adaptTo(Class<Type> type) {
if (Base.class.isAssignableFrom(type)) {
return (Type) base;
}
return null;
}
}
-------------------------------------
Do you like to have an scriptHelper method like this ? than i would open
an jira issue. Or do you any other suggestions ?
Markus
Re: OT: iterators/for-each loops (Re: sling.include only follows
one path)
Posted by Markus Pallo <pa...@dig.de>.
Andreas Kuckartz wrote:
>> // iterate over brick groups and include them
>> brickGroups = wall.getBrickGroups();
>> for (i = 0; i < brickGroups.size(); i++) {
>> sling.include(brickGroups.get(i).getPath());
>> }
>>
>
> It is OT but in such a situation one probably could/should use a for-each loop instead:
>
> for (BrickGroup brickGroup : wall.getBrickGroups()){
> sling.include(brickGroup.getPath());
> }
>
> Cheers,
> Andreas
>
>
thanks, that gives the hint to the problem.....
I made a test and changed wall/html.esp as seen below.
i before include is "1" and after include its "3".
So "i" of the wall is changed by having also "i" in brickgroup
template.....
---------------------------
brickGroups = wall.getBrickGroups();
for (i = 0; i < brickGroups.size(); i++) {
%>
i before include <%= i %><br/>
<%
sling.include(brickGroups.get(i).getPath());
%>
i after include <%= i %><br/>
<%
}
-----------------------
Wondering if this is a bug or a feature ?
Markus
--
------------------------------------------------------------------
DIG Digitale Medienberatungs-
und Produktions- GmbH
Neckarstr. 1/5
78727 Oberndorf a. N.
Amtsgericht Stuttgart HRB 480914
Geschäftsführer: Carsten Huber
------------------------------------------------------------------
Tel: +49 (0)7423 8750 60
Fax: +49 (0)7423 8750 23
Internet: http://www.dig.de
eMail: pallo@dig.de
Ein Unternehmen der Schwarzwälder Bote Mediengruppe
OT: iterators/for-each loops (Re: sling.include only follows one
path)
Posted by Andreas Kuckartz <a....@ping.de>.
> // iterate over brick groups and include them
> brickGroups = wall.getBrickGroups();
> for (i = 0; i < brickGroups.size(); i++) {
> sling.include(brickGroups.get(i).getPath());
> }
It is OT but in such a situation one probably could/should use a for-each loop instead:
for (BrickGroup brickGroup : wall.getBrickGroups()){
sling.include(brickGroup.getPath());
}
Cheers,
Andreas
Re: sling.include only follows one path
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Christoph,
Christoph Papke schrieb:
> Hi folks,
>
> we're having a strange problem with the "sling.include"-method in our
> "esp"-templates.
>
> At the moment we're trying to develop a flexible content model for a
> newspaper company.
> Here is a short extract of our repository structure:
>
>
> ------------------------------------------------
> wall (sling:resourceType = "wall")
> |
> |--> brickgroup1 (sling:resourceType = "brickgroup")
> | |
> | |--> brick11 (sling:resourceType = "statichtmlbrick")
> | |--> brick12 (sling:resourceType = "contentbrick")
> | |--> brick13 (sling:resourceType = "contentbrick")
> |
> |--> brickgroup2 (sling:resourceType = "brickgroup")
> |
> |--> brick21 (sling:resourceType = "contentbrick")
> |--> brick22 (sling:resourceType = "contentbrick")
> |--> brick23 (sling:resourceType = "statichtmlbrick")
> ------------------------------------------------
>
>
> And here are our main templates in the "apps"-directory (hint: we use an
> OCM-framework to retrieve content from the repository):
>
>
> ------------------------------------------------
> apps/wall/html.esp:
> -------------------
> ...
> // iterate over brick groups and include them
> brickGroups = wall.getBrickGroups();
> for (i = 0; i < brickGroups.size(); i++) {
> sling.include(brickGroups.get(i).getPath());
> }
> ...
>
> apps/brickgroup/html.esp:
> -------------------------
> ...
> // iterate over bricks and include them
> bricks = brickgroup.getBricks();
> for (i = 0; i < bricks.size(); i++) {
> sling.include(bricks.get(i).getPath());
> }
> ...
>
> apps/contentbrick/html.esp:
> ---------------------------
> ...
> // include content item
> sling.include(contentbrick.getContent().getPath());
> ...
>
> apps/statichtmlbrick/html.esp:
> ------------------------------
> ...
> <%= statichtmlbrick.getHtmlText() %>
> ...
> ------------------------------------------------
>
> Now here is my problem. If "brick12" includes e.g. a referenced article,
> which has includes to other content items, then "brick13" is never
> reached in loop of the "brickgroup"-template.
Out of my belly, I would say above code should basically work unless
there is an error while handling the include of the
contentbrick.getContetn().getPath() in which case request processing may
be aborted.
You would find more information in the log file.
>
> It's the same with "brickgroup2", because "brickgroup1" also includes
> other content items.
>
> It seems that the "sling.include"-method only follows one include path.
That would be absolutely wrong and desasterous I would say. Also, you
say the "abort" happens after handling brick12 -- but at that time
brick11 and brick12 have already been handled, which makes two and not
just a single one.
>
> Is this a bug or a feature or do I get something completely wrong here?
I would assume that there is something wrong while trying to handle the
brick12 include ...
Regards
Felix