ofbiz ide

[snowch]

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

[David E Jones]

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

[snowch]

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

[snowch]

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.