Re: From Component API to Sling API (was: Simplifying our component api)
Hi all, > Am Montag, den 08.10.2007, 12:08 +0200 schrieb Bertrand Delacretaz: > > Yes, so my proposal is not much different to what we have now, except > > that, as we see below, Content and Servlets are more decoupled from > > JCR, mostly by using URIs instead of paths. > > I like this (further) decoupling. I think generally I would be cautious about introducing too much abstraction. In many respects unnecessary abstraction causes software to fail in the market. I agree with Stefano 100% on this one ... --- http://www.betaversion.org/~stefano/papers/ac2006.2.pdf see slide 145 and following (I am not kidding...;) ) --- ... which he calls "Flexibility syndrome" or "yagni". I think one of the reasons why Hibernate was more successful than JDO or EJB is really because it clearly always focussed on an RDBMS as the backing store, which made its purpose very simple and clear and allowed for a lot of optimizations that made sense for that one persistence layer. I believe see that leaving out the right features and extension points is the real art of software design and development, which in my mind shows particularly well in Apple vs. MS applications ;) Some more thoughts on choices and flexibility of Joel on that: http://www.joelonsoftware.com/items/2006/11/21.html Bottom-line (and small-surprise-tm): I do not mind strong ties between Sling and JCR. I think we should address all the possible things that people could possibly use Sling for beyond JCR, once we are confronted with real-life usecases. (in Stefano speak: "scratch your own itch!") regards, david
Re: [RT] breaking Sling into smaller pieces?
Hi all, I think it is a great idea to come up with a rock-solid architecture diagram on how things work and breaking sling up into different larger pieces is certainly a good idea. For me sling has a very simple main purpose: It is the JCR centric web application development framework of my dreams. This is the main differentiator for me. In my mind differentiators have to be simple. I think being more osgi than web framework A or more restful than framework B does not really justify slings existence. I think it is crucial for the success of sling to be able to argue why it is different, not so much why it is incrementally better. I think putting the Content Repository at its core certainly gives sling a very clear and easy to express differentiator. I am very much in agreement with Bertrand split-up. Of course I would personally but sling-jcr into sling-core but i think that's to be expected, considering my point of view ;) regards, david On 10/9/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > Hi Sling team, > > (hmmm...long read ahead, sorry about that but I tried to keep it pragmatic ;-) > > When talking about Sling to people who don't know it, a reaction that > comes up very often is "this stuff looks cool, but I cannot really > figure out what it does". > > Looking at the list of bundles [1], I think breaking up Sling in > smaller pieces might help a lot, by allowing people to focus on what's > important for them. > > - o - > > I suggest the following parts: > > 1) Scriptable JCR-based REST resource processing framework (sling-core-*) > This is the clear focus of the project, other modules are only here to > support it. > > This module: > -Maps incoming HTTP requests to resources (JCR nodes or OCM-mapped objects) > -Uses servlets or scripts to process the requests based on the HTTP > uniform interface (get, post, put, delete). > > A simple example webapp allows developers to test this without > spending more than 15 minutes to download, run and start exploring it. > > This is usually the only module that web developers need to learn. > > If possible, the API of this module is independent of OSGi, but that's > not a priority. > > > 2) OSGI console and utilities (sling-osgi-*) > This can be useful outside of Sling, but it is not our priority to > make it standalone. > > > 3) Scripting tools (sling-scripting-*) > JSP compiler, future interfaces to other scripting engines, etc. > > These tools could also be useful outside of Sling, but it is not our > priority to make them standalone. > > > 4) JCR tools (sling-jcr-*) > Glue code for interaction between Sling and JCR repositories. > > - o - > > Users of the Sling core usually do not need to understand how 2), 3) > and 4) work. > > For modules 2) and 3) and 4), we try to reuse stuff from other > projects, as much as possible, or contribute stuff to other projects > so that they fit our needs. > > - o - > > If we agree on this, the next step might be to reorganize our code > base, with those four Maven modules at the top (sling-core, > sling-osgi, sling-scripting and sling-jcr), and sub-modules below > them. This entails little or no changes to existing code, just moving > modules around and renaming some of them to use their parent module's > name as a prefix. > > WDYT? > > -Bertrand > > > [1] http://incubator.apache.org/sling/site/architecture.html >
Re: [RT] breaking Sling into smaller pieces?
Hi guys, > > For me sling has a very simple main purpose: > > It is the JCR centric web application development > > framework of my dreams. > Yes, true, but ... "JCR-centric" is a very vague term in itself :-) I agree that there are many flavours of how you could use the a content repository, there should be a recommend way though. In my mind the initial message should be: If you would like to build a webapp using a content repository ...use sling. I think sling will be more successful providing "rails" instead of "options", in a sense something like: If you want to build a webapp using a content repository, this is how you develop, deploy and run it. (sling: osgi, rest, content packages, ...) > > I think being more osgi than web framework A or > > more restful than framework B does not really justify > > slings existence. I think it is crucial for the success > > of sling to be able to argue why it is different, > > not so much why it is incrementally better. > I do not completely agree here: There are multiple requirements for a > web application framework: Extensibility, Manageability, Stability, > Ease-of-Use, Data Persistence come to mind; certainly there are more. I completely agree, but don't ever want to find myself in a in position arguing why sling easier to use than wicket or more extensible than spring. If someone ask me: "why should I use Sling?" then my answer will always be "...because you believe that everything is content." > Now, Sling is probably not revolutionary with respect to a single > requirement (except with regard to Data Persistencew) in that it is > better to extend than framework X, better to manage than framework Y > etc. All-in-all, when counting all parts together, you get a framework > which is dramatically "better" than other frameworks in the field. And > this is IMHO the real value of Sling. I think I am in no position to judge the extensibility, stability or manageability of other webframeworks, simply because I have not used any of them long enough. ;) However since perception is reality, I think we will never be able to be (perceived as) more robust and extensible than spring or easier to use than wicket or ror. So in my mind attempting to differentiate along these lines is pointless... Let me try to explain my view differently, the most trafficked "Photo Managment Application" on the net is facebooks. It lacks tons of features (until recently you were not even able to sort photos), but it has its "secret sauce" which is the "Social Graph". In my mind slings secret sauce is the Content Repository. > > I think putting the Content Repository at its core > > certainly gives sling a very clear and easy to > > express differentiator. > This is what we do, except that we do not lock the Sling API into the > JCR but say, a Sling application may depend on Sling providing the data > to work with in a uniform fassion and that Sling applications do not > have to care much about persistence issues. This is IMHO a big > differentiator to most if not all frameworks around. I think it is very common for web frameworks to abstract their persistence. Amongst the ones that I can remember off the top of my head only very few don't. > Currently, Sling is of course locked into JCR, as the Content > provisioning only supports JCR and authentication depends on and > requires the JCR repository. I agree and it sounds like nobody has a real-life usecase to use something else really. It reminds me a bit of the argument "Yes, SOAP could be sent using various transport protocols, but in reality people only use http, and there really is no reason not to use http ;)" ...so why the abstraction? I think abstraction or indirection always come at a price. regards, david
Re: Microsling, first shot, feedback is welcome
wow! congrats looks great, and works just fine. way less than 15 minutes, though... ;) regards, david On 10/11/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > On 10/11/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > > > I think the current revision of > > http://svn.apache.org/repos/asf/incubator/sling/whiteboard/microsling > > is worth having a look... > > Forgot to mention that the current version does not use the OCM > mapping - I'm not too familiar with that and would have needed more > time to implement it, so for now it's raw JCR. > > Using OCM should be easy though, as long as the resource resolver and > the rendering scripts are consistent with each other. The Resource > abstraction allows any Object to be selected as the current resource > to process. > > Patches are welcome, and committers should feel free to commit changes > directly, of course. > > -Bertrand >
Re: Actions (methods) must not appear in URIs
hi roy, > but how i see the current design of (micro)sling - there is not any > intention of 'storing' actions in the uri. of course a user can still > code some 'actions' in his script - but this would not be the fault of > sling. the 'selectors' are primarily used to resolve to a different > 'view' of the content, or to pass additional render information, e.g. > the dimensions of a resized image. i completely agree with toby. i see selectors exclusively as a means to display the same logical content in different ways for example: as html, as pdf, as a small navigation-images, as an html "teaser" in a list, etc... generally, i think that selectors are generally only relevant for GETs anyway. from what i can see there is absolutely no intention to put http methods into a selector. i think we never did that, and i am 100% with you that this would be bad design. is there anything in particular that makes you think that there is a danger that this would happen in (micro)sling? maybe we were not able to articulate the intention of the script mapping when it comes to methods and selectors properly... regards, david
Re: [POLL] microsling: Future of microsling
> What do you think of (1) making microsling the "reference > implementation" of the new Sling API and thus (2) promoting it > to the trunk and finally (3) try to reuse parts of microsling > code for the real Sling ? +1 ... loving it ;) regards, david
Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)
Hi guys, > I agree, that we might want to wait for a real-life request. > On the other hand it is not only the end-users fault if not the correct > methods could be used, though browsers are probably the major number of > culprits. Many times it is just a question of firewall limitation which > can by no means be circumvented by the casual user on the internet ... I agree, aswell. Generally, I guess what I would be excited to use from a microsling user perspective is: (a) a flexible and very easily extensible GET that does all my different renditions of a content node on the server (b) a clean PUT and DELETE that operates as expected, which is probably triggered through some XHR based js lib in the browser. (c) a functionally powerful POST that (amongst other things) allows me to trigger any content repository modification through a straight html-form in a browser. Generally, this means that as a user I am less interested in tweaking the "writing" mechanisms to the repository, since they are sufficiently simple and complete, while the rendering/presentation is very user and usecase specific. I would personally stay away from any of the mentioned "HTTP method simulation" techniques (until requested). Personally I would assume that there are requirements such as dealing versioning operations or batching up multiple modifications that (short of implementing WebDAV and its ugly cousins) would go into the "powerful" ootb POST handling. Personally I could see a powerful POST handling to be very similar to what Bertrand and I use in http://www.day.com/maven/rjax/ Thoughts? regards, david
Re: microsling user feedback
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 <[EMAIL PROTECTED]> wrote: > Am Freitag, den 19.10.2007, 11:42 +0200 schrieb Bertrand Delacretaz: > > On 10/19/07, Felix Meschberger <[EMAIL PROTECTED]> 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
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: [RT] ScriptResolver
hi lars, thanks a lot for the illustration. i think this is a great approach. i would like to ask a couple of detailed questions though. > If two nodes in the graph have the same distance to the primaryType, > following rules are applied: > 1) nt:base has precedence over nt:unstructured really? my gut feel would have been the other way around... i haven't thought it through though... did you have a particular rationale that you can share? > 2) built-in node types have precedence over nt:base since nt:base is the "mother" all built-in nodes i think i can agree to the sentence pre-pending "other " ;) > 3) user-defined node types have precedence over built-in node types ack. > 4) an alphabetical precedence ordering takes place it sounds like this is so arbitrary that i would probably just opt for a quick "implementation" defined (==undefined) resolution instead of sorting. what do you think? did you mean to specify a resolution order by (1) - (4) or is the sequence of the rules arbitrary. regards, david
Re: Script engines as plugins?
> 1) Our own simple "jar service provider" mechanism > 2) List of script engine class names as a MicroslingMainServlet init parameter maybe thats a stupid idea and i am not sure if i even want to bring up this option ;) : (3) how about using the workspace itself as an extension mechanism... something like: /.microsling/script-engines/esp /.microsling/script-engines/fm /.microsling/script-engines/rb ... which would host all the mapping information also allow for dynamic extension and distribution/installation as a content package. regards, david
Re: [RT] microsling ajax client
> > We could use microjax as a nickname maybe. how about "slingjax". regards, david
Re: microsling scripting for POSTs
Hi Michael, > I think that the processing of POSTs, i.e. writing into the repository > should be scriptable just like the processing of GETs is. This means that > the MicrojaxPostServlet should not parse hard-coded parameters and do some > hard-coded stuff with them. It should invoke a script. That script should be > able to write, delete, modify, etc (e.g. by getting the request and the > repository as scriptable objects). I agree, there may be cases where you want to handle the POST on the server side. Mostly this is the case when you don't trust the user/client. Comments in a blog are the perfect example. In some initial discussions we talked about the following scripting capabilities for example: html.esp -> would handle /mynode.html edit/html.esp -> would handle /mynode.edit.html POST.esp -> would handle/overwrite the POST PUT.esp -> would handle/overwrite the PUT > AFAIK there is still some filters to be implemented, but IMO that will not > cut it. I think that the core functionality of repository writing needs to > be open for the app developer (even if you think of Sling as a > "presentation" framework - my simple blogging app has already hit this > wall). We could still keep the mechanism right now for very simple cases or > as a fall-back. While i agree that we can never cover 100% of the usecases I think we should aim to cover the 95% simple usecases without modifying the POST. I think extending the standard ootb behaviour as we find good broadly supported usecase basis makes a lot of sense. > (*) In order to not get too esoteric, here's some use cases that bugged me > (I am aware that there are workarounds for these): > My example app is a blogging application and I would like blog readers to be > able to leave comments. The problems are: > - the comments shall have a date. Currently, I need to set the date in the > browser and pass it along as a request parameter. What I would really like > is to set this date on the server, i.e. add a custom property before the > node gets written > (I am aware that I could use Repository Observers to get this done but do > not I want to write Java code for this) I think this is a very common usecase. I thought about that numerous times and I am even considering whether we should bolt that right into the repository, since for example a lot of databases support a timestamp on creation or modification. Of course in the short term I think this is a very common usecase and we could initialize all date properties in microjax with "current date". > - the comments shall be checked for Spam before they are written. > Especially, comments that contain links shall be get a special property > "suspicious" hmm... good point... i don't really have a good answer for that one, seems like this would be a good candiate or the POST.esp extension? > - I would like to moderate or delete comments in a batch, i.e. modify > multiple nodes in one request You should be able to do that already, right? Using (absolute) paths you should be able to modify any node in the repository. regards, david
Node Resource.getNode() vs. Object Resource.getRawData()
Hi guys, I recently stumbled over a change in the org.apache.sling.api.resource.Resource interface that may be a symptom of a slight misalignment of my view of the grand scheme of (micro-)sling. Item Resource.getItem() was changed into Object Resource.getRawData() I have to admit that I never understood the more abstract .getItem() to begin with since i would have expected a .getNode() since all of the usecases that I know of use a node and not a property. Changing this to a .getRawData() returning an Object illustrates that we seem to have a difference in opinion (again) on the role of JCR in microsling. For me personally being JCR backed is the most defining feature of microsling. Extensibility, restfulness, ease-of-use and many other features are already claimed and established by numerous other web app frameworks, and trying to make a case that sling is incrementally better is not a case that i would attempt to make. To me this sounds like a case of what Stefano calls "Flexibility Syndrome" http://www.betaversion.org/~stefano/papers/ac2006.2.pdf pages 145 and following. I think his conclusion to "always" avoid the "flexibility syndrome" is spot on. In this case i think already the .getItem() expresses a flexibility syndrome where we can't really come up with a usecase but still leave a door open. The .getRawData() only takes this further into an even more "flexible" direction. I think a .getNode() would be much less confusing and more direct. If someone should ever need a getItem() or even a .getRawData() i think we could always address that later. I guess to sum it up, my personal preference would be the following: (*1*) Node Resource.getNode() (2) Object Resource.getNode() (3) Item Resource.getItem() (4) Object Resource.getItem() ... (xx) Object Resource.getRawData() I think simplicity is a key paradigm of microsling. I would hate to sacrifice simplicity on the most frequent case for very doubtful cases that we don't even know yet if we are ever going to have them. regards, david
microsling: extension vs. mime-type script resolution
Hi guys, I noticed that the resolution for scripts in microsling is based on the mime-type and not how I would have expected based on the extension. Personally, I think that this is somewhat confusing since the rest of the script resolution (selectors) is straight from the request url. I think that the additional indirection to go through a mime-type table adds complexity (since it is yet another mechanism) and is questionable to begin with since somehow it seems to tie the response mime-type into the request behaviour for no apparent reason. I know of a lot of cases where the same response script offers responses in various (not limited) mime-types, based on what the user uploaded to the repository. Personally, I would rather just go for a straight, more direct extension-based resolution than engaging in the whole mimetype business. regards, david
Re: microsling: extension vs. mime-type script resolution
Hi Felix, thanks for shedding some more light on the rationale. > Actually, the resolution is based on the request url extension, only > that there is some kind of an indirection, others call this > abstraction :-) The problem is, that the extension is not all the times > unique. For example, there are people using .htm and others that are > using .html but all of them mean text/html. So instead of requiring two > scripts for .htm and .html, we just require html (for text/html). I still don't understand why anyone would require two scripts. In the end it is not up to the surfer to just decide to choose their extension. Much like in the static webserver case where the webmaster decides which extension to use either .html or .htm for his static files the person that builds microsling website would decide how their extensions are mapped. I can't even come up with a usecase where a "magic" .html and .htm extension equivalence would add value. Actually in our current version of our WCMS we also offer flexibility on the extension (interestingly enough back then with the exact same .html & .htm issue in mind) but after ~10 years of using it, I have to say, there really is absolutely no need for it, and I would never be in favour of something like that. > It gets of course more interesting in the case where there is no request > extension: What script should we select ? Currently, we default to > text/plain, which is probably not the correct solution. I think that just illustrates the issue at hand in a very clear way. My expectation was that if I have no extension, I would map no script at all. (well, to the GET.esp script, if I really needed to, which in most cases should stay untouched and I would really encourage to have the standard WebDAV GET to be executed, which in my mind is perfect in most cases) > > I think that the additional indirection to go through a mime-type table adds > > complexity (since it is yet another mechanism) and is questionable to begin > > with since somehow it seems to tie the response mime-type into the request > > behaviour for no apparent reason. > In fact there is one reason, and I think this reason validates it all: > The client tells by means of the request, what he or she expects. So in > the same way as the request URL indicates the desired content to be > delivered, the response mime-type is derived from (a) the client request > URL and (b) to the HTTP Accept header (not implemented in microsling, > yet to be done in Sling) to indicate the expected response content type. > This is no tie-in, just trying to meet up with the client's expectation. Personally I am afraid to have accept-header influence the response mime-type. Frankly, in real live I have never seen something like that implemented and I would be scared to only anticipate the effects on proxies and reverse proxies. Also I think that clients are not very specific about that. I really would recommend to serve up resources that differ in mimetype with different URLs. Personally, I would probably stay away from building any behaviors on accept headers. > > I know of a lot of cases where the > > same response script offers responses in various (not limited) mime-types, > > based on what the user uploaded to the repository. > Well, this is a delicate issue: If as a client I request something with > extension .txt I do expect a plain text response and not a GIF and I do > absolutely not care what some other guy might have stored in the > repository. If of course there is not plain text representation of the > addressed content, I would expect an appropriate HTTP status code. Some clients (Firefox) base their mime-type handling strictly on the response content-type header, others use a mix of extension, actual content and headers (IE). So I agree that it is very good practice if the content-type header, the extension and actual content match up. No doubt. I am not talking about extension to mime-type mappings like txt or html. Very frequently extensions like: .do, .jsp, .asp map to all sorts of mimetypes so the real-life web infrastructure is certainly capable of dealing with a 1-to-many relationship between extensions and mime-types. Well, let's look at the following examples: Assume that /myuploads is a node that is used to spool uploaded nt:resource nodes for one reason or another. Let's say I have jpg called my.jpg (which could also be a my.pdf ;) Now for the script resolution I would like to map .spool to my spool.esp rather than anything even vaguely related to a mime-type. /myuploads.spool/my.jpg or /myuploads.spool/my.jpg?get=1234-123423-34234-23455 > Hope, this makes my case clear for using the response content type for > the script resolution, I may not see it. To me this is just a dangerous and problematic indirection with a lot of potential for errors. Let's say my extensions-mimetype table is different from an other microsling install that I copy my scripts from then things don't work out a
Re: Node Resource.getNode() vs. Object Resource.getRawData()
sounds good to me ;)
> > ...Let us keep the Resource completely abstract...
> I like that.
+1
> > ...public interface JcrResource extends Resource {
> > Node getNode();
> > }..
> Ok
can we make it "NodeResource" ?
> >... public interface MappedResource extends Resource {
> > Object getObject();
> > }..
> Ok - I'd call that OcmMappedResource maybe, as "mapped" is a kinda generic
> name.
sounds good.
i would probably propose:
public interface ObjectMappedNodeResource extends NodeResource {
}
> >... For microsling, we can then safely assume, that the Resource is always a
> > JcrResource...
> ok
sounds like a good approach.
regards,
david
Re: microsling scripting for POSTs
hi guys, > We could have a "magic" repository location for scripts that would be > > automatically bound to repository events, based on the touched node's > > resource type. > > For example, a script named > > /sling/events/nt/file/event.js > > would be called for any events on nt:file nodes, or > > /sling/events/myblog/comment/node_added.js > > would be called when a node is added with slingResourceType=myblog/comment > > How does that sound? I think that would be a cool way of exposing the > > rich JCR events functionality, and it is fairly easy to implement. sounds good to me. How about making it a magic-subdirectory of the ResourceType location. Something like a myresourcetype/.events/add_node.esp This somehow brings up a related topic. In our experience it turned out to be helpful to put things in the "same location" that you would like to move or install from one repository to another. This is opposed to splitting things up "by type" (events, scripts, ...). So my goal would be that if I develop a microsling app every thing that i need in my app could be organized as follows: /apps/myapp /apps/myapp/docroot/my.gif /apps/myapp/docroot/my.css /apps/myapp/components/homepage/html.esp /apps/myapp/components/homepage/edit/html.esp /apps/myapp/components/homepage/.events/modify.js /apps/myapp/components/homepage/.events/all.js /apps/myapp/components/contentpage/html.esp /apps/myapp/components/contentpage/edit/html.esp in my example my resourcetypes "homepage" and "contentpage" live in the "components" folder. this would allow me to package up my entire "myapp" or just bits and pieces of it with a simple content package or export, would inidicate that it is good practice to sort of "namespace" your app. Thoughts? regards, david
Re: microsling scripting for POSTs
> > > ...I was actually thinking about making JCR observers scriptable as well. > > This is in fact a very interesting extension. Still I would strongly > > suggest to not implement this in microsling but in Sling > Why? > Repository events are a very important differentiator of JCR as > compared to other content storage mechanisms, so I don't see why this > shouldn't be in microsling. As I said above, on top of being an entry > point to Sling, microsling can also be an entry point for JCR, to help > people discover it in an easy to use scriptable environment. I agree that this is a great feature of JCR and needs to be exposed. ... and the simplicity of the usage of observation is just stunning, so i love it. However, I would agree with Felix in the sense that it probably is possible to write a lot of "microsling" worthy apps without having the observation feature. So i guess I would also put it rather low on a priority list and wait for someone needs it. (Which probably will happen sooner than later) I think it is great though the way we "specified" it in this thread and we should keep it this simple wherever we implement it. regards, david
Re: microsling: extension vs. mime-type script resolution
Hi Jukka, > On Nov 20, 2007 3:26 PM, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > > 1. The URI is split in four parts (resource path, selectors, > > extension, suffix), where "resource path" is the longest part of the > > request path that matches a Node in the repository i think, that it is true that the difference between selectors and the extension is arbitrary, and i see its value mostly for explanatory purposes. one will end up being a filename, the other will be a directory name. > I would only split the URI (path) to two parts, the resource path and > anything that comes after that. Basically, the resolver would start > with a context node and a URI path (without any leading parts like the > webapp or servlet path removed) and walk down the node hierarchy using > segments of the given URI path until no matching node is found. The > result of this resolution is a new context node and the remaining > unresolved part of the URI path. from an implementation standpoint i think thats a good thing to do. from a users perspective i think there is value in guiding how to use the flexibility with the "unresolved parts" of the url. so one might say that this is purely a "best practices discussion", and thats where the four parts come in handy. > > 4. If no Servlet is found, the ScriptResolver looks for a script, > > building its path as follows: > > /sling/scripts/RT/ME.EXT > I would remove this part from the resolution process within the Sling > framework, and leave it up to a default servlet like > SlingScriptServlet, that would construct the /RT/ME.EXT path using the > remaining path info from step 1 above and recursively call the > resolution process using /sling/scripts as the context to find an > appropriate script node. good question. I have to say that I consider leaving out the right options, buttons and extension points the true art of building good software. Personally, I have not run into a situation where this way of resolving to scripts was an issue, so I see little value in making this extensible. > (I'd still like to use slashes > as separators instead of dots, but that's a minor concern) Just to make sure, does that mean that we would have something like: /mypage/html /mypage/edit/html /mypage/headimage/png instead of /mypage.html /mypage.edit.html /mypage.headimage.png regards, david
Re: microsling scripting for POSTs
> I think microsling is an excellent educational tool, which easily shows > how Sling is supposed to work. In addition, microsling is also an > excellent prototyping tool to build very simple web applications (wow, > what ist that again ?) without any super-duper needs. > If you need versatility, extensibility, special needs, (you name it), > you should turn to Sling. i think i agree: i think microsling is ideal for the rapid and agile "building" of an application sling is perfect for the enterprise heavy duty "running" of the application microsling is only on the left and sling is on the left and the right ;) regards, david
Re: Location of JSP Classes
Hi Bertrand, > > ...i'm strongly against removing the class files from the repository. > > from my experience it is very valuable if you can remove the classes > > remotely > Do you need to be able to remove individual class files from the repository? Definitely. Especially for larger projects, some real-life projects run with hundreds (if not thousands) of jsps, which used to be a huge overhead to compile. how much of that is better now using a different compiler and how much really was a jasper performance issue to begin with I don't really know. > If you can live with a "delete all compiled JSP classes" function, we > can probably find another solution, like a utility that can be called > from a script to do that. > Deleting JSPs is a development/debugging concern, having to call a > script (via a URL) to do that is not harder than having to know where > and when to delete stuff in the repository. I am scared of everything that we don't put into the repository considering clustering and backup/restore issues. I recall that we basically went to hell and back for everything that we did not put into the repository, so please be very careful with that. Now for certain intermediary files that may not be an issue, I just would like to be very, very careful. > > >...I'm all for using a standard version, and forget about > > > having classes in the repository, at least for now. > > i would not care. i reckon the changes are not very complicated and > > can easily be reapplied to a new jasper version > Sure, but it's easy to lose track, and I don't think we have a > comprehensive set of automated tests for Jasper. > Besides, having our own fork of Jasper bloats Sling and might make > people wary of why we have that - all kinds of warnings go off in my > programming brain when I see a project doing this. I think we are looking for an additional abstraction when it comes to the place where we store the resulting servlet source, right? Well, let's see if we can come up with a good patch that is convincing and non-intrusive to allow our abstraction into Jasper. regards, david .ps: Is it correct that we don't have an issue actually compiling the classes into the repository (and also classload them from the repository), our issue would the transpilation to the servlet java source, right? (or did Jasper remove that intermediary step while I was asleep for a bunch of years ;))
Re: Logos (proposal 3)
hi guys, i would rather stay away from adding too much other stuff to the logo... i would be tempted reduce things a bit. anyhow, i tried to capture a large clean pixeled apache logo and tried it on the sling typo for testing purposes here... i did not have the correct font, so i used arial black. please do not consider this an alternative proposal this is just to help the process... this is not even using any design software just firefox and apple keynote. http://www.day.com/o.file/sling-logo-components.pdf?get=f814221cbf3817b2f17b4e6d30fd20db generally. i think that "design by committee" in visual design always leads to questionable results at best. regards, david On 12/1/07, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > cool. looks better :-) > > maybe you could also be a bit more 'artistic' and include something of > the 'sling' theme in the logo. > sling stands for a framework that combines jcr, j2ee and osgi. so > maybe a sling around some blocks? just thinking :-) > > regards, toby > > On 12/1/07, Ricky E. <[EMAIL PROTECTED]> wrote: > > sling: > > http://www.kb3llm.org/apachelogo/pro3d.jpg > > > > Then I was thinking something like this for micro: > > > > micro: > > http://www.kb3llm.org/apachelogo/pro3dm.jpg > > > > > -- > -< [EMAIL PROTECTED] >--- > 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: Logos (proposal 3)
> I do not understand the reflection thing :-) > And also, though it looks nice having the apache feather at the lower > right corner, it covers an important part of the "g" and allows > misreading "sling" for "slina" in this case ... :) i couldn't agree more... as i said i am just trying to help the effort of making the current proposal from a technical level more compelling. i don't even want to get started about my reservations for the current proposal in general. personally, i understand this whole excercise more as a questionable experiment or a teaching exercise rather than a serious effort to get a usable logo. as mentioned before, i think the whole exercise is a bit weird since "design by committee" always ends up with visually crippled solutions. specifically since (to my knowledge) the people on this list have no design experience or education whatsoever, to me this is a bit the blind leading the blind. regards, david On 12/2/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi, > > I do not understand the reflection thing :-) > > And also, though it looks nice having the apache feather at the lower > right corner, it covers an important part of the "g" and allows > misreading "sling" for "slina" in this case ... > > Regards > Felix > >
Re: SLING-117: don't go up the path in ResourceResolver for GET requests, and get rid of suffixes?
Hi Bertrand, > > Am Freitag, den 30.11.2007, 15:59 +0100 schrieb Bertrand Delacretaz: > > > ...Do we really need suffixes? I'm still a bit confused about their goals > > > for GET requests. > > Not sure, whether we use them, sometimes, they may be helpful > That sounds much like YAGNI to me ;-) I know of a usecase for the suffix that is very common. let's assume i would like to let a user upload an arbitrary file into an nt:resource node. To be able to provide a sensible filename for the later download I would also store the original filename along side. Now since the browser uses the last segment of the URL as the filename on the downloaders local disk, I need to have an option to append that filename at the tail end of the URI to allow for a useable filename on the client An example could work like this: /mypage - title = pdfpage title - text = this is my pdf + upload (nt:resource) - originalFilename = my.pdf An example URI could like this: /mypage/upload.spool/my.pdf Where the .spool extension would kick-off the spool.esp script that then delegates after checking the suffix with the originalFilename delegates to the WebDAV GET. This allows to expose "my.pdf" still as the "filename" of the browser download. regards, david
Re: [jira] Commented: (SLING-114) ECT - Ecmascript Client Templates
> Isn't this too close to JSTL ? is there a .jstl extension? regards, david
Re: [jira] Commented: (SLING-114) ECT - Ecmascript Client Templates
> Don't know and IMHO doesn't matter. The question is whether there would > be a possibility of mixing the two when talking of "jst files" ... since i think there is no such thing like a "jstl file" i think the two concepts are distant enough. i don't see someone getting them mixed up. as a matter of fact "jst" is already used as a short form for "JavaScript Template" in various other javascript templating projects... regards, david
Re: Request Data Validation
> imo we need not request input validation. if you want to restrict, use > the repository value constraints :-) seriously: +1 anyway, i think we should not even consider a different level of validation that could possibly conflict with what we have in the repository. sling can use the nodetype definitions to do the validation before trying to commit. if we have a usecase that goes beyond the validations we have in jcr then we can engage in further discussions. the focus is on "use"-case not "make-up"-case. i sure don't hope this is another case of "abstracting away from the repo" and that's why we would like to introduce a whole new constraint framework even for simple things such as "number in a range" or a "string that matches a given regexp". regards, david
Re: Request Data Validation
hi carsten, hehe ;) > He, you're taking all the fun out of this discussion :) > Now, I think it makes sense to have an additional validation mechanism > on top of JCR. I guess with the node type definitions you can't handle > all validation cases (like validating one field depends on the value of > another one etc.). So we need these hooks. i am all for a general "validate()" hook. (... to take care of the "dream"-case. ;) ) > It makes sense to leverage the validation information from the > nodetypes, of course. And I also think that it makes sense to validate > the input based on this information before a commit. So some sort of > general service doing this would be great... excellent. then all the general cases from xss to integer validation can easily be taken care of via regular nodetype definition. regards, david
Re: Request Data Validation
Hi Michael, thanks for the reminder. I think this is very relevant for this discussion. > When this was first discussed I think the result was to "implement the POST > script". But I would like to extend the behavior of the PostServlet without > having to reimplement everything it does. That would be something like > "implement the POST script (do some validation there) and pass on the > request to the POST servlet or not (depending on the validation)". Exactly. I think you should be able to do whatever customlogic you would like to do in the POST script and then call the default PostHandler with something like ...persistPostChangesFromRequest(jcrsession, request) or similar ;) At least my two cents regards, david
Re: use case: resolving a resource based on a node´s version
hi guys, i would rather stay away from all that business and just let the application handle it. it is important to understand that for versioning jcr does not have the concept of a head version but the concept of a node in that particular workspace. so different people can already have different views on the same content just using different workspaces. the cases where someone wants to view or diff special versions in my can easily be delegated to the application and in my mind does not need to be a first level concept in sling. i would really like to stay away from all the locale since i find that i would not even like to model that on to the individual resource in my applications, since i want the tree to diverge in different locales. i think that our url processing is complicated enough and i would really like to delegate everything beyond what we have now to the application, until we find a usecase that is not served well by delegating this kind of functionality to the application. regards, david On 12/12/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > On Dec 12, 2007 6:27 PM, Juan José Vázquez Delgado > <[EMAIL PROTECTED]> wrote: > > > ...it´s more natural for me to have > > > > /content/some/resource.html/version1/lang1 > > than > > /content/mytext.a4.print.s:version:1:4.s:locale:fr_CH.html > > ... > > I agree that your suggestion looks nicer (also because you have > simpler values that might not reflect reality ;-), and that means we > don't "invade" the selectors space which is good. > > I'd still like to define a syntax to differentiate suffixes that are > handled by Sling/microsling, as opposed to suffixes used by > applications. > > How about > > /content/some/resource.html/s:version:1.4/s:lang:fr/somefile.pdf > > where suffixes starting with s: are reserved for Sling usage? > > -Bertrand >
Re: µsling 2.0 requirements (was: [RT] Shall we merge microsling into Sling?)
sounds great. regards, david On 12/18/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > Hi > > Wow, V2.0 already :-) > > We seem to agree on the need to merge µsling back into Sling, so I > think it' be good to agree on the goals first - feel free to comment > and expand on the following list of high-level goals and requirements > for µsling 2.0. > > µsling 2.0 is a preconfigured instance of Sling, meant to allow web > developers to test drive Sling by building scripted web and REST > applications backed by a JCR repository. > > The µsling 2.0 distribution only requires a Java 5 VM to run, no > installation is needed. Fifteen minutes should be enough to start > µsling and understand the basic concepts, based on self-guiding > examples. > > Java programming is not required to build web and REST applications > with µsling 2.0: both server-side and client-side javascript code and > presentation templates can be used to process HTTP requests. Other > scripting and templating languages (JSP and BSF-supported ones) can > be plugged in easily. > > The µjax "application protocol" and client-side javascript "JCR proxy" > library make it easy to write powerful Ajaxish JCR-based applications > with µsling 2.0. > > µsling 2.0 is built on the same codebase as Sling, it's only a > specific configuration of Sling. > > All µsling 2.0 features are available in Sling applications, as long > as they are enabled in the Sling configuration. > > Sling (and µsling, as it runs the same core code) uses OSGi to > modularize the framework, but µsling does not require any OSGI skills, > and makes OSGI largely invisible to beginners. > > All Sling features and modules can also be activated in a µsling 2.0 > instance, by installing and activating the required OSGi bundles. > > µsling 2.0 passes all the integration tests of the existing microsling > test suite (SVN revision 605206), with minor adaptations where needed. > > µsling 2.0 includes a WebDAV server module to make it easy to copy > scripts into the JCR repository. > > This WebDAV module currently supports the Jackrabbit JCR repository, > but Sling is meant to run with any JCR repository. > > -Bertrand >
Re: json export: recursive by default
hi guys,
in my experience there are really 3 cases that are worth
distinguishing from a users perspective.
#1 - i want all the properties of a node in one response
#2 - i want all the childnodes of a node and their properties in one response
#3 - i want all the childnodes and properties at an infinite or
arbitrary level in
one response
i would argue that #1 & #2 make up 90% of all the requests.
#1 & #2 are not a big deal with respect to serverside caching since
they are usually very cheap.
so i would argue that with respect to caching we should probably take
care of the expensive #3...
personally, with ujax in mind, i certainly would argue that the default
behavior is important for a method like ujax.getContent("/mynode")
should be to just get the proprties of a node in a shallow manner.
which to me hints that this should probably also be the the default
behaviour of "/mynode.json" (== "/mynode.0.json").
to align with the webdav propfind "Depth" header i would recommend to go with
"/mynode.infinity.json"
regards,
david
On 1/9/08, Tobias Bocanegra <[EMAIL PROTECTED]> wrote:
> > > > Why not:
> > > >
> > > > /stuff.json?depth=1
> > > >
> > > > It's not like we need to use the URI mapping for everything.
> > > because this breaks caching.
> >
> > Really? I'm probably out of touch with current practice in HTTP
> > caching, but at least in theory there should be nothing in query
> > parameters that would prevent caching.
>
> but in real life. for example when a form input is used to display
> search results. so the content of the resulting page changes if the
> underlying search space changes. and since not all apps use proper
> cache prevention (like no-cache headers etc.) most proxies do not
> cache requests with a query (at least afaik).
>
> in any case, i find it a very good and simple differentiator (beside
> the common http headers) to decide whether to cache responses or not.
> and i would keep it this way in sling.
>
> regards, toby
> --
> -< [EMAIL PROTECTED] >---
> 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 >---
>
Sling Launchpad: How to get access to the current JCR session from .esp
Hi guys, I have been trying to access the JCR session from my .esp script to create content for an import script that needs to create many nodes in the repository. I think my initial thought was to get access to the session from the node on the resource via the .getSession() method on Node, but since the actual node was hidden by ScriptableNode I didn't find a quick way to do that. Then I thought that we might even want to expose the session in a more direct way. With my "JCR framework"-hat on I would obviously expect something on a per request basis that let's me access the jcr session that is associated with a specific request, given the authentication information etc. on the http requests. Maybe we should also get the JCR session from the resource though, which I think would fit the current (more abstract) design of Sling better. Is there a current solution that I missed? What would be a possible future way of doing that? regards, david
Re: Sling Launchpad: How to get access to the current JCR session from .esp
Hi Guys, Felix says: > Coming back to David's initial problem, that the ScriptableNode does not > provide the getSession() method: We have SLING-154 [1], which is > concerned with completing the ScriptableNode implementation, and there > is a way to access the Session, I think, we do not need to do anything > else at the moment. Well my problem that goes even beyond that. Even if I would manage to acquired a Session somehow all the nodes that come back from calls will be ScriptableNodes and will hide the methods that I need to manipulate the node. I agree with Felix that https://issues.apache.org/jira/browse/SLING-154 resolves my Issue in a pragmatic fashion. ...on a more general level, though. Carsten says: > For instance, if you have a non-jcr-resource this resource ... Can we please not use that as an argument... I really think we should focus on the real use-cases we have at hand. I know I sound like a broken record regarding the abstraction of Sling from JCR. Getting access to session and node is just the beginning. Personally, I think it makes little sense to promote abstraction on the Sling API layer, if we re-introduce all the JCR dependencies "rightfully" and based on use-cases through the back door into all the scripting layers. I guess what beats me is, why we can't build abstraction into the system as we go along and just cover our current needs for now. YAGNI. Scratch your own itch. Flexibility Syndrome. Feel free to ignore the above rant since I think we discussed this matter on this list many times over... regards, david
Re: Sling Launchpad: How to get access to the current JCR session from .esp
> I think you missinterpreted my comment and quoted my statement out of > context. ;) i competely agree... regards, david
Re: Default JSON format (was: How does one build Sling?)
hi guys,
On Jan 22, 2008 9:47 AM, Peter Svensson <[EMAIL PROTECTED]> wrote:
> DOJOTree vs. generic json tree
You are bringing up very good point.
First of all I think the default serialization should not include
"jcr:primaryType" (and other system props) and I still think that this
is something that we did not get around to fix for ujax.
I reported an Issue for that:
https://issues.apache.org/jira/browse/SLING-182
I personally believe that we should support a simple way for people to
get to different views of the same json (like the DOJO tree structure).
Now, I am not sure if we need to do that on the server side, maybe Peter
can shed some light on this: If you would acquire the data through
something like ujax.getContent() and then manipulate the object tree
on the client side, can you then supply the data for the DOJO tree
after that from a client side method or does the DOJO tree strictly require
a URL?
If it is easier to do things server sided then I would recommend to extend
the "filter" mechanisms on the server side. Now looking at:
/mynode.0.json
/mynode.1.json
/mynode.infinity.json
... from a url perspective something like ...
/mynode.all.0.json
/mynode.all.1.json
... or ...
/mynode.dojotree.infinity.json
could do the trick...
thoughts?
regards,
david
On 1/22/08, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:
> Hi,
>
> (renaming the thread to attract attention of our JSON folks)
>
> On Jan 22, 2008 9:47 AM, Peter Svensson <[EMAIL PROTECTED]> wrote:
> > ...The json that would be nice to have is something like this;
> >
> > {
> > label: 'name',
> > identifier: 'name',
> > items:
> > [
> > { name:'Fruit', type:'category'},
> > { name:'Cinammon', type: 'category',
> > children:
> > [
> > { name:'Cinammon Roll', type:'poptart' },
> > { name:'Brown Sugar Cinnamon', type:'poptart' },
> > { name:'French Toast', type:'poptart' }
> > ]
> > },
> > { name:'Chocolate', type: 'category'}
> > ]
> > }
> >
> > Where the only important stuff here is that child nodes should be put in a
> > separate array [], not as an object to the parent node, like this;
>
> ...(snipped current format)
>
> Ok, so basically you'd like the child nodes to be in an array named
> "children".
>
> I know others on this list have more javascript experience than me,
> what do people think?
>
> > Also, I have difficulties understanding what to do with the
> >
> > "testing":
> >{"jcr:primaryType":"nt:unstructured",
> >
> > part, since I would somehow like it to be like this;
> >
> > children:
> > [
> > {
> > title: 'testing',
> > jcr_primaryType: 'nt:unstructured',
> > children:
> > [
> > { title:"test2", sling_resourceType:
> > "usling/example", jcr_primaryType: "nt:unstructured", text: "Default text of
> > the test node"},
> >
> > ]
> > }
> > ]
> >
> > Hmm. I really think that this would be the correct translation, now that
> > I've printed it out. The problem was in choosing how to remove the current
> > "name: {}" structure to move the name into the object (where it is anyway),
> > like children: [{title: name}]...
>
> Ok, I agree that the above is more immediately understandable than the
> current format.
>
> The downside, iiuc, is that if forces the use of ".children." to
> access children...well, not sure if that's a downside, let's hear what
> other javascript aficionados think!
>
> > ...Note that children is just a convenient name, and doesn't mean anything
> > magic. Also, I would feel very much more comfortable not having quotes
> > around property names. I understand that they're there to escape the ':' ,
> > which are very magic in js and separates property names from values,
> > therefore I replaced them with underscores
>
> IIUC, the goal with removing the quotes is only to make the JSON look
> nicer, is that right?
>
> The problem with transforming sling:resourceType to sling_resourceType
> in JSON is the possible confusion in documentation and in people's
> minds...I don't like that too much.
>
> As you indicate, making other JSON renditions pluggable would be easy,
> but I think we should be able to agree on a good enough default
> format.
>
> -Bertrand
>
Re: Default JSON format (was: How does one build Sling?)
> > ...I personally believe that we should support a simple way for people to > > get to different views of the same json (like the DOJO tree structure). > > Now, I am not sure if we need to do that on the server side... > That can be done on the client, sure, but I think we should support > some useful cases on the server side. it depends on the client lib that you are using. some js client libs require urls to pull their data from, then we are locked into doing that on the server. > > ... from a url perspective something like ... > > > > /mynode.all.0.json > > /mynode.all.1.json > > > > ... or ... > > > > /mynode.dojotree.infinity.json > > > > could do the trick... > Agreed, the convention would then be to use the last selector > (0,1,infinity) for the recursion level, and the selector before that > for the JSON "flavor". given our current resolving i think we actually can leave this open. right? if i assume that i have the following setup. .../json.servlet (which handles everything that is not mapped) .../dojotree/json.esp (woudl deal with the server sided conversion) wouldn't that be natural? it is then up to the dojotree/json.esp to worry about the additional parameters... right? > Currently the default renderers are hardcoded in the > launchpad-servlets module, but we'll need to make them pluggable at > some point anyway, so implementing what you suggest shouldn't be a > problem. i see ;) regards, david
Re: Default JSON format (was: How does one build Sling?)
hi guys, i am still somewhat confused why we are looking into the whole escaping issue. was there an actual issue at hand? so far i have not experienced any issue with the current "escaping" and i really would stay away from something like url escaping... i simply don't see a need. am i mistaken? btw: i am happy to remove the quotes from names that don't need the quotes. regards, david On 1/22/08, Peter Svensson <[EMAIL PROTECTED]> wrote: > Ahem. :) I kind of assumed that the "sling:resourceType" property was magic, > and anything inside it would something that could be rendered in a browser. > Maybe not. > > I think that one of the problems in learning Sling is that it seems to be > infinitely configurable, so that you can add renderers for things on the > fly, et.c. But if I say it this was; If there is some kind of basic type in > Sling for content to be consumed in a browser, then that could reasonably be > decalured to be of type urlencoded String. Would that be OK. > > Also, for my current project (Bunkai editor for Sling), I don't really need > the content int he json structure, I only need the hierarchical structure, > in array format already described, and some unique id/name that I can use > later, when a treenode (in Dojo) is sleected, to get the actual content. > > Cheers, > PS > > On Jan 22, 2008 12:07 PM, Bertrand Delacretaz <[EMAIL PROTECTED]> > wrote: > > > On Jan 22, 2008 11:53 AM, Peter Svensson <[EMAIL PROTECTED]> wrote: > > > > > ...The 'meaning' of a property value is application domain specific > > anyway, so > > > I think we can choose any encoding type which is reasonably simple, as > > long > > > as it is documented clearly > > > > But how do you decide (in the general case, with the default JSON > > renderer) which properties to escape() and which to send out > > unescaped? > > > > And how do you tell the client (dont' say "configuration" please ;-) > > which ones are escaped? > > > > -Bertrand > > >
Re: ujax ponderings
hi peter, On 1/22/08, Peter Svensson <[EMAIL PROTECTED]> wrote: > Sure, I'm installing it right now. But it feels kind of odd to use a > commercial product to be able to understand an Apache project :) totally... i think once the packaging and documentation is up to par, in my mind there should even be a more efficient way to get your hands on ujax directly from apache. sorry for the little detour to "day", i am sure in a couple of weeks from now this will not be necessary anymore... > Don't get > me wrong, though. I'll use it to try to understand how things work, but am I > allowed to use things in ujax and copy them to my Sling installation? How > does CRX relate to Sling? CRX is our commercial offering around jackrabbit. the crx installer that is attached to the blogpost features the prerelease of ujax... the firststeps.zip should also help to understand things... you should definitely be able to copy your ujax app to your opensource sling install, as a matter of fact even the extracted firststeps.zip should work in you sling install. please feel free to contact me directly if you have issue with the installer and crx, since i am not sure that this is of greater interest for this list ;) sorry again for the detour. regards, david
Re: ujax ponderings
hi peter,
to me this looks like there is no /ujax-test node in your repository.
could that be? i am not sure where the ujax-test creates its nodes...
btw. for generic ujax prototyping i usually use these installers here:
http://dev.day.com/microsling/content/blogs/main/microjax.html
which make things a lot more transparent since there is a jcr
explorer that comes with it... anyway, since you want to build
top of trunk this might be all that valuable...
regards,
david
On 1/22/08, Peter Svensson <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I've now managed to compile and install the stand-alone version of
> microsling from the repo. Very well polished process. I'm very impressed :)
> Now, I'm trying out some moves with the ujax.js library which a friendly
> soul has provided, to see if I can grok more what it is doing.
>
> I've done the following;
>
> 1) I've run the ujax-test from the Sling start page, which ran OK
> 2) I've seen that a new directory under my mountpoint is created, called
> ujax-test.
> 3) I try to do the following in my html-based client;
>
> var root = ujax.getContent("/ujax-test");
> console.log("root ujax node is "+root);
> console.dir(root);
>
> And I get an empty object, because;
>
> 22.01.2008 22:46:56 *INFO * MicroslingResourceResolver: Path '/ujax-
> test.json' does not resolve to an Item (MicroslingResourceResolver.java,
> line 363)
>
>
> And I wonder what I'm missing. Thankful for help,
>
> Cheers,
> PS
>
Re: Change in default handler
hi peter, i think this is an issue that sling tried to execute the js file instead of just delivering it. this was part of a bigger discussion and should have been removed by now. felix may have more details. regards, david On 1/28/08, Peter Svensson <[EMAIL PROTECTED]> wrote: > Hi, I've finally found some time again to see if I can get Sling and Bunkai > to work together. My plan at the moment is to create my own custom esp > script to handle serialization of resources hierarchies into json, in a way > that can be consumed by Dojo. > > I've managed to mount the latest svn revision of Sling and use Launchpad. > I've copied Bunkai into the webDAv mount, and manage to access my html page. > The css gets read correctly, but when I try to laod any js file, I get this; > > javax.script.Bindings.put(Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; > (500) > > The requested URL /bunkai/dojo-1.0.2/dojo/dojo.js resulted in an error in > Sling Core Default Servlet. > Exception: > > java.lang.NoSuchMethodError: > javax.script.Bindings.put(Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; > at > org.apache.sling.scripting.resolver.impl.DefaultSlingScript.verifySlingBindings(DefaultSlingScript.java:305) > at > org.apache.sling.scripting.resolver.impl.DefaultSlingScript.eval(DefaultSlingScript.java:97) > at > org.apache.sling.scripting.resolver.impl.DefaultSlingScript.service(DefaultSlingScript.java:162) > at > org.apache.sling.servlet.resolver.defaults.DefaultServlet.doGet(DefaultServlet.java:81) > > And I understand that this means that the current Launchpad does not > know how to provide .js files. > Most probably, it's a simple operation to copy code or classes from > the old microsling project, to get this working, but I'm not sure how > to go about it. > > Any directions welcome :) > > Cheers, > PS >
Re: SLING-154, ScriptableNode access to Properties and JCR methods, how?
Hi Bertrand, > The simplest way might be to require the use of node.getPath() instead > of node.path, and use javascript property names for content access > only, not for JCR getters. I completely agree to that solution. I think I have a strong bias for using node.propname for accessing the properties and the node.childnodename for child nodes. One of the reasons to resolve the issue this way is that this would allow compatibility between ujax (jst) and .esp when it comes to content access. (especially if we would introduce a currentNode on the server side aswell) I think accessing the original Node methods with node.getPath, node.getSession() is perfectly acceptable. regards, david
Re: SLING-213 vs. SLING-126
Hi Guys, i had a quick chat with Felix and would like to propose the following: (1) since we are handling responses to POSTs that have to be both machine readable and human readable and even more importantly has to be handled gracefully by both XHR and "regular" browser POST the default response needs to be text/html. Since also the regular browser POST has to be "machine readable" we end up with the following contract. (2) the returned xhtml contains identified and specified "Id" attributes that are used for machine readability. The Id's used are as follows: "Status", "Message", "Location", "ParentLocation", "Path", "Referer", "ChangeLog" at this point. The CDATA of the elements with the respective attributes contain the values resulting from the POST operation. "Location" and "ParentLocation" contain a (possibly rewritten) "href" attribute with the same target information. (3) If the "ujax:redirect" parameter is used, it will either contain a URL to be placed into the Location header of the 301/302 response, or a reference to the "newly generated" resource using the "*" notation (for example, "*.html, *.edit.html). I think it would be great if the above was put into junit tests. Please let me know if that makes sense. regards, david On 2/4/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi, > > Thinking about this a bit, I get quite at unease. Initially I understood > ujax as a two-part protocoll: A client-side and a server-side part. The > server-side part would care for accessing the storage while the > client-side would care for user interaction and GUI support. This IMHO > means, the protocol should be defined for "machine-machine" interaction > and leave the human interface to the client-side frontend. > > Looking from this position, there are the following options: > >* Send back success information for the client >* Redirect to the input form submitting the POST >* Redirect to the modified/created Resource > > The main issue is the question of sending back success information, > because the other two cases can be handled by the ujax:redirect > parameter. Now for sending this information and keeping in mind the > separation of the tasks of client and server, I would just send back > plain machine readable information, that is JSON (parsing HTML is > error-prone at best ;-) ). > > Therefore, I would really like to make it as simple as possible by > defining a new property ujax:response as follows and dropping > ujax:redirect: > > ujax:response = ujax:status -> send back status info as JSON > ujax:response = *[ext] -> redirect to modfied/created Resource > where ext is used as the extension, > default .html > ujax:response = ujax:referer -> redirect to Referer: > > As a default (when ujax:response property is missing), I suggest to > redirect to the created/modified Resource. > > Am Samstag, den 02.02.2008, 14:13 +0100 schrieb Tobias Bocanegra: > > another thought: since the extension of a request pretty much > > determines what content should be returned, i suggest to use the > > extension to select the POST response: > > > > assume a resource at /foo/bar > > > > POST /foo/bar > >writes back changes and redirect per default to the referrer > > Not sure... > > > POST /foo/bar.html > > writes back changes and responds with the suggested HTML status response > > Probably might also expect to just get the modified Resource back as > HTML ??? > > > POST /foo/bar.json > > writes back changes and responds with a JSON status response (tbd) > > Same but as JSON ?? > > > > for node creation: > > > > POST /foo/bar/* > > creates node, writes back changes and redirects to the newly created > > resource (default .html ext.) > > POST /foo/bar/*.html (or /foo/bar.html/*) ?? > > creates node, writes back changes and responds with the HTML status > > response > > POST /foo/bar/*.json (or /foo/bar.json/*) ?? > > creates node, writes back changes and responds with the JSON status > > response > > These show exactly, the complexities of your proposal, all look bad and > ugly.. > > Regards > Felix > > > > > things that at not very clear to be are: > > - needs the creation request to be /*.html or .html/* so that the > > resources .html extension mapped > > servlet does not get selected? > > - how can one still use a custom POST script for that resource ? maybe > > the extension for the > > HTML status response should be .xhtml ? > > > > regards, toby > > > > On 2/1/08, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > > > hi, > > > i've discussed this with david extensively and since he was the > > > inventor of the ujax (former rjax) "protocol" he thinks now that the > > > proposal to use the referer as default redirect is not useful. > > > it was also david that proposed the html response which is of a format > > > that it is human (browser response), machine (xml) and dhtml > > > (javascript) readable. > > > > > > i think it
Re: Need to have the ability to add primary content type to PUT in UjaxPostServlet
hi eric, what do you mean by sling:primaryType? are you referring to jcr:primaryType? regards, david On 2/5/08, Marts, Eric <[EMAIL PROTECTED]> wrote: > I updated class to handle sling:primaryType request parameter. Need to get > into main branch. > > addNode(node, type); > > Eric >
Re: SLING-154, ScriptableNode access to Properties and JCR methods, how?
> Node methods are accessible in javascript with their real names like > "node.getPath()". very cool. > Node poperties and child nodes are accessible as javascript > properties, like "node.text". sounds great. > On Feb 1, 2008 8:01 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > ...I am perfectly fine going back to not having the methods be > > properties and access properties and child nodes as properties of the > > node - which is equally natural, of course. But then, we should finally > > keep it one way or the other, ok ?... > Sure, I think the current status is usable, and direct access to JCR > methods allows edge cases to be solved, if needed. sounds excellent, exactly what i was looking for... i especially like this approach since it allows for a similar access to content in client sided ujax. regards, david
Re: Breakthrough with Bunkai
Hi Peter, Thanks a lot for the update, that sounds great. Congratulations. > heres a snippet which I used in conjunction with the 15 minutes Sling > example; > <... source code ... /> that looks about what i expected for a dojo-tree specific integration effort, that you were referring to very early on... is that about right? > Also, I'm not sure where this script should reside, and where bunkai itself > should be put.. Generally we (at Day) tend to put applications into the /apps folder. So you would find your script somewhere in the /apps/bunkai folder. I think there are a still couple of open questions around where to put what when it comes to something very general, like the mentioned alternative .json rendition. > I also need to find a good license to put bunkai under. > The source code editor is not mine, for instance. I think from an Apache standpoint we certainly would have a recommendation about the preferred licensing terms in the part of the galaxy ;) [ hint: http://www.apache.org/licenses/LICENSE-2.0.html ] regards, david
Re: [PROPOSAL]: Add Resource.listChildren() method
Hi guys, I agree with Lars. on top of that I would like to mention the following things: (1) I feel like with a getChildren() method we slowly see parts of the Node interface sneak in through the back door. I think it is fairly public that I am not a big fan of the abstraction from Node but now that we have the abstraction I think we should even think of Resources that do not even the concept of a hierarchy. (2) I would really like to table the sling API discussions for a while and let us all gather some experience with what we have before we we start modifying the API. From my personal perspective the constant change in the sling API is the biggest problem for the few early adopters we have. just my two cents... regards, david On 2/15/08, Lars Trieloff <[EMAIL PROTECTED]> wrote: > Hi Carsten, > > I have to disagree. Treating all languages the same will result in an > API that does not match the concepts of most languages supported. > Different programming languages have different concepts and if possible, > we should support these concepts. > > This does not interfere with implementing the listChildren() method in a > clean way, but we should also keep in mind that some languages we > support do not have a concept of methods alltogether (Javascript, > Velocity, Freemarker), some are dynamically typed and some are untyped. > > By disregarding this fact we create a cumbersome API that feels like the > DOM API (that was designed to be language-independent and lead to > implementations like DOM4j or JDOM that fit better to the concepts of > the programming language environment) > > To sum it up: When implementing scripting support, we should allow the > scriptingengine to add additional convenience accessors and type > conversions, but we should not implement some concepts (like > listChildren()) exclusively for one language. > > regards, > > > Lars > > > On Wed, 2008-02-13 at 09:42 +0100, Carsten Ziegeler wrote: > > Now, rethinking as well :) I would also go one step further > > > > All languages should be treated the same. It's too confusing that one > > script language provides additional behaviour/methods on objects that > > other language do not provide. This will cause problems over time. > > > > A resource should not provide a way to get the resource resolver. I > > think this is the root cause of the problem (ok, so far it is actually > > the resource provider). We already have a way to get the resource > > resolver and that's the request object, so instead of using: > >resource.getResourceResolver().listChildren(resource) > > you use > >request.getResourceResolver().listChildren(resource) > > which frees us from passing the resource resolver to the providers. > > And it's even much cleaner as a resource does not need to know anything > > about the resource resolver. > > > > I don't think that going this clean api way :) is too much to type for > > all our script fans here. Assuming that you iterate over children once > > in a script, you have to type approx. 30 more characters - compared to > > the overall size of a script its negletable :) > > Ok, more seriously, this gives us well defined > > > > Felix Meschberger wrote: > > > Hi all, > > > > > > I have been rethinking all these and also Carsten's input on our past > > > discussion regarding "intelligence of a Resource". I also looked at the > > > API and the intentions of it again, which I summarize as follows: > > > > > >Resource - The object representating some datum in Sling. This may be > > > a JCR Node or > > > Property or an OSGi Bundle resource or an OS filesystem file. > > >ResourceResolver - The object providing access to Resource instances > > > from the > > > application context. The ResourceResolver represents the > > > external view of > > > the Resource tree. > > >ResourceProvider - The object capable of representing certain data as > > > Resource > > > objects. > > > > > > The ResourceResolver interface is typically implemented once. It > > > incorporates the logic of dealing with multiple ResourceProvider > > > services. ResourceProvider instances may be provided by multiple parties > > > outside of the scope of the ResourceResolver. The ResourceProvider > > > instances are the factories of Resource objects: The ResourceResolver > > > asks the ResourceProvider for the creation of Resource objects. That is, > > > Resource objects are created under the auspices of the ResourceProvider > > > and not of the ResourceResolver. > > > > > > What this means is, that Resource objects have absolutely no means of > > > accessing the mechanism of how a ResourceResolver uses ResourceProvider > > > services to find and create Resource objects. Consequently, the Resource > > > cannot list children and cannot access relative resources. > > > > > > Therefore I have to revert and agree with Carsten, that any such
Re: various questions regarding alternative scripting engines
hi guys, > var node = resource.adaptTo(Packages.javax.jcr.Node) i personally think this sucks since it is going to be a cryptic part in the beginning of all my esp scripts... in my view this really should be hidden. the point of using scripting is to hide all the unnecessary detail of whats going on underneith... as a matter of fact i would like to see a "currentNode" variable in all the scripting environments, so i don't have to deal with the resource to begin with... regards, david On 2/15/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi, > > Am Freitag, den 15.02.2008, 11:43 +0100 schrieb Michael Marth: > > > Hi Felix, > > > > > > > > > But if I try to access something like $resource.node (which I would > have > > > > expected) Velocity does not recognize the expression. How do I get to > > > the > > > > node? Do I have the wrong syntax? I looked at the src of > JcrNodeResource > > > and > > > > expected to be able to use something like .node, .getNode() or similar. > > > > > > > > > I do not exactly know, how velocity maps Java objects. But a resource is > > > definitely a Resource and by conincidence a JcrNodeResource. In > > > addition, the JcrNodeResource.getNode() method is not public and not > > > part of the API. > > > > > > When you want to access the node of a resource you will have to adapt > > > the Resource to the Node class, something like: > > > > > > $resource.adaptTo(Node.class); > > > > > > But I am not exactly sure about the exact syntax. > > > > > > I am not exactly a velocity expert, but I tried this and had no success so > > far. But I also think that having to "cast" (sort of) a resource into a > node > > in a script is a bit weird. > > > This is not a cast its an adaption to another "view" of the same > resource. > > > > Especially, if you consider that > > resource.nodeworks in esp's. Could we not just get the node as an > > object right away? > > > Which is probably an error as it introduces an API in JavaScript which > is not paralelled by the other APIs, we should probably remove that > > > > > > I am aware that this has been discussed before, but I do not see any > > advantages of abstraction lost if the node object is available to the > > scripts if the resource in question is actually a node. > > > I do not quite understand this sentence. Do you want to say, the node is > lost due to the abstraction ? This is not the case as you can adapt the > resource to the node. > > > > The script needs to > > "know" it handles nodes anyway. > > > Yes, your particular script might now, but a script in general might not > care ... So we have the resource and that's it. You get the node by > adapting the resource. The question is how to use this API in your > favourite scripting language. > > E.g. in JavaScript you can do > >var node = resource.adaptTo(Packages.javax.jcr.Node) > > maybe in Velocity the equivalent might be > >#set( $node = $resource.adaptTo(javax.jcr.Node) ) > > Regards > Felix > > > > > WDYT? > > Michael > >
Re: various questions regarding alternative scripting engines
hi carsten, > Ok, we can still argue about the name though... :) I would call it just > "node" as we already have "resource" i agree that node would be intuitive. there are really two issues why i personally would mildly favor "currentNode". a) when working with jcr "node" is a very frequently used local variable (at least in my code ;) ) and we could avoid some collisions. b) in ujax on the client side we already called it "currentNode" and it is also called currentNode granted that both of these reason make for a rather weak bias, i am happy to be convinced otherwise. regards, david
Re: help, my content model looks un-Slingable
Hi Jukka, I think that's a great idea. On top of that we used in microjax in case a node was not mapped we tried the following. if the node was located in /content/ we tried /apps/ as the default resource type which works out beatifully to keep simple applications simple. To address Michaels issue I would recommend to do the following: If a resource cannot be resolved to a resourcetype I would recommend to just go up the tree and take the resource type of the parent. I think that would easily address the issue of people that have a large tree of information but can't change anything in the tree itself. They can just apply a sling:resoureType to the root node of that tree and be done with it. regards, david On 2/15/08, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Hi, > > On Fri, Feb 15, 2008 at 5:19 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > Am Freitag, den 15.02.2008, 15:47 +0100 schrieb Michael Marth: > > > Maybe it would be helpful if we had some additional script resolution > > based > > > on URLs or paths. In my example I could map a script to nt:resource if > > the > > > resource is below /content/mails or so. Such a mechanism could really be > > > helpful for users that have no possibility to modify existing content. > > > > We have discussed and abandoned this idea before, because we could not > > find a generic and easy way of defining which part of the path would > > influence script selection. If you can provide us with such a > > definition, we would re-evaluate our findings. > > How about allowing a sling:config child node that could be added to > any node and could contain script and servlet mappings and other > configuration settings that would apply only to that subtree? This > would solve both this and the multiple domain issue from the other > thread. > > I suggested this already earlier, but the general response was that > the mapping configuration should be a property of the components > instead of the content. That's a valid point, but I think relaxing > that criteria is the only way to allow this kind of customization. > > BR, > > Jukka Zitting >
Re: LDAP user authentication
I would argue that a proper architecture would be to use the repository authentication to go directly to ldap. Since this would allow you to use the repository users for access control. This is exactly how we integrated it in our commercial content repository [1] (which is based on jackrabbit) and I would argue that this is the only proper way of dealing with authentication in sling since this would allow the repository to reflect particularly read privileges properly for example in search results. In my mind one of the main purposes of using a content repository is to be able to ignore access control all together on the application layer. regards, david [1] http://www.day.com/crx (testdrive here: http://jcr.day.com ) On 2/21/08, Torgeir Veimo <[EMAIL PROTECTED]> wrote: > > On 21 Feb 2008, at 22:47, Vidar Ramdal wrote: > > >> On 21 Feb 2008, at 22:25, Vidar Ramdal wrote: > >>> Does anyone have a working example of configuring Sling to using an > >>> external LDAP server for authentication? > > On 2/21/08, Torgeir Veimo <[EMAIL PROTECTED]> wrote: > >> I'd assume this is sort of orthogonal to Sling at the moment? > >> > >> One option would be to employ something like Spring security or > >> SecurityFilter with an appropriate LDAP realm impl. This would make > >> sure all requests would return something sane in the > >> getUserPrincipal() and isUserInRole() calls. You could then code > >> accordingly in your Sling components. > > > > I see. But using a servlet filter would not enforce security on the > > JCR itself. Perhaps it would be easier to setup Jackrabbit with LDAP, > > and then handle authorization issues when Sling connects to > > Jackrabbit. > > > > If Jackrabbit actually supported any authorisation.. (I assume you > know it's planned for JCR 2.0, see also > https://issues.apache.org/jira/browse/JCR-1171) > . You can store ACLs as node children though (we currently do this, > but we don't enforce security through the AccessManager mechanism > provided by JCR itself but at a higher level). > > My general experience is that many application might need the concept > of ownership (eg your blog posts are only editable by you), but that > read permissions are mostly set at world-readable. The concept of > ownership would be integral to your domain model, and should probably > be enforces as part of any DAO layer. If you need anything more > advanced than that, all access to the JCR nodes should go through a > proper DAO layer, also for reading, which would sort of make it wise > to use something else than Sling. > > > -- > > Torgeir Veimo > [EMAIL PROTECTED] > > > > >
Re: How to I chmod -x on Javascript files
Hi guys, I think we had this discussion before. I really strongly disagree with executing anything that has an exact match in the content repository. If we have an exact match in the repository we need to let the webdav servlet take care of things. So a GET to .jsp, .esp, .ecma, never executes, but just does a plain old get. if you want to execute a script directly (which in my mind violates resource orientation) one should be forced to to use let's say a ".run" extension. so: GET /test.esp -> returns the sourcecode GET /test.esp.run -> executes the script I am not even sure that we need this feature, but please don't break the WebDAV access to resources in sling by default. regards, david
Re: Change server side JavaScript extension to ecma (was: How to I chmod -x on Javascript files)
hi guys, as I mentioned in the other thread, I think the primary issue is with making sure to delegate all the exact matches in the repository to "static" webdav delivery. I think that renaming the server-side ecma script stuff is great and should be done as soon as possible ;) I only have a very smallish bias for ".ecma" over ".es" regards, david On 2/21/08, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > On Thu, Feb 21, 2008 at 4:50 PM, Tobias Bocanegra > <[EMAIL PROTECTED]> wrote: > > +1 good idea. but would be ".es" a better extension? > > > Agree with .es > > > -Bertrand >
Re: How to I chmod -x on Javascript files
responding to myself: > so: > > GET /test.esp -> returns the sourcecode > GET /test.esp.run -> executes the script > after talking to Bertrand and suddenly remembering the discussion I had with Felix a while ago ;) I think Felix came up with the even better solution to use the proper extension that fits the mime-type. so we would end up with something like: GET /test.esp.exec.html or GET /test.esp.html to trigger an execution of script. As far as I understand people are generally in agreement with that so feel free to ignore my previous mail ;) regards, david
Re: Theme Handling
i am also for removing it for now. regards, david On 2/21/08, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > Hi, > > currently we have the Theme and ThemeResolver interfaces in the core. > The support for themes is not yet implemented and we haven't discussed > this topic yet. > > So I think we should either discuss this topic for an upcoming release > or remove this feature for now. I'm not sure if Sling should already > provide support for themes. > > Carsten > > -- > Carsten Ziegeler > [EMAIL PROTECTED] >
Re: How to I chmod -x on Javascript files
Hi guys, > > > Executing a resource as a script is just another way of rendering > > > a representation to be sent to the client. > > thats what's this all about :-) > Exactly. I don't understand why people seem to consider > "executability" as some kind of special property that needs custom > support when the standard Sling features are quite enough to cover > that use case. After thinking things through a bit again, I think that the custom "exec" selector would be the best solution. But as Jukka pointed out, this is just a convenience thing, to avoid having to create a node with a resourcetype that points to your script. Personally, I think we can turn it off for now. regards, david
Re: Allowing anonymous access per default?
hi all, here my +1 for anonymous access by default. also prompting the user with a 401 for something that he does not have read access for is not an option, since in jcr if you are able to read content there is no way to tell that something exists. > > But still, the desired behavior is to ask the user for authentication if > > he is not authenticated and write permission is denied. > Your problem has nothing to do with the fact that we allow anonymous > access per default now. > Before that you could login as anonymous and would face the same problems. > This is rather a problem of the post servlet and the permission checking > there. Could you please open an issue? i agree with carstens assessment. i don't think though that the desired respeonse code for a permission denied on the repository level is a 401 even for "anonymous", but i think it should be a 403 error code instead. thoughts? regards, david
Re: Replace ujax: prefix to sling:
hi guys, i think it is confusing to deal with all those technologies for a newbie. everything from jackrabbit to sling to jcr to osgi to launchpad to ujax. some of this complexity is not necessary and can be removed easily. i think the ujax / sling distinction can definitely go. i would basically recommend to replace ujax with sling throughout the code, this particularly includes the js side, and would graduate ujax into the sling js library, which makes perfect sense to me. regarding r-u-microjax, and related acronyms, this was more making fun of bad acronyms than anything else and i always hoped that someone would come along with a better name, so i am more than happy to just call it "sling". regards, david On Mon, Mar 10, 2008 at 8:09 PM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > doesn't the "Jax" refer to the mechanism how the form post is handled? > it would at least call it 'sjax' > > regards, toby > > > > On 3/10/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > Currently names used by Sling are prefixed with sling: with the > > exception of well known parameters of the ujax servlets. To get all > > these prefixes in line I suggest we change the prefix used by ujax > > parameters to sling: > > > > WDYT ? > > > > Regards > > > > Felix > > > > > > > -- > -< [EMAIL PROTECTED] >--- > 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: /sling/sling.js path hidden by OSGi management console
hi guys, >* /system/sling/console - the sling console >* /system/sling/info- the info servlet >* /system/sling/docroot/sling.js - the client side library... this works out beautifully for me under 1.5 conditions ;) (1) the docroot mapping works at some point. which leads to the fact that i can do
Re: /sling/sling.js path hidden by OSGi management console
> > And as you mention sling.js is static, so why not > > * /system/static/sling.js - the client side library... > > to make it explicit. why would that be interesting to a user? static is not a property of that script include that bears any meaning to the user regards, david
Re: /sling/sling.js path hidden by OSGi management console
> Ah, now I remember the reason for docroot In this case, I would NOT > put sling.js into docroot. IMHO it is not required to access this > as /sling.js i thought so ;) from a "user" perspective though it is hard to explain and justify a "funky" url. i think this is very similar to the webdav url. i think the "simplest" case needs to be very simple and i definitely see value in going out of our way to make the first steps as simple as possible... regards, david
Re: How-to execute a query from an ESP script?
> This is why we have ResourceResolver.findResources() > and .queryResources() ;-) I think that I agree that this may be functionally simpler, however I think that it is not exactly "intuitive" (which for me makes up the the biggest part of "Simple"). If I want to "execute a JCR query" as Gert put it I don't understand what business I have with a thing called the "ResourceResolver". If I have a really simple problem, I think we should offer a really simple solution with having some first understand the internal architecture of Sling. regards, david -- Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
Re: Node name generation
hi guys, personally, i don't care too much as long as we keep the "simple case" namely where the default namehint (if it is not explicitly set) is derived from jcr:title, title etc.. of course, i think we should (like for all form elements that have a special meaning to sling) prefix it with "sling:" my personal favorite would be "sling:nameHint" regards, david On Mon, Apr 14, 2008 at 5:05 PM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > Bertrand Delacretaz wrote: > > > On Mon, Apr 14, 2008 at 4:38 PM, Felix Meschberger <[EMAIL PROTECTED]> > wrote: > > > > > > > ...Can we find something > > > else than "nodeName" ? How about "exactName" ?... > > > > > > > nodeName is IMHO better, as the parameter describes the name of the > > created node...exactName could be the exact name of your sister ;-) > > > > > :) > > > > But to be consistent, nameHint should be nodeNameHint maybe. A bit > > longish but very clear. > > > > > Ok, we should either use "nodeNameHint" and "nodeName" > > or > > "name" and "nameHint" > > From those two options I would prefer the first one. > > Carsten > > > > > > > > ... And then, I would not filter or otherwise mangle the exact name > (this is > > > the difference to Betrand's proposal) and rather fail if the name is > > > invalid > > > > > > > We are in agreement, that's what I suggested, no filtering for nodeName. > > > > -Bertrand > > > > > > > > -- > Carsten Ziegeler > [EMAIL PROTECTED] > -- Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
Re: How-to execute a query from an ESP script?
Hi Guys,
here is my take (using JCR of course ;) ):
<%
var qm=currentNode.getSession().getWorkspace().getQueryManager();
var q=qm.createQuery("SELECT * FROM nt:resource ORDER BY
jcr:lastModified", "sql");
var res=q.execute().getNodes();
while (res.hasNext) {
hit=res.nextNode();
%><%= hit.getPath() %><%
}
%>
However, I think this really should be a lot simpler...
looking the the Sling.getContent() on the client side, I think for
javascript on the client
side we should have something like a Sling.query() that returns a
collection of nodes.
Since think that we in the long run it would be great to offer scripts
on the server
side the same level of convience i think the resulting script (both on
the client
and on the server) should look something like this.
<%
var res=Sling.query("SELECT * FROM nt:resource ORDER BY jcr:lastModified");
for (var a in res) {
hit=res[a];
%><%= hit.getPath() %><%
}
%>
regards,
david
JCR Explorer
hi craig, personally, i think that it would be great if the jcr explorer was backed on the standard sling json serialization and the standard forms conventions for writing content. i have recently seen a great example of a very good jcr explorer using extjs. as a matter of fact i think that this was visually substantially superior to the dojo/swing based jcr explorers that i have seen in the past. i think it may well be worth the effort of looking into finding out what we can do around the gplv3 licensing of extjs. just my two cents... ;) regards, david On Tue, Apr 22, 2008 at 4:37 PM, Craig L. Ching <[EMAIL PROTECTED]> wrote: > I'll take a shot at the JCR explorer. My time is very limited, but I'll > try and get a start this weekend. Is there a JIRA with some good > requirements yet? > > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of > > Bertrand Delacretaz > > Sent: Tuesday, April 22, 2008 5:15 AM > > To: sling-dev@incubator.apache.org > > Subject: Re: Welcome Janandith, let's make Scala happen for Sling > during > > GSoc! > > > > On Tue, Apr 22, 2008 at 12:08 PM, Vidar Ramdal <[EMAIL PROTECTED]> wrote: > > > > > ... I guess this means that the JCR Explorer project was > declined?... > > > > Yes, unfortunately that won't happen, and there was another project > > about creating more tests (yum ;-) which won't happen either as part > > of GSoC. We're lucky, and very grateful to Google and everyone > > involved, to get one slot! > > > > And nothing prevents the other projects from happening, it's just that > > they won't happen within GSoC this time. > > > > -Bertrand > -- Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
Re: JCR Explorer
> Personally, I prefer dojo and would rather contribute something based on > that. If people want to do an ext-based explorer, I'm not sure that's > something I'd be interested in. As for looks, I'd need you to be more > specific about how ext is "visually substantially superior." Honestly, > though, there is more to javascript UI development than just looks ;-) well, i would agree to that... as long as we can agree that "looks" specifically visual consistency is important for a ui. > I am genuinely interested in your opinion and examples, though, because > I've seen some really good dojo-based UI's. > I do think that the default L&F of dojo maybe isn't the best, but I'm certain > we wouldn't have to live with that. well, maybe i just have only seen the wrong dojo ui's so far... maybe you could point me to a couple of good examples or themes that you think work with from a visual perspective. and i guess visual consistency comes amongst other things from about a zillion small css settings that i am personally not prepared to put in my time to fix them in dojo. i know that for myself, that i would then probably live with ugly interface and hate it every time i use it ;) (jokingly i would compare it to using fvwm on linux) regards, david
Re: JCR Explorer
> > ...code speaks louder than > > words. So I'll continue with my concept based on dojo, if someone beats > > me to it with ext, then so be it ;-)... > Whoever does the work gets to decide, so go for it! absolutely! regards, david -- Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
Re: Simplifying script paths and names?
hi guys, after going through this entire discussion and looking at issue: https://issues.apache.org/jira/browse/SLING-387 i would like to raise the following point. i think it is important that this change was originally suggested to make the simple cases as simple and intuitive as possible for the user of sling and not to come up with something that is really easy and consistent to map for the sling implementation. let me try to explain with an example: as a user of sling i would like to have my app in /apps/myapp and lets say i have a node of resourceType "myapp/homepage" at "/content/myapp". i would like to to be able to structure my applications as follows: (1) /apps/myapp/homepage/hompage.esp (or html.esp or GET.esp) (2) /apps/myapp/homepage/edit.esp (or edit.html.esp) (3) /apps/myapp/homepage/header/highlight.jpg.esp (4) /apps/myapp/homepage/header/selected.jpg.esp (5) /apps/myapp/homepage/header/small.jpg.esp where /content/myapp.html -> (1) /content/myapp.edit.html -> (2) /content/myapp.header.highlight.jpg -> (3) /content/myapp.header.selected.jpg -> (4) /content/myapp.header.small.jpg -> (5) i think it is important that we avoid unnecessary repetition at any point and we would allow for enough flexibility in the /apps directory allow the user to come up with something short, distinct and meaningful. regards, david On Fri, Apr 18, 2008 at 6:34 PM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > hi, > i just want to add, that most of the requests that actually hit sling > will probably be plain .html requests with no selectors. so the > /apps/foo/foo.jsp will probably resolve those requests. since requests > that usually need selectors are image requests which are very good > cacheable in a higher teer. so i don't think that in a real-live > scenario, the resource resolution performance is that relevant. and of > course it can easily be cached. > > -- > toby > > > > > On 4/18/08, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > > Felix Meschberger wote: > > > > > > > Hi, > > > > > > Am Freitag, den 18.04.2008, 16:35 +0200 schrieb Carsten Ziegeler: > > > > > > > Having scripts in /apps and /libs where /libs has precendence of /apps > > still feels not very intuitive for me. > > > > > > > > > > It is the other way around: /apps has precedence over /libs. And this is > > > IMHO intuitive. > > > > > > > > Hehe, you see, it's not intuitive for me (ok, I'll write down 100 times > > "apps has precedence over libs, apps has precedence over libs..." > > > > > > Carsten > > > > -- > > Carsten Ziegeler > > [EMAIL PROTECTED] > > > -- Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
Re: Simplifying script paths and names?
hi guys, i agree with carsten that we probably can't reach on consensus on this list and "design" by committee in this case certainly shows its weaknesses. this is a topic where everybody can have an opinion about but only very few of us larger scale experience with using the sling script resolution to solve their real-life needs. i think that it is probably the easiest if toby and i come up with a proposal as an actual patch that suits our needs and experiences from a users perspective and meets the performance requirements, and then take this a basis for discussion, and check with you guys where we have shortfalls on the performance side of things... generally, i would like to keep this proposal backwards compatible to the current one, since there are only 2 or 3 that are broken and the rest is perfectly fine and suits the needs. keeping things backwards compatible also makes this a minor change and convenience improvement for current users. regards, david On Sat, Apr 26, 2008 at 11:14 PM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > > > > > > > Well, on the other hand, it has been pointed out that the real issue is > > > just the fact that all scripts are named "htlm.*". I'm really not very > > > optimistic that the simple looking solution to duplicate the node name > (or > > > whatever makes up the last node in the hierarchy) to get the file name > is a > > > clear and simple concept. Telling people that they can write "foo.jsp" > to > > > get html while they have to use "pdf.jsp" to get a pdf, seems very > > > complicated to explain and understand. And as I pointed out, as soon as > you > > > are heavily using any other format than html, you end up with the same > mess > > > (all files named pdf.*) > > > > > > > > > I did think a bit about the refactoring and renaming problems that might > > occur when using prefixes. Since this is a restless architecture it might > be > > necessary to replicate at least the script which is calling the script > which > > is needed by both resources. This is pretty easy when having the scripts > > named the same way (no prefixes). Having a prefix would require renaming, > as > > well as renaming the parent node would require changing the prefix. (which > > would break the default refactoring features for renaming in Eclipse) > > > > Propably it is usefull to remember that a script is never identified > simply > > by its name but additionaly the path. So the name does never identify the > > script (which script is called?) but identfies under which circumstances > it > > is called(when is it called?). > > > > It may be usefull to have an optional prefix (nodename as prefix) to > > "freeze" a path and prevent usage at another location. (This feature would > > come along with the renaming problem but would at least not be the default > > behaviour and require the awareness of the developer of the constraint he > > produces). > i don't see you use case. usually the script is never referenced > directly but addressed via the sling resource type. if you change a > resource type, you would need to adjust the path (and of course the > script prefix) but not change it anywhere else. > i did quite some development with scripts by now for our cms-showcase, > and i think i only included a script directly in 1 or 2 special > locations. all other "includes" work via content include using the > resource type. > > another idea...how about adding an optional name between the type and > the extension? eg: > > /apps/myapp/foo/html.foo.jsp > > the resolution will only check for the "/apps/myapp/foo/html" part, > the extension (jsp) selects the script engine and the intermediate > "foo" is cosmetics for the editors. so when renaming a resource type, > you only need to change the path in the first place. the resolution > will still work. the intermediate name can be changed later. this also > would allow for nice names like "foo/html.FooMain.jsp" or something. > > WDYT? > > -- > toby > > > > > > > > Dominik > > > -- Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
Re: Post Servlet Response Codes
On Tue, Apr 29, 2008 at 3:47 PM, Alexander Saar <[EMAIL PROTECTED]> wrote: > This could look as follows: > > POST to /foo-> 200 OK and a XHTML representation > POST to /foo.html -> 200 OK and a XHTML representation > POST to /foo.xml-> correct response codes and a XML > representation > POST to /foo.json -> correct response codes and a JSON representation +1 ;) regards, david -- Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
Re: Post Servlet Response Codes
Hi Roy, Roy Fielding wrote: > IMO, avoiding a 201 response just because one browser doesn't support > it in a given context is wrong -- we should encourage the browser > to be fixed and use a version-specific work-around for existing users. > In most cases, browser-specific javascript or CSS is preferable to > making the server's response browser-specific. Absolutely. Actually I think there is no issue with a 201. Is someone aware of a browser issue with a 201? > I'd like to reduce the coupling between client and server assumptions. I think this would favor a solution where the current default response (a browser/javascript friendly 200 text/html) would be deprecated (as the default) in favor of a more standards compliant solution. If I read Alex's suggestion and the consensus correctly that's exactly the proposed direction. So we would keep the "browser friendly" response around as special case for people who need to be able to interact with the current real-life browser. > I watched Michael's excellent screencasts last week and noticed many > cases where example client code is being tied directly to the server > implementation. Things like "for" loops to iterate over sets of nodes > on the client side look cool from the programmer perspective, but are > really awful from the HTTP perspective. Resources in HTTP are like > stored procedures in databases -- they should only be treated like > storage units when the user is creating a mashup of someone else's > services. The server owner (or the owner's implementation framework) > should be defining special resources for list views like index or > iteration. I see... currently we supply such a default list (actually tree) view of a resources in .json as a default sample in Sling. As a matter of fact we already allow a variety of different views that can be consumed by various client frameworks. It definitely would be desirable to come up with a more URL oriented view aswell, similar to Atom or WebDAV. (which we btw. already support over the repository) > HTTP is designed to respond with a "list of node references" when a > GET is made on a "directory", where "directory" is defined by some > pattern known only by the server (usually URIs that end in "/" or > "/index"). I see... I think we have not even considered the handling of that in sling so i think a get to /folder/ is not used yet. > Likewise, a POST to that same directory URI should > create a new node "within" that directory space and, if successful, > return 201 and the new node's URI in the Location field. IIRC, > Sling is using a path segment of "*" for that purpose. It should > be configurable. Good point... Darn, I wish I thought of that earlier. Posting to /folder/ instead of /folder/* seems even more natural. > There can also be a special resources for "all content". > For example, it used to be common to have things like > > http://example.com/foo > http://example.com/foo/ > http://example.com/foo.tar > http://example.com/foo.tar.gz > > where the first would generate a "normal" representation (like > sending the jcr:content property) or redirect to the second, the > second would provide a "directory view" of the subnodes, the > latter two would generate an tar archive on the fly, and the > last would deflate as well. Some implementations prefer to put > all of the "content" views under the parent "directory", at least > partly because it makes access control easier, but I always > preferred to think of content-containment relations as a > virtual subdirectory. Hence, every file.xml also defines a > directory of "file.xml/*" nodes ... YMMV. I think one could view our current handling of .json extensions for something like ... http://example.com/foo.x.json ... as another example of that. > None of the above is particularly RESTful in any sense -- it > is just using HTTP's hierarchical namespace. To be RESTful, we > need to ignore the client-visible implementation patterns and > replace them with links (specific references within a context > that tells the client what to expect, such as mark-up element > attributes, links with rel types, or URI templates that can be > communicated to the client). That is what Atom does, for example. > It doesn't matter what URI structure is used to relate Atom > posts to Atom feeds, since all representations are interlinked > with relation types that define the content relationships > regardless of their containment hierarchy. I see. Would it be fair to say that the containment hierarchy should be viewed as a very typical relationship and therefore could deserve a short-hand treatment, while we still want to be able to cover the more general case of a relationship between arbitrary resources. > In other words, think of a repository as a tree of content with > a nearly infinite number of potential views over that content. > Sling should automatically provide a comprehensive subset
Re: Post Servlet Response Codes
> > I am fine with this, too. If there is no objection I will change that > > value to trigger the IE-friendly (which it is ;-) ) mode to "browser". > I don't see any reason to include it as a mode. As a workaround, sure, > but that should be very specific to the User-Agent field and not require > special programming by application devs. Actually, this is not about a specific browser, this is the only way how any browser can deal with a file multipart upload so a dhtml app can access its result. Since there is no client side trick (for security reasons) to do a file upload other than a straight form POST (no xhr or anything) and since there is no response code other than 200 and no other way than the DOM of a text/html document that allows you to transport the result of the POST (like let's say the "location" after the 201) to a client-side app this is not a browser specific workaround. I wish there was something else but browsers are very consistent here. Frankly, I am not even sure what browsers could do about that in the future. regards, david
Re: [Vote] Release Sling
hi carsten, the release built just fine for me. congrats. a couple of assertion seem to fail on the sling client side testing: .../sling-test/sling/sling-test.html i don't think it is something major but maybe we want to clean that up or remove from the release. regards, david On Thu, Jun 5, 2008 at 8:25 PM, Jean-Michel Pittet <[EMAIL PROTECTED]> wrote: > +1 (even though non binding ;) looking forward to the release! > > Cheers > JM > > On Thu, Jun 5, 2008 at 6:32 PM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: >> Hello everyone, >> >> let's give it a second try. I cut a new candidate as outlined today. >> >> I've put all release artifacts here: >> >> http://people.apache.org/~cziegeler/releases/sling/ >> >> The releases are in >> >> http://people.apache.org/~cziegeler/releases/sling/releases >> >> This is a big source tree of our release, so this is the important stuff. >> For convenience we have two additional binary releases here: the launchpad >> app and webapp. >> >> >> I've built the corresponding maven artifacts of all modules which can be >> found here: >> >> http://people.apache.org/~cziegeler/releases/sling/maven >> >> The KEYS file to check my signature is at >> http://people.apache.org/~cziegeler/releases/sling/ >> >> This is basically just one big release, so please cast your votes. >> >> Thanks >> Carsten >> -- >> Carsten Ziegeler >> [EMAIL PROTECTED] >> > > > > -- > -- > Day JCR Cup 08 - Win a MacBook Pro > see: http://dev.day.com/ > -< [EMAIL PROTECTED] >-- > Jean-Michel Pittet - Senior VP of Engineering > Day, +41 61 226 98 98, CH-4001 Basel > -- Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
Re: JCR browser
hi craig, i think this is a great start. congratulations. there are a couple of observations that i made which are likely to be unrelated to the use dojo so i thought i'd share them here. (1) deep links, bookmarks & backbutton since i am fan of deep links into content when i am sharing content locations i think it would be a great feature to expose the current navigation path in the url that's displayed in the browser. this can for example be done through a # in the url basically whenever i click on a folder in the tree. this should also fix back button and bookmarkability. (2) cookies it seems that all the opening states of the tree are stored in cookies... i would probably only store the last open position in the cookie since in my experience it is sometimes even more desirable to have sort of a "clean" start, with only my last position reopened ;) (3) safari works beautifully... ...but complains about a slow script 3 times before the browser starts up. i think this could be addressed by looking into what takes the load time. in firefox with firebug enabled for tracking the startup of roughly 43s which is probably most network latency related. (4) network roundtrips i think that once the browser is up and running the amount of network traffic that is transported is in very good shape. i stumbled over an incident that surprised me a little bit though. i expected a single .json to be transported to the client when i would open a new tree node clicking on the [+], which is true for most nodes, but not for nodes with deep children underneith... for example opening /images issued 9 http requests. i hope some of this may be helpful... regards, david On Thu, Jun 5, 2008 at 10:38 PM, Craig L. Ching <[EMAIL PROTECTED]> wrote: > Ugh and I did the one worst thing any web developer can do, I told you > all about it and didn't note that I've only tested with FF 2.0.0.14. > And I'm now discovering that I should have tested safari and IE because > it's not working ;-) Hopefully I'll have those browsers working real > soon. > >> -Original Message- >> From: Craig L. Ching [mailto:[EMAIL PROTECTED] >> Sent: Thursday, June 05, 2008 3:28 PM >> To: sling-dev@incubator.apache.org >> Subject: JCR browser >> >> Hi all, >> >> Well, I've not really had a lot of time to spend on this yet. >> That said, though, I want to show you what I *have* done. >> It's not much beyond Lars' original demos, but I do find it >> useful while developing sling apps to make sure things are >> created correctly and help debug problems. I have a demo >> running on one of my servers, >> http://samurai.webasap.net/jcr-explorer/data/demo/browser.html >> . I still haven't had time to get the path combo box >> working, so ignore that for now. And some of the editors on >> the grid aren't set up yet (e.g. 'true' >> and 'false' will be tick boxes when I get time to implement >> those). You probably won't like the styling if you're not a >> dojo fan, but, never fear, I have some ideas to make that a >> bit cleaner ;-) >> >> Anyway, let me know what you think. Any additions that would >> be necessary for a first release, read-only jcr browser would >> be appreciated. Hopefully seeing this will motivate someone >> to work with me to get my changes into SVN ;-) I can provide >> patches, however, I don't think I've done my best to design >> them into the sling code base properly, so I'm going to work >> on that next. >> >> Oh, one last thing, it says "JCR Explorer" everywhere, but >> I'm thinking of going with "JCR Browser" instead. Comments on a name? >> >> Cheers, >> Craig >> > -- Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
Re: sling/js-client module (was: How to override system/sling.js with my own variant?)
personally i would refrain from creating own variants of the sling.js i think one should extend it properly from another let's say mysling.js file. regards, david On Tue, Jun 24, 2008 at 10:59 AM, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > Hi, > > On Tue, Jun 24, 2008 at 8:14 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: >> ...I think, the sling.js file is misplaced in the post bundle and should >> probably be moved into its own bundle > > Agreed. > > I suggest creating a new clients/js-client module, a bundle which > serves sling.js directly, and also contains the test page for that, > that's currently at [1]. > > WDYT? > > -Bertrand > > [1] > http://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/content/src/main/resources/content/sling-test/sling/ > -- Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
Re: script include
On Mon, Jul 28, 2008 at 9:42 AM, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > On Fri, Jul 25, 2008 at 2:25 PM, Tobias Bocanegra > <[EMAIL PROTECTED]> wrote: >> ...i'm looking for a way to include a jsp script from within another but >> respecting the resource type hierarchy > > Just to make sure we're all on the same page: including the *source > code* of a JSP script within another while taking the current request > in consideration to select the included script is problematic, as JSP > scripts are compiled in advance, not during request execution. > > So if you do something like > > I guess what you want is the *output* of the script included in the > current request's output, right? fully agreed. > As opposed to including foo.jsp's code in the current script, which > would work in purely interpreted languages like javascript. > Then, using the resourceType hierarchy to find the script might be > what you're looking for. precisely... thanks for the summary. regards, david
Re: SlingPostServlet: How to handle resource paths when creating content (Re: [jira] Commented: (SLING-588) Sling ignores specified node path when creating content)
hi guys, i think it is dangerous if we have a different behavior on a POST (that originally should have been a PUT anyway, but due to browser limitations...) based on the existence of a node. I think that would violate the idempotent behavior that we had on the "PUT oriented" operations in the slingpostservlet. regards, david On Wed, Jul 30, 2008 at 1:46 PM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > On 7/30/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: >> Hi, >> >> all taking this to the list for discussion because Lars it making some >> important points. >> >> Lars Trieloff (JIRA) schrieb: >> >> > If you could decide for a way of fixing the NPE, I would be glad >> > >> > to have a working workaround. (and close this bug) However I still >> > think it is quite easy to find out which case the servlet is dealing >> > with. As the user is free to specify the action of the form, he can >> > post to /some/sample if he wants no dot and /some/sample.html if he >> > wants a dot. >> >> > >> > Speaking more broadly we are increasingly introducing "tricks", >> > >> > special cases and magic post parameters to deal with a very specific >> > use case "most of the times in a CMS or such" while ignoring the needs >> > of other use cases like DAM, Blog, Wiki, social networking, forum, >> > online shop, podcast, file sharing and other content-centric web >> > applications. Having a RESTful web application framework implies in >> > my opinion to respect concepts like Resource, Representation, URI >> > and to avoid RPC-like interaction if not necessary. >> >> I agree and thinking about it the SlingPostServlet is more about modifying >> (create, update, delete) content and less about content representation. As >> such the URL fired at the SlingPostServlet should probably be more treated >> as the actual path than it is today. >> >> The actual code, which does this is buried in the >> ModifyOperation.getItemPath method, which tries to locate the item to work >> on from the resource. For an existing resource, there is nothing much to be >> done, as we have the item through the resource. >> >> For a non-existing resource, the resource path, contains the full path from >> the URL (actually it is ServletRequest.getPathInfo()) including anything >> which might be interpreted as selectors and extensions and even suffix. The >> idea of this was, that the SlingPostServlet might redirect to this URL after >> the update. >> >> Now, in the meantime we have applied various changes to the >> SlingPostServlet, which influence the creation of the name of a node to >> create: >> >> * :name and :nameHint to handle how names are generated >> in the case of Slash-Star request (trailing / or /*) >> * :redirect to indicate whether to redirect to the modified >> or created node after the request. >> >> Taking all this into account, I come to agree with Lars, that the >> SlingPostSerlvet should treat the resource path of a non-existing resource >> (to be created) as is without modification. > i don't think that this is a good idea. otherwise you would need to > know on the client if a resource already exists or not. ii find it > very dangerous if the resolution is not symmetric. > > IMO, with the extension, you choose the type of response you want. eg, > with .json you get a json response, with .html you get a html > response. etc... > >> We still have to deal with the / and /* suffixes, but we do not cut off any >> extensions any more from the path. >> >> In the case of a redirect, the :redirect parameter could just be set with >> *.selectors.ext to redirect to the newly create resource with selectors and >> extensions, where the SlingPostServlet replaces "*" with the actual location >> URL of it. > > regards, toby > -- Visit: http://dev.day.com/ - Day JCR Cup 08 - Win a MacBook Pro
Re: sling examples: sling-generated path
> Out of curiosity: why not just POST to the location? That seems to be more > in sync with how POST is defined in HTTP... for known resources this is the case... and everybody is welcome to do that. in some cases, sling should be put in charge to create something "new and unique" without the developer having to choose... let's say adding new comments to a blog post for example. anyway, in hind-sight the /xyz/* for the POST is probably not ideal and in my mind should be deprecated in favour of /xyz/ with a trailing slash. regards, david
Re: sling examples: sling-generated path
>> for known resources this is the case... and everybody is welcome to do >> that. > Sure; in *that* case of course PUT is right... ...and of course that works aswell ;) except for that it is a pain to impossible to get a browser to do that. think of file uploads for example... also there is a quite a bit of infrastructure around that strips custom headers and disallows methods beyond GET and POST. ...but i am sure that we are all aware of that ;) >> Being able to use PUT would be the answer, but browsers don't do that. > Browsers do with XHR; is this required to work with forms? (as you can guess > from that question, I'm a total newbie wrt Sling). well, as long as you are not dealing with binaries ;) also the semantics of PUT do not reflect the PATCH style updates. >> anyway, in hind-sight the /xyz/* for the POST is probably not ideal >> and in my mind should >> be deprecated in favour of /xyz/ with a trailing slash. > Yep. That would align it with how adding to collections works in AtomPub. cool. regards, david
Re: Replacing JcrResourceResolverFactory by a Sling ResourceResolverFactory
hi guys, i don't have an opinion on the organization of code, so cleaning things up is always good. what i would strongly caution though is fostering the divergence between the resource tree and the node tree. since there are good tools to browse, search and manage the node tree this is really one of the main advantages that sling brings to the table opposed to many of the other web frameworks. the url mapping to content nodes is simple and straight forward similar to the fs mapping in a static webserver. this transparency is taken away when we have a resource tree that diverges from the node tree. or in a simple example: to find out what happens when a request goes to /bin/... is almost impossible and going through all the configurations of all the bundles and the respective sling.servlet.paths to find out what's going on in the system is definitely not efficient. starting to expose services like access control on the resource tree is something that i find dangerous and problematic. access control should really be enforced at the data (jcr) layer and slowly copying the entire jcr api into a proprietary resource api with the same feature set seriously is the wrong path. i would really like to get rid of the duality of these two api's that essentially will do the same same thing in the long run. just my two cents, regards, david On Sun, Nov 9, 2008 at 7:28 PM, Juanjo Vázquez <[EMAIL PROTECTED]> wrote: >> The proposal also allows for much more >> flexibility in building the Resource tree made of ResourceProviders >> where each ResourceProvider itself may actually be provided by a >> ResourceProviderFactory. > > > Felix, this implementation would allow to have an only one security > management for the whole virtual resources tree, really?. I understand this > is not possible until now. > > BR, > > Juanjo. > -- Visit: http://dev.day.com/
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
hi roy,
thanks for the thoughtful comment.
as a matter of fact felix and i actually discussed something along those
lines as a "cache"but i really like the idea to have all the root mapping stored
somewhere centrally. we thought of putting it into /var, but i agree that
/etc/map may just be a good solution for that. instead of looking at this as the
cache, i think it is much smarter to look at this as the real source of the
mapping information. this we will also get a simple overview over all the
mappings that are in effect.
to make it more convenient for distributed user base to put those aliases
in place we can still have the users "suggesting" them on "their" content
items and have a service or a review process translate them into the
/etc/map once they are approved.
sounds very good to me.
regards,
david
On Sat, Nov 22, 2008 at 1:11 AM, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> Sounds like an easy way to bypass delegated security.
>
> I don't like the idea of sprinkling root-level aliases
> all over the content tree. I think it would be incredibly
> complex and impossible to maintain over time, and not even
> remotely scalable for virtual hosting setups.
>
> I think that Sling should use a content tree to establish the
> root mappings; e.g.,
>
> /etc/map/{scheme}/{host.port}/{uri_path}
>
> with the default contents being
>
> /etc/map/http/example.com.80/
> +-- sling:redirect = "http://www.example.com/";
>www.example.com.80/
> +-- sling:alias = "/example/"
>*.example.com.80/
> +-- sling:redirect = "http://www.example.com/";
>localhost.*/
> +-- sling:alias = "/content/"
>localhost.*/cgi-bin/
> +-- sling:alias = "/scripts/"
>localhost.*/gateway/
> +-- sling:alias = "http://gbiv.com/";
>
> The resolver would check the path for a match by walking
> down the /etc/map tree. If there is a name match, then continue
> following that path. Otherwise, if there is a "*" match, then
> follow that path. If neither, then the mapping is defined by the
> properties on the last matching node.
>
> sling:alias is a path mapping (what we call an internal redirect
> in httpd because it isn't visible to the client). Note that this
> can be very flexible: The last example configures a reverse proxy of
>
> http://localhost/gateway/ <==> http://gbiv.com/
>
> The advantage here is that the mappings are easily cached without
> new code, easily visible to users by looking at the tree, and
> versioned just like any other content. If you want to make the
> matching even faster, then this /etc/map tree can be walked as a
> regular expression and compiled each time the map tree changes,
> which is much easier than walking the entire content tree.
>
> In my opinion, path mappings in the rest of the content tree
> should be limited to same-level aliases and external redirects.
>
> Roy
>
--
Visit: http://dev.day.com/
Re: sling for apachecon site
hi aaron, that's great. thanks for considering sling. personally, i would be very interested to see what we as the sling community could do to absorb the requirements of the apache webproperties... i am trying to make it out to apache con europe, but i am not sure that i definitely will make it. i would be more than happy to talk about how sling can be an extremely valuable platform for a web cms set of requirements. regards, david 2009/3/12 J Aaron Farr : > > One more random thought: > > The ApacheCon website is current written in Ruby on Rails. Well, > actually it uses extensions to Radiant, an RoR CMS. I through it > together last summer when I became fed-up maintaining the previous pile > of code that I had been handed. > > However, the current site has plenty of bugs and needs refactoring and > fixing. I like Rails but there aren't a lot of Radiant/Rails people > here at the ASF, so I've often been tempted to port the code to one of > the ASF frameworks. > > Lately I've been particularly tempted to moving it to either CouchDB > (with maybe some Rails on the front end) or Sling. But honestly, I > don't know where to start with Sling. > > Anyway, I'll be at ApacheCon Europe is anyone wants to find me and chat > about this idea. I'm not promising I'll do the site in Sling, but I'd > like to at least get an idea of how that would be done. > > -- > J Aaron Farr jadetower.com[US] +1 724-964-4515 >馮傑仁 cubiclemuses.com [HK] +852 8123-7905 > -- Visit: http://dev.day.com/
Re: [POLL] getting rid of scripting (almost)
Excellent proposal! Very timely! +1. Scripting is evil. regards, david On Wed, Apr 1, 2009 at 11:11 AM, Torgeir Veimo wrote: > Well I think sling should be changed to work with flat file systems instead > of JCR. Putting data into a typed node tree puts too many constraints on > what data we can put into it. > > 2009/4/1 Felix Meschberger > >> Hi, >> >> Vidar Ramdal schrieb: >> > On Wed, Apr 1, 2009 at 10:49 AM, Michael Dürig >> wrote: >> > >> >> +1 if we make Whitespace [1] the primary language for Sling. >> >> >> >> [1] http://compsoc.dur.ac.uk/whitespace/ >> > >> > +1 >> > >> > I took a look at Whitespace, and liked it so much that I decided to >> > port the entire Sling codebase to it. >> > >> > I'm sure you will agree, so as soon as I get my svn account, I'll >> > start replacing the ugly, old-fashioned Java classes with clean, white >> > Whitespace files. >> >> If you like clean languages you should consider my new Null proposal [1] >> currently being discussed. It is based on the Null programming language. >> >> Regards >> Felix >> >> [1] http://wiki.apache.org/incubator/NullProposal >> >> > -- Visit: http://dev.day.com/
JSR-283 Proposed Final Draft posted, waiting for download fix.
Dear Jackrabbit-Devs & Sling-Devs, as you may have seen JSR-283 has been posted for proposed final draft. http://jcp.org/aboutJava/communityprocess/pfd/jsr283/index.html Unfortunately, there seems to be an error in the posting since the download link on the page results in a "Not Found Error". I alerted the PMO of the JCP at Sun this morning CET. The PMO (Project Management Office) is administrating all JSRs and is responsible for posting the proposed final draft. I will keep you posted on the progress. regards, david
Re: JSR-283 Proposed Final Draft posted, waiting for download fix.
Good news ;) I am happy announce on behalf of the JSR-283 Expert Group that JSR-283 is out for Proposed Final Draft review. http://jcp.org/aboutJava/communityprocess/pfd/jsr283/index.html There are a lot new and exciting features in the specification and changed the structure of the specification to make a big section Java Language since a lot of you ported JCR outside of the Java Language. For a little more information, visit: http://dev.day.com/microsling/content/blogs/main/jsr283proposedfinaldraft.html Feedback is very welcome jsr-283-comme...@jcp.org regards, david On Wed, Apr 1, 2009 at 8:44 PM, David Nuescheler wrote: > Dear Jackrabbit-Devs & Sling-Devs, > > as you may have seen JSR-283 has been posted for proposed final draft. > http://jcp.org/aboutJava/communityprocess/pfd/jsr283/index.html > > Unfortunately, there seems to be an error in the posting since the > download link on the page results in a "Not Found Error". > I alerted the PMO of the JCP at Sun this morning CET. > The PMO (Project Management Office) is administrating all JSRs and is > responsible for posting the proposed final draft. > > I will keep you posted on the progress. > > regards, > david > -- Visit: http://dev.day.com/
Re: JCR2 upgrade plans ?
hi guys, > I think that Sling should be able to run on JCR 1.0 for a long time; we > shouldn't tie us to a new version; however, of course we might have some > optional functionality requiring JCR 2.0. i think we should naturally embrace jcr 2.0, i don't really think that we will have backwards compatibility issues since i would not expect that there are other repositories than jackrabbit that are currently used with sling. so in my opinion we should probably use jcr 2.0 where it makes sense particularly over proprietary jackrabbit apis as soon as they are available in jackrabbit... thoughts? regards, david
Re: [VOTE] Graduate Apache Sling as a top level project
+1 (non-binding) regards, david On Mon, May 18, 2009 at 5:10 PM, Alexander Klimetschek wrote: > On Mon, May 18, 2009 at 9:12 AM, Felix Meschberger wrote: >> [X] +1 Graduate as a top level project >> [ ] 0 Don't care >> [ ] -1 Don't graduate yet, because > > +1 graduate: more Sling fun for everyone! > > (non-binding, though ;-)) > > Regards, > Alex > > -- > Alexander Klimetschek > alexander.klimetsc...@day.com
Re: (In)Security in Sling
hi guys, i really think this should be dealt with, using proper repository access control. as soon as we start to let the application deal with security we need to worry about it every specific application, and become prone to "xyz-injection" similar to the problem that db's have with "sql injection". it becomes particularly tricky if you try to filter things out of the query results and the likes... my personal guidance would be to make the access control "tighter" in the sense that one would forbid read privileges to "/apps" and "/homes" for the anonymous user (in case that is not desired) and have the script execution use a session with appropriate privileges to read and execute. regards, david On Tue, Jun 2, 2009 at 12:50 PM, Ian Boston wrote: > Felix, > +1 > In addition, I would like to see a marker on the parent nodes that > designates the subtree as containing executable content. > > Then the special session can be used to execute the scripts, but only after > it had checked to see the script is located in an "executable" subtree. > A suitably authorized user could read and write, > > Perhaps this already exists ? > Ian > On 2 Jun 2009, at 11:33, Felix Meschberger wrote: > >> Hi, >> >> John Crawford schrieb: >>> >>> I have been working with sling for quite some time and, of course, Day >>> products. One thing that I have been increasingly concerned with is the >>> end >>> users ability to scrape all of the sites content and code with minimal >>> effort using the built in functionality of the SlingPostServlet. >> >> The Sling Get Servlet to be precise ;-) >> >>> >>> For Example: >>> >>> http://dev.day.com/discussion-groups/users.infinity.json >>> http://dev.day.com/discussion-groups/apps.infinity.json >> >> As Jukka said, you may employ access control to prevent this. >> >> But there is a glitch for the scripts located in /apps and /libs: >> Currently scripts are read from the repository using the session of the >> current user, that is the request user. >> >> So preventing access to >> >>> http://dev.day.com/discussion-groups/apps/mailingLists/mailingLists.jsp >> >> by simply denying read-access for the anonymous user actually prevents >> using the site at all. >> >> One solution to this problem could be to not load the scripts with the >> session of the current user but to use a special-purpose session (for >> example an admin session) to do this. >> >> This way, you may lock down /apps and /libs for general consumption but >> may still execute the scripts in there. >> >> WDYT ? >> >> Regards >> Felix >> >> >> (this >>> >>> one really disturbs me) >>> >>> So far, my solution has been to provide a proxy (namely Apache2) in front >>> of >>> sling to filter out any undesired requests. Seems to work. But, by >>> doing >>> this, it takes way what is so cool about Sling. I have reported to Day >>> Support numerous times, but they don't seem too concerned about it. But >>> for >>> sites where the content is critical or where we require users to pay for >>> our >>> content, it is very important to us. >>> >>> Is there a better way to handle this? >>> >>> Please let me know your thoughts. >>> >>> Respectfully, >>> John >>> > > -- David Nuescheler Chief Technology Officer mailto: david.nuesche...@day.com web: http://www.day.com/ http://dev.day.com twitter: @daysoftware
Re: (In)Security in Sling
hi ian, sorry for the confusion. there are is no privilege to "execute" something in jcr. i am not even sure that they should be part of the repository since the repository is not going to execute things anyway. i think if one has a tight coupling like between the os and the fs this may make sense, but i see the repo/sling coupling much looser so i would probably just go for the read privilege. the read privilege seems to be cause issue as far as i can tell not necessarily the execute privilege. right? regards, david On Tue, Jun 2, 2009 at 2:00 PM, Ian Boston wrote: > So that marker should be and ACL containing an ACE with execute privilege > granted to the appropriate session. > I wasn't aware that there was such a privilege in the Jackrabbit > DefaultAccessManager or 283, > but I agree thats were it should be. > > On a practical note, > Unless DefaultAccessManager et al is going to be re-implemented for Sling, > then this should go back to Jackrabbit as DAM is heavily protected for > obvious reasons, and when I looked trying to extend the way in which > principals for a session were resolved, there didn't appear to be many (if > any) extension points available in DAM since registration of bits in the > compiled privileges bitmap > (o.a.j.core.security.authorization.PrivilegeRegistry.registerPrivilege) is > private (very) > > Ian > > On 2 Jun 2009, at 11:59, David Nuescheler wrote: > >> hi guys, >> >> i really think this should be dealt with, using proper repository >> access control. >> as soon as we start to let the application deal with security we need to >> worry about it every specific application, and become prone to >> "xyz-injection" >> similar to the problem that db's have with "sql injection". >> it becomes particularly tricky if you try to filter things out of the >> query results >> and the likes... >> >> my personal guidance would be to make the access control "tighter" in the >> sense that one would forbid read privileges to "/apps" and "/homes" for >> the >> anonymous user (in case that is not desired) and have the script execution >> use a session with appropriate privileges to read and execute. >> >> regards, >> david >> >> On Tue, Jun 2, 2009 at 12:50 PM, Ian Boston wrote: >>> >>> Felix, >>> +1 >>> In addition, I would like to see a marker on the parent nodes that >>> designates the subtree as containing executable content. >>> >>> Then the special session can be used to execute the scripts, but only >>> after >>> it had checked to see the script is located in an "executable" subtree. >>> A suitably authorized user could read and write, >>> >>> Perhaps this already exists ? >>> Ian >>> On 2 Jun 2009, at 11:33, Felix Meschberger wrote: >>> >>>> Hi, >>>> >>>> John Crawford schrieb: >>>>> >>>>> I have been working with sling for quite some time and, of course, Day >>>>> products. One thing that I have been increasingly concerned with is >>>>> the >>>>> end >>>>> users ability to scrape all of the sites content and code with minimal >>>>> effort using the built in functionality of the SlingPostServlet. >>>> >>>> The Sling Get Servlet to be precise ;-) >>>> >>>>> >>>>> For Example: >>>>> >>>>> http://dev.day.com/discussion-groups/users.infinity.json >>>>> http://dev.day.com/discussion-groups/apps.infinity.json >>>> >>>> As Jukka said, you may employ access control to prevent this. >>>> >>>> But there is a glitch for the scripts located in /apps and /libs: >>>> Currently scripts are read from the repository using the session of the >>>> current user, that is the request user. >>>> >>>> So preventing access to >>>> >>>>> http://dev.day.com/discussion-groups/apps/mailingLists/mailingLists.jsp >>>> >>>> by simply denying read-access for the anonymous user actually prevents >>>> using the site at all. >>>> >>>> One solution to this problem could be to not load the scripts with the >>>> session of the current user but to use a special-purpose session (for >>>> example an admin session) to do this. >>>> >>>> This way, you may lock down /apps and /libs for general consumption but >>>> may still e
[jira] Created: (SLING-45) Sling leaks PermSpace memory on restart of the webapp
Sling leaks PermSpace memory on restart of the webapp - Key: SLING-45 URL: https://issues.apache.org/jira/browse/SLING-45 Project: Sling Issue Type: Improvement Reporter: David Nuescheler Priority: Minor After restarting the Sling webapp a number of times in a Servlet Container I ran out of PermSpace. It seems like some classes or other objects are not entirely removed upon restart of the webapp. Unfortunately I don't have any detailed memory profiler dump, but I think it should be reasonably evident once someone attaches a memory profiler and restarts the webapp. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-154) Allow access to Node and Property Methods on ScriptableNode and ScriptableProperty
Allow access to Node and Property Methods on ScriptableNode and ScriptableProperty -- Key: SLING-154 URL: https://issues.apache.org/jira/browse/SLING-154 Project: Sling Issue Type: Improvement Components: Scripting Reporter: David Nuescheler Priority: Minor I would like to propose access to all jcr Node methods from ScriptableNode and access to the jcr Property. I recently wanted to access the Property.getLength() method from a .esp script and didn't find a good way starting out from my very convenient ScriptableNode. This discussion already talks about a similar issue: http://www.mail-archive.com/sling-dev@incubator.apache.org/msg01481.html So ideally somthing like an automatic getter mapping that I know from earlier rhino projects would mean that I could access the same information through for example prop.length or prop.getLength(). I think it would be great if all jcr Property and Node methods would be exposed, otherwise we are hiding jcr features from the script user. I think maybe the solution also requires a ScriptableProperty. WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-157) output of primitives using <%= %> in .esp does not work
output of primitives using <%= %> in .esp does not work --- Key: SLING-157 URL: https://issues.apache.org/jira/browse/SLING-157 Project: Sling Issue Type: Bug Components: Scripting Reporter: David Nuescheler Priority: Minor while trying to output a non string value using the <%= %> syntax I stumbled over an issue that somehow prevented the output without an error. so: <%= 1 %> does not produce output, while <%= "1" %> works fine. a workaround for the application developer of course would be to convert the output to a string first, but i think it would be great to fix that, since people output counters and other non string variables frequently. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-182) ujax: introduce default filtering of system properties on the server side
ujax: introduce default filtering of system properties on the server side - Key: SLING-182 URL: https://issues.apache.org/jira/browse/SLING-182 Project: Sling Issue Type: Bug Components: Scripting Reporter: David Nuescheler Priority: Minor currently the default .json serialization does not skip the "jcr:properties" on the server side but this filtering happens on the client in the ujax.getContent() method. I think we should integrate this filtering on the server side and also allow for other behaviours like "include all system properties" and additional meta information like "length of binary properties". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-154) Allow access to Node and Property Methods on ScriptableNode and ScriptableProperty
[ https://issues.apache.org/jira/browse/SLING-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569217#action_12569217 ] David Nuescheler commented on SLING-154: I was recently looking for the "addNode()" method and couldn't find it in the code. Am I looking in the wrong place? If not I would really like to recommend to map all Node methods. > Allow access to Node and Property Methods on ScriptableNode and > ScriptableProperty > -- > > Key: SLING-154 > URL: https://issues.apache.org/jira/browse/SLING-154 > Project: Sling > Issue Type: Improvement > Components: Scripting >Reporter: David Nuescheler >Assignee: Felix Meschberger >Priority: Minor > Fix For: 2.0.0 > > Attachments: SLING-154.partial.patch, SLING-154_2.patch > > > I would like to propose access to all jcr Node methods from ScriptableNode > and access to the jcr Property. > I recently wanted to access the Property.getLength() method from a .esp > script and didn't find a good way starting > out from my very convenient ScriptableNode. > This discussion already talks about a similar issue: > http://www.mail-archive.com/sling-dev@incubator.apache.org/msg01481.html > So ideally somthing like an automatic getter mapping that I know from earlier > rhino projects would mean > that I could access the same information through for example prop.length or > prop.getLength(). > I think it would be great if all jcr Property and Node methods would be > exposed, otherwise we are hiding jcr features from > the script user. I think maybe the solution also requires a > ScriptableProperty. > WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SLING-154) Allow access to Node and Property Methods on ScriptableNode and ScriptableProperty
[ https://issues.apache.org/jira/browse/SLING-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Nuescheler reopened SLING-154: add all methods of the Node interface to ScriptableNode > Allow access to Node and Property Methods on ScriptableNode and > ScriptableProperty > -- > > Key: SLING-154 > URL: https://issues.apache.org/jira/browse/SLING-154 > Project: Sling > Issue Type: Improvement > Components: Scripting >Reporter: David Nuescheler >Assignee: Felix Meschberger >Priority: Minor > Fix For: 2.0.0 > > Attachments: SLING-154.partial.patch, SLING-154_2.patch > > > I would like to propose access to all jcr Node methods from ScriptableNode > and access to the jcr Property. > I recently wanted to access the Property.getLength() method from a .esp > script and didn't find a good way starting > out from my very convenient ScriptableNode. > This discussion already talks about a similar issue: > http://www.mail-archive.com/sling-dev@incubator.apache.org/msg01481.html > So ideally somthing like an automatic getter mapping that I know from earlier > rhino projects would mean > that I could access the same information through for example prop.length or > prop.getLength(). > I think it would be great if all jcr Property and Node methods would be > exposed, otherwise we are hiding jcr features from > the script user. I think maybe the solution also requires a > ScriptableProperty. > WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-81) Add write-support to Javascript API for JCR
[
https://issues.apache.org/jira/browse/SLING-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569868#action_12569868
]
David Nuescheler commented on SLING-81:
---
sounds great.
i think it would be cool if that same mechanism works in ujax (or i should say:
"could work in ujax") which seems to be the case...
> Add write-support to Javascript API for JCR
> ---
>
> Key: SLING-81
> URL: https://issues.apache.org/jira/browse/SLING-81
> Project: Sling
> Issue Type: Sub-task
> Components: microsling
>Reporter: Lars Trieloff
>
> The current Javascript API is good at reading data from the repository, but
> has not yet a working implementation of assignments like
> node.mimetype = "text/plain" a.k.a node["mimetype"] = "text/plain"
> node["members"] = ["bertrand", "lars"];
> node["childnode"] = {"mimetype": "text/plain", "text": "bla bla bla"}
> The first example should call node.setProperty("mimetype", "text/plain");
> The second example should call node.setProperty("members", new String[]
> {"bertrand", "lars"});
> The third example should either set the properties of the child node
> "childnode" or of the node referenced in a property called "childnode".
> This should also allow for nesting of properties,
> node["childnode"] = {"mimetype": "text/plain", "text": "bla bla bla",
> "childnode: {"mimetype" : "text/plain" }}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-295) Specify nodetype for node creation
[ https://issues.apache.org/jira/browse/SLING-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573880#action_12573880 ] David Nuescheler commented on SLING-295: I would go with the jcr:primaryType aswell instead of a magic ujax:primaryType. So far we used ujax: for things that don't have representation in content. I think everything that has trivial representation in content should map the name of the property directly to the form input name just make it simple to understand. I think it is intuitive for the user to use jcr:primaryType and other jcr: properties. In my mind jcr:mixinTypes for example should be treated like a normal multivalue property, please don't introduce a special comma separated case for that. > Specify nodetype for node creation > -- > > Key: SLING-295 > URL: https://issues.apache.org/jira/browse/SLING-295 > Project: Sling > Issue Type: Improvement >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Attachments: patch.txt > > Original Estimate: 0h > Remaining Estimate: 0h > > It would be nice to specify the node type for new nodes when they are created > through the post servlet. > Perhaps by specifying a node type parameter (like ujax:nodetype)? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-367) change sling:post: to sling: for "command" prefixes in form names
change sling:post: to sling: for "command" prefixes in form names - Key: SLING-367 URL: https://issues.apache.org/jira/browse/SLING-367 Project: Sling Issue Type: Bug Components: ujax Reporter: David Nuescheler I think it is fair to also prefix the form elements that express certain "commands" with "sling:" since they are sling related. i see it more as a side effect that the "sling:resourceType" also gets persisted. generally, i think everything that has something to with "sling" should be prefixed with "sling". I think we need to make sure that we don't complicate the most simple cases just to a avoid possible collisions -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-367) change sling:post: to sling: for "command" prefixes in form names
[ https://issues.apache.org/jira/browse/SLING-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592373#action_12592373 ] David Nuescheler commented on SLING-367: i think the behavior is consistent if all the form-names that bear any relevance are prefixed with "sling:". the fact that some of these sling commands also persist as a property is a side effect at best i think. i think it is very confusing to have to learn all these different conventions just because some of the sling related commands are also persisted as content. Especially since it complicates the "simple" most common case of the usage and there definitely is no need for a new "namespace" since users will not make up arbitrary sling properties, this will always be avery defined set. > change sling:post: to sling: for "command" prefixes in form names > - > > Key: SLING-367 > URL: https://issues.apache.org/jira/browse/SLING-367 > Project: Sling > Issue Type: Bug > Components: Post Servlets >Reporter: David Nuescheler > > I think it is fair to also prefix the form elements that express certain > "commands" > with "sling:" since they are sling related. > i see it more as a side effect that the "sling:resourceType" also gets > persisted. > generally, i think everything that has something to with "sling" should be > prefixed > with "sling". > I think we need to make sure that we don't complicate the most simple cases > just > to a avoid possible collisions -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
