[Lazarus] Nested control is not repainted in designtime

[Roland Turcan]

On 19/03/2008, Michael Van Canneyt <michael at freepascal.org> wrote:
>
> You have no options currently. I have EXACTLY the same needs , and
>  believe me, I searched :-)


Seeing that I heavily use tiOPF, and remember seeing a Remote
Persistence Layer in tiOPF, I thought I better ask this question in
that NG as well. I knew that Peter Hinrichsen used a remote
persistence layer, but didn't know what it entails.

>From his reply below, this sounds very promising, even for Free Pascal
users. The big bonus being, my tiOPF based applications would need no
code changes. :)


-------- Original Message --------
Subject: Re: multi-tier (n-tier ) applications with tiOPF
Date: Thu, 20 Mar 2008 07:05:14 +1100
From: Peter Hinrichsen <peter_hinrichsen at dontspamme.com>
Newsgroups: tiopf.development
References: <12d8.47e11cbc.33203 at goofy.opensoft.homeip.net>

> Peter, if you don't mind, would you be able to answer a few questions or
> explain a bit on how it works?

I will put together a demo (soon) - this has to be done for the ADUG
Symposium, so it will get done this time.

> I'm looking for a solution that will work on Linux and Windows. Free
> Pascal obviously. ;-)
>
>
>      PC #1                           PC #2                      PC #3
> Client Application    ----->    Application Server    ----->   RDMS (db)

That's about it.

It uses Indy HTTP server at the back end, and either IndyHTTPClient, or
MSXMLDOM on the client.

The remote persistence layer works the same way as all the other
persistence layers, so you can write either hard coded visitors, or auto
map and you code will work connecting directly to the database, and via
the app server. It's stateless, so lots of users can connect to the same
app server as their connection time is very short. The trick was to get
transaction management work. The TtiQueryRemote has BeginTransaction,
Commit and Rollback just like the other persistence layers and some
state is maintained on the application server to handle this. (If you
click around the code, you will find a TtiStatefullDBConectionPool for
this purpose)

> I know the remote persistence layer does something with HTTP and XML,
> but that is as far as my knowledge goes. :-(  What packet transport does
> it use?

HTTP. That's as low level as tiOPF goes. Just XML wrapped up in
plain-old HTTP.

> Does it handle delta packets? Is it stateless?

Not sure what you mean by delta-packets.

It's stateless from the point of view of client connection to the
server. Long business transactions (several network round trips) can be
held open with some state being maintained on the app server.

> What performance
> do you get compared to a client/server setup?

It's slower. I clocked it a while ago but can't remember the figures.
There is a performance hit when data is read from the server, converted
to xml, passed down the wire then the xml is parsed.

On my systems, I have addressed the performance hit by caching as much
static data on the client as possible. There is some good framework code
in the \tiOPF2\Trunk\ApplicationServer\tiDBProxyServerExtension directory.

> I guess the latter depends
> on the packet transport mechanism.

Not so much the packet transport, but the data marshallings. XML is
sloooow to parse. There is a CSV wrapper that is about 20 x faster and I
use this when caching large blocks of data. The problem with the CSV
mechanism is that it's structures are not self-describing. Your code
must be in sycn with the file structures.

> I have downloaded MidWare for Kylix (old beta) and Hyperbase (midas drop
> in replacement) to see if it inspires me to come up with some solution.
> But if I can draw from any of your experience, that would be great too.


The heart of the remote persistence layer is the TtiDataBuffer. A suite
of classes that give Midas like functionality. The TtiDataBuffer is a
list of table structures. There is a reader and a writer that converts
the object graph to and from xml. There are visitors that convert the
TtiDataBuffer into objects.

So to add some more detail to your diagram:

BOM -> Visitor -> TtiDataBuffer -> XML -> IndyHTTPClient ->
IndyHTTPServer -> XML -> TtiDataBuffer -> Database.

The code base is rock-solid and has been used in a complex production
system for about four years. There are plenty of unit tests, The main
down side is the usual lack of docs.

P.
---------------[ end ]--------------


Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/