Administrator
|
Hi All,
Following Mathieu's question about "OFBiz public API" and the points he already mentioned I decided to create a new thread. I don't know what will happen with the other tread (mostly about removing/replacing component-load.xml). That's not the subject here. Mathieu wrote: <<My broad understanding of what is part of OFBiz public API is: - the plugin mechanism - the data model and data access (Entity Engine) - The ability to call existing services and implement new ones (Service Engine) - the HTTP routing mechanism (Event Handler) - the various configuration files location in “{component}/config” directories.>> I tend to agree with this list. From the top of my head, I'd add (maybe not a the same level and maybe we need to define level/s) 1. Obviously, the Java API ! 2. All things (why not?) supported by XSD files. It includes Entity and Services Engines, not all feature are documented/supported by XSD files though. It also includes component-loader.xsd and ofbiz-component.xsd which are somehow parts of the subject of the other thread 3. OFBiz Gradle tasks I don't know what to say about Groovy scripts which are replacing simple-method services. What else? Jacques |
Hi Jacques,
you've created another mail thread with exactly the same title. The first thread already has answers which would get lost if your new thread would be answered. I propose that you simply answer the first thread directly. Thanks, Michael Am 08.01.20 um 05:38 schrieb Jacques Le Roux: > Hi All, > > Following Mathieu's question about "OFBiz public API" and the points > he already mentioned I decided to create a new thread. > I don't know what will happen with the other tread (mostly about > removing/replacing component-load.xml). That's not the subject here. > > Mathieu wrote: > > <<My broad understanding of what is part of OFBiz public API is: > - the plugin mechanism > - the data model and data access (Entity Engine) > - The ability to call existing services and implement new ones > (Service Engine) > - the HTTP routing mechanism (Event Handler) > - the various configuration files location in > “{component}/config” directories.>> > > I tend to agree with this list. From the top of my head, I'd add > (maybe not a the same level and maybe we need to define level/s) > > 1. Obviously, the Java API ! > 2. All things (why not?) supported by XSD files. > It includes Entity and Services Engines, not all feature are > documented/supported by XSD files though. > It also includes component-loader.xsd and ofbiz-component.xsd which > are somehow parts of the subject of the other thread > 3. OFBiz Gradle tasks > > I don't know what to say about Groovy scripts which are replacing > simple-method services. > > What else? > > Jacques > > smime.p7s (5K) Download Attachment |
Administrator
|
Hi Michael,
I purposely created a new thread because then there were no answers and I wanted to create a new thread not inserted in the initial thread. But because I got issue with my temporary IP address (due to my Internet provider) it was sent later. OK, copying there... Jacques Le 08/01/2020 à 08:32, Michael Brohl a écrit : > Hi Jacques, > > you've created another mail thread with exactly the same title. The first thread already has answers which would get lost if your new thread would > be answered. > > I propose that you simply answer the first thread directly. > > Thanks, > > Michael > > > Am 08.01.20 um 05:38 schrieb Jacques Le Roux: >> Hi All, >> >> Following Mathieu's question about "OFBiz public API" and the points he already mentioned I decided to create a new thread. >> I don't know what will happen with the other tread (mostly about removing/replacing component-load.xml). That's not the subject here. >> >> Mathieu wrote: >> >> <<My broad understanding of what is part of OFBiz public API is: >> - the plugin mechanism >> - the data model and data access (Entity Engine) >> - The ability to call existing services and implement new ones (Service Engine) >> - the HTTP routing mechanism (Event Handler) >> - the various configuration files location in “{component}/config” directories.>> >> >> I tend to agree with this list. From the top of my head, I'd add (maybe not a the same level and maybe we need to define level/s) >> >> 1. Obviously, the Java API ! >> 2. All things (why not?) supported by XSD files. >> It includes Entity and Services Engines, not all feature are documented/supported by XSD files though. >> It also includes component-loader.xsd and ofbiz-component.xsd which are somehow parts of the subject of the other thread >> 3. OFBiz Gradle tasks >> >> I don't know what to say about Groovy scripts which are replacing simple-method services. >> >> What else? >> >> Jacques >> >> > |
Free forum by Nabble | Edit this page |