-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XE5+ changes #39
base: master
Are you sure you want to change the base?
XE5+ changes #39
Conversation
reckface
commented
Apr 7, 2015
- Rename TRestClient to TJsonRestClient to avoid collisions with native TRestClient
- Introduce Post functions to support returning of data sets
- Introduce Display name parameter to make created datasets with user friendly titles
- Fall back to stNull to ftString instead of ftUnknown
- Expand the use of superobject since native Delphi serialization/Json handling is not as robust
The Delphi XE5 already contains TRestClient, so this was renamed to TJsonRestClient Additionally, TClientDataSet was added
Expanded the functionality to support HTTP Posts that returned datasets. Also removed the directives that conditionally prevented the use of SuperObject. The Delphi generic based Json deserialization (unmarshalling) produced unpredictable results, whereas the superobject was more predictable.
The Field Definition can now have a display name instead of the json-determined fieldName
@reckface I merged some PRs and this PR is now conflicting. Can you fix this? The name change will be a big break change, but, I don't think is a big problem to us. What do you think @fabioxgn? @thomaserlang can you review this PR? |
I'm fine with the TRestClient name change. Why isn't there a "PutJSON" and "PatchJSON"? I agree that the other JSON libs sucks. The official Delphi JSON serialization does not work for half of my valid JSON data. I would prefer Superobject as the default. Even though the code is a big mess, it's possible to change. I have long thought about building a much simpler version. |
For me SuperObject can be the default too, but, the Rather than comment the directive in
for this:
in |
I agree. It should still be possible to use another library. |
@RobertoSchneiders The only problem with name change is that it will break existing PRs, but just leave this one to be merged last and we are ok. But wouldn't it be a better option to use a namespace instead of renaming the class? We already had problems with Or do we need to support Delphi versions that doesn't support namespaces? If we do not have to support older versions, I'd prefer to namespace all the units instead of changing the class name, like:
|
Happy to change it back. On Sat, Apr 11, 2015 at 2:57 PM, Fábio Gomes [email protected]
|
Just a thought. We can use namespaces when coding, but the package won't On Mon, Apr 13, 2015 at 9:00 AM, Eti Kagbala [email protected] wrote:
|
You cloud add a deprecated alias... for backwards compatibility
|
@reckface but does anyone use the packages? There isn't a package for XE7 for example and anyone complained about it, I don't like the whole package idea and nobody is maintaining them. For me we could drop the packages all together. |
I don't know enough about Delphi and packages, I just know I had difficulty On Mon, Apr 13, 2015 at 1:32 PM, Fábio Gomes [email protected]
|
About the packages, I think we can remove all of them. I don't think they are useful for anything at all. @reckface It will probably be another library witch depends on delphi-rest-client-api. Try to put it in a GitHub repository and we will take a look. |