Component Manifest

This is actually a double request:-

There is currently no emphatic or reliable way to KNOW( from code rather than the editor) the method names exposed with a component. It would be very helpful if when creating a component if the build automatically created a ‘manifest.json’ in a similar format to that included in plug ins(but obviously with exposed method names rather than ‘command’ names). It would also be technically useful if SOME 4D Commands that can be executed on the ‘host’ database could be executed the other way around within the context of a specific component from the host, This only applies to a very very small subset of commands…particularly ‘METHOD GET NAMES’…but only returning the ‘exposed’ names(There are couple of 4D enviroment commands too where that might be useful such as get database localization and get 4d file).

Secondly it is not always easy to recognise from Code or extract the CONSTANTS that a plug has implemented-these are seen by the editor but they are not programatically identifiable, and where they do exist it is necessary to read the data from an XML file.

As a key example i refer here to 4D IC. The plug has a Manifest that gives all the 4D IC Commands and in the resources whilst there is a document called ‘constants.xlf’ it does not reveal the constants that apply to 4D IC. Therefore when programmatically analysing a piece of code that contains these words it is not possible to automatically know that these resolve to a constant.(So ‘TCP Connection Closed’ for example). Some 3rd Party plugs DO correctly have a Constants.xml which reveals their constants-but not all(although that might just be older ones that have not been updated).

It would be useful to have a way programmatically to obtain the themes, names and values they resolve to of all Constants both internal and for 3rd party plugs/4D Plugs ins(filtering options to get just the constants for a given plug or a given theme would be excellent).-the result could be returned to a collection.

Why would any of the above be of any use? Two specific usage examples-both of which apply to work i am doing:

  1. Creating functionality for users to create ‘code’ in text and execute via ‘process 4D Tags’ where one would want to replace the instance of a constant verb(TCP Connection Closed for example) with the value of that constant prior to executing. and potentially creating a user accessible editor which validates the ‘code’ they write(this is writing executable statements on top of a compiled database).

  2. Analytical Code. I have code in a component which automatically puts my variable declarations into my code(others may be doing different things around the same concepts-i know others would like to be able to get the constants information) and whilst my code can recognise all commands/methods/plug in methods etc it cannot know the meaning of a constant or indeed that it is a constant so cannot know that it does not need declaring, being able to get the full list of constants applicable to the host would improve the viability of deep diving code like this.