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

[Mattias Gärtner]

Zitat von Martin Friebe <lazarus at mfriebe.de>:

> 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".

There is no single data structure that holds all data of one 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"

yes


> the Ide will or should have some structure holding the combined data.

Sometimes only parts are known.
The glue class is TUnitInfo. It does not hold all data, but with it you get to
everywhere else.


> 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.

Correct. The actual file content is in the codetools. The actual lines as seen
in the source editor is in synedit. The codehelp can hold the xml nodes. The
form designer holds the lfm as component. ...


> 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?

The codetools have that already.
But for speed you have to optimize in one way or the other. You can not have
both fast.


> 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.
>


Mattias