Need to have the ability to add primary content type to PUT in UjaxPostServlet
I updated class to handle sling:primaryType request parameter. Need to get into main branch. addNode(node, type); Eric
[jira] Commented: (SLING-220) NPE when requesting content with selector
[ https://issues.apache.org/jira/browse/SLING-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565587#action_12565587 ] Tobias Bocanegra commented on SLING-220: here the complete stacktrace: java.lang.NullPointerException at org.apache.sling.jcr.resource.internal.JcrResourceResolver.getResourceInternal(JcrResourceResolver.java:360) at org.apache.sling.jcr.resource.internal.JcrResourceResolver.getResource(JcrResourceResolver.java:137) at org.apache.sling.servlet.resolver.SlingServletResolver.getServletAt(SlingServletResolver.java:322) at org.apache.sling.servlet.resolver.SlingServletResolver.resolveServlet(SlingServletResolver.java:145) at org.apache.sling.core.impl.request.RequestData.init(RequestData.java:156) at org.apache.sling.core.impl.SlingMainServlet.service(SlingMainServlet.java:259) at org.apache.sling.core.impl.SlingMainServlet.service(SlingMainServlet.java:172) at org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:109) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:75) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.sling.launcher.webapp.SlingServlet.service(SlingServlet.java:195) at com.day.j2ee.servletengine.ServletRuntimeEnvironment.service(ServletRuntimeEnvironment.java:228) at com.day.j2ee.servletengine.RequestDispatcherImpl.doFilter(RequestDispatcherImpl.java:293) at com.day.j2ee.servletengine.RequestDispatcherImpl.service(RequestDispatcherImpl.java:312) at com.day.j2ee.servletengine.RequestDispatcherImpl.service(RequestDispatcherImpl.java:354) at com.day.j2ee.servletengine.ServletRequestHandler.execute(ServletRequestHandler.java:313) at com.day.j2ee.servletengine.DefaultThreadPool$DequeueThread.run(DefaultThreadPool.java:134) at java.lang.Thread.run(Thread.java:613) > NPE when requesting content with selector > - > > Key: SLING-220 > URL: https://issues.apache.org/jira/browse/SLING-220 > Project: Sling > Issue Type: Bug > Components: Resource >Reporter: Tobias Bocanegra > > request to: http://localhost:5002//content/test/contacts.navimage.jpg > java.lang.NullPointerException >at > org.apache.sling.jcr.resource.internal.JcrResourceResolver.getResourceInternal(JcrResourceResolver.java:360) >at > org.apache.sling.jcr.resource.internal.JcrResourceResolver.getResource(JcrResourceResolver.java:137) >at > org.apache.sling.servlet.resolver.SlingServletResolver.getServletAt(SlingServletResolver.java:322) >at > org.apache.sling.servlet.resolver.SlingServletResolver.resolveServlet(SlingServletResolver.java:145) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-220) NPE when requesting content with selector
NPE when requesting content with selector - Key: SLING-220 URL: https://issues.apache.org/jira/browse/SLING-220 Project: Sling Issue Type: Bug Components: Resource Reporter: Tobias Bocanegra request to: http://localhost:5002//content/test/contacts.navimage.jpg java.lang.NullPointerException at org.apache.sling.jcr.resource.internal.JcrResourceResolver.getResourceInternal(JcrResourceResolver.java:360) at org.apache.sling.jcr.resource.internal.JcrResourceResolver.getResource(JcrResourceResolver.java:137) at org.apache.sling.servlet.resolver.SlingServletResolver.getServletAt(SlingServletResolver.java:322) at org.apache.sling.servlet.resolver.SlingServletResolver.resolveServlet(SlingServletResolver.java:145) ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Open Wiki
Hi Bertrand, I just asked for it to be created, have been distracted until now. Regards Felix Am Samstag, den 02.02.2008, 09:50 +0100 schrieb Bertrand Delacretaz: > On Jan 23, 2008 9:21 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > > ...I'd call it SLINGPUBLIC to make it clearer what it's about... > > Felix, did you request creation this new SLINGPUBLIC wiki space already? > I think we have agree on having it. > > -Bertrand
[jira] Resolved: (SLING-218) TagHandlerPool reuses tags, so need to initialize attributes in sling IncludeTagHandler
[ https://issues.apache.org/jira/browse/SLING-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-218. - Resolution: Fixed Fix Version/s: 2.0.0 Assignee: Felix Meschberger Applied patch in Rev. 618424. Please close if this works for you. Thanks. > TagHandlerPool reuses tags, so need to initialize attributes in sling > IncludeTagHandler > --- > > Key: SLING-218 > URL: https://issues.apache.org/jira/browse/SLING-218 > Project: Sling > Issue Type: Bug >Reporter: Tobias Bocanegra >Assignee: Felix Meschberger > Fix For: 2.0.0 > > Attachments: includetaghandler.r617505.patch > > > the TagHandlerPool reuses tag handlers. but the sling include tag handler is > not aware of that. the problem is that the > setters of the attributes are not called if not indicated in the jsp tag. eg: > >
Re: [jira] Commented: (SLING-194) use default format for JSON resource loader
Hi all, I would like to put on discussion, whether we drop the former very simple format of JSON in favor of the format generated by the JsonWriter. This would allow for simple round-tripping and would also not generate to many different and incompatible formats. The result of this would be to replace JsonReader by the current XJsonReader and the requirement to modify any existing .json files used for initial content loading. And of course the temporary .xjson extension would not be supported any more. WDYT ? Regards Felix Am Montag, den 04.02.2008, 12:17 -0800 schrieb Felix Meschberger (JIRA): > [ > https://issues.apache.org/jira/browse/SLING-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565502#action_12565502 > ] > > Felix Meschberger commented on SLING-194: > - > > Applied modified patch in Rev 618414. > > The patch is modified such, that XJsonReader extends JsonReader and > overwrites createNode and createResource methods. > > I think, we may well drop the old JSON format support implemented by > JsonReader in favor of the "standard" JsonWriter format. > > > use default format for JSON resource loader > > > > > > Key: SLING-194 > > URL: https://issues.apache.org/jira/browse/SLING-194 > > Project: Sling > > Issue Type: Improvement > > Components: Repository > >Reporter: Tobias Bocanegra > >Assignee: Felix Meschberger > > Attachments: loader-xjson.r616687.patch > > > > > > the current org.apache.sling.jcr.resource.internal.loader.JsonReader has a > > pretty simple format for loading content from the bundles into the > > repository. the pain is that if you already have repository content, you > > can't create just a JSON dump and put it in the resource. > > suggest to change the JsonReader to accept a JSON dump as provided by a > > JSON content export by the default servlet. >
[jira] Commented: (SLING-194) use default format for JSON resource loader
[ https://issues.apache.org/jira/browse/SLING-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565502#action_12565502 ] Felix Meschberger commented on SLING-194: - Applied modified patch in Rev 618414. The patch is modified such, that XJsonReader extends JsonReader and overwrites createNode and createResource methods. I think, we may well drop the old JSON format support implemented by JsonReader in favor of the "standard" JsonWriter format. > use default format for JSON resource loader > > > Key: SLING-194 > URL: https://issues.apache.org/jira/browse/SLING-194 > Project: Sling > Issue Type: Improvement > Components: Repository >Reporter: Tobias Bocanegra >Assignee: Felix Meschberger > Attachments: loader-xjson.r616687.patch > > > the current org.apache.sling.jcr.resource.internal.loader.JsonReader has a > pretty simple format for loading content from the bundles into the > repository. the pain is that if you already have repository content, you > can't create just a JSON dump and put it in the resource. > suggest to change the JsonReader to accept a JSON dump as provided by a JSON > content export by the default servlet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-194) use default format for JSON resource loader
[ https://issues.apache.org/jira/browse/SLING-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-194: --- Assignee: Felix Meschberger > use default format for JSON resource loader > > > Key: SLING-194 > URL: https://issues.apache.org/jira/browse/SLING-194 > Project: Sling > Issue Type: Improvement > Components: Repository >Reporter: Tobias Bocanegra >Assignee: Felix Meschberger > Attachments: loader-xjson.r616687.patch > > > the current org.apache.sling.jcr.resource.internal.loader.JsonReader has a > pretty simple format for loading content from the bundles into the > repository. the pain is that if you already have repository content, you > can't create just a JSON dump and put it in the resource. > suggest to change the JsonReader to accept a JSON dump as provided by a JSON > content export by the default servlet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-219) Use native representations for boolean and numbers in JSON export
[ https://issues.apache.org/jira/browse/SLING-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-219. - Resolution: Fixed Fix Version/s: 2.0.0 Applied patch slightly modified in Rev. 618408. Modifications: - Use switch instead of Ifs - Use shared DateFormat instance (synchronized of course) Please close, if this fixes your issue. Thanks. > Use native representations for boolean and numbers in JSON export > - > > Key: SLING-219 > URL: https://issues.apache.org/jira/browse/SLING-219 > Project: Sling > Issue Type: Improvement > Components: JSON >Reporter: Tobias Bocanegra >Assignee: Felix Meschberger > Fix For: 2.0.0 > > Attachments: JsonItemWriter-r61526.patch > > > the current JSON export uses just the getString() representation for all > property types. if would be good if the property type can be preserved. > although it's not possible for all property types, at least for 'boolean', > 'long' and 'double' the JSON equivalent should be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-219) Use native representations for boolean and numbers in JSON export
[ https://issues.apache.org/jira/browse/SLING-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-219: --- Assignee: Felix Meschberger > Use native representations for boolean and numbers in JSON export > - > > Key: SLING-219 > URL: https://issues.apache.org/jira/browse/SLING-219 > Project: Sling > Issue Type: Improvement > Components: JSON >Reporter: Tobias Bocanegra >Assignee: Felix Meschberger > Attachments: JsonItemWriter-r61526.patch > > > the current JSON export uses just the getString() representation for all > property types. if would be good if the property type can be preserved. > although it's not possible for all property types, at least for 'boolean', > 'long' and 'double' the JSON equivalent should be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-213) ujax post servlet should respond with status page instead of default redirect
[ https://issues.apache.org/jira/browse/SLING-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565495#action_12565495 ] Felix Meschberger commented on SLING-213: - Applied modified patch in Rev. 618397: Default response is HTML response and elements with well-known ID tags: Status : status code, e.g. 200 Message : status code message, e.g. OK Location : URL to created/modified Resource, e.g. http://host/a/b/c ParentLocation: URL to parent of created/modified Resource, e.g. http://host/a/b Path : Absolute path of created/modified Resource, e.g. /a/b/c Referer : Referer header of POST request ChangeLog : The operations applied, list of add, removed, modify All values are available as element content of the respective DOM elements, the elements are available by getElementById modified ujax:redirect support (1) ujax:redirect parameter not set: Default HTML response, see above (2) ujax:redirect parameter set to any URL : Temporary redirect (302) to the given URL (3) ujax:redirect parameter contains "*" : Temporary redirect (302) to the URL where "*" is replaced with the name (Node.getName()) of the Resource created/modified. Example for (3): Given a node with name "1234" is created: ujax:redirect=* ==> redirect to "1234" ujax:redirect=*.html ==> redirect to "1234.html" ujax:redirect=*/suffix.pdf ==> redirect to "1234/suffix.pdf" ujax:redirect=prefix/*/suffix.pdf ==> redirect to "prefix/1234/suffix.pdf" > ujax post servlet should respond with status page instead of default redirect > - > > Key: SLING-213 > URL: https://issues.apache.org/jira/browse/SLING-213 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Tobias Bocanegra >Assignee: Felix Meschberger > Attachments: ujax_post.r616964-1.patch > > > it is desirable that the ujax post serlvet responds with a status page rather > than with a default redirect. > this allows clients (javascript+formpost or ajax based) to react better on > the modifications. > will provide a patch for the post servlet that responds with that status > page. the old redirect behavior can still be achieved by sending a > ujax:redirect="*" input parameter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-213) ujax post servlet should respond with status page instead of default redirect
[ https://issues.apache.org/jira/browse/SLING-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-213. - Resolution: Fixed Considering this issue fixed. Please close if ok for you. Thanks. > ujax post servlet should respond with status page instead of default redirect > - > > Key: SLING-213 > URL: https://issues.apache.org/jira/browse/SLING-213 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Tobias Bocanegra >Assignee: Felix Meschberger > Attachments: ujax_post.r616964-1.patch > > > it is desirable that the ujax post serlvet responds with a status page rather > than with a default redirect. > this allows clients (javascript+formpost or ajax based) to react better on > the modifications. > will provide a patch for the post servlet that responds with that status > page. the old redirect behavior can still be achieved by sending a > ujax:redirect="*" input parameter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-213) ujax post servlet should respond with status page instead of default redirect
[ https://issues.apache.org/jira/browse/SLING-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565491#action_12565491 ] Felix Meschberger commented on SLING-213: - Adapted integration tests in Rev. 618395: - UslingIntegrationTestClient: * use default ujax: parameters, but do not overwrite test-provided values * default status is 200 (ok) now, was 302 (temp redirect) - HttpTestBase: Gather messages while waiting for Sling startup in a list instead of a Set to keep the order of the messages - PostRedirectTest: Adapt to new ujax:redirect semantics - PostServletDeleteTest: Adapt to default status 200 (OK) - PostServletOrderTest: minor message format > ujax post servlet should respond with status page instead of default redirect > - > > Key: SLING-213 > URL: https://issues.apache.org/jira/browse/SLING-213 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Tobias Bocanegra >Assignee: Felix Meschberger > Attachments: ujax_post.r616964-1.patch > > > it is desirable that the ujax post serlvet responds with a status page rather > than with a default redirect. > this allows clients (javascript+formpost or ajax based) to react better on > the modifications. > will provide a patch for the post servlet that responds with that status > page. the old redirect behavior can still be achieved by sending a > ujax:redirect="*" input parameter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Board Report Feb/08
Hi all, I submitted the February 2008 report and prepared a template May 2008 report for further additions. If there is anything missing or wrong in the February 2008 report, please reply to this mail, such that I may fix this. Thanks. Regards Felix Am Montag, den 28.01.2008, 09:16 +0100 schrieb Felix Meschberger: > Hi all, > > Time is approaching to deliver our board report. I prepared the report > page on our wiki [1] and invite you all to review and ammend where > appropriate. > > Thanks and Regards > Felix > > [1] http://cwiki.apache.org/confluence/x/4REB
[jira] Closed: (SLING-217) Scripting Resolver bundle compiled with JDK 6 may produce NoSuchMethodError
[ https://issues.apache.org/jira/browse/SLING-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-217. --- Resolution: Fixed Fixed in Rev. 618288 by using the non-standard -Xbootclasspath/p: command line option for compilation. > Scripting Resolver bundle compiled with JDK 6 may produce NoSuchMethodError > --- > > Key: SLING-217 > URL: https://issues.apache.org/jira/browse/SLING-217 > Project: Sling > Issue Type: Improvement > Components: Scripting >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > Sometimes a NoSuchMethodError is thrown in the > DefaultSlingScript.verifyBindings method when filling the > javax.servlet.SimpleBindings object for the script evaluation. > This happens, if the scripting/resolver bundle is compiled with JDK 1.6, that > is the generic SimpleBindings class contained in JDK 1.6. This causes the put > method to be bound to the parameters (String, Object) while the BSF 3 > SimpleBindings class from the scripting/api bundle used in a JDK 1.5 > environment has a put method taking (Object, Object). > Now, one fix of course is to make sure, the scripting/resolver bundler is > compiled with JDK 1.5 instead of JDK 1.6. Another solution could be to use > the scripting/api bundle (or the BSF 3 library) on the boot class path for > the compilation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-217) Scripting Resolver bundle compiled with JDK 6 may produce NoSuchMethodError
[ https://issues.apache.org/jira/browse/SLING-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565350#action_12565350 ] Carsten Ziegeler commented on SLING-217: Yes, this seems to work on macs as well. > Scripting Resolver bundle compiled with JDK 6 may produce NoSuchMethodError > --- > > Key: SLING-217 > URL: https://issues.apache.org/jira/browse/SLING-217 > Project: Sling > Issue Type: Improvement > Components: Scripting >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: 2.0.0 > > > Sometimes a NoSuchMethodError is thrown in the > DefaultSlingScript.verifyBindings method when filling the > javax.servlet.SimpleBindings object for the script evaluation. > This happens, if the scripting/resolver bundle is compiled with JDK 1.6, that > is the generic SimpleBindings class contained in JDK 1.6. This causes the put > method to be bound to the parameters (String, Object) while the BSF 3 > SimpleBindings class from the scripting/api bundle used in a JDK 1.5 > environment has a put method taking (Object, Object). > Now, one fix of course is to make sure, the scripting/resolver bundler is > compiled with JDK 1.5 instead of JDK 1.6. Another solution could be to use > the scripting/api bundle (or the BSF 3 library) on the boot class path for > the compilation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-213) ujax post servlet should respond with status page instead of default redirect
[ https://issues.apache.org/jira/browse/SLING-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565320#action_12565320 ] Felix Meschberger commented on SLING-213: - As a result of the discussion, I change the patch such, that any "extension" of the ujax:redirect parameter starting with "*" is used as the request extension for the redirect (302) to the created/modified node. > ujax post servlet should respond with status page instead of default redirect > - > > Key: SLING-213 > URL: https://issues.apache.org/jira/browse/SLING-213 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Tobias Bocanegra >Assignee: Felix Meschberger > Attachments: ujax_post.r616964-1.patch > > > it is desirable that the ujax post serlvet responds with a status page rather > than with a default redirect. > this allows clients (javascript+formpost or ajax based) to react better on > the modifications. > will provide a patch for the post servlet that responds with that status > page. the old redirect behavior can still be achieved by sending a > ujax:redirect="*" input parameter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-126) MicrojaxPostServlet: redirect to Referer if provided, unless ujax_redirect is provided
[ https://issues.apache.org/jira/browse/SLING-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-126. --- Resolution: Won't Fix Assignee: Felix Meschberger Closing this issue as won't fix as the proposed patch collides with SLING-213. > MicrojaxPostServlet: redirect to Referer if provided, unless ujax_redirect is > provided > -- > > Key: SLING-126 > URL: https://issues.apache.org/jira/browse/SLING-126 > Project: Sling > Issue Type: Improvement > Components: microsling >Reporter: Bertrand Delacretaz >Assignee: Felix Meschberger >Priority: Minor > Attachments: launchpad-json-status-r615414.patch > > > Currently, the Referer HTTP header is ignored for redirects, as > MicrojaxPostServlet redirects to the created or modified node. > Redirecting to the Referer is often useful in browser-based applications, to > enable this I suggest the following logic: > 1) If ujax_redirect parameter is given, redirect to that after the POST > 2) else use the "Referer" HTTP header, if provided > 3) else redirect to the Node that was created or modified. > We might want to add a "magic" value (a star?) to ujax_redirect that says > "use method 3) even if Referer is given", or "insert the path of the > created/modified Node instead of the star"? > For now, I'll implement the simple logic shown above, and we can refine if > needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SLING-213 vs. SLING-126
Hi all, Thanks for your replies. So I will take that route and modify the Sling-213 patch as described (notably the *[ext] variant). Further, I close SLING-126 as won't fix as it is superceded by SLING-213. Regards Felix Am Montag, den 04.02.2008, 09:49 +0100 schrieb David Nuescheler: > 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 s
Re: SLING-213 vs. SLING-126
Hi, On Feb 4, 2008 9:49 AM, David Nuescheler <[EMAIL PROTECTED]> wrote: > ...(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 ok > ...(2) the returned xhtml contains identified and specified "Id" attributes > that are used for machine readability ok, that's similar to my suggestion earlier in this thread, fine with that. > ...(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)... ok > ...I think it would be great if the above was put into junit tests.,, Sure - the launchpad-webapp integration tests already exercise the ujax protocol, so it's only a matter of adding tests for the new/improved stuff - including parsing of the returned xhtml. -Bertrand
Re: SLING-213 vs. SLING-126
On Feb 4, 2008 9:50 AM, Peter Svensson <[EMAIL PROTECTED]> wrote: > There's a fairly good discussion here; > http://extjs.com/forum/archive/index.php/t-4047.html... Thanks, I'll have a look! > ...Another tack (I think Google did this last year in response to a phishing > Cross-domain trick for gmail) is to prepend a 'for(;;);' , which runs the > attacker in circles :)... Ooohhh - phishers, all your CPUs are belong to us ;-) -Bertrand
Re: SLING-213 vs. SLING-126
There's a fairly good discussion here; http://extjs.com/forum/archive/index.php/t-4047.html with several good links. The basic idea is to make it impossible to use eval() to get the data, so for instance the server could always put the JSON string between '/*' and '*/', which will make a comment out of the string, thus hiding it from any evaluation. Another tack (I think Google did this last year in response to a phishing Cross-domain trick for gmail) is to prepend a 'for(;;);' , which runs the attacker in circles :) Cheers, PS On Feb 4, 2008 9:31 AM, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > On Feb 4, 2008 9:20 AM, Peter Svensson <[EMAIL PROTECTED]> wrote: > > > ...If you/we use JSON, I might also suggest to wrap > > it in an error-inducing layer, to be stripped by the client before > eval(), > > to avoid JavaScript Cross-domain snooping > > Do you have a suggestion for this error inducing layer? Just a > constant String before the JSON data, or something more sophisticated? > > -Bertrand >
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: SLING-213 vs. SLING-126
On Feb 2, 2008 2:13 PM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > ...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. Agreed, that's how Sling works for "normal" operations, so it's consistent. > ...POST /foo/bar >writes back changes and redirect per default to the referrer > POST /foo/bar.html > writes back changes and responds with the suggested HTML status response > POST /foo/bar.json > writes back changes and responds with a JSON status response (tbd)... I would handle that a bit differently: IMHO, POST to an existing Resource should be handled in a very simple way, with minimal ujax functionality: in that case, I'd just allow creating/updating Properties on the Resource. My rationale here is: for such POSTs, you're talking to the Resource, not to the "ujax engine". And for POSTs using the "magic star": > POST /foo/bar/* > POST /foo/bar/*.html > POST /foo/bar/*.json I'd say "now, due to the use of the magic star, you are talking to the ujax engine", which is a Resource that behaves in a different way than standard Resources. The ujax engine processes the request, creates a java UjaxResultObject (simple thing, basically a list of what the ujax engine did), and this object can be serialized in xhtml or json depending on the request's extension. The xhml is both machine and human readable, with qualified links to created and modified items, like newnode.html. To summarize, compared to your proposal, the differences are: a) POSTs to Resources that exist do not involve the full ujax engine, they only allow updates to the Resource, using the ujax conventions on request parameter names. No redirect is needed in this case, the request simply returns the Resource's updated state. b) POSTs to the "magic star" talk to the ujax engine, which allows more operations (updates, creation of new nodes, deletes, moves, etc.), with more options, and returns complete information, in HTML or JSON, on what happened, with links to all created nodes. I think this isolates the "special case" of ujax better: the star in URLs is a good sign that something special is going on, but if it's not used things remain very simple. -Bertrand
Re: SLING-213 vs. SLING-126
On Feb 4, 2008 9:20 AM, Peter Svensson <[EMAIL PROTECTED]> wrote: > ...If you/we use JSON, I might also suggest to wrap > it in an error-inducing layer, to be stripped by the client before eval(), > to avoid JavaScript Cross-domain snooping Do you have a suggestion for this error inducing layer? Just a constant String before the JSON data, or something more sophisticated? -Bertrand
Re: SLING-213 vs. SLING-126
Hi, On Feb 4, 2008 9:11 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > ...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... Agreed, but should not necessarily stop us from making the protocol human readable, if that has other benefits. If Toby has a good use-case for XHTML status responses (like simple HTML form-based interactions, which can be useful), and if we can generate this XHTML in a safe and parsable way (read on for more about that), no problem with me. I'll reply separately to Toby's proposal about how to handle POSTs, as I have a slightly different suggestion. -Bertrand
Re: SLING-213 vs. SLING-126
I can't say that I follow all examples described properly, but in general I would very much agree that, wherever possible, only use 'raw' data between server and (Ajax/JavaScript) client. As soon as the server does View or redirects, things gets complicated quickly - for both sides. So if it is at all possible, to ensure a clean protocol, try to send all information as XML or JSON. If you/we use JSON, I might also suggest to wrap it in an error-inducing layer, to be stripped by the client before eval(), to avoid JavaScript Cross-domain snooping. Cheers, PS On Feb 4, 2008 9:11 AM, 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 would be great to apply the patch of SLING-213 and forget > > > about the referer stuff of SLING-126. > > > > > > regards, toby > > > > > > > > > On 2/1/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > > > > > I am trying to apply the patch of SLING-213 [1], which conains a > rewrite > > > > of the ujax POST servlet. There is just one issue with this patch, > which > > > > I would like to sort out on the list. This patch changes the > response > > > > behaviour of the POST requests as follows: > > > > > > > >* The default response is a status 200 response containing a list > of > > > > changes in HTML > > > > format > > > >* Setting the ujax:redire
Re: SLING-213 vs. SLING-126
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 would be great to apply the patch of SLING-213 and forget > > about the referer stuff of SLING-126. > > > > regards, toby > > > > > > On 2/1/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > > > > I am trying to apply the patch of SLING-213 [1], which conains a rewrite > > > of the ujax POST servlet. There is just one issue with this patch, which > > > I would like to sort out on the list. This patch changes the response > > > behaviour of the POST requests as follows: > > > > > >* The default response is a status 200 response containing a list of > > > changes in HTML > > > format > > >* Setting the ujax:redirect request parameter to "*" causes a 302 > > > (temporary redirect) > > > to the modified/created node > > >* Setting ujax:redirect to an URL causes a 302 (temporary redirect) > > > to the given URL > > > > > > This setting collides, with what was intended by SLING-126 [2], where a > > > redirect to the Referer URL was postulated. > > > > > > I would now like to resolve this issue of the response to a POST > > > request. Can you please enlighten me on that front ? > > > > > > My personal opinion would be to get redirected to the Referer by default > > > (this is the standard GUI case, probably), with an option to redirect to > > > a possibly newly created node (ujax:redirect is *) or - in the Ajax case > > > - get a machine readable response, JSON that is. > > > > > > WDYT ? > > > > > > Regards > > > Felix > > > > > > [1] h
Re: Apache License agreement signed.
Great! Now I just have to actually read how to go about things :) I'm having a full schedule at the moment, trying to finish a customer project and doing slide for Web Monday all at once. A realistic aim for taking up the Bunkai /Sling integration again is Wednesday/Thursday. I'll check out the tests for launchpad to see how to get an object which defines the root of the resource tree in ESP and then I'll build a classical JSON structure from there. The rest is mostly done. Cheers, PS On Feb 4, 2008 8:49 AM, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > On Jan 31, 2008 2:38 PM, Peter Svensson <[EMAIL PROTECTED]> wrote: > >... I've mailed it now, so I'll ping you in a couple of days.. > > I just checked, and Peter's CLA has been recorded. > > -Bertrand >
