I fully agree!
JavaScript binding is a great thing and its potential is enormous!
It should absolutly be a part of Thrift.
As already written, I propose starting with a powerful testing framwork
for JavaScript, to have similar testing capabilities as with C++ or
other languages.
Currently I have a working test/cpp/srcTestServer.cpp and client using
the C++ HttpServer, provided by
https://issues.apache.org/jira/browse/THRIFT-247
I did some Test and reproduced that error mentioned in
https://issues.apache.org/jira/browse/THRIFT-816
on wire: [1,"testList",2,0,{"0":{"lst":["i32",3,3,2,1]}}]
I propose choosing a mature JavaScript unit test framework, e.g.
QUnit(what's state-of-the-art?) and implement unit tests on
http://svn.apache.org/repos/asf/incubator/thrift/trunk/lib/js/test/test.html
I'm ready to contribute!
Roger
Am 08.07.2010 09:08, schrieb Jordan (JIRA):
[
https://issues.apache.org/jira/browse/THRIFT-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan updated THRIFT-816:
--------------------------
Description:
Please let me know if this is supposed to be standard behavior or just resolve
if this is a feature not a bug. This may also be related to the problem of
lists being deserialized incorrectly.
Basically if I a data type type:
ResponseObject {
1: ResponseDetail responseDetail
}
And I have a service call method that returns something of type ResponseObject
service TheService {
ResponseObject makeCall()
}
If the implementation of makeCall returns a ResponseObject with responseDetail
set to null, then on the javascript client I will get a ResponseObject with a
ResponseDetail that is NOT null. Instead it will be an object with not much
character to it (all booleans will be false, all numbers will be zero etc.) I
would expect nulls to come across the wire properly and show up as nulls on the
client. Am I mistaken?
Someone please confirm that this is a bug and not an intended feature.
I will try to track down where this is coming from, but I might get stuck.
I would really like to get all these bugs ironed out, so if someone could
dedicate about an hour of their time sometime within the next weak, to have a
phone conversation about the code base, I can begin to help more effectively
instead of just filing bug reports.
I honestly think that this javascript target of thrift is one of the most
important components of the entire project. I commend the developers and would
love to help out.
was:
Please let me know if this is supposed to be standard behavior or just resolve
if this is a feature not a bug. This may also be related to the problem of
lists being deserialized incorrectly.
Basically if I a data type type:
ResponseObject {
1: ResponseDetail responseDetail
}
And I have a service call method that returns something of type ResponseObject
service TheService {
ResponseObject makeCall()
}
And the implementation of makeCall returns a ResponseObject with responseDetail
set to null, then on the javascript client I will get a ResponseObject with a
ResponseDetail that is NOT null. Instead it will be an object with not much
character to it (all booleans will be false, all numbers will be zero etc.)
Someone please confirm that this is a bug and not an intended feature.
I will try to track down where this is coming from, but I might get stuck.
I would really like to get all these bugs ironed out, so if someone could
dedicate about an hour of their time sometime within the next weak, to have a
phone conversation about the code base, I can begin to help more effectively
instead of just filing bug reports.
I honestly think that this javascript target of thrift is one of the most
important components of the entire project. I commend the developers and would
love to help out.
returning null for an object, sets it to a dummy object with all zero/default
values as opposed to returning null.
-------------------------------------------------------------------------------------------------------------------
Key: THRIFT-816
URL: https://issues.apache.org/jira/browse/THRIFT-816
Project: Thrift
Issue Type: Bug
Components: Compiler (JavaScript)
Affects Versions: 0.4
Reporter: Jordan
Please let me know if this is supposed to be standard behavior or just resolve
if this is a feature not a bug. This may also be related to the problem of
lists being deserialized incorrectly.
Basically if I a data type type:
ResponseObject {
1: ResponseDetail responseDetail
}
And I have a service call method that returns something of type ResponseObject
service TheService {
ResponseObject makeCall()
}
If the implementation of makeCall returns a ResponseObject with responseDetail
set to null, then on the javascript client I will get a ResponseObject with a
ResponseDetail that is NOT null. Instead it will be an object with not much
character to it (all booleans will be false, all numbers will be zero etc.) I
would expect nulls to come across the wire properly and show up as nulls on the
client. Am I mistaken?
Someone please confirm that this is a bug and not an intended feature.
I will try to track down where this is coming from, but I might get stuck.
I would really like to get all these bugs ironed out, so if someone could
dedicate about an hour of their time sometime within the next weak, to have a
phone conversation about the code base, I can begin to help more effectively
instead of just filing bug reports.
I honestly think that this javascript target of thrift is one of the most
important components of the entire project. I commend the developers and would
love to help out.
