Hi,
I noticed that when TXDataWebConnection connects to the Xdata server, it downloads the entire structure of the model on the client.
This leaves me somewhat perplexed, I am practically "giving away" my entire data structure to my competition. With regards to our security and privacy/secrets of our technology and making the structure of our databases public.
I think many of our customers will not accept this strange policy.
Is there a way, a property, an event to set so that this does NOT happen?
Thanks in advance.
No. The TXDataWebClient and needs the model to know how to properly invoke the endpoints. Alternative would be not using TXDataWebClient but just raw HTTP request using another component/class.
The model doesn't provide the structure of your database, it provides the structure of your API, which is "public" anyway (requests to the API can be inspected by anyone from the browser network tab).
I agree that it is necessary for TMS WEBCore, but exposing the complete list of all classes, detailed with fields, type and length, well defined in a single structure does not seem "prudent" to me, at least for my clients. Maybe just to ask for a paltry list of 2 fields.
Of course I can create an ad hoc model for this last case, but I don't agree with the design choice.
Wasn't it perhaps easier to incorporate these structures directly into the application, during compilation, limiting ourselves only to the classes involved in the design time phase?
Thanks anyway.
That's also one option you have.
They would still be available for anyone reading the source code, and still the endpoints will be available in the API.
Reading source code is not for everyone and is laborious. Instead now I have a single complete list, nice and ready, in which I just need to copy and paste.
I'll have to come up with something to avoid this problem.
Perhaps use TXDataWebClient ONLY at design time to populate the persistent fields (of which there are so many) of the different TXDataWebDatasets, and use a different connection to receive the necessary Json,at runtime.
But, at this point,
Is TXDataWebDataset fully usable without the indication of the Connection and above all the Entity, but only with the indication of the structure of the fields of the dataset?
(If so I will have to invent something for the cached update and manage the ApplyUpdate, an old problem with your datasets)
Thanks
Yes, you can input a JSON array of objects to it to bind to data-aware controls.
Well, I have a little project for a finance company that has security as the first objective to achieve.
With practically the entire database structure having to be downloaded, it is not even conceivable to use Xdata in Web Core for similar situations (indeed, the data structure must be as difficult as possible to interpret).
Is it possible that this could not happen with an option or a property in future?
Clearly with the consequent management of any shortcomings that will be my responsibility.
(...Or for these cases I have to use Unigui, which, being server side, naturally hides the Xdata data structure).
The $model is just needed as a helper for using TXDataWebClient so that you can invoke the XData endpoints at a higher level, like calling IMyService.SomeMethod. The client (web app) needs the model to know how to invoke such service.
If you don't use the model, you can still invoke XData using the regular HTTP/JSON class that you would do with any other different server. So there is no need to completely change a framework just for that. Just don't use the helper classes and use it in a more lower level (the regular way).
The reasoning is clear to me, but unfortunately I think that in this way the very convenient Tfields fetching utilities for the TWebXdataset structures and the automatic ApplyUpdate are lost. Especially in projects with many datasets and many Tfields.
Or is there some way to preserve them?
Thanks a lot
That comes from the model.
...and which I only need for design time and compile time (TFields and ApplyUpdate), not to decide it at runtime.
My thought is that it should be integrated into the javascript code itself, only and only for the portion of entities relating to the single form or the single procedure.
So it becomes difficult to reconstruct the entire scheme from the outside, which is now really easy to achieve on a silver platter.
Unfortunately the competition in our industry (tax-accounting) is really fierce trying to study
and copy what competing companies do.
I understand that the logic and approach you have taken is more for shared and public APIs than for very private use.
Thanks and good work