Am Mittwoch, den 09.01.2008, 07:35 +0100 schrieb Carsten Ziegeler:
Felix Meschberger wrote:
Hi Carsten,
Am Dienstag, den 08.01.2008, 07:55 +0100 schrieb Carsten Ziegeler:
It's difficult to tell what is going wrong from here, but one possible
problem could be the startup order of the
Felix Meschberger wrote:
Maybe the case of inability loading the content due to missing node
types. This is fortunately an exception (NoSuchNodeTypeException) we can
handle appropriately. Then we may postpone loading the content until the
node types exist. Maybe we might add an eventing for
hi,
currently the DefaultServlet handles the json content export. it
exports only the current node and its properties. i am not sure if
this default behaviour is desirable and would expect that the default
behaviour would be so that the json exporter would recursively export
the current node and
[
https://issues.apache.org/jira/browse/SLING-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-146:
---
Assignee: Carsten Ziegeler (was: Felix Meschberger)
Replace Resource.getURI() by
Bertrand Delacretaz wrote:
On Jan 9, 2008 10:42 AM, Philipp Koch [EMAIL PROTECTED] wrote:
...my proposal:
full recursive mode should be default. if you would like to specify
the recursion depth one could e.g. specify a request parameter that
specifies the depth
Isn't that a bit
[
https://issues.apache.org/jira/browse/SLING-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-146.
--
Resolution: Fixed
Replace Resource.getURI() by Resource.getPath()
On Jan 9, 2008 10:42 AM, Philipp Koch [EMAIL PROTECTED] wrote:
...my proposal:
full recursive mode should be default. if you would like to specify
the recursion depth one could e.g. specify a request parameter that
specifies the depth
Isn't that a bit dangerous?
A json GET at / would
Hi Paddy,
On Jan 9, 2008 2:21 AM, Padraic Hannon [EMAIL PROTECTED] wrote:
...So far we have a pretty strong link
between Content and a Component (at least expressed by the
documentation)
Those interfaces are gone, replaced (in a different way) by Resource
and Servlet.
I think
Hi,
Am Mittwoch, den 09.01.2008, 11:03 +0100 schrieb Carsten Ziegeler:
Bertrand Delacretaz wrote:
On Jan 9, 2008 10:42 AM, Philipp Koch [EMAIL PROTECTED] wrote:
...my proposal:
full recursive mode should be default. if you would like to specify
the recursion depth one could e.g.
...requesting /a/b/c.all.json would return the subtree rooted at
node c to be dumped as JSON.
what about using 0 or -1 instead of all. this would save some lines of
parsing and would from my point of view cleaner in terms of depth
notation.
regards,
philipp
On 1/9/08, Felix Meschberger [EMAIL
So you have an url /a/b/c.-1.json ? Not sure, whether is nice :-)
Regards
Felix
Am Mittwoch, den 09.01.2008, 15:45 +0100 schrieb Philipp Koch:
...requesting /a/b/c.all.json would return the subtree rooted at
node c to be dumped as JSON.
what about using 0 or -1 instead of all. this would
what about omitting the depth selector for a full recursive export?
eg:
/a/b/c.json - export all recursively
/a/b/c.0.json - export the 'c' node + props only
/a/b/c.1.json - export the 'c' node and all direct children
regards, toby
On 1/9/08, Philipp Koch [EMAIL PROTECTED] wrote:
So you
Isn't that a bit dangerous?
A json GET at / would then get the whole repository...
and how would you do that? is there a way addressing the root node ?
GET /.json HTTP/1.1?
GET /jcr:root.json HTTP/1.1?
regards, toby
--
- [EMAIL PROTECTED] ---
The problem with defaulting to full recursive export (which is what you
propose by omitting the selector), is that you may start a full
repositoy traversal by coincidence. Defaulting to just the properties of
the node prevents this.
If we require some selector value to have a recursive traversal,
So you have an url /a/b/c.-1.json ? Not sure, whether is nice :-)
i do not want to win a beauty contest ;-) and if all is even nicer
is questionable (depends on personal bias) .
regards, philipp
On 1/9/08, Felix Meschberger [EMAIL PROTECTED] wrote:
So you have an url /a/b/c.-1.json ? Not
Felix Meschberger wrote:
The problem with defaulting to full recursive export (which is what you
propose by omitting the selector), is that you may start a full
repositoy traversal by coincidence. Defaulting to just the properties of
the node prevents this.
If we require some selector value to
On Jan 9, 2008 4:24 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote:
...I still prefer that full recursion is the default
I would agree with that if that's the majority opinion, and if there's
a clear way of having less recursion.
So I'd be ok with
/stuff.json - full recursion
Carsten Ziegeler wrote:
Felix Meschberger wrote:
Maybe the case of inability loading the content due to missing node
types. This is fortunately an exception (NoSuchNodeTypeException) we can
handle appropriately. Then we may postpone loading the content until the
node types exist. Maybe we
On Jan 9, 2008 4:08 PM, Tobias Bocanegra [EMAIL PROTECTED] wrote:
Isn't that a bit dangerous?
A json GET at / would then get the whole repository...
and how would you do that? is there a way addressing the root node ?
GET /.json HTTP/1.1?
Ok, not the root then, but GET /content.json
i completely agree with carsten (as i have already written in an earlier post).
regards,
philipp
On 1/9/08, Carsten Ziegeler [EMAIL PROTECTED] wrote:
Felix Meschberger wrote:
The problem with defaulting to full recursive export (which is what you
propose by omitting the selector), is that
I like felix's idea of using selectors. I would hate to call /foo.json and get
it and all its child nodes. Think of a file system, you don't expect to request
the root folder and get a full dump. However, if you requested /foo.recurs.json
you may expect a full dump.
Paddy
Sent via BlackBerry
+1 (with the non-committer hat in mind ;-)
I find the /foo.all.json and /foo.1.json notation very intuitive. And /
foo.json only returns the foo node and its properties.
Alex
Am 09.01.2008 um 16:58 schrieb [EMAIL PROTECTED]:
I like felix's idea of using selectors. I would hate to call /
Hi,
On Jan 9, 2008 5:40 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote:
/stuff.json - full recursion
/stuff.1.json - 1 level recursion
etc...
Why not:
/stuff.json?depth=1
It's not like we need to use the URI mapping for everything.
BR,
Jukka Zitting
I'll put something in the whiteboard area. Basically, I wanted to make
a sample app that used some of the new concepts and also demonstrated
how resources can be shared (along with their ocm mappings) across
multiple bundles since I think this may be a common use case.
-paddy
On Jan 9,
I think the use case approach is the best way to unpack this. As such
it seems we have been discussing three use cases:
1 Display a node and its properties
2 Display a node, its properties, and its children
3 Display a node its properties, and the full structure underneath it
If those are the
Why not:
/stuff.json?depth=1
It's not like we need to use the URI mapping for everything.
because this breaks caching.
however, i think there are actually 2 use cases. the first is that you
need the deep serialization of a tree, e.g. a page, or an exploded
xml, or a dialog node structure
Hi,
On Jan 9, 2008 11:01 PM, 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
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
Hi,
On Jan 10, 2008 12:45 AM, Tobias Bocanegra [EMAIL PROTECTED] wrote:
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
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
30 matches
Mail list logo
