On Sun, 11 Nov 2007, Graeme Geldenhuys wrote:
On 10/11/2007, Al Boldi [EMAIL PROTECTED] wrote:
This is a big misconception. The fact that TForm has the ability to host
business rules and whatever else does not mean that you have to do it this
way. You can maintain whatever model you
On 11/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote:
Indeed. But I think that all will agree that the fact that it IS possible
allows to do real RAD, making it possible to create new programs very fast.
Agreed! That's why I think they are great for prototyping. :)
Prototypes normally
On Sun, 11 Nov 2007, Graeme Geldenhuys wrote:
On 11/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote:
Indeed. But I think that all will agree that the fact that it IS possible
allows to do real RAD, making it possible to create new programs very fast.
Agreed! That's why I think
Am Sonntag, den 11.11.2007, 13:00 +0100 schrieb Michael Van Canneyt:
On Sun, 11 Nov 2007, Graeme Geldenhuys wrote:
BTW. Graeme, the RTTI controls make much of your MV(*) layers redundant or
at least even more of a breeze. If you want I can send you an article I
wrote a couple of years
On 10/11/2007, Al Boldi [EMAIL PROTECTED] wrote:
You don't need to do this. Eg: create a form without code or non-visual
components, bind BO attributes and components in a single line, and the
MVP will do the rest for you using informations from the model.
Sure, this is great when you are
Graeme Geldenhuys wrote:
On 10/11/2007, Al Boldi [EMAIL PROTECTED] wrote:
You don't need to do this. Eg: create a form without code or
non-visual components, bind BO attributes and components in a single
line, and the MVP will do the rest for you using informations from the
model.
Joao Morais wrote:
Al Boldi wrote:
Oh, I meant the OPF design. Is it possible to isolate the OPF from the
MVP?
Ah yes, they are completely decoupled. You can:
var
VClient: TClient;
VClientList: TPressProxyList;
begin
VClient := TClient.Create;
// or
VClient :=
Al Boldi wrote:
You simply cannot compare a form with three combos
and two grids between dbware and mvp approaches. The former will eat
five groups of data access components, shortcuts to include some
funcionality and a lot of time to configure and debug everything. MVP
will eat five lines of
Al Boldi wrote:
Joao Morais wrote:
I am currently working in an IO-like project with a smarter, faster and
more customizable OPF engine, decoupled frameworks (after all data type
and opf aren't the same thing), no dbware or tdataset dependency, and
the best item: no backward compatibility to
Joao Morais wrote:
Al Boldi wrote:
Joao Morais wrote:
I am currently working in an IO-like project with a smarter, faster and
more customizable OPF engine, decoupled frameworks (after all data type
and opf aren't the same thing), no dbware or tdataset dependency, and
the best item: no
Al Boldi wrote:
You see, trying to create an OPF as a separate layer that
connects to the db via a broker is just broken by design, as this will
introduce a tremendous overhead due to the dual caching problem.
I agree with you that this will cause some overhead, but it is not as
much as you
Joao Morais wrote:
Al Boldi wrote:
You see, trying to create an OPF as a separate layer that
connects to the db via a broker is just broken by design, as this will
introduce a tremendous overhead due to the dual caching problem.
I agree with you that this will cause some overhead, but it
Al Boldi wrote:
do object cache, lazy loading, bulk retrieving, etc.
That's where things become interesting, because you have to figure out how to
interface with your non-OO db, aka relational-DB, without incurring any
duplicate overhead.
Interesting and amusing.
an OPF should not be
Joao Morais wrote:
Al Boldi wrote:
A small overhead do exist actually,
I don't think it's small, unless you mean small apps which deal with
textual data only. For large apps that deal with blobs, the overhead may
bring down your system.
No, small overhead even to applications that
Al Boldi wrote:
Joao Morais wrote:
1. the real bottleneck is in the database
and in the network;
Correct. Let's call this the server-side, which isn't under our control.
Sometimes it is, eg building smart DMLs and smart strategies to retrieve
data, using prepared statements when possible,
Al Boldi wrote:
The problem with this is that, the proper construction of the OOrdb
cache manager is critically dependent on the native access to the dbAPI.
Otherwise you may be hindered by the dual-cache problem.
No, only one cache that references objects. No relational data is
cached, just
Joao Morais wrote:
Al Boldi wrote:
Of course you are not caching any relational data, but you said that you
are using a connection broker to the rdb, which caches the rdb data,
which means extra overhead.
Hmmm... the rdb or the suite that access the rdb caching data means
extra resource
Bogusław Brandys wrote:
What is the current state of InstantObjects port to FreePascal ? Could
we port it totally to use it with Lazarus also ?
I'm interested in it but need a fresh look what was done and what is
missing (especially missing features of fpc/lazarus which are critical
to port
On Thu, 08 Nov 2007 22:51:13 +0100
Bogusław Brandys [EMAIL PROTECTED] wrote:
[...]
Is visual inheritance working now under Lazarus for TForm
descendants ?
Some parts work since a year, but there are some missing parts (e.g.
TFrames, editing Ancestor and Descendant at the same time). Please
On 08/11/2007, Bogusław Brandys [EMAIL PROTECTED] wrote:
What is the current state of InstantObjects port to FreePascal ? Could
we port it totally to use it with Lazarus also ?
Last time I mailed someone on that, development was going although
slowly. That's been quite a few months back so it
Hello,
What is the current state of InstantObjects port to FreePascal ? Could
we port it totally to use it with Lazarus also ?
I'm interested in it but need a fresh look what was done and what is
missing (especially missing features of fpc/lazarus which are critical
to port it completely).
Joao Morais wrote:
I am currently working in an IO-like project with a smarter, faster and
more customizable OPF engine, decoupled frameworks (after all data type
and opf aren't the same thing), no dbware or tdataset dependency, and
the best item: no backward compatibility to bother.
22 matches
Mail list logo
