I'm currently creating a basic eclipse plugin prototype of an ofbiz-ide.
The plugin will need to manipulate ofbiz metadata (definitions of components/entity/service/etc). The options: 1) ignore existing ofbiz code base and create separate plugin logic for reading/writing metadata 2) extract the ofbiz code (Start.init(), etc) to read/write the metadata without requiring ofbiz to be running so that the plugin can manipulate the metadata directly using the same code that ofbiz uses for reading the metadata on startup. 3) add an API to ofbiz for manipulating the metadata that the plugin would use while ofbiz is running, e.g. ComponentDef myComponent = OfbizComponent.createComponentDef(String componentName ...); EntityDef myEntity = myComponent.createEntityDef( ... ); etc. option (1) will be the quickest to start with, but will result in a lot of duplicate code if metadata such as autorelations are to be displayed in the ide. Any comments appreciated. Thanks in advance ... Chris |
So the difference between #2 and #3 in your list would be that #2 writes out the XML files directly, while #3 would do so through an API? There is a bit of both right now in the OFBiz framework APIs. The Entity Engine, for example, was at one point used with full round- tripping quite a bit, but using a template to generate the XML. At the time the template was a JSP, which was a pain, so now using FTL would make it a lot easier and cleaner. The general approach in the past was to keep the data in memory in their natural objects, and then write templates to write XML files from those objects. This sort of API to support an IDE plugin or other tools has been discussed a bit, and there are various extensions to the current code you'll probably need. In general you'll want to start with the ofbiz-component.xml files (finding them through the chain of component-load.xml files, starting with the one in framework/base/config). Those files have all of the main resources information in them, though from a tool perspective there is a lot of data to load, and a lot that references other things that you'll want to keep track of for navigation aids and such. In any case, this is something that I (and probably many others) would like to see move forward, so as you run into operations you need to do for getting/setting data in OFBiz, please make some noise on this mailing list and we'll see who can pitch in. -David On Apr 5, 2007, at 4:27 AM, Christopher Snow wrote: > I'm currently creating a basic eclipse plugin prototype of an ofbiz- > ide. > The plugin will need to manipulate ofbiz metadata (definitions of > components/entity/service/etc). The options: > > 1) ignore existing ofbiz code base and create separate plugin logic > for > reading/writing metadata > > 2) extract the ofbiz code (Start.init(), etc) to read/write the > metadata > without requiring ofbiz to be running so that the plugin can > manipulate > the metadata directly using the same code that ofbiz uses for reading > the metadata on startup. > > 3) add an API to ofbiz for manipulating the metadata that the plugin > would use while ofbiz is running, e.g. > > ComponentDef myComponent = > OfbizComponent.createComponentDef(String componentName ...); > EntityDef myEntity = myComponent.createEntityDef( ... ); > etc. > > option (1) will be the quickest to start with, but will result in a > lot > of duplicate code if metadata such as autorelations are to be > displayed > in the ide. > > Any comments appreciated. Thanks in advance ... > > Chris > > smime.p7s (3K) Download Attachment |
On Thu, 2007-04-05 at 09:05 -0400, David E. Jones wrote:
> So the difference between #2 and #3 in your list would be that #2 > writes out the XML files directly, while #3 would do so through an API? Yes, that is what I was thinking. > > There is a bit of both right now in the OFBiz framework APIs. The > Entity Engine, for example, was at one point used with full round- > tripping quite a bit, but using a template to generate the XML. At > the time the template was a JSP, which was a pain, so now using FTL > would make it a lot easier and cleaner. > > The general approach in the past was to keep the data in memory in > their natural objects, and then write templates to write XML files > from those objects. > > This sort of API to support an IDE plugin or other tools has been > discussed a bit, and there are various extensions to the current code > you'll probably need. > > In general you'll want to start with the ofbiz-component.xml files > (finding them through the chain of component-load.xml files, starting > with the one in framework/base/config). Those files have all of the > main resources information in them, though from a tool perspective > there is a lot of data to load, and a lot that references other > things that you'll want to keep track of for navigation aids and such. > > In any case, this is something that I (and probably many others) > would like to see move forward, so as you run into operations you > need to do for getting/setting data in OFBiz, please make some noise > on this mailing list and we'll see who can pitch in. > For option #3, could the API be called using RMI, or would it have to be called in-process? E.g. // list the components in a JFace view - can this be done via RMI? Collection components = ComponentConfig.getAllComponents(); Iterator i = components.iterator(); while (i.hasNext()) { ComponentConfig cc = (ComponentConfig) i.next(); // feed into a JFace viewer } > -David > > > On Apr 5, 2007, at 4:27 AM, Christopher Snow wrote: > > > I'm currently creating a basic eclipse plugin prototype of an ofbiz- > > ide. > > The plugin will need to manipulate ofbiz metadata (definitions of > > components/entity/service/etc). The options: > > > > 1) ignore existing ofbiz code base and create separate plugin logic > > for > > reading/writing metadata > > > > 2) extract the ofbiz code (Start.init(), etc) to read/write the > > metadata > > without requiring ofbiz to be running so that the plugin can > > manipulate > > the metadata directly using the same code that ofbiz uses for reading > > the metadata on startup. > > > > 3) add an API to ofbiz for manipulating the metadata that the plugin > > would use while ofbiz is running, e.g. > > > > ComponentDef myComponent = > > OfbizComponent.createComponentDef(String componentName ...); > > EntityDef myEntity = myComponent.createEntityDef( ... ); > > etc. > > > > option (1) will be the quickest to start with, but will result in a > > lot > > of duplicate code if metadata such as autorelations are to be > > displayed > > in the ide. > > > > Any comments appreciated. Thanks in advance ... > > > > Chris > > > > > |
Any comments on this? anyone?
Thanks in advance ... On 5 Apr 2007, at 15:28, Christopher Snow wrote: > On Thu, 2007-04-05 at 09:05 -0400, David E. Jones wrote: >> So the difference between #2 and #3 in your list would be that #2 >> writes out the XML files directly, while #3 would do so through an >> API? > > Yes, that is what I was thinking. > >> >> There is a bit of both right now in the OFBiz framework APIs. The >> Entity Engine, for example, was at one point used with full round- >> tripping quite a bit, but using a template to generate the XML. At >> the time the template was a JSP, which was a pain, so now using FTL >> would make it a lot easier and cleaner. >> >> The general approach in the past was to keep the data in memory in >> their natural objects, and then write templates to write XML files >> from those objects. >> >> This sort of API to support an IDE plugin or other tools has been >> discussed a bit, and there are various extensions to the current code >> you'll probably need. >> >> In general you'll want to start with the ofbiz-component.xml files >> (finding them through the chain of component-load.xml files, starting >> with the one in framework/base/config). Those files have all of the >> main resources information in them, though from a tool perspective >> there is a lot of data to load, and a lot that references other >> things that you'll want to keep track of for navigation aids and >> such. >> >> In any case, this is something that I (and probably many others) >> would like to see move forward, so as you run into operations you >> need to do for getting/setting data in OFBiz, please make some noise >> on this mailing list and we'll see who can pitch in. >> > > For option #3, could the API be called using RMI, or would it have > to be > called in-process? E.g. > > // list the components in a JFace view - can this be done via RMI? > > Collection components = ComponentConfig.getAllComponents(); > Iterator i = components.iterator(); > while (i.hasNext()) { > ComponentConfig cc = (ComponentConfig) i.next(); > // feed into a JFace viewer > } > >> -David >> >> >> On Apr 5, 2007, at 4:27 AM, Christopher Snow wrote: >> >>> I'm currently creating a basic eclipse plugin prototype of an ofbiz- >>> ide. >>> The plugin will need to manipulate ofbiz metadata (definitions of >>> components/entity/service/etc). The options: >>> >>> 1) ignore existing ofbiz code base and create separate plugin logic >>> for >>> reading/writing metadata >>> >>> 2) extract the ofbiz code (Start.init(), etc) to read/write the >>> metadata >>> without requiring ofbiz to be running so that the plugin can >>> manipulate >>> the metadata directly using the same code that ofbiz uses for >>> reading >>> the metadata on startup. >>> >>> 3) add an API to ofbiz for manipulating the metadata that the plugin >>> would use while ofbiz is running, e.g. >>> >>> ComponentDef myComponent = >>> OfbizComponent.createComponentDef(String componentName ...); >>> EntityDef myEntity = myComponent.createEntityDef( ... ); >>> etc. >>> >>> option (1) will be the quickest to start with, but will result in a >>> lot >>> of duplicate code if metadata such as autorelations are to be >>> displayed >>> in the ide. >>> >>> Any comments appreciated. Thanks in advance ... >>> >>> Chris >>> >>> >> > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
Free forum by Nabble | Edit this page |