You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Michael Marth <mm...@day.com> on 2007/10/18 18:03:18 UTC
microsling user feedback
Hi,
Bertrand has asked me to give some user feedback on microsling on this list.
I have been playing with microsling for just one day now and did not have a
look at (full) sling, yet, but from my very limited understanding so far the
issues I found should apply to sling as well.
First of all, I very much like the idea of having a simple, lightweight
framework for creating web apps on top of JCRs. microsling seems to go in
the right direction. I like it.
Some problems I had on the way (my use case was a blogging app):
conceptual stuff:
- I was wondering how I can have several templates for one content type. I
could work around this issue in my very simple case, but how can I have e.g.
an edit template and a view template for a blog entry (depending on some
request parameter or so)?
Related to this: how can I render node X when node Y is requested? In my
case: I got a blog entry (node Y) that has several comments (nodes X) that I
want to display on the same page. In Ruby on Rails there is the concept of
partial templates and I was expecting something similar. I understand that I
can traverse the JCR and grab the corresponding nodes (which I did) but in
that case I need to copy template code (re partial templates: the idea is
basically that an object exposes different methods to render itself. In the
contect of sling this idea of might clash with sling's concept of pluggable
presentation scripting engines, though. If so, I'd prefer microsling to be
opinionated<http://gettingreal.37signals.com/ch04_Make_Opinionated_Software.php>,
i.e. decide on one scripting engine).
- the content templates reside in the repository (i.e . on a WebDAV drive in
my case). However, static html pages need to reside in the war file. In my
use case this was especially weird, because the comment input forms were in
the repository (because they are located on the blog entry renderer page)
where as the "create new blog entry" form was in the war file. I would
prefer if I could put all my templates and static content in the repository.
- it seems to me that content I want to render needs to have the property
"slingResourceType" (is that really correct?). Not a big problem for new web
apps, but really a bit intrusive. I mean, the presentation app shouldnt
require changes on the content.
Some other feedback:
- the SlingPostServlet should provide some mechanism to a) let the user set
the name of the node to be created (I take it that's obvious anyway) and b)
set the node type and mixins. Maybe similar to the "slingResourceType"
mechanism?
- I was wondering how I can use the repository authentication and
authorization mechanisms for my app. Could someone give me a pointer,
please?
Cheers
Michael
Re: microsling user feedback
Posted by Tobias Bocanegra <to...@day.com>.
> microsling does no auth at all at the moment !
ok. sorry for allege that. i didn't look at the code :-)
>
> This must be something that Michael did with his support for WebDAV
> redirection stuff. He would have to show the scripts for us to further
> help.
>
> Regards
> Felix
>
> >
> > - grab the credentials from the request and construct
> > SimpleCredentiials. if there are no credentials, use NULL
> > - login to the repository
> > - if login fails, send a 401
> >
> > i don't know why the webdav servlet sends a 401...actually it should
> > allow anonymous access.
> > regards, toby
> >
> >
> >
> > > >
> > > > Cheers
> > > > Michael
> > > >
> > > >
> > > > On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Am Freitag, den 19.10.2007, 15:09 +0200 schrieb David Nuescheler:
> > > > > > Therefore I think that a GET to the exact repository path should
> > > > > > generally be handled the same way as the WebDAV GET.
> > > > > > I think this is very easy to understand for everybody and
> > > > > > means that microsling generally works just like every
> > > > > > other WebDAV enabled webserver for everything that is
> > > > > > static.
> > > > >
> > > > > This sounds very plausible, but has some implications, which turn out to
> > > > > be somewhat problematic. Therefore, I just added a StreamServlet which
> > > > > streams a resource of type nt:file (which is most likely what is
> > > > > required by Michael) and in addition support If-Modified-Since header
> > > > > such that a 304 may be sent back just in case.
> > > > >
> > > > > This more or less should match, what WebDAV does in this respect, and I
> > > > > think we are done without any special handling.
> > > > >
> > > > > > Personally, I think that this is a very simple and
> > > > > > straightforward solution that leverages a lot of features
> > > > > > implemented in WebDAV entirely correctly.
> > > > > > Think of etag or modified since behaviour on GET
> > > > > > or PUT and DELETE which all would have to be
> > > > > > re-implemented in microsling.
> > > > >
> > > > > Streaming out of a Sling Application currently only discusses reading
> > > > > (GET) not updating, which is done as described by Betrand using access
> > > > > to the WebDAV servlet included with microsling.
> > > > >
> > > > > > Generally I think WebDAV is very Restful and a very
> > > > > > good basis to start and sort of decorate microsling
> > > > > > on top of a webdav enabled server.
> > > > >
> > > > > This sounds like an interesting point, though: Running Sling/microsling
> > > > > ontop of a WebDAV server instead of a repository .... :-)
> > > > >
> > > > > > I think assuming assuming that people add an extension
> > > > > > to let's say /content/mypage when GETting /content/mypage.html
> > > > > > though microsling is good practice anyway.
> > > > >
> > > > > Definitely, it also helps determine the default response content type.
> > > > >
> > > > > Regards
> > > > > Felix
> > > > >
> > > > >
> > >
> > >
> >
> >
>
>
--
-----------------------------------------< 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: microsling user feedback
Posted by Felix Meschberger <fm...@gmail.com>.
Am Freitag, den 19.10.2007, 17:51 +0200 schrieb Tobias Bocanegra:
> > > Even for resources that are readable for for anonymous users I get the basic
> > > authentication popup of the browser. Surely, this can be suppressed (maybe
> > > by wrapping the WebDAV servlet?). But this also made me wonder how the
> > > single-sign-on would work between a (raw, unwrapped) WebDAV-based part (that
> > > uses basic authent) and microsling (that uses the jsessionid cookie/Java
> > > appserver mechanisms)? microsling could of course accept the basic
> > > authentication headers if a WebDAV login occurred first, but how would it
> > > work the other way round?
> first, why does microsling do a jesseionid based auth? i don't see the
> need to this at all (at least for the default auth handler). the way
> basic auth should work is:
microsling does no auth at all at the moment !
This must be something that Michael did with his support for WebDAV
redirection stuff. He would have to show the scripts for us to further
help.
Regards
Felix
>
> - grab the credentials from the request and construct
> SimpleCredentiials. if there are no credentials, use NULL
> - login to the repository
> - if login fails, send a 401
>
> i don't know why the webdav servlet sends a 401...actually it should
> allow anonymous access.
> regards, toby
>
>
>
> > >
> > > Cheers
> > > Michael
> > >
> > >
> > > On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Am Freitag, den 19.10.2007, 15:09 +0200 schrieb David Nuescheler:
> > > > > Therefore I think that a GET to the exact repository path should
> > > > > generally be handled the same way as the WebDAV GET.
> > > > > I think this is very easy to understand for everybody and
> > > > > means that microsling generally works just like every
> > > > > other WebDAV enabled webserver for everything that is
> > > > > static.
> > > >
> > > > This sounds very plausible, but has some implications, which turn out to
> > > > be somewhat problematic. Therefore, I just added a StreamServlet which
> > > > streams a resource of type nt:file (which is most likely what is
> > > > required by Michael) and in addition support If-Modified-Since header
> > > > such that a 304 may be sent back just in case.
> > > >
> > > > This more or less should match, what WebDAV does in this respect, and I
> > > > think we are done without any special handling.
> > > >
> > > > > Personally, I think that this is a very simple and
> > > > > straightforward solution that leverages a lot of features
> > > > > implemented in WebDAV entirely correctly.
> > > > > Think of etag or modified since behaviour on GET
> > > > > or PUT and DELETE which all would have to be
> > > > > re-implemented in microsling.
> > > >
> > > > Streaming out of a Sling Application currently only discusses reading
> > > > (GET) not updating, which is done as described by Betrand using access
> > > > to the WebDAV servlet included with microsling.
> > > >
> > > > > Generally I think WebDAV is very Restful and a very
> > > > > good basis to start and sort of decorate microsling
> > > > > on top of a webdav enabled server.
> > > >
> > > > This sounds like an interesting point, though: Running Sling/microsling
> > > > ontop of a WebDAV server instead of a repository .... :-)
> > > >
> > > > > I think assuming assuming that people add an extension
> > > > > to let's say /content/mypage when GETting /content/mypage.html
> > > > > though microsling is good practice anyway.
> > > >
> > > > Definitely, it also helps determine the default response content type.
> > > >
> > > > Regards
> > > > Felix
> > > >
> > > >
> >
> >
>
>
Re: microsling user feedback
Posted by Tobias Bocanegra <to...@day.com>.
> > Even for resources that are readable for for anonymous users I get the basic
> > authentication popup of the browser. Surely, this can be suppressed (maybe
> > by wrapping the WebDAV servlet?). But this also made me wonder how the
> > single-sign-on would work between a (raw, unwrapped) WebDAV-based part (that
> > uses basic authent) and microsling (that uses the jsessionid cookie/Java
> > appserver mechanisms)? microsling could of course accept the basic
> > authentication headers if a WebDAV login occurred first, but how would it
> > work the other way round?
first, why does microsling do a jesseionid based auth? i don't see the
need to this at all (at least for the default auth handler). the way
basic auth should work is:
- grab the credentials from the request and construct
SimpleCredentiials. if there are no credentials, use NULL
- login to the repository
- if login fails, send a 401
i don't know why the webdav servlet sends a 401...actually it should
allow anonymous access.
regards, toby
> >
> > Cheers
> > Michael
> >
> >
> > On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > Am Freitag, den 19.10.2007, 15:09 +0200 schrieb David Nuescheler:
> > > > Therefore I think that a GET to the exact repository path should
> > > > generally be handled the same way as the WebDAV GET.
> > > > I think this is very easy to understand for everybody and
> > > > means that microsling generally works just like every
> > > > other WebDAV enabled webserver for everything that is
> > > > static.
> > >
> > > This sounds very plausible, but has some implications, which turn out to
> > > be somewhat problematic. Therefore, I just added a StreamServlet which
> > > streams a resource of type nt:file (which is most likely what is
> > > required by Michael) and in addition support If-Modified-Since header
> > > such that a 304 may be sent back just in case.
> > >
> > > This more or less should match, what WebDAV does in this respect, and I
> > > think we are done without any special handling.
> > >
> > > > Personally, I think that this is a very simple and
> > > > straightforward solution that leverages a lot of features
> > > > implemented in WebDAV entirely correctly.
> > > > Think of etag or modified since behaviour on GET
> > > > or PUT and DELETE which all would have to be
> > > > re-implemented in microsling.
> > >
> > > Streaming out of a Sling Application currently only discusses reading
> > > (GET) not updating, which is done as described by Betrand using access
> > > to the WebDAV servlet included with microsling.
> > >
> > > > Generally I think WebDAV is very Restful and a very
> > > > good basis to start and sort of decorate microsling
> > > > on top of a webdav enabled server.
> > >
> > > This sounds like an interesting point, though: Running Sling/microsling
> > > ontop of a WebDAV server instead of a repository .... :-)
> > >
> > > > I think assuming assuming that people add an extension
> > > > to let's say /content/mypage when GETting /content/mypage.html
> > > > though microsling is good practice anyway.
> > >
> > > Definitely, it also helps determine the default response content type.
> > >
> > > Regards
> > > Felix
> > >
> > >
>
>
--
-----------------------------------------< 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: microsling user feedback
Posted by Felix Meschberger <fm...@gmail.com>.
Another case for my point, that we should keep the WebDAV servlet and
the microsling servlet separate :-)
Regards
Felix
Am Freitag, den 19.10.2007, 17:13 +0200 schrieb Michael Marth:
> Hi,
>
> I gave it a shot to put the static resources in the repository and access
> them through WebDAV. It worked, but there is one issue that I would like to
> mention in this discussion about the correct implementation:
>
> Even for resources that are readable for for anonymous users I get the basic
> authentication popup of the browser. Surely, this can be suppressed (maybe
> by wrapping the WebDAV servlet?). But this also made me wonder how the
> single-sign-on would work between a (raw, unwrapped) WebDAV-based part (that
> uses basic authent) and microsling (that uses the jsessionid cookie/Java
> appserver mechanisms)? microsling could of course accept the basic
> authentication headers if a WebDAV login occurred first, but how would it
> work the other way round?
>
> Cheers
> Michael
>
>
> On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
> >
> > Hi,
> >
> > Am Freitag, den 19.10.2007, 15:09 +0200 schrieb David Nuescheler:
> > > Therefore I think that a GET to the exact repository path should
> > > generally be handled the same way as the WebDAV GET.
> > > I think this is very easy to understand for everybody and
> > > means that microsling generally works just like every
> > > other WebDAV enabled webserver for everything that is
> > > static.
> >
> > This sounds very plausible, but has some implications, which turn out to
> > be somewhat problematic. Therefore, I just added a StreamServlet which
> > streams a resource of type nt:file (which is most likely what is
> > required by Michael) and in addition support If-Modified-Since header
> > such that a 304 may be sent back just in case.
> >
> > This more or less should match, what WebDAV does in this respect, and I
> > think we are done without any special handling.
> >
> > > Personally, I think that this is a very simple and
> > > straightforward solution that leverages a lot of features
> > > implemented in WebDAV entirely correctly.
> > > Think of etag or modified since behaviour on GET
> > > or PUT and DELETE which all would have to be
> > > re-implemented in microsling.
> >
> > Streaming out of a Sling Application currently only discusses reading
> > (GET) not updating, which is done as described by Betrand using access
> > to the WebDAV servlet included with microsling.
> >
> > > Generally I think WebDAV is very Restful and a very
> > > good basis to start and sort of decorate microsling
> > > on top of a webdav enabled server.
> >
> > This sounds like an interesting point, though: Running Sling/microsling
> > ontop of a WebDAV server instead of a repository .... :-)
> >
> > > I think assuming assuming that people add an extension
> > > to let's say /content/mypage when GETting /content/mypage.html
> > > though microsling is good practice anyway.
> >
> > Definitely, it also helps determine the default response content type.
> >
> > Regards
> > Felix
> >
> >
Re: microsling user feedback
Posted by Michael Marth <mm...@day.com>.
Hi,
I gave it a shot to put the static resources in the repository and access
them through WebDAV. It worked, but there is one issue that I would like to
mention in this discussion about the correct implementation:
Even for resources that are readable for for anonymous users I get the basic
authentication popup of the browser. Surely, this can be suppressed (maybe
by wrapping the WebDAV servlet?). But this also made me wonder how the
single-sign-on would work between a (raw, unwrapped) WebDAV-based part (that
uses basic authent) and microsling (that uses the jsessionid cookie/Java
appserver mechanisms)? microsling could of course accept the basic
authentication headers if a WebDAV login occurred first, but how would it
work the other way round?
Cheers
Michael
On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
>
> Hi,
>
> Am Freitag, den 19.10.2007, 15:09 +0200 schrieb David Nuescheler:
> > Therefore I think that a GET to the exact repository path should
> > generally be handled the same way as the WebDAV GET.
> > I think this is very easy to understand for everybody and
> > means that microsling generally works just like every
> > other WebDAV enabled webserver for everything that is
> > static.
>
> This sounds very plausible, but has some implications, which turn out to
> be somewhat problematic. Therefore, I just added a StreamServlet which
> streams a resource of type nt:file (which is most likely what is
> required by Michael) and in addition support If-Modified-Since header
> such that a 304 may be sent back just in case.
>
> This more or less should match, what WebDAV does in this respect, and I
> think we are done without any special handling.
>
> > Personally, I think that this is a very simple and
> > straightforward solution that leverages a lot of features
> > implemented in WebDAV entirely correctly.
> > Think of etag or modified since behaviour on GET
> > or PUT and DELETE which all would have to be
> > re-implemented in microsling.
>
> Streaming out of a Sling Application currently only discusses reading
> (GET) not updating, which is done as described by Betrand using access
> to the WebDAV servlet included with microsling.
>
> > Generally I think WebDAV is very Restful and a very
> > good basis to start and sort of decorate microsling
> > on top of a webdav enabled server.
>
> This sounds like an interesting point, though: Running Sling/microsling
> ontop of a WebDAV server instead of a repository .... :-)
>
> > I think assuming assuming that people add an extension
> > to let's say /content/mypage when GETting /content/mypage.html
> > though microsling is good practice anyway.
>
> Definitely, it also helps determine the default response content type.
>
> Regards
> Felix
>
>
Re: microsling user feedback
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Freitag, den 19.10.2007, 15:09 +0200 schrieb David Nuescheler:
> Therefore I think that a GET to the exact repository path should
> generally be handled the same way as the WebDAV GET.
> I think this is very easy to understand for everybody and
> means that microsling generally works just like every
> other WebDAV enabled webserver for everything that is
> static.
This sounds very plausible, but has some implications, which turn out to
be somewhat problematic. Therefore, I just added a StreamServlet which
streams a resource of type nt:file (which is most likely what is
required by Michael) and in addition support If-Modified-Since header
such that a 304 may be sent back just in case.
This more or less should match, what WebDAV does in this respect, and I
think we are done without any special handling.
> Personally, I think that this is a very simple and
> straightforward solution that leverages a lot of features
> implemented in WebDAV entirely correctly.
> Think of etag or modified since behaviour on GET
> or PUT and DELETE which all would have to be
> re-implemented in microsling.
Streaming out of a Sling Application currently only discusses reading
(GET) not updating, which is done as described by Betrand using access
to the WebDAV servlet included with microsling.
> Generally I think WebDAV is very Restful and a very
> good basis to start and sort of decorate microsling
> on top of a webdav enabled server.
This sounds like an interesting point, though: Running Sling/microsling
ontop of a WebDAV server instead of a repository .... :-)
> I think assuming assuming that people add an extension
> to let's say /content/mypage when GETting /content/mypage.html
> though microsling is good practice anyway.
Definitely, it also helps determine the default response content type.
Regards
Felix
Re: microsling user feedback
Posted by David Nuescheler <da...@day.com>.
Hi guys,
I agree that I would really like to keep things as simple as
possible.
Therefore I think that a GET to the exact repository path should
generally be handled the same way as the WebDAV GET.
I think this is very easy to understand for everybody and
means that microsling generally works just like every
other WebDAV enabled webserver for everything that is
static.
In addition to that we allow "url decoration" such as
selectors and extensions, these are handled by microsling
in its more advanced request processing and mapping.
Personally, I think that this is a very simple and
straightforward solution that leverages a lot of features
implemented in WebDAV entirely correctly.
Think of etag or modified since behaviour on GET
or PUT and DELETE which all would have to be
re-implemented in microsling.
Generally I think WebDAV is very Restful and a very
good basis to start and sort of decorate microsling
on top of a webdav enabled server.
I think there are no collisions or special cases, I would
generally say that if someone addresses an item
directly with what i would call an "exact path match",
the WebDAV behaviour by default is an excellent choice.
I think assuming assuming that people add an extension
to let's say /content/mypage when GETting /content/mypage.html
though microsling is good practice anyway.
regards,
david
On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
> Am Freitag, den 19.10.2007, 11:42 +0200 schrieb Bertrand Delacretaz:
> > On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
> >
> > > ...I would
> > > say, that we should not mix microsling/Sling generation and WebDAV
> > > generation as it will never correctly workout, unfortunately....
> >
> > Why wouldn't that work?
>
> Because a WebDAV GET is not the same as a microsling/Sling GET in the
> general case.
>
> > I agree that mixing WebDAV and other protocols in the same URL space
> > might not work depending on what the other protocols are, but what
> > could go wrong in the simple microsling case?
>
> Just having to explain: A request is passed through Sling Servlet
> resolutions unless the RequestURL exactly matches the JCR resource in
> which case the request is handled as if it were a WebDAV request ...
> This calls for nasty problems and hard to explain special cases.
>
> >
> > I'm curious mostly, I cannot argue 100% that it would work, so if you
> > have contrary evidence it'd help me figure out the issues.
> >
> > Having a full WebDAV implementation (the Jackrabbit one I assume)
> > *plus* our cool resource resolving and scripting stuff in the same URI
> > space sounds like a big benefit for microsling...there might be
> > downsides, but I'd prefer us to analyze them before dismissing the
> > idea.
>
> With the exception that it does not work. We (Day) tried this in other
> products (Communiqué for concrete) and always came to the conclusion,
> that we have to clearly separate WebDAV from the rest. So in Communiqué
> we solved the issue of just prefixing WebDAV requests such that
> http://host/dav/xxx/yyy would be a WebDAV request to resource /xxx/yyy
> while http://host/xxx/yyy would be the "normal" request to
> resource /xxx/yyy.
>
> And as always: Keeping things simple means: Don't create special
> cases ...
>
> Regards
> Felix
>
>
Re: microsling user feedback
Posted by Felix Meschberger <fm...@gmail.com>.
Am Freitag, den 19.10.2007, 11:42 +0200 schrieb Bertrand Delacretaz:
> On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
>
> > ...I would
> > say, that we should not mix microsling/Sling generation and WebDAV
> > generation as it will never correctly workout, unfortunately....
>
> Why wouldn't that work?
Because a WebDAV GET is not the same as a microsling/Sling GET in the
general case.
> I agree that mixing WebDAV and other protocols in the same URL space
> might not work depending on what the other protocols are, but what
> could go wrong in the simple microsling case?
Just having to explain: A request is passed through Sling Servlet
resolutions unless the RequestURL exactly matches the JCR resource in
which case the request is handled as if it were a WebDAV request ...
This calls for nasty problems and hard to explain special cases.
>
> I'm curious mostly, I cannot argue 100% that it would work, so if you
> have contrary evidence it'd help me figure out the issues.
>
> Having a full WebDAV implementation (the Jackrabbit one I assume)
> *plus* our cool resource resolving and scripting stuff in the same URI
> space sounds like a big benefit for microsling...there might be
> downsides, but I'd prefer us to analyze them before dismissing the
> idea.
With the exception that it does not work. We (Day) tried this in other
products (Communiqué for concrete) and always came to the conclusion,
that we have to clearly separate WebDAV from the rest. So in Communiqué
we solved the issue of just prefixing WebDAV requests such that
http://host/dav/xxx/yyy would be a WebDAV request to resource /xxx/yyy
while http://host/xxx/yyy would be the "normal" request to
resource /xxx/yyy.
And as always: Keeping things simple means: Don't create special
cases ...
Regards
Felix
Re: microsling user feedback
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
> ...I would
> say, that we should not mix microsling/Sling generation and WebDAV
> generation as it will never correctly workout, unfortunately....
Why wouldn't that work?
I agree that mixing WebDAV and other protocols in the same URL space
might not work depending on what the other protocols are, but what
could go wrong in the simple microsling case?
I'm curious mostly, I cannot argue 100% that it would work, so if you
have contrary evidence it'd help me figure out the issues.
Having a full WebDAV implementation (the Jackrabbit one I assume)
*plus* our cool resource resolving and scripting stuff in the same URI
space sounds like a big benefit for microsling...there might be
downsides, but I'd prefer us to analyze them before dismissing the
idea.
Note that if we wire WebDAV in a clean way in microsling, Sling OSGi
can use the same wiring to do something different (resource spooling
etc).
-Bertrand
Re: microsling user feedback
Posted by Philipp Koch <ph...@day.com>.
well i was maybe not that clear. in regards of the spool servlet
implemention: currently ("big" sling) a file can addressed by path
and sling spooles it out of the repository, which is very cool and
should be supported as well in the micro sling. so how the spool part
is implemented is another story and if we could use the webdav stuff
(jackrabbit) for that which works really well and supports all the
http 1.1 stuff, so why don't we use that?
regards, philipp
On 10/19/07, Philipp Koch <ph...@day.com> wrote:
> the way how the current "big" sling does spool static resources out of
> the repository is very nice and should somehow (as suggested by felix
> (kind of spool servlet) added to the micro sling "product" as well.
>
> regards,
> philipp
>
> On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
> > Hi,
> >
> > At first sight, this looks intriguing indeed. But on second sight, it
> > mixes concepts introduces dependencies and just does not seem right.
> >
> > In addition to my other post, where I postulate a SpoolServlet, I would
> > say, that we should not mix microsling/Sling generation and WebDAV
> > generation as it will never correctly workout, unfortunately.
> >
> > Rather I would say microsling/Sling generates all output itself. To
> > support WebDAV through microsling/Sling we should create a different
> > WebApp which is only responsible for supporting WebDAV.
> >
> > Regards
> > Felix
> >
> > Am Freitag, den 19.10.2007, 09:48 +0200 schrieb David Nuescheler:
> > > Hi guys,
> > >
> > > > > ...- the content templates reside in the repository (i.e . on a WebDAV drive in
> > > > > my case). However, static html pages need to reside in the war file....
> > > > Would an "initial content loader" mechanism be useful? I have some
> > > > code from another project that copies all resources found under
> > > > WEB-INF/initial-content into the repository at startup, is that
> > > > something that would help you in your application setup?
> > > I think I am missing something...
> > >
> > > Shouldn't you be able to to just put any static file into the repository via
> > > webdav, and then just use the webdav url to retrieve it again?
> > >
> > > That being said, i think it would be great if microsling ootb handles
> > > "static resources" properly. I think if someone addresses
> > > an item with an "exact match" in a url (no additional extensions or selector)
> > > I think that resource should be taken care of the same way as we do that in the
> > > WebDAV layer today...
> > >
> > >
> > > As an example let's say my repo looks like this.
> > >
> > > /content [nt:unstructured]
> > > /content/myblog [my:blog]
> > > /content/docroot [nt:folder]
> > > /content/docroot/privacy.html [nt:file]
> > >
> > > I think the resolution of GET requests to the following urls should
> > > work as follows:
> > >
> > > http://myhost/content/myblog.html -> /content/myblog execs the "html.esp"
> > > http://myhost/content/docroot/privacy.html -> delegates to webdav
> > > since it was an "exact match"
> > > http://myhost.content/docroot -> delegates to webdav since it was an
> > > "exact match"
> > > http://myhost.content/docroot.html -> /content/docroot execs the "html.esp"
> > >
> > > This should also allow to bind webdav directly to microsling, which i
> > > find more intuitive.
> > >
> > > Does that make sense?
> > >
> > > regards,
> > > david
> >
> >
>
Re: microsling user feedback
Posted by Philipp Koch <ph...@day.com>.
the way how the current "big" sling does spool static resources out of
the repository is very nice and should somehow (as suggested by felix
(kind of spool servlet) added to the micro sling "product" as well.
regards,
philipp
On 10/19/07, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> At first sight, this looks intriguing indeed. But on second sight, it
> mixes concepts introduces dependencies and just does not seem right.
>
> In addition to my other post, where I postulate a SpoolServlet, I would
> say, that we should not mix microsling/Sling generation and WebDAV
> generation as it will never correctly workout, unfortunately.
>
> Rather I would say microsling/Sling generates all output itself. To
> support WebDAV through microsling/Sling we should create a different
> WebApp which is only responsible for supporting WebDAV.
>
> Regards
> Felix
>
> Am Freitag, den 19.10.2007, 09:48 +0200 schrieb David Nuescheler:
> > Hi guys,
> >
> > > > ...- the content templates reside in the repository (i.e . on a WebDAV drive in
> > > > my case). However, static html pages need to reside in the war file....
> > > Would an "initial content loader" mechanism be useful? I have some
> > > code from another project that copies all resources found under
> > > WEB-INF/initial-content into the repository at startup, is that
> > > something that would help you in your application setup?
> > I think I am missing something...
> >
> > Shouldn't you be able to to just put any static file into the repository via
> > webdav, and then just use the webdav url to retrieve it again?
> >
> > That being said, i think it would be great if microsling ootb handles
> > "static resources" properly. I think if someone addresses
> > an item with an "exact match" in a url (no additional extensions or selector)
> > I think that resource should be taken care of the same way as we do that in the
> > WebDAV layer today...
> >
> >
> > As an example let's say my repo looks like this.
> >
> > /content [nt:unstructured]
> > /content/myblog [my:blog]
> > /content/docroot [nt:folder]
> > /content/docroot/privacy.html [nt:file]
> >
> > I think the resolution of GET requests to the following urls should
> > work as follows:
> >
> > http://myhost/content/myblog.html -> /content/myblog execs the "html.esp"
> > http://myhost/content/docroot/privacy.html -> delegates to webdav
> > since it was an "exact match"
> > http://myhost.content/docroot -> delegates to webdav since it was an
> > "exact match"
> > http://myhost.content/docroot.html -> /content/docroot execs the "html.esp"
> >
> > This should also allow to bind webdav directly to microsling, which i
> > find more intuitive.
> >
> > Does that make sense?
> >
> > regards,
> > david
>
>
Re: microsling user feedback
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
At first sight, this looks intriguing indeed. But on second sight, it
mixes concepts introduces dependencies and just does not seem right.
In addition to my other post, where I postulate a SpoolServlet, I would
say, that we should not mix microsling/Sling generation and WebDAV
generation as it will never correctly workout, unfortunately.
Rather I would say microsling/Sling generates all output itself. To
support WebDAV through microsling/Sling we should create a different
WebApp which is only responsible for supporting WebDAV.
Regards
Felix
Am Freitag, den 19.10.2007, 09:48 +0200 schrieb David Nuescheler:
> Hi guys,
>
> > > ...- the content templates reside in the repository (i.e . on a WebDAV drive in
> > > my case). However, static html pages need to reside in the war file....
> > Would an "initial content loader" mechanism be useful? I have some
> > code from another project that copies all resources found under
> > WEB-INF/initial-content into the repository at startup, is that
> > something that would help you in your application setup?
> I think I am missing something...
>
> Shouldn't you be able to to just put any static file into the repository via
> webdav, and then just use the webdav url to retrieve it again?
>
> That being said, i think it would be great if microsling ootb handles
> "static resources" properly. I think if someone addresses
> an item with an "exact match" in a url (no additional extensions or selector)
> I think that resource should be taken care of the same way as we do that in the
> WebDAV layer today...
>
>
> As an example let's say my repo looks like this.
>
> /content [nt:unstructured]
> /content/myblog [my:blog]
> /content/docroot [nt:folder]
> /content/docroot/privacy.html [nt:file]
>
> I think the resolution of GET requests to the following urls should
> work as follows:
>
> http://myhost/content/myblog.html -> /content/myblog execs the "html.esp"
> http://myhost/content/docroot/privacy.html -> delegates to webdav
> since it was an "exact match"
> http://myhost.content/docroot -> delegates to webdav since it was an
> "exact match"
> http://myhost.content/docroot.html -> /content/docroot execs the "html.esp"
>
> This should also allow to bind webdav directly to microsling, which i
> find more intuitive.
>
> Does that make sense?
>
> regards,
> david
Re: microsling user feedback
Posted by David Nuescheler <da...@day.com>.
Hi guys,
> > ...- the content templates reside in the repository (i.e . on a WebDAV drive in
> > my case). However, static html pages need to reside in the war file....
> Would an "initial content loader" mechanism be useful? I have some
> code from another project that copies all resources found under
> WEB-INF/initial-content into the repository at startup, is that
> something that would help you in your application setup?
I think I am missing something...
Shouldn't you be able to to just put any static file into the repository via
webdav, and then just use the webdav url to retrieve it again?
That being said, i think it would be great if microsling ootb handles
"static resources" properly. I think if someone addresses
an item with an "exact match" in a url (no additional extensions or selector)
I think that resource should be taken care of the same way as we do that in the
WebDAV layer today...
As an example let's say my repo looks like this.
/content [nt:unstructured]
/content/myblog [my:blog]
/content/docroot [nt:folder]
/content/docroot/privacy.html [nt:file]
I think the resolution of GET requests to the following urls should
work as follows:
http://myhost/content/myblog.html -> /content/myblog execs the "html.esp"
http://myhost/content/docroot/privacy.html -> delegates to webdav
since it was an "exact match"
http://myhost.content/docroot -> delegates to webdav since it was an
"exact match"
http://myhost.content/docroot.html -> /content/docroot execs the "html.esp"
This should also allow to bind webdav directly to microsling, which i
find more intuitive.
Does that make sense?
regards,
david
Re: microsling user feedback
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Michael,
Thanks for the feedback, it's good to have a (guinea pig) microsling
user so early ;-)
Replying to what hasn't been addressed in this thread yet:
> ...this idea of might clash with sling's concept of pluggable
> presentation scripting engines, though. If so, I'd prefer microsling to be
> opinionated<http://gettingreal.37signals.com/ch04_Make_Opinionated_Software.php>,
> i.e. decide on one scripting engine)...
We will probably have an official favorite scripting engine as time
goes, but at this point I think it's good to be open - if only to
validate the microsling design that allows plugging in different
script engines.
My personal microsling scripting engine is server-side javascript with
ESP templates, I think that'd be a very good choice to write our
examples in: the language is lightweight, powerful, well-known and
fairly readable.
Note also that scripts are not meant for presentation only: for HTTP
requests that do not use the GET method, microsling looks for scripts
having the method name, like POST.js. See ScriptFilenameBuilderTest
for details.
> ...- the content templates reside in the repository (i.e . on a WebDAV drive in
> my case). However, static html pages need to reside in the war file....
Would an "initial content loader" mechanism be useful? I have some
code from another project that copies all resources found under
WEB-INF/initial-content into the repository at startup, is that
something that would help you in your application setup?
-Bertrand
Re: microsling user feedback
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/18/07, Tobias Bocanegra <to...@day.com> wrote:
> ...you would add a 'selector' for different views of the same content.
> eg:
> /content/blog/entry1.html for view and
> /content/glob/entry1.edit.html for editing...
That's correct, see ScriptFilenameBuilderTest for examples of how this
translates to different script names.
The script names that microsling tries to find are also logged.
> ...you just iterate over the child content and call <sling:include/> or
> whatever the aequivalent in microsling is. we need to elaborate this...
We don't have sling:include in microsling yet, I'll create a JIRA
issue for that.
> ...usually you would put the 'static' content, in a 'docroot' node as
> nt:files and let the
> default nt:file script spool them to the client....
We also need to enhance the default servlet to serve files...on my way to JIRA.
-Bertrand
Re: microsling user feedback
Posted by Tobias Bocanegra <to...@day.com>.
> conceptual stuff:
>
> - I was wondering how I can have several templates for one content type. I
> could work around this issue in my very simple case, but how can I have e.g.
> an edit template and a view template for a blog entry (depending on some
> request parameter or so)?
you would add a 'selector' for different views of the same content.
eg:
/content/blog/entry1.html for view and
/content/glob/entry1.edit.html for editing
> Related to this: how can I render node X when node Y is requested? In my
> case: I got a blog entry (node Y) that has several comments (nodes X) that I
> want to display on the same page. In Ruby on Rails there is the concept of
> partial templates and I was expecting something similar. I understand that I
> can traverse the JCR and grab the corresponding nodes (which I did) but in
> that case I need to copy template code (re partial templates: the idea is
> basically that an object exposes different methods to render itself. In the
> contect of sling this idea of might clash with sling's concept of pluggable
> presentation scripting engines, though. If so, I'd prefer microsling to be
> opinionated<http://gettingreal.37signals.com/ch04_Make_Opinionated_Software.php>,
> i.e. decide on one scripting engine).
you just iterate over the child content and call <sling:include/> or
whatever the aequivalent in microsling is. we need to elaborate this.
> - the content templates reside in the repository (i.e . on a WebDAV drive in
> my case). However, static html pages need to reside in the war file. In my
> use case this was especially weird, because the comment input forms were in
> the repository (because they are located on the blog entry renderer page)
> where as the "create new blog entry" form was in the war file. I would
> prefer if I could put all my templates and static content in the repository.
usually you would put the 'static' content, in a 'docroot' node as
nt:files and let the
default nt:file script spool them to the client.
> - I was wondering how I can use the repository authentication and
> authorization mechanisms for my app. Could someone give me a pointer,
> please?
this would be the job of the authentication filter / or sling service
and shoud not be of the primary concern of the user (developer).
regards, toby
ps: thanks for summarizing this questions. i think this is a good
starting point for a wiki/faq for [micro]sling.
--
-----------------------------------------< 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 >---