Re: BUG?: JsonRepresentation does not inherit size from wrapped StringRep
I'm not sure I'm convinced. When using the constructor that takes (String jsonString) the passed arg is put into a StringRepresentation which is then stored in this.jsonRepresentation of the JsonRepresentation object. The private getJsonText method then will not use the first if case (because this.jsonObject is still null) and it will fall into the else if case (as this.jsonRepresentation is not null). This case is very simple as it directly takes StringRepresentation.getText() and returns that as the result (in the case where the String based constructor was used, in the case where the Representation based constructor was used the behavior may be a bit more ambiguous). If the wrapped representation is not aimed to be parsed (in order to get a JsonObject, JsonArray, etc) and is only aimed to be written, the JsonRepresentation is useless. The JsonRepresentation is not useless in this case. All the helpers can still be used to get formal json objects out of the representation using the toJson() methods (which will parse the underlying string rep but will still never set the internal jsonObject var). Also, the data still represents json formatted data conceptually. I still prefer the string constructor on the JsonRepresentation because it gives much greater control over the json formatting. One can also rely on Restlet's built in handling of media type and any other functionality that might be added or triggered by the variant system. When constructed through String or Representation the JsonRepresentation never changes its nature (it always knows it was not constructed with a json object and never forgets this fact no matter what methods you call on it). In these cases it is very possible to know the size (and even guaranteed to know the size in the String case). This makes the use of the chunked header quite unnecessary in these cases, and it breaks and slows down some proxy configurations which then have to do extra work to reassemble the response before passing it on. I have fallen back to using StringRepresentation to overcome this. In addition to needing to add extra json code (where I used to be able to pull the json right out of the representation) it also means I have to jump through more hoops to get a application-json header back through manual configuration of something that is supposed to be one of the nice things that Restlet does for you without making you jump through a bunch of hoops. It really does feel like a loophole. If you don't want to allow JsonRepresentation to be used as a convenience wrapper around a String then why provide a constructor that causes it to behave as one? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2428093
Re: BUG?: JsonRepresentation does not inherit size from wrapped StringRep
Hi Ben, thanks a lot, I'm now awaken. I've added an implementation of the getSize method that checked if the wrapped representation is available of not. We may rely on the getJsonText, however this could have an impact on large objects since the each call to getJsonText compute a new value. Best regards, Thierry Boileau I'm not sure I'm convinced. When using the constructor that takes (String jsonString) the passed arg is put into a StringRepresentation which is then stored in this.jsonRepresentation of the JsonRepresentation object. The private getJsonText method then will not use the first if case (because this.jsonObject is still null) and it will fall into the else if case (as this.jsonRepresentation is not null). This case is very simple as it directly takes StringRepresentation.getText() and returns that as the result (in the case where the String based constructor was used, in the case where the Representation based constructor was used the behavior may be a bit more ambiguous). If the wrapped representation is not aimed to be parsed (in order to get a JsonObject, JsonArray, etc) and is only aimed to be written, the JsonRepresentation is useless. The JsonRepresentation is not useless in this case. All the helpers can still be used to get formal json objects out of the representation using the toJson() methods (which will parse the underlying string rep but will still never set the internal jsonObject var). Also, the data still represents json formatted data conceptually. I still prefer the string constructor on the JsonRepresentation because it gives much greater control over the json formatting. One can also rely on Restlet's built in handling of media type and any other functionality that might be added or triggered by the variant system. When constructed through String or Representation the JsonRepresentation never changes its nature (it always knows it was not constructed with a json object and never forgets this fact no matter what methods you call on it). In these cases it is very possible to know the size (and even guaranteed to know the size in the String case). This makes the use of the chunked header quite unnecessary in these cases, and it breaks and slows down some proxy configurations which then have to do extra work to reassemble the response before passing it on. I have fallen back to using StringRepresentation to overcome this. In addition to needing to add extra json code (where I used to be able to pull the json right out of the representation) it also means I have to jump through more hoops to get a application-json header back through manual configuration of something that is supposed to be one of the nice things that Restlet does for you without making you jump through a bunch of hoops. It really does feel like a loophole. If you don't want to allow JsonRepresentation to be used as a convenience wrapper around a String then why provide a constructor that causes it to behave as one? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2428093 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2428111
Re: BUG?: JsonRepresentation does not inherit size from wrapped StringRep
In the case of the wrapped jsonRepresentation object it might be sufficient to pass the call to getSize through to jsonRepresentation.getSize without doing the full calculation. In this case you gain the benefit of knowing the size when the wrapped representation knows its own size but don't suffer the penalty of repeated calculation if it does not. On Tue, Dec 8, 2009 at 12:50 AM, Thierry Boileau thierry.boil...@noelios.com wrote: Hi Ben, thanks a lot, I'm now awaken. I've added an implementation of the getSize method that checked if the wrapped representation is available of not. We may rely on the getJsonText, however this could have an impact on large objects since the each call to getJsonText compute a new value. Best regards, Thierry Boileau I'm not sure I'm convinced. When using the constructor that takes (String jsonString) the passed arg is put into a StringRepresentation which is then stored in this.jsonRepresentation of the JsonRepresentation object. The private getJsonText method then will not use the first if case (because this.jsonObject is still null) and it will fall into the else if case (as this.jsonRepresentation is not null). This case is very simple as it directly takes StringRepresentation.getText() and returns that as the result (in the case where the String based constructor was used, in the case where the Representation based constructor was used the behavior may be a bit more ambiguous). If the wrapped representation is not aimed to be parsed (in order to get a JsonObject, JsonArray, etc) and is only aimed to be written, the JsonRepresentation is useless. The JsonRepresentation is not useless in this case. All the helpers can still be used to get formal json objects out of the representation using the toJson() methods (which will parse the underlying string rep but will still never set the internal jsonObject var). Also, the data still represents json formatted data conceptually. I still prefer the string constructor on the JsonRepresentation because it gives much greater control over the json formatting. One can also rely on Restlet's built in handling of media type and any other functionality that might be added or triggered by the variant system. When constructed through String or Representation the JsonRepresentation never changes its nature (it always knows it was not constructed with a json object and never forgets this fact no matter what methods you call on it). In these cases it is very possible to know the size (and even guaranteed to know the size in the String case). This makes the use of the chunked header quite unnecessary in these cases, and it breaks and slows down some proxy configurations which then have to do extra work to reassemble the response before passing it on. I have fallen back to using StringRepresentation to overcome this. In addition to needing to add extra json code (where I used to be able to pull the json right out of the representation) it also means I have to jump through more hoops to get a application-json header back through manual configuration of something that is supposed to be one of the nice things that Restlet does for you without making you jump through a bunch of hoops. It really does feel like a loophole. If you don't want to allow JsonRepresentation to be used as a convenience wrapper around a String then why provide a constructor that causes it to behave as one? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2428093 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2428111 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2428114
BUG?: JsonRepresentation does not inherit size from wrapped StringRep
JsonRepresentation has the member variable jsonRepresentation for using a wrapped Representation object in some cases. The bug I'm seeing is that getSize() on the JsonRepresentation object always returns -1 in those cases where it is backed by this other underlying representation. I believe a better behavior would be for JsonRepresntation to over getSize() to return jsonRepresentation.getSize() in those cases. I'm using 2.0-M5 (until M6 hits the public maven repo) but the problem looks like it is also in M6. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2427907
Re: BUG?: JsonRepresentation does not inherit size from wrapped StringRep
Hello Ben, your first post has been moderated, but was lost in the list of posts... sorry. Actually, the wrapped Representation is first parsed (in the private getJsonText() method) as JsonObject, even when the write method is called. Thus, it is difficult to know by advance the size of the text representation generated by the org.json library. If the wrapped representation is not aimed to be parsed (in order to get a JsonObject, JsonArray, etc) and is only aimed to be written, the JsonRepresentation is useless. Best regards, Thierry Boileau JsonRepresentation has the member variable jsonRepresentation for using a wrapped Representation object in some cases. The bug I'm seeing is that getSize() on the JsonRepresentation object always returns -1 in those cases where it is backed by this other underlying representation. I believe a better behavior would be for JsonRepresntation to over getSize() to return jsonRepresentation.getSize() in those cases. I'm using 2.0-M5 (until M6 hits the public maven repo) but the problem looks like it is also in M6. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2427907 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2428085
BUG?: JsonRepresentation does not inherit size from wrapped StringRep
JsonRepresentation has the member variable jsonRepresentation for using a wrapped Representation object in some cases. The bug I'm seeing is that getSize() on the JsonRepresentation object always returns -1 in those cases where it is backed by this other underlying representation. I believe a better behavior would be for JsonRepresntation to over getSize() to return jsonRepresentation.getSize() in those cases. I'm using 2.0-M5 (until M6 hits the public maven repo) but the problem looks like it is also in M6. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2424382
