You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2007/10/19 10:20:30 UTC
We need an equivalent of sling:include in microsling
Hi,
Maybe an interface like this (to be expanded with more useful
functions) would be good?
public interface SlingScriptHelpers {
/** Include the resource pointed to by the given path in the
current response */
void include(String relativeOrAbsolutePath) throws IOException,
ServletException;
}
And this would be made available to scripts as a variable named "sling".
I haven't looked in detail at the existing Sling stuff, so we might
need more than that?
(keeping in mind the minimalism of microsling)
-Bertrand
Re: We need an equivalent of sling:include in microsling
Posted by Felix Meschberger <fm...@gmail.com>.
Ok, I will add such a thing while resolving the script stuff.
Regards
Felix
Am Freitag, den 19.10.2007, 14:55 +0200 schrieb Bertrand Delacretaz:
> On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
> > ...I would not create another interface for this. A simple bean class
> > should probably suffice it, I think ...
>
> The same idea occured to me while riding my bike to lunch. Riding
> bikes is a Good Thing ;-)
>
> So I agree on using a simple wrapper class, without adding another
> interface to the API.
>
> -Bertrand
Re: We need an equivalent of sling:include in microsling
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
> ...I would not create another interface for this. A simple bean class
> should probably suffice it, I think ...
The same idea occured to me while riding my bike to lunch. Riding
bikes is a Good Thing ;-)
So I agree on using a simple wrapper class, without adding another
interface to the API.
-Bertrand
Re: We need an equivalent of sling:include in microsling
Posted by Felix Meschberger <fm...@gmail.com>.
I would not create another interface for this. A simple bean class
should probably suffice it, I think ...
Regards
Felix
Am Freitag, den 19.10.2007, 11:32 +0200 schrieb Bertrand Delacretaz:
> On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
> > So we would probably have:
> >
> > public class Sling {
> ...
> > public void include(String path) throws ServletException, IOException
> ...
>
> Yes, something like that.
>
> I wouldn't call the class "Sling" though, as it's not sling, it's only
> a poor lonesome helper class. But I'd call the variable that holds
> this in scripts "sling".
>
> > Would this be for scripting-only ?
>
> It doesn't have to, but as you mentioned it makes less sense in java
> code, where people are expected to know their J2EE stuff.
>
> That's why I called the interface SlingScriptHelpers in my initial
> suggestion: it's usually meant for scripting, but of course people can
> use it in java code if they want.
>
> -Bertrand
Re: We need an equivalent of sling:include in microsling
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
> So we would probably have:
>
> public class Sling {
...
> public void include(String path) throws ServletException, IOException
...
Yes, something like that.
I wouldn't call the class "Sling" though, as it's not sling, it's only
a poor lonesome helper class. But I'd call the variable that holds
this in scripts "sling".
> Would this be for scripting-only ?
It doesn't have to, but as you mentioned it makes less sense in java
code, where people are expected to know their J2EE stuff.
That's why I called the interface SlingScriptHelpers in my initial
suggestion: it's usually meant for scripting, but of course people can
use it in java code if they want.
-Bertrand
Re: We need an equivalent of sling:include in microsling
Posted by Felix Meschberger <fm...@gmail.com>.
So we would probably have:
public class Sling {
private HttpServletRequest request;
private HttpServletResponse response;
public void include(String path) throws ServletException, IOException
{
RequestDispatcher rd = request.getRequestDispatcher(path);
rd.include(request, response);
}
}
Would this be for scripting-only ?
Regards
Felix
Am Freitag, den 19.10.2007, 10:57 +0200 schrieb Bertrand Delacretaz:
> On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
>
> > > ...a convenience class should encapsulate this in order to
> > > make microsling easy to use. either:
> > > sling.include(...)
> > > document.include(...)
> > > response.include(...)
> >
> > Would not do that. People know the Servlet API and we should not invent
> > additional helper stuff, which is just hard to maintain. Rather we will
> > provide taglibs for JSP (in Sling not microsling, though).
>
> Why taglibs for JSP and no equivalents for other languages?
>
> In my view of microsling's target audience, people should not need to
> know the Servlet API to do a simple include: that's something people
> do all the time, so it should be obvious.
>
> And I don't want to cripple microsling either, it's smaller than
> Sling, less extensible, and lacks enterprise-level features maybe, but
> microsling users should not feel like second-class citizens, IMHO.
>
> So I really think we need a comfortable way to include content in
> microsling scripts.
>
> -Bertrand
Re: We need an equivalent of sling:include in microsling
Posted by Philipp Koch <ph...@day.com>.
> So I really think we need a comfortable way to include content in
> microsling scripts.
this makes sense since we could support for different scripting languages.
regards,
philipp
On 10/19/07, Bertrand Delacretaz <bd...@apache.org> wrote:
> On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
>
> > > ...a convenience class should encapsulate this in order to
> > > make microsling easy to use. either:
> > > sling.include(...)
> > > document.include(...)
> > > response.include(...)
> >
> > Would not do that. People know the Servlet API and we should not invent
> > additional helper stuff, which is just hard to maintain. Rather we will
> > provide taglibs for JSP (in Sling not microsling, though).
>
> Why taglibs for JSP and no equivalents for other languages?
>
> In my view of microsling's target audience, people should not need to
> know the Servlet API to do a simple include: that's something people
> do all the time, so it should be obvious.
>
> And I don't want to cripple microsling either, it's smaller than
> Sling, less extensible, and lacks enterprise-level features maybe, but
> microsling users should not feel like second-class citizens, IMHO.
>
> So I really think we need a comfortable way to include content in
> microsling scripts.
>
> -Bertrand
>
Re: We need an equivalent of sling:include in microsling
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
> > ...a convenience class should encapsulate this in order to
> > make microsling easy to use. either:
> > sling.include(...)
> > document.include(...)
> > response.include(...)
>
> Would not do that. People know the Servlet API and we should not invent
> additional helper stuff, which is just hard to maintain. Rather we will
> provide taglibs for JSP (in Sling not microsling, though).
Why taglibs for JSP and no equivalents for other languages?
In my view of microsling's target audience, people should not need to
know the Servlet API to do a simple include: that's something people
do all the time, so it should be obvious.
And I don't want to cripple microsling either, it's smaller than
Sling, less extensible, and lacks enterprise-level features maybe, but
microsling users should not feel like second-class citizens, IMHO.
So I really think we need a comfortable way to include content in
microsling scripts.
-Bertrand
Re: We need an equivalent of sling:include in microsling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Freitag, den 19.10.2007, 10:34 +0200 schrieb Tobias Bocanegra:
> for example:
> document.write(...) would write to the response writer
JSP defines the writer using the variable out, so we should use that
name. The EspReader will create the out value on demand while for Plain
Javascript files the writer must be explicitly retrieved from the
response.
For Velocity Templates the response writer is used to evaluate the
template in the first place.
> but of course, a convenience class should encapsulate this in order to
> make microsling easy to use. either:
> sling.include(...)
> document.include(...)
> response.include(...)
Would not do that. People know the Servlet API and we should not invent
additional helper stuff, which is just hard to maintain. Rather we will
provide taglibs for JSP (in Sling not microsling, though).
Regards
Felix
Re: We need an equivalent of sling:include in microsling
Posted by Tobias Bocanegra <to...@day.com>.
> Maybe an interface like this (to be expanded with more useful
> functions) would be good?
>
> public interface SlingScriptHelpers {
> /** Include the resource pointed to by the given path in the
> current response */
> void include(String relativeOrAbsolutePath) throws IOException,
> ServletException;
> }
>
> And this would be made available to scripts as a variable named "sling".
>
> I haven't looked in detail at the existing Sling stuff, so we might
> need more than that?
> (keeping in mind the minimalism of microsling)
the j2ee equivalent would be:
req.getRequestDispatcher(path).include(req, resp);
right? so i think this very same mechanism should also be available
for the scripts.
we need to define how the j2ee context is exposed to the script.
for example, i would expect that in esp, there would be 'document' or
'context' field exposed.
for example:
document.write(...) would write to the response writer
and
response.setContentType(...) would set the response content type
so:
request.getRequestDispatcher(...).include(reqest, response) should
actually work.
but of course, a convenience class should encapsulate this in order to
make microsling easy to use. either:
sling.include(...)
document.include(...)
response.include(...)
regards, toby
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: We need an equivalent of sling:include in microsling
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
> ...We have the Servlet Request Dispatcher, which IMHO should be used in
> microsling (using as much of existing/known API as possible)...
Sure, that was the plan.
> ...Thus a
> script may easily do request.getRequestDispatch(path).include(req, res)....
I agree that that would work, but Isn't that a bit ugly to do in a script?
As it's something that people do all the time, I'd like to provide a
simple call like "sling.include(relativeOrAbsolutePath)" to be used in
ESP and Velocity templates for example.
> ...Optionally, we might want to add support for retrieving a
> RequestDispatchre using a Resource object, but I am not sure whether we
> already require this in microsling....
Probably not, I agree.
-Bertrand
Re: We need an equivalent of sling:include in microsling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
We have the Servlet Request Dispatcher, which IMHO should be used in
microsling (using as much of existing/known API as possible). My
proposal of SLING-64 incorporates a uniform way of calling the scripts
always providing the request, response and context objects. Thus a
script may easily do request.getRequestDispatch(path).include(req, res).
Optionally, we might want to add support for retrieving a
RequestDispatchre using a Resource object, but I am not sure whether we
already require this in microsling.
Regards
Felix
Am Freitag, den 19.10.2007, 10:20 +0200 schrieb Bertrand Delacretaz:
> Hi,
>
> Maybe an interface like this (to be expanded with more useful
> functions) would be good?
>
> public interface SlingScriptHelpers {
> /** Include the resource pointed to by the given path in the
> current response */
> void include(String relativeOrAbsolutePath) throws IOException,
> ServletException;
> }
>
> And this would be made available to scripts as a variable named "sling".
>
> I haven't looked in detail at the existing Sling stuff, so we might
> need more than that?
> (keeping in mind the minimalism of microsling)
>
> -Bertrand