Marcos Douglas wrote:
Lee Jenkins <l...@datatrakpos.com> wrote:
My goals in its development has been to ensure that the framwork overall:
A) Not tied to any particular GUI front-end, they should be swappable. I
should be able to present my Model/Controller (or other business logic) in
different UI's such as Flex, Silverlight, ExtJS, Dojo, OpenLaszlo, etc while
still keeping 95% of the code on the server.
His framework already supports all of these UI?!
No. Only a partially finished Flex UI and the Dojo UI I'm working on now. My
point was that would be possible to "plug in" different UI's.
B) Any server platform or protocol. For instance, you should be able to
deploy your application using what ever server protocol that is appropriate
for the job. So feasibly you should be able to deploy your server app to
FastCGI, Apache Module, ISAPI or even a stand alone synapse based HTTP
server like I am using for testing.
This is very interesting ... but you are not creating too many
options? If there are many options, more harder it is to understand,
isn't?
I don't think so because the framework itself doesn't incorporate any
communication protocols. Using your favorite existing Server platform (like
fpWeb/LazWeb) you write a small method for when a request comes in like the one
below to handle the request/response:
var
lApp: TRiaApplication;
begin
lApp := FServer.ServerPool.RetrieveOrCreateApplication(URI, lSessionOID);
try
lApp.HandleClientRequest(InputData, OutputData, Cookies);
// Pass back and new or changed cookies to the server.
if lApp.OutCookies.Count > 0 then
begin
for lCounter := 0 to lApp.OutCookies.Count - 1 do
begin
OutCookies.Add(lApp.OutCookies[lCounter]);
end;
end;
finally
FServer.ServerPool.ReleaseApplication(lApp);
end;
end;
InputDate is the post data received from the client and OutputData is a stream
that will contain the response to send to the client. So in your server
application, you're just feeding the TRiaApplication with simple data to handle
the request and sending back to the client the data that TRiaApplication
provides back in the OutputData stream. Its always works the same way, since
TRiaApplication doesn't care where InputData and OutputData come from so you can
use any server platform and then simply feed the TRiaApplication as indicated.
The TRiaApplication.HandleClientRequest method has two overloads that can take
either Streams or Strings:
procedure HandleClientRequest(const AInput: string; var AReturnString: string;
ACookies: TStringList); overload; virtual;
procedure HandleClientRequest(AInStream, AOutStream: TStream; ACookies:
TStringList); overload; virtual;
--
Warm Regards,
Lee
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal