You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Gabriel Walt <gw...@adobe.com> on 2014/07/24 18:29:02 UTC
Script language independent overrides
Hi all,
Currently, when components are built with one script language (like JSP), it is hard or impossible to extend them with another script language (like Sightly).
For example, if there is a my-component/my-component.jsp, this cannot be overridden with a Sightly script in
my-sub-component/my-component.html (my-sub-component having a sling:resourceSuperType that points to my-component).
Wouldn't it be interesting to allow Sling overrides to work independently of the scripting language?
On a related topic, if a script includes another one, it is also impossible to override that included file in another scripting language.
For example, if my-component/my-component.jsp does a <sling:call script="myscript.jsp"/>, then myscript.jsp cannot be overridden with a my-sub-component/myscript.html Sightly script.
This makes the components very specific to the language they have been implemented in and not generic enough to allow developers to choose their language of choice when building upon an existing set of foundation components.
Would there be a way to improve that and remove that limitation?
Gabriel
Re: Script language independent overrides
Posted by Justin Edelson <ju...@justinedelson.com>.
Hi Catalin,
Gabriel's original post was about components extending each other
using sling:resourceSuperType, not overriding with the search path
(i.e. /apps overriding /libs). But this works as well (although it
accomplishes something very different).
I'm guessing we need ITs which demonstrate both of these cases.
They'll have to be written with ESP and JSP as that's what is
available in the IT environment.
Regards,
Justin
On Thu, Jul 24, 2014 at 12:43 PM, Catalin Buzoiu <cb...@adobe.com> wrote:
> I believe this is not currently possible because of the different extensions. The same should hold true between JSPs and ESPs, for example.
>
> Catalin
>
> Sent from my iPhone
>
> On Jul 24, 2014, at 6:35 PM, "Carsten Ziegeler" <cz...@apache.org>> wrote:
>
> Hi,
>
> isn't it the case that if the jsp is in /libs I can override it with a Sightly script in /apps ?
>
> Carsten
>
>
> 2014-07-24 18:29 GMT+02:00 Gabriel Walt <gw...@adobe.com>>:
>
> Hi all,
>
> Currently, when components are built with one script language (like JSP), it is hard or impossible to extend them with another script language (like Sightly).
>
> For example, if there is a my-component/my-component.jsp, this cannot be overridden with a Sightly script in
> my-sub-component/my-component.html (my-sub-component having a sling:resourceSuperType that points to my-component).
>
> Wouldn't it be interesting to allow Sling overrides to work independently of the scripting language?
>
> On a related topic, if a script includes another one, it is also impossible to override that included file in another scripting language.
>
> For example, if my-component/my-component.jsp does a <sling:call script="myscript.jsp"/>, then myscript.jsp cannot be overridden with a my-sub-component/myscript.html Sightly script.
>
> This makes the components very specific to the language they have been implemented in and not generic enough to allow developers to choose their language of choice when building upon an existing set of foundation components.
>
> Would there be a way to improve that and remove that limitation?
>
> Gabriel
>
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org<ma...@apache.org>
Re: Script language independent overrides
Posted by Catalin Buzoiu <cb...@adobe.com>.
I believe this is not currently possible because of the different extensions. The same should hold true between JSPs and ESPs, for example.
Catalin
Sent from my iPhone
On Jul 24, 2014, at 6:35 PM, "Carsten Ziegeler" <cz...@apache.org>> wrote:
Hi,
isn't it the case that if the jsp is in /libs I can override it with a Sightly script in /apps ?
Carsten
2014-07-24 18:29 GMT+02:00 Gabriel Walt <gw...@adobe.com>>:
Hi all,
Currently, when components are built with one script language (like JSP), it is hard or impossible to extend them with another script language (like Sightly).
For example, if there is a my-component/my-component.jsp, this cannot be overridden with a Sightly script in
my-sub-component/my-component.html (my-sub-component having a sling:resourceSuperType that points to my-component).
Wouldn't it be interesting to allow Sling overrides to work independently of the scripting language?
On a related topic, if a script includes another one, it is also impossible to override that included file in another scripting language.
For example, if my-component/my-component.jsp does a <sling:call script="myscript.jsp"/>, then myscript.jsp cannot be overridden with a my-sub-component/myscript.html Sightly script.
This makes the components very specific to the language they have been implemented in and not generic enough to allow developers to choose their language of choice when building upon an existing set of foundation components.
Would there be a way to improve that and remove that limitation?
Gabriel
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org<ma...@apache.org>
Re: Script language independent overrides
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
isn't it the case that if the jsp is in /libs I can override it with a
Sightly script in /apps ?
Carsten
2014-07-24 18:29 GMT+02:00 Gabriel Walt <gw...@adobe.com>:
>
> Hi all,
>
> Currently, when components are built with one script language (like JSP),
> it is hard or impossible to extend them with another script language (like
> Sightly).
>
> For example, if there is a my-component/my-component.jsp, this cannot be
> overridden with a Sightly script in
> my-sub-component/my-component.html (my-sub-component having a
> sling:resourceSuperType that points to my-component).
>
> Wouldn't it be interesting to allow Sling overrides to work independently
> of the scripting language?
>
> On a related topic, if a script includes another one, it is also
> impossible to override that included file in another scripting language.
>
> For example, if my-component/my-component.jsp does a <sling:call
> script="myscript.jsp"/>, then myscript.jsp cannot be overridden with a
> my-sub-component/myscript.html Sightly script.
>
> This makes the components very specific to the language they have been
> implemented in and not generic enough to allow developers to choose their
> language of choice when building upon an existing set of foundation
> components.
>
> Would there be a way to improve that and remove that limitation?
>
> Gabriel
>
>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Script language independent overrides
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
IMHO <sling:call> solves a specific problem but at the end of the day is a Sling Anti-Pattern. I am not very happy to evolve this beyond the basic functionality.
The Sling-correct way to render stuff is to use <sling:include> (or <sling:forward> if you will). As such I agree with Carsten to suggest converting the code to use <sling:include>.
In fact, the <sling:include> allows you to set a resource type along with the resource (relative) path which may create a virtual resource with the given resource type if the named resource does not exist and thus then execute the respective rendering
Regards
Felix
Am 22.08.2014 um 10:50 schrieb Gabriel Walt <gw...@adobe.com>:
>
> Thanks for your answers! Let me try to provide more context and be more
> specific.
>
> With sling:resourceSuperType (or with /apps /libs overlaying), you can
> customize any script of your component. A common practice is to split
> large script templates into partials that can then each be independently
> customized, to avoid full script duplication, and to adapt only parts
> of it.
>
> The typical example is a page component that can for instance end up with
> a structure like:
> - page.jsp
> - head.jsp
> - headlibs.jsp
> - body.jsp
> - top.jsp
> - content.jsp
> - bottom.jsp
> - bodylibs.jsp
>
> These scripts are usually all included with something like a sling:call,
> but then this makes it impossible in an extending component to use a
> different script language than the one used in the super-type (so in our
> example we'd be forced to go with JSP, and couldn't use ESP, Sightly, etc).
>
> Thus, it would be nice to be able to do an include of script partials that
> are not binding to a particular script language, like for instance:
> <sling:call script="myscript.*" />
> instead of:
> <sling:call script="myscript.jsp" />
>
> Best,
> Gabriel
>
>
Re: Script language independent overrides
Posted by Justin Edelson <ju...@justinedelson.com>.
Hi,
Adding more options to sling:include makes perfect sense, but changing
the behavior of sling:call does not. When I write
<sling:call script="foo.jsp"/>
I mean "call the script foo.jsp". I don't mean "call any script named foo."
Regards,
Justin
On Fri, Aug 22, 2014 at 6:51 AM, Julian Sedding <js...@gmail.com> wrote:
> Yes, I would be in favour of deprecating <sling:call/>. It never felt
> very "slingish". If we can also get rid of <sling:eval/>, I believe we
> could even simplify the ServletResolver and remove the methods that
> were presumably added to support these tags.
>
> One option could be to extend the <sling:call/> tag in the following fashion:
> * deprecate "script" attribute
> * if the "script" attribute is present, remove the extension (i.e.
> last dot) and interpret as selectorString
> * add new attribute "selectors", which is implemented like the
> proposed <sling:partial/> tag
>
> Unless I am missing something, this would provide backwards
> compatibility, while at the same time supporting Gabriel's use-case.
>
> Regards
> Julian
Re: Script language independent overrides
Posted by Julian Sedding <js...@gmail.com>.
If we can keep the <sling:include/> tag easy to understand, I would be
happy with such an approach. I fear, however, that it could get overly
complicated.
Just for consideration, I see these two use-cases:
* include a resource (currently <sling:include/>); this typically
re-dispatches the request internally
* modularize rendering scripts (currently <sling:call/>); this does
not re-dispatch the request, the context remains the same
Do the two use-cases justify separate tags? I don't know.
Regards
Julian
On Fri, Aug 22, 2014 at 12:56 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> I would be in favour of having just one tag, the include one - so if I see
> it correctly the only problem is that it changes the set of visible
> selectors. So if we allow a way to deal with that with the include tag, we
> have a single tag and people have not to wonder which tag to use when.
>
> Carsten
>
>
> 2014-08-22 12:51 GMT+02:00 Julian Sedding <js...@gmail.com>:
>
>> Yes, I would be in favour of deprecating <sling:call/>. It never felt
>> very "slingish". If we can also get rid of <sling:eval/>, I believe we
>> could even simplify the ServletResolver and remove the methods that
>> were presumably added to support these tags.
>>
>> One option could be to extend the <sling:call/> tag in the following
>> fashion:
>> * deprecate "script" attribute
>> * if the "script" attribute is present, remove the extension (i.e.
>> last dot) and interpret as selectorString
>> * add new attribute "selectors", which is implemented like the
>> proposed <sling:partial/> tag
>>
>> Unless I am missing something, this would provide backwards
>> compatibility, while at the same time supporting Gabriel's use-case.
>>
>> Regards
>> Julian
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: Script language independent overrides
Posted by Carsten Ziegeler <cz...@apache.org>.
I would be in favour of having just one tag, the include one - so if I see
it correctly the only problem is that it changes the set of visible
selectors. So if we allow a way to deal with that with the include tag, we
have a single tag and people have not to wonder which tag to use when.
Carsten
2014-08-22 12:51 GMT+02:00 Julian Sedding <js...@gmail.com>:
> Yes, I would be in favour of deprecating <sling:call/>. It never felt
> very "slingish". If we can also get rid of <sling:eval/>, I believe we
> could even simplify the ServletResolver and remove the methods that
> were presumably added to support these tags.
>
> One option could be to extend the <sling:call/> tag in the following
> fashion:
> * deprecate "script" attribute
> * if the "script" attribute is present, remove the extension (i.e.
> last dot) and interpret as selectorString
> * add new attribute "selectors", which is implemented like the
> proposed <sling:partial/> tag
>
> Unless I am missing something, this would provide backwards
> compatibility, while at the same time supporting Gabriel's use-case.
>
> Regards
> Julian
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Script language independent overrides
Posted by Julian Sedding <js...@gmail.com>.
Yes, I would be in favour of deprecating <sling:call/>. It never felt
very "slingish". If we can also get rid of <sling:eval/>, I believe we
could even simplify the ServletResolver and remove the methods that
were presumably added to support these tags.
One option could be to extend the <sling:call/> tag in the following fashion:
* deprecate "script" attribute
* if the "script" attribute is present, remove the extension (i.e.
last dot) and interpret as selectorString
* add new attribute "selectors", which is implemented like the
proposed <sling:partial/> tag
Unless I am missing something, this would provide backwards
compatibility, while at the same time supporting Gabriel's use-case.
Regards
Julian
Re: Script language independent overrides
Posted by Carsten Ziegeler <cz...@apache.org>.
If you pass in the resource object into include, no resource solution is
done, though it changes the selectors.
Instead of adding another tag which makes it more unclear, whether to use
include, call, or partial - why not add an option to the include tag?
And if call has been invented to circumvent the above things, why not
deprecate it then?
Carsten
2014-08-22 12:30 GMT+02:00 Julian Sedding <js...@gmail.com>:
> The approach mentioned by Carsten has two drawbacks:
> * it changes the selectors seen by any scripts included further down
> the include stack (IIRC this was the reason why <sling:call/> was
> introduced in the first place)
> * resourceResolution has to be done again, even though we know we want
> to render the same resource (maybe <sling:include
> resource="${resource}"/> also prevents this, I didn't check)
>
> I created SLING-3874[0] with a proof-of-concept implementation for a
> <sling:partial/> tag. This allows selecting another rendering script
> for the current resource with the specified selector. Downstream
> includes are not affected by this, however.
>
> Example page.jsp (see Gabriel's example above):
> <html>
> <sling:partial selectors="head"/>
> <sling:partial selectors="body"/>
> </html>
>
> Regards
> Julian
>
> [0] https://issues.apache.org/jira/browse/SLING-3874
>
> On Fri, Aug 22, 2014 at 12:11 PM, Gabriel Walt <gw...@adobe.com> wrote:
> >
> > Wow, couldn't believe this was working, very nice!! :)
> >
> > Thanks!
> >
> >
> > On 22/08/14 11:17, "Carsten Ziegeler" <cz...@apache.org> wrote:
> >
> >>You can simply use sling:include instead, add a selector and your script
> >>act on that specific selector - that's language independent.
> >>
> >>Carsten
> >>
> >>
> >>2014-08-22 10:50 GMT+02:00 Gabriel Walt <gw...@adobe.com>:
> >>
> >>>
> >>> Thanks for your answers! Let me try to provide more context and be more
> >>> specific.
> >>>
> >>> With sling:resourceSuperType (or with /apps /libs overlaying), you can
> >>> customize any script of your component. A common practice is to split
> >>> large script templates into partials that can then each be
> independently
> >>> customized, to avoid full script duplication, and to adapt only parts
> >>> of it.
> >>>
> >>> The typical example is a page component that can for instance end up
> >>>with
> >>> a structure like:
> >>> - page.jsp
> >>> - head.jsp
> >>> - headlibs.jsp
> >>> - body.jsp
> >>> - top.jsp
> >>> - content.jsp
> >>> - bottom.jsp
> >>> - bodylibs.jsp
> >>>
> >>> These scripts are usually all included with something like a
> sling:call,
> >>> but then this makes it impossible in an extending component to use a
> >>> different script language than the one used in the super-type (so in
> our
> >>> example we'd be forced to go with JSP, and couldn't use ESP, Sightly,
> >>>etc).
> >>>
> >>> Thus, it would be nice to be able to do an include of script partials
> >>>that
> >>> are not binding to a particular script language, like for instance:
> >>> <sling:call script="myscript.*" />
> >>> instead of:
> >>> <sling:call script="myscript.jsp" />
> >>>
> >>> Best,
> >>> Gabriel
> >>>
> >>>
> >>>
> >>
> >>
> >>--
> >>Carsten Ziegeler
> >>Adobe Research Switzerland
> >>cziegeler@apache.org
> >
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Script language independent overrides
Posted by Julian Sedding <js...@gmail.com>.
The approach mentioned by Carsten has two drawbacks:
* it changes the selectors seen by any scripts included further down
the include stack (IIRC this was the reason why <sling:call/> was
introduced in the first place)
* resourceResolution has to be done again, even though we know we want
to render the same resource (maybe <sling:include
resource="${resource}"/> also prevents this, I didn't check)
I created SLING-3874[0] with a proof-of-concept implementation for a
<sling:partial/> tag. This allows selecting another rendering script
for the current resource with the specified selector. Downstream
includes are not affected by this, however.
Example page.jsp (see Gabriel's example above):
<html>
<sling:partial selectors="head"/>
<sling:partial selectors="body"/>
</html>
Regards
Julian
[0] https://issues.apache.org/jira/browse/SLING-3874
On Fri, Aug 22, 2014 at 12:11 PM, Gabriel Walt <gw...@adobe.com> wrote:
>
> Wow, couldn't believe this was working, very nice!! :)
>
> Thanks!
>
>
> On 22/08/14 11:17, "Carsten Ziegeler" <cz...@apache.org> wrote:
>
>>You can simply use sling:include instead, add a selector and your script
>>act on that specific selector - that's language independent.
>>
>>Carsten
>>
>>
>>2014-08-22 10:50 GMT+02:00 Gabriel Walt <gw...@adobe.com>:
>>
>>>
>>> Thanks for your answers! Let me try to provide more context and be more
>>> specific.
>>>
>>> With sling:resourceSuperType (or with /apps /libs overlaying), you can
>>> customize any script of your component. A common practice is to split
>>> large script templates into partials that can then each be independently
>>> customized, to avoid full script duplication, and to adapt only parts
>>> of it.
>>>
>>> The typical example is a page component that can for instance end up
>>>with
>>> a structure like:
>>> - page.jsp
>>> - head.jsp
>>> - headlibs.jsp
>>> - body.jsp
>>> - top.jsp
>>> - content.jsp
>>> - bottom.jsp
>>> - bodylibs.jsp
>>>
>>> These scripts are usually all included with something like a sling:call,
>>> but then this makes it impossible in an extending component to use a
>>> different script language than the one used in the super-type (so in our
>>> example we'd be forced to go with JSP, and couldn't use ESP, Sightly,
>>>etc).
>>>
>>> Thus, it would be nice to be able to do an include of script partials
>>>that
>>> are not binding to a particular script language, like for instance:
>>> <sling:call script="myscript.*" />
>>> instead of:
>>> <sling:call script="myscript.jsp" />
>>>
>>> Best,
>>> Gabriel
>>>
>>>
>>>
>>
>>
>>--
>>Carsten Ziegeler
>>Adobe Research Switzerland
>>cziegeler@apache.org
>
Re: Script language independent overrides
Posted by Gabriel Walt <gw...@adobe.com>.
Wow, couldn't believe this was working, very nice!! :)
Thanks!
On 22/08/14 11:17, "Carsten Ziegeler" <cz...@apache.org> wrote:
>You can simply use sling:include instead, add a selector and your script
>act on that specific selector - that's language independent.
>
>Carsten
>
>
>2014-08-22 10:50 GMT+02:00 Gabriel Walt <gw...@adobe.com>:
>
>>
>> Thanks for your answers! Let me try to provide more context and be more
>> specific.
>>
>> With sling:resourceSuperType (or with /apps /libs overlaying), you can
>> customize any script of your component. A common practice is to split
>> large script templates into partials that can then each be independently
>> customized, to avoid full script duplication, and to adapt only parts
>> of it.
>>
>> The typical example is a page component that can for instance end up
>>with
>> a structure like:
>> - page.jsp
>> - head.jsp
>> - headlibs.jsp
>> - body.jsp
>> - top.jsp
>> - content.jsp
>> - bottom.jsp
>> - bodylibs.jsp
>>
>> These scripts are usually all included with something like a sling:call,
>> but then this makes it impossible in an extending component to use a
>> different script language than the one used in the super-type (so in our
>> example we'd be forced to go with JSP, and couldn't use ESP, Sightly,
>>etc).
>>
>> Thus, it would be nice to be able to do an include of script partials
>>that
>> are not binding to a particular script language, like for instance:
>> <sling:call script="myscript.*" />
>> instead of:
>> <sling:call script="myscript.jsp" />
>>
>> Best,
>> Gabriel
>>
>>
>>
>
>
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>cziegeler@apache.org
Re: Script language independent overrides
Posted by Carsten Ziegeler <cz...@apache.org>.
You can simply use sling:include instead, add a selector and your script
act on that specific selector - that's language independent.
Carsten
2014-08-22 10:50 GMT+02:00 Gabriel Walt <gw...@adobe.com>:
>
> Thanks for your answers! Let me try to provide more context and be more
> specific.
>
> With sling:resourceSuperType (or with /apps /libs overlaying), you can
> customize any script of your component. A common practice is to split
> large script templates into partials that can then each be independently
> customized, to avoid full script duplication, and to adapt only parts
> of it.
>
> The typical example is a page component that can for instance end up with
> a structure like:
> - page.jsp
> - head.jsp
> - headlibs.jsp
> - body.jsp
> - top.jsp
> - content.jsp
> - bottom.jsp
> - bodylibs.jsp
>
> These scripts are usually all included with something like a sling:call,
> but then this makes it impossible in an extending component to use a
> different script language than the one used in the super-type (so in our
> example we'd be forced to go with JSP, and couldn't use ESP, Sightly, etc).
>
> Thus, it would be nice to be able to do an include of script partials that
> are not binding to a particular script language, like for instance:
> <sling:call script="myscript.*" />
> instead of:
> <sling:call script="myscript.jsp" />
>
> Best,
> Gabriel
>
>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Script language independent overrides
Posted by Gabriel Walt <gw...@adobe.com>.
Thanks for your answers! Let me try to provide more context and be more
specific.
With sling:resourceSuperType (or with /apps /libs overlaying), you can
customize any script of your component. A common practice is to split
large script templates into partials that can then each be independently
customized, to avoid full script duplication, and to adapt only parts
of it.
The typical example is a page component that can for instance end up with
a structure like:
- page.jsp
- head.jsp
- headlibs.jsp
- body.jsp
- top.jsp
- content.jsp
- bottom.jsp
- bodylibs.jsp
These scripts are usually all included with something like a sling:call,
but then this makes it impossible in an extending component to use a
different script language than the one used in the super-type (so in our
example we'd be forced to go with JSP, and couldn't use ESP, Sightly, etc).
Thus, it would be nice to be able to do an include of script partials that
are not binding to a particular script language, like for instance:
<sling:call script="myscript.*" />
instead of:
<sling:call script="myscript.jsp" />
Best,
Gabriel
Re: Script language independent overrides
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 24.07.2014, at 19:11, Justin Edelson <ju...@justinedelson.com> wrote:
> If the author didn't want to
> do that, they shouldn't use sling:call and instead use sling:include
> with replaceSelectors.
Right. sling:call addresses the script and that is simply wrong - it needs to be a sling:include and strictly rely on sling resource resolution (selectors, extensions etc.). If you use sling:call and address the script, you of course tie yourself to the script engine in question (i.e. usually JSP).
Cheers,
Alex
Re: Script language independent overrides
Posted by Justin Edelson <ju...@justinedelson.com>.
Gabriel-
IMHO, your scenario is invalid and has nothing to do with the
difference in scripting engines. If you have
my-component/my-component.jsp and my-sub-component has a
sling:resourceSuperType of my-component, then the correct way to have
a script for my-sub-component is to call that script
my-sub-component.<ext> (where ext could be any valid script
extension).
To be clear, this is specific to the use of the component name as the
script name. If instead, you named these scripts html.<ext>, then the
name would be consistent, i.e. my-sub-component/html.html will
override my-component/html.jsp.
The point you make about sling:call is different. That's an
implementation choice of the author of the base component to tie their
component to a specific scripting engine. If the author didn't want to
do that, they shouldn't use sling:call and instead use sling:include
with replaceSelectors.
Regards,
Justin
On Thu, Jul 24, 2014 at 12:29 PM, Gabriel Walt <gw...@adobe.com> wrote:
>
> Hi all,
>
> Currently, when components are built with one script language (like JSP), it is hard or impossible to extend them with another script language (like Sightly).
>
> For example, if there is a my-component/my-component.jsp, this cannot be overridden with a Sightly script in
> my-sub-component/my-component.html (my-sub-component having a sling:resourceSuperType that points to my-component).
>
> Wouldn't it be interesting to allow Sling overrides to work independently of the scripting language?
>
> On a related topic, if a script includes another one, it is also impossible to override that included file in another scripting language.
>
> For example, if my-component/my-component.jsp does a <sling:call script="myscript.jsp"/>, then myscript.jsp cannot be overridden with a my-sub-component/myscript.html Sightly script.
>
> This makes the components very specific to the language they have been implemented in and not generic enough to allow developers to choose their language of choice when building upon an existing set of foundation components.
>
> Would there be a way to improve that and remove that limitation?
>
> Gabriel
>
>