[Lazarus] The Data-Model for SynEdit / The Data Model for Lazarus [Code Structure / SourceEdit and SyneEdit]

Martin Friebe lazarus at mfriebe.de
Thu Dec 18 17:51:10 CET 2008


Mattias Gärtner wrote:
> Zitat von Martin Friebe <lazarus at mfriebe.de>:
>
>   
>> [...]
>> But for Lazarus a benefit could be, that such a model could also contain
>> data, on top of the information hold for synEdit. The Lfm (FormDesigner)
>> info could become part of this.
>>     
>
> What has synedit to do with the form designer?
> I'm not sure how synedit should handle the unit concept.
> The lfm is associated with the unit. A unit has a starting file (e.g. unit1.pas)
> and an arbitrary list of include files, plus the po file of the project/package,
> the fpdoc xml file and .res files. Each of them work together and need very
> different code.
>   
The other way round. Synedit has no interest in the other structures. 
But the IDE may have an interest in a structure holding the combined data.

As I said, I have not looked at how this is currently handled. Or if 
there is a common DataStructure for a "pascal Unit". I will inform my 
self (by reading up the source) when I have the time.

There was a discussion between you and Paul on the dev-list:
> doable except one thing. I dont know where to hook before unit save
> > > event. We just dont have it. Moreover unit save is not that plain
> > > as one can expect. At least I expected sourceeditor have something
> > > like Save method. 
> No, because the source editor is only one part of the IDE, so a save
> must be handled one level higher
"saving is not as plain as one can expect"

the Ide will or should have some structure holding the combined data. 
But at current it appears it has to go down to code-tools and/or SynEdit 
(or SynEdit via code-tools) to get the actual Text.

Synedits Data holding structure could either be more integrated into 
that IDE structure (if that is there, I will look for it later). Or It 
could be subclassed, extended and used for a higher purpose than just 
SynEdit.

I will have to look at the current structures to see if that makes any 
sense at all.
I just threw it in as an Idea, seeing if I get some feedback.

>
>   
>> The it would only need an appropriate serialize class to save all of them.
>>
>> This may simplify the current implementation (even so I admit much based
>> on assumption on fragmented knowledge) which has to retrieve this info
>> from the various components. (the need for the source-editor or main ide
>> to fetch the text from SynEdit)
>>     
>
> synedit is the 'lines' view of the sources. Most of the lazarus code don't work
> with lines, but with whole files or absolute positions.
>
>   
So what if SynEdit could have a "model"  (An object exposing it's data) 
in both ways?


This is not a proposal to throw over all the working code. This is first 
to see which directions make sense inside SynEdit, and maybe 
SourceEditor at some stage.
Once that has developed into a more modular form, and gained the ability 
to provide that functionality, it can be reviewed, if any other code 
could benefit from it.

Best regards
Martin







More information about the Lazarus mailing list