This may be a question with a simple answer. I am using a VM with Win XP And DXE. I am trying to do the simple little DataSnap app, using the wizards to create the server and client apps. I create the server, build and run it, on port 211, the default. Then I use the client wizard, and when I get to Test Connection, it just hangs.
This may be a question with a simple answer. I am using a VM with Win XP And DXE. I am trying to do the simple little DataSnap app, using the wizards to create the server and client apps. I create the server, build and run it, on port 211, the default. Then I use the client wizard, and when I get to Test Connection, it just hangs.
So is this something to do with the VM? Or some little feature of XE? New to DataSnap, so am fumbling in the dark
So is this something to do with the VM? Or some little feature of XE? New to DataSnap, so am fumbling in the dark
Willo van der Merwe Bill Meyer
ReplyDeleteI don't understand your requirements and constraints, however, my experience with frameworks and such isn't very good, usually, they take you about 60% of the road and then leave you there with a ton of frustrations, investment and difficulty in debugging...
I've wrote a simple "framework" that is very lightweight and bare-bones, about 1k of code and it doesn't need any documentation, unfortunately I can't share the code, but the idea is so simple that you'll get it immediately, basically, it's only routing for requests and has default class functions, everything else needs to be implemented inside TRouteObject descendants:
Client Request => TIdHTTPServer => custom context class => TRouteObject[Dispatcher] [=> TRouteObject[Dispatcher]
TUsersRoute = class(TRouteObject)
...
class function GetRoute: string; { returns users }
function GetDocumentation: string; { empty html document | json based on request headers}
function ActionAdd: Boolean;
function ActionList: Boolean;
function ActionDelete: Boolean;
....
req: /users/doc[documentation]
resp:
ActionAdd: adds a new users, required parameters are: etc....
ActionList: lists all users, required parameters are: ...
ActionDelete: deletes a user from system, required parameters are...
req: /users/add?first_name=joe&last_name=doe&age=22&sex=male&etc...
resp: success, fail, json object, etc.
req: /users/delete?id=1337&mark_x=true&etc...
resp: success, fail, json object, etc.
TCustomerRoute = class(TRouteObjectDispatcher)
...
class function GetRoute: string; { returns customer }
function GetDocumentation: string; { -||- }
function ActionAdd: Boolean;
....
if you haven't already figured out, each "TRouteObject" is in it's own unit, it can contain a connection to db -- warning, this would happen in a separated thread -- AND it's registered in the "initialization" unit via:
unit uUsersRoute
initialization
GRouteList.RegisterRoute(TUsersRoute);
unit uCustomerRoute
initialization
GRouteList.RegisterRoute(TCustomerRoute);
basically, only the required objects will be instantiated, everything else it's "there" waiting to be created when needed and based on user request.
also, please note that you need to store login information in user session and/or db(if you can afford the extra io)
if TIdHTTPServer isn't "enough", you can look at alternatives, i.e. http.sys or create your own http server based on windows's api.
***note: I changed the names of the classes... you can named them whatever so long as you understand the concept and it's useful to YOUR needs.
***note: the "GetDocumentation" was something to help the developers that needed to interface with our service, it's not required, but it sure does help alot, especially since every "route object" is in it's own unit, you can easily provide the proper documentation as a html/json string and you don't have to use additional tools and notify people about documentation being changed, added a new feature? nice, you're already in that unit, update documentation, users can simply go in their browser and do:
req: sd.doman.gtld/users/doc
resp: documentation as html document
the above concept worked great for us, because it handles everything it needed to handle while not requiring us to do a ton of voodoo and debug a lot of code that expands over dark magic, rtti and some other stuff that nobody understands (:
anyways, have fun!
Dorin Duminica And if turning a request to /users/delete?id=1337&mark_x=true&etc... into a ActionDelete method call is not done via RTTI then how?
ReplyDeleteStefan Glienke the way we expose "actions" is by "registering" them when the "route" object is created, i.e. AddAction('delete', ActionDelete); so, no RTTI
ReplyDeletewe took this a step further and implemented the whole shebang in DWS (-;
P.S. names in routes are case insensitive