Subscribe to this thread
Home - General / All posts - M9 programming basics
vincent

1,972 post(s)
#07-May-20 18:29

Hi,

As always, coming from 8, I don't find what I need in 9. Frustrating, as often. So, 2 questions for starting:

1- Is there any graphical object model somewhere ?

2- Is there dedicaced pages for objects ? For example, a page that list all properties and method for a drawing ? If so, where ? I found this page : http://www.manifold.net/doc/api/scripts-net.html Is that all what is available ? Seems like a novel to read compared to 8.

Thank you.

tjhb
10,094 post(s)
#07-May-20 19:41

Yes, that's it! But despite appearances, it is not nearly as complex as the model for 8.

The main conceptual difference is that the model for 9 is much flatter, and correspondingly, it is much less object-oriented, more oriented towards the functional paradigm.

So there is little reliance on object properties. Now all important properties are driven by metadata, contained in the mfd_* system tables (two per datasource).

For your example, not only is there no list of properties and methods for a drawing: there simply is no drawing object. It's not hiding anywhere--as far as we are concerned, a drawing is just its metadata (and the result of course). You set drawing properties just by changing entries in the system tables. There's nothing else.

While 8 is driven by a hierarchical object model, 9 has an interface model, and the interface is not to objects but to tables.

Correspondingly, while in 8 most of the things we need to do programmatically are exposed as specific methods on objects--and this infrastructure largely reduplicates and reinterprets things we can also do in Manifold 8 SQL (with gaps in both directions, so in SQL we often had to paint in the text of queries to get the job done)--now, in Manifold 9, we just use SQL, and it is made much easier and more elegant to do this from API code. There is no reduplication of functions (beyond what is necessary to make the API work, e.g. in the various Builder functions), and no gaps.

So far, there is no summary map for the API. That would be a good idea--then it would be clear how flat and simple it really is.

tjhb
10,094 post(s)
#07-May-20 19:59

Typo:

(with gaps in both directions, so in SQL scripts we often had to paint in the text of queries to get the job done)

cartomatic

905 post(s)
#08-May-20 08:47

SQL in m9 rocks, one can do a lot with it but apis for rendering maps / drawings / images to rasters would be nice. Or an equivalent of IMS API with output such as WMS, WFS, WPS, vector tiles, etc.


maps made easy - www.cartomatic.pl || www.cartoninjas.net

adamw


10,447 post(s)
#08-May-20 09:22

We are planning to provide the API for rendering together with the web map server in the form usable from a desktop application.

cartomatic

905 post(s)
#08-May-20 10:53

excellent. can't wait :)


maps made easy - www.cartomatic.pl || www.cartoninjas.net

BerndD

162 post(s)
#12-May-20 12:55

Sometimes it's the little snippets in the comments that make me happy .


Organizations that want to adapt to CHANGE are using products that can adapt.

www.yeymaps.io

rk
621 post(s)
#07-May-20 20:37

This reminds me.

Recently while using the SDK of another GIS product I remebered fondly that M8 programming doc has Obtained From section. Utterly useful. The other SDK doc was missing that and it was pain to find how to obtain any of the thousands of types.

I tried to do something like it for M9. The list is short and that is a good thing.

Attachments:
m9_obtained_from.txt

tjhb
10,094 post(s)
#07-May-20 23:22

Riivo,

Do you want to collaborate on a simple API diagram? Graphical. It could go both ways, both down and up ("obtained from"). [So that would be two diagrams.]

I think it would be very worthwhile.

Tim

tjhb
10,094 post(s)
#07-May-20 23:43

Another thing I would be interested in collaborating on (with you and others):

Writing Manifold 9 support (mainly SQL, possibly also the API) for Microsoft Visual Studio Code.

We need syntax highlighting, we need code folding, we need Intellisense.

Now that the language is mature.

I tend to think that these things should be produced externally, i.e. by customising standard third-party tools, rather than by reinventing wheels within the Manifold environment.


Also, we all need to talk again about a curated code repository. With Adam too.


But of course we don't need to solve everything at once!

Major milestone today, product is complete. (I always say this, but now it is.)

vincent

1,972 post(s)
#08-May-20 02:05

Thank you Tim for your explanation about the model. I realize one more time how much everything is table in 9. I'll get use to it. Probably, what I want to do can be done just in one SQL command window, with many queries with Split and Call, a call to scripts. I see programming is less needed in 9.

Major milestone today, product is complete.

I agree with you regarding SQL and exposed functions. But it still lack basic buttons in the UI. A few things to select vectors would be nice. I don't think it is appealing for new user to have an empty UI. I use M8 for more than a decade. It has too many button to click, but I miss them. I hate to have to store tens of keyboard shortcuts in my memory for basics things. What does a disabled person do with Manifold ? If you have only one arm, seriously ? Can you shift-crtl+drag with one hand ?

I hate to invoke Context Help. Many thing in this page should be visible as a button in the UI. Experienced users have to expand their SQL knowledge a lot, learn to program it as newbies... should we have to get our minds full of shortcut ? I use 3 GIS per day, I cannot imagine each of them being made like M9.

tjhb
10,094 post(s)
#08-May-20 05:15

Not much of that has to do with programming.That’s not important, but this...

I use 3 GIS per day, I cannot imagine each of them being made like M9.

What on Earth do you mean by that? You should unpack it. It might be more important than you think.

tjhb
10,094 post(s)
#08-May-20 06:13

I imagine you just meant: the other user interfaces I use are very different from Manifold 9, so learning each one is significant work.

I don't think you meant that the Manifold 9 UI must be rubbish, or should be changed, because it is not like the others.

vincent

1,972 post(s)
#08-May-20 12:25

I just meant that I'm happy not to have to remind 3 sets of keyboard shortcut because of a lack of putton to push to do basics things. M9 is the only in this category.

adamw


10,447 post(s)
#08-May-20 12:58

Not to say that we shouldn't be working to make the UI more intuitive (we should), but as a general note - with a very limited set of exceptions, commands in 9 can be used without shortcuts and that's enforced by our design process. We are first creating a command and put it onto a menu (main or context), and only after we do that we add an optional keyboard shortcut. The exceptions are keyboard shortcuts for commonly used controls - eg, F2 to edit the name of an item in a list or a tree, Ctrl-A to select all items in a list or all text in a text box, Ctrl-Shift-A to unselect all items in a list, etc.

So, (a) if you are trying to recall a command that you used and forgot about, or are otherwise looking for a command, check the menus, and (b) if you ever encounter a command that can only be invoked via a keyboard shortcut and is not on any menu, let us know and we will fix it - we agree that all commands should be represented visually in the UI.

rk
621 post(s)
#08-May-20 07:44

Yes,

I've thought about these things too. I have less idea how to draw a diagram. But I can certainly dive into VS Code language extensions.

tjhb
10,094 post(s)
#08-May-20 16:56

Great. It's an undertaking. I appreciate what we would be getting ourselves into. I think it would be fun, but it also might have some curly moments.

Let's talk about it offline? We can copy Adam in as well.

adamw


10,447 post(s)
#08-May-20 09:44

Regarding the curated code repository - we will reorganize our Github repositories, add a repository for common add-ins, add a starter script or two and start accepting additions and changes from the community. These add-ins will currently be part of the fat ZIP install and if and when we will make changes to our delivery methods (we have a couple of things planned) we will support them as part of the system.

Regarding rich editing features for queries / scripts - we agree that, especially with scripts, it is best for us to concentrate on making it easy to use the object model from a vast array of third-party development tools rather than trying to re-create them. But we would still like to provide some of the most useful features inside Manifold - eg, syntax highlighting and perhaps a very light version of auto-completion / API lookup, for our API only.

tjhb
10,094 post(s)
#08-May-20 16:23

Adam these are wonderful initiatives. I can't say how pleased I am. Thank you.

In any way I can be involved, I will be. Thanks again.

Tim

rk
621 post(s)
#09-May-20 22:17

I copied every class definition under Manifold namespace from Visual Studio (Go To Definition - F12) to files.

With Manifold 8 I turned the textfiles into a table and cleaned it up a bit.

Now I have table of all methods from Manifold namespace. It can be sorted by class name, method name, and return type. The latter gives the Obtained From information.

Attachments:
m8_Release9_API.map

rk
621 post(s)
#11-May-20 20:32

Not yet diagrams, but closer.

Attachments:
obtained_from.txt
obtains.txt

rk
621 post(s)
#11-May-20 21:35

First draft

Attachments:
M9_Object_Model_draft1.png

tjhb
10,094 post(s)
#12-May-20 09:21

Riivo,

I think you're driving things in the right direction, and (again) I would like to collaborate.

To my mind there are opportunities to structure ideas according to their order (a) of importance to the whole picture, (b) of frequency of use, (c) of similarity.

It's even possible that a few things could be left out.

What we want (I think) is a diagram that looks simple to any serious colleague wanting to structure GIS data with a fresh idea.

I think a few structuring categories from outside the API would also help.

Maybe I should start with my own picture rather than words.

tjhb
10,094 post(s)
#13-May-20 03:08

I would would still like to collaborate! (Just say.)

I mentioned external structuring categories. That made hard work of what should be simple:

I meant tables, drawings, images (maybe one or two others). These should structure the picture.

The API structure serves these categories. It does not precede them, should not replace them.

(Added.) And before any of that is purpose. Are we scripting, or writing an external application. Same API, different pictures.

Tim

rk
621 post(s)
#28-Jun-20 17:57

I forgot to publish this earlier. I added hyperlinks to API methods.

Attachments:
obtained_from.html
obtains.html

adamw


10,447 post(s)
#29-Jun-20 15:32

This is quite nice!

Two things:

1. It might make sense to filter out primitive types from both lists.

2. We'll consider adding a short section for each object to the API doc which will describe what the object represents and where it can be obtained from. (Which objects are obtained from the object at hand is clear from the documentation of properties and methods that immediately follows.)

rk
621 post(s)
#29-Jun-20 15:58

I quite like the primitive type sections. Ah, these are all the bool functions, etc.

vincent

1,972 post(s)
#12-May-20 13:20

That is useful ! Good work !

Should have been included with the software.

artlembo


3,400 post(s)
#29-Jun-20 14:31

this looks so much like the way they presented object model for M8, and that was unbelievably helpful. I think this will go a very long way in making it easier to script in M9.

rk
621 post(s)
#29-Jun-20 16:14

I drew it after M8 object model chart.

In M9 much of the *meat* is in Proprerties.

I once started to gather all the possible Property names and value ranges. It is work started, but not in progress.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.