[Lazarus] Java's Document & Elements model

Kostas Michalopoulos badsector at slashstone.com
Thu Jun 26 14:10:56 CEST 2008


I understand what Document is, as i said i've used it before. It is just one 
of the cases where too much flexibility is as bad (or worse) as no 
flexibility at all. As said in other branches of this thread, this can be ok 
for some cases but in most cases you won't need this extra complexity. 
Nothing is simpler and faster than

DocData:='sometext';
...
TextOut(X, Y, DocData);

for *most* cases, at least. The cases where a simple approach is not 
efficient enough, can have a different implementation. But these are special 
cases you don't see used often in a GUI (as also mentioned, in the whole 
Lazarus IDE only SynEdit could benefit from it and the rest of the GUI would 
only have increased memory/cpu requirements because of the extra 
abstractions to make these things work).

----- Original Message ----- 
From: "Graeme Geldenhuys" <graemeg.lists at gmail.com>
To: "General mailing list" <lazarus at lazarus.freepascal.org>
Sent: Thursday, June 26, 2008 9:01 AM
Subject: Re: [Lazarus] Java's Document & Elements model


> 2008/6/26 Kostas Michalopoulos <badsector at slashstone.com>:
>> I have the feeling that Swing uses this wherever text is used. This is 
>> why
>> you can set a JLabel's caption to "<html>This is <b>some bold test</b> 
>> near
>> an image <img src='foo.png'>" and having it working. This provides a lot 
>> of
>> flexibility. And this is one of the reasons why Swing is *so* slow :-). 
>> In a
>> program of medium size i did in Java which was in Swing, i used this 
>> feature
>> only once. Yet i could do without it if the toolkit was a little more
>> faster.
>>
>> Please don't bring stuff like this to LCL. Or at least make them so 
>> optional
>> one can throw them out completelly if not needed. Anything more elaborate
>> than:
>
> OK, you are understanding the Document Interface incorrectly. But I
> think you are correct about any Swing component that stores text,
> using the Document Interface. The Document Interface is where the
> content (text) is stored, it's nothing visual. Think of the Document
> as a String/TStringList replacement.  It's up the the individual
> component to decide how to paint the content.
>
> The Document Interface has some nice advantages. Because the data/text
> (content) is abstracted, it's easier to implement things like
> Model-View-Controller. Different behavior is very easily added to the
> Document via filters (eg: auto spell check, uppercase all text, filter
> out tab characters or other not printable characters etc..). And these
> filter can be reused with other components supporting the Document
> Interface.  The other really nice benefit is that different components
> can share the same Document. Hence they will always be in sync and
> only have a single instance in memory.  This could be very handy for
> SynEdit if it supports multiple views into the same document (eg:
> Editor window is split in two and each part is viewing different
> sections of the same text document. Edit one and the other is
> automatically in sync.).
>
>
> Regards,
> - Graeme -
>
>
> _______________________________________________
> fpGUI - a cross-platform Free Pascal GUI toolkit
> http://opensoft.homeip.net/fpgui/
> _______________________________________________
> Lazarus mailing list
> Lazarus at lazarus.freepascal.org
> http://www.lazarus.freepascal.org/mailman/listinfo/lazarus 




More information about the Lazarus mailing list