Ofbiz and Ruby on Rails

[cjhowe]

Si and Leon and others,
I just started to look at some Ruby on Rails stuff and
was curious as to your impressions of what aspects of
OFBiz could not be replicated in RoR.  Or is it
possible to get off Java entirely?  How much of OFBiz
could be entirely reused vs. how much would just be
translating templates, etc?

[Leon Torres-2]

Yeah we've been looking into this kind of thing and talking to some people about
Rails and OFBiz.  This is actually a huge topic which might be better discussed
at a conference or something.

- Leon


Chris Howe wrote:
> Si and Leon and others,
> I just started to look at some Ruby on Rails stuff and
> was curious as to your impressions of what aspects of
> OFBiz could not be replicated in RoR.  Or is it
> possible to get off Java entirely?  How much of OFBiz
> could be entirely reused vs. how much would just be
> translating templates, etc?
>

[David E Jones-2]

This is an interesting topic from an infrastructure perspective. It  
sounds like there is some suggestion of incorporating it into the  
framework and moving to it as the standard UI layer tool set...

Has anyone done any conversions of existing OFBiz artifacts to  
compare size and complexity and establish some prospective tools or  
patterns for integration with other pieces and such? Actually, from a  
PoC perspective once could do the same things we did early on with  
OFBiz: define the artifacts and make sure we can define everything we  
want, and then build the engine behind them. In other words we  
defined XSD (or DTD in the early days) files, and some text XML files  
based on them to develop towards and support. These were written to  
replace specific pages, usually picking a more complicated one. For  
example, the first form widget form in OFBiz was the EditProduct form  
with the two columns and such, and that form definition existed even  
before the form widget engine.

This sort of PoC effort would be the first step for anything like this.

-David


On Aug 4, 2006, at 6:45 PM, Leon Torres wrote:

> Yeah we've been looking into this kind of thing and talking to some  
> people about Rails and OFBiz.  This is actually a huge topic which  
> might be better discussed at a conference or something.
>
> - Leon
>
>
> Chris Howe wrote:
>> Si and Leon and others,
>> I just started to look at some Ruby on Rails stuff and
>> was curious as to your impressions of what aspects of
>> OFBiz could not be replicated in RoR.  Or is it
>> possible to get off Java entirely?  How much of OFBiz
>> could be entirely reused vs. how much would just be
>> translating templates, etc?

[Alex Caudill]

The way I see it, a set of Ruby on Rails models which interface with OFBiz
via SOAP seems like the path of least resistance at this particular
moment. My intention was to use Rails to implement a much less complex,
user-friendly web-facing
application, using a subdomain-as-account-key model to handle multi-tenancy,
while still managing backoffice operations with OFBiz itself.

[Si Chen-2]

and I'd just like to get more people involved in OFBiz, so if you'd  
like to use Ruby, that's great too :)

I do think SOAP integration is the best way to go, by the way.

On Aug 4, 2006, at 5:59 PM, Alex Caudill wrote:

> The way I see it, a set of Ruby on Rails models which interface  
> with OFBiz
> via SOAP seems like the path of least resistance at this particular
> moment. My intention was to use Rails to implement a much less  
> complex,
> user-friendly web-facing
> application, using a subdomain-as-account-key model to handle multi-
> tenancy,
> while still managing backoffice operations with OFBiz itself.

[Alex Caudill]

http://jruby.codehaus.org/Milestones

It seems that JRuby is capable of running Rails in production mode. I'll try
to come up with some PoC for it sometime this week.

[cjhowe]

Judging by the responses I think I misunderstand RoR.
In my newly introduced mind I see RoR being of the
same kind of animal as the OFBiz framework.  In that
mindset it would be a replacement of sorts.

I was trying to weigh whether it would be easier to
expand OFBiz's UI capabilities with AJAX and getting a
consensus on what an OFBiz template should and should
not include (ie OFBiz standards) for modularity sake
and what not or to rewrite OFBiz's busines logic in
RoR.  

The majority of the actual usefulness that I saw with
RoR was the way it "consumes" data be it from a local
database or a webservice.

So, my question was more towards what is the ofbiz
framework giving us that Ror can't or doesn't easily.

And what benefits does RoR offer that can/can't be
replicated in OFBiz?

--- David E Jones <[hidden email]>
wrote:

>
> This is an interesting topic from an infrastructure
> perspective. It  
> sounds like there is some suggestion of
> incorporating it into the  
> framework and moving to it as the standard UI layer
> tool set...
>
> Has anyone done any conversions of existing OFBiz
> artifacts to  
> compare size and complexity and establish some
> prospective tools or  
> patterns for integration with other pieces and such?
> Actually, from a  
> PoC perspective once could do the same things we did
> early on with  
> OFBiz: define the artifacts and make sure we can
> define everything we  
> want, and then build the engine behind them. In
> other words we  
> defined XSD (or DTD in the early days) files, and
> some text XML files  
> based on them to develop towards and support. These
> were written to  
> replace specific pages, usually picking a more
> complicated one. For  
> example, the first form widget form in OFBiz was the
> EditProduct form  
> with the two columns and such, and that form
> definition existed even  
> before the form widget engine.
>
> This sort of PoC effort would be the first step for
> anything like this.
>
> -David
>
>
> On Aug 4, 2006, at 6:45 PM, Leon Torres wrote:
>
> > Yeah we've been looking into this kind of thing
> and talking to some  
> > people about Rails and OFBiz.  This is actually a
> huge topic which  
> > might be better discussed at a conference or
> something.
> >
> > - Leon
> >
> >
> > Chris Howe wrote:
> >> Si and Leon and others,
> >> I just started to look at some Ruby on Rails
> stuff and
> >> was curious as to your impressions of what
> aspects of
> >> OFBiz could not be replicated in RoR.  Or is it
> >> possible to get off Java entirely?  How much of
> OFBiz
> >> could be entirely reused vs. how much would just
> be
> >> translating templates, etc?
>
>

[BJ Freeman]

Not sure why as discussion about changing java to RoR.
that is the same as saying change compiere to ofbiz.

That would be one big undertaking, as it is now, there are enough people
doing testing ofbiz.
That I would think would be a more constructive discussion.


Chris Howe sent the following on 8/4/2006 8:30 PM:

> Judging by the responses I think I misunderstand RoR.
> In my newly introduced mind I see RoR being of the
> same kind of animal as the OFBiz framework.  In that
> mindset it would be a replacement of sorts.
>
> I was trying to weigh whether it would be easier to
> expand OFBiz's UI capabilities with AJAX and getting a
> consensus on what an OFBiz template should and should
> not include (ie OFBiz standards) for modularity sake
> and what not or to rewrite OFBiz's busines logic in
> RoR.  
>
> The majority of the actual usefulness that I saw with
> RoR was the way it "consumes" data be it from a local
> database or a webservice.
>
> So, my question was more towards what is the ofbiz
> framework giving us that Ror can't or doesn't easily.
>
> And what benefits does RoR offer that can/can't be
> replicated in OFBiz?
>
> --- David E Jones <[hidden email]>
> wrote:
>
>> This is an interesting topic from an infrastructure
>> perspective. It  
>> sounds like there is some suggestion of
>> incorporating it into the  
>> framework and moving to it as the standard UI layer
>> tool set...
>>
>> Has anyone done any conversions of existing OFBiz
>> artifacts to  
>> compare size and complexity and establish some
>> prospective tools or  
>> patterns for integration with other pieces and such?
>> Actually, from a  
>> PoC perspective once could do the same things we did
>> early on with  
>> OFBiz: define the artifacts and make sure we can
>> define everything we  
>> want, and then build the engine behind them. In
>> other words we  
>> defined XSD (or DTD in the early days) files, and
>> some text XML files  
>> based on them to develop towards and support. These
>> were written to  
>> replace specific pages, usually picking a more
>> complicated one. For  
>> example, the first form widget form in OFBiz was the
>> EditProduct form  
>> with the two columns and such, and that form
>> definition existed even  
>> before the form widget engine.
>>
>> This sort of PoC effort would be the first step for
>> anything like this.
>>
>> -David
>>
>>
>> On Aug 4, 2006, at 6:45 PM, Leon Torres wrote:
>>
>>> Yeah we've been looking into this kind of thing
>> and talking to some  
>>> people about Rails and OFBiz.  This is actually a
>> huge topic which  
>>> might be better discussed at a conference or
>> something.
>>> - Leon
>>>
>>>
>>> Chris Howe wrote:
>>>> Si and Leon and others,
>>>> I just started to look at some Ruby on Rails
>> stuff and
>>>> was curious as to your impressions of what
>> aspects of
>>>> OFBiz could not be replicated in RoR.  Or is it
>>>> possible to get off Java entirely?  How much of
>> OFBiz
>>>> could be entirely reused vs. how much would just
>> be
>>>> translating templates, etc?
>>
>
>

[Ryan Warnick]

For web-facing applications, I really like JSON.

Ryan

> -----Original Message-----
> From: Si Chen [mailto:[hidden email]]
> Sent: Friday, August 04, 2006 7:33 PM
> To: [hidden email]
> Subject: Re: Ofbiz and Ruby on Rails
>
> and I'd just like to get more people involved in OFBiz, so if you'd
> like to use Ruby, that's great too :)
>
> I do think SOAP integration is the best way to go, by the way.
>
> On Aug 4, 2006, at 5:59 PM, Alex Caudill wrote:
>
> > The way I see it, a set of Ruby on Rails models which
> interface with
> > OFBiz via SOAP seems like the path of least resistance at this
> > particular moment. My intention was to use Rails to
> implement a much
> > less complex, user-friendly web-facing application, using a
> > subdomain-as-account-key model to handle multi- tenancy,
> while still
> > managing backoffice operations with OFBiz itself.

[cjhowe]

My curiosity is that there are several reasons why
various people are attracted to this project
1) The data model (data layer)
2) The framework (database manipulation, etc)
3) The applications (business logic)
4) The widgets (presentation layer)
5) and so on

The data model is what it is and can be used in any
framework.

The time consuming part of the business logic doesn't
come from the lines of code, but the thought process.
Since the thought process is fairly straight forward,
rewriting the business logic in another language would
be a fairly small project.

Half of the presentation layer (at least on the
backend) is created automatically with RoR's scaffold.
 So, that's a fairly small project to translate with
huge UI benefits compared to the OFBiz community
project's current UI.

The discussion I'm after isn't so much about changing
Java to RoR, but hypothetically what does one lose by
leaving Java for RoR and can the apparent benefits of
RoR be obtained in a Java based OFBiz?

If the answer is that you don't lose much by switching
to RoR and the benefits of RoR cannot be easily
obtained in a Java based OFBiz, then the question
should be about changing Java to RoR.  There seems to
be a lot of interest in improving the UI in OFBiz, but
not so much through the tools that currently exist.
If you don't lose much with RoR on functionality, why
reinvent the wheel, just throw on some new racing
slicks ;)

--- BJ Freeman <[hidden email]> wrote:

> Not sure why as discussion about changing java to
> RoR.
> that is the same as saying change compiere to ofbiz.
>
> That would be one big undertaking, as it is now,
> there are enough people
> doing testing ofbiz.
> That I would think would be a more constructive
> discussion.
>
>
> Chris Howe sent the following on 8/4/2006 8:30 PM:
> > Judging by the responses I think I misunderstand
> RoR.
> > In my newly introduced mind I see RoR being of the
> > same kind of animal as the OFBiz framework.  In
> that
> > mindset it would be a replacement of sorts.
> >
> > I was trying to weigh whether it would be easier
> to
> > expand OFBiz's UI capabilities with AJAX and
> getting a
> > consensus on what an OFBiz template should and
> should
> > not include (ie OFBiz standards) for modularity
> sake
> > and what not or to rewrite OFBiz's busines logic
> in
> > RoR.  
> >
> > The majority of the actual usefulness that I saw
> with
> > RoR was the way it "consumes" data be it from a
> local
> > database or a webservice.
> >
> > So, my question was more towards what is the ofbiz
> > framework giving us that Ror can't or doesn't
> easily.
> >
> > And what benefits does RoR offer that can/can't be
> > replicated in OFBiz?
> >
> > --- David E Jones <[hidden email]>
> > wrote:
> >
> >> This is an interesting topic from an
> infrastructure
> >> perspective. It  
> >> sounds like there is some suggestion of
> >> incorporating it into the  
> >> framework and moving to it as the standard UI
> layer
> >> tool set...
> >>
> >> Has anyone done any conversions of existing OFBiz
> >> artifacts to  
> >> compare size and complexity and establish some
> >> prospective tools or  
> >> patterns for integration with other pieces and
> such?
> >> Actually, from a  
> >> PoC perspective once could do the same things we
> did
> >> early on with  
> >> OFBiz: define the artifacts and make sure we can
> >> define everything we  
> >> want, and then build the engine behind them. In
> >> other words we  
> >> defined XSD (or DTD in the early days) files, and
> >> some text XML files  
> >> based on them to develop towards and support.
> These
> >> were written to  
> >> replace specific pages, usually picking a more
> >> complicated one. For  
> >> example, the first form widget form in OFBiz was
> the
> >> EditProduct form  
> >> with the two columns and such, and that form
> >> definition existed even  
> >> before the form widget engine.
> >>
> >> This sort of PoC effort would be the first step
> for
> >> anything like this.
> >>
> >> -David
> >>
> >>
> >> On Aug 4, 2006, at 6:45 PM, Leon Torres wrote:
> >>
> >>> Yeah we've been looking into this kind of thing
> >> and talking to some  
> >>> people about Rails and OFBiz.  This is actually
> a
> >> huge topic which  
> >>> might be better discussed at a conference or
> >> something.
> >>> - Leon
> >>>
> >>>
> >>> Chris Howe wrote:
> >>>> Si and Leon and others,
> >>>> I just started to look at some Ruby on Rails
> >> stuff and
> >>>> was curious as to your impressions of what
> >> aspects of
> >>>> OFBiz could not be replicated in RoR.  Or is it
> >>>> possible to get off Java entirely?  How much of
> >> OFBiz
> >>>> could be entirely reused vs. how much would
> just
> >> be
> >>>> translating templates, etc?
> >>
> >
> >
>

[Ryan Warnick]

I've spent some time playing with RoR and it seems like the real value of
RoR is its ability to consume an "entity" definition and some UI artifacts
and then generate database tables, CRUD methods, and a web-based UI.  So,
based on my experience, I would tend to agree that there is a lot of overlap
with ofbiz functionality (entity engine, widgets, etc.).  On the other hand,
if the desire is to make Ruby (not RoR) available in ofbiz for implementing
services, etc., then that is a different story.

We have implemented several desktop-like applications by exposing ofbiz
services over JSON so that they can be consumed by an AJAX UI framework like
Dojo, GWT, Bindows, etc.  The real benefit here is being able to take entity
engine data structures maps and lists of maps and directly consume them on
the client side with very little glue code.  We also get the same benefit
going the other way (calling services).

Ryan

> -----Original Message-----
> From: Chris Howe [mailto:[hidden email]]
> Sent: Friday, August 04, 2006 9:31 PM
> To: [hidden email]
> Subject: Re: Ofbiz and Ruby on Rails
>
> Judging by the responses I think I misunderstand RoR.
> In my newly introduced mind I see RoR being of the same kind
> of animal as the OFBiz framework.  In that mindset it would
> be a replacement of sorts.
>
> I was trying to weigh whether it would be easier to expand
> OFBiz's UI capabilities with AJAX and getting a consensus on
> what an OFBiz template should and should not include (ie
> OFBiz standards) for modularity sake and what not or to
> rewrite OFBiz's busines logic in RoR.  
>
> The majority of the actual usefulness that I saw with RoR was
> the way it "consumes" data be it from a local database or a
> webservice.
>
> So, my question was more towards what is the ofbiz framework
> giving us that Ror can't or doesn't easily.
>
> And what benefits does RoR offer that can/can't be replicated
> in OFBiz?
>
> --- David E Jones <[hidden email]>
> wrote:
>
> >
> > This is an interesting topic from an infrastructure perspective. It
> > sounds like there is some suggestion of incorporating it into the
> > framework and moving to it as the standard UI layer tool set...
> >
> > Has anyone done any conversions of existing OFBiz artifacts
> to compare
> > size and complexity and establish some prospective tools or
> patterns
> > for integration with other pieces and such?
> > Actually, from a
> > PoC perspective once could do the same things we did early on with
> > OFBiz: define the artifacts and make sure we can define
> everything we
> > want, and then build the engine behind them. In other words
> we defined
> > XSD (or DTD in the early days) files, and some text XML
> files based on
> > them to develop towards and support. These were written to replace
> > specific pages, usually picking a more complicated one. For
> example,
> > the first form widget form in OFBiz was the EditProduct
> form with the
> > two columns and such, and that form definition existed even
> before the
> > form widget engine.
> >
> > This sort of PoC effort would be the first step for anything like
> > this.
> >
> > -David
> >
> >
> > On Aug 4, 2006, at 6:45 PM, Leon Torres wrote:
> >
> > > Yeah we've been looking into this kind of thing
> > and talking to some
> > > people about Rails and OFBiz.  This is actually a
> > huge topic which
> > > might be better discussed at a conference or
> > something.
> > >
> > > - Leon
> > >
> > >
> > > Chris Howe wrote:
> > >> Si and Leon and others,
> > >> I just started to look at some Ruby on Rails
> > stuff and
> > >> was curious as to your impressions of what
> > aspects of
> > >> OFBiz could not be replicated in RoR.  Or is it possible
> to get off
> > >> Java entirely?  How much of
> > OFBiz
> > >> could be entirely reused vs. how much would just
> > be
> > >> translating templates, etc?
> >
> >
>
>

[BJ Freeman]

My curiosity is if you feel all this is wrong, which is the impression i
get from your communication here, why not go off and do your own thing.

Chris Howe sent the following on 8/4/2006 9:40 PM:

> My curiosity is that there are several reasons why
> various people are attracted to this project
> 1) The data model (data layer)
> 2) The framework (database manipulation, etc)
> 3) The applications (business logic)
> 4) The widgets (presentation layer)
> 5) and so on
>
> The data model is what it is and can be used in any
> framework.
>
> The time consuming part of the business logic doesn't
> come from the lines of code, but the thought process.
> Since the thought process is fairly straight forward,
> rewriting the business logic in another language would
> be a fairly small project.
>
> Half of the presentation layer (at least on the
> backend) is created automatically with RoR's scaffold.
>  So, that's a fairly small project to translate with
> huge UI benefits compared to the OFBiz community
> project's current UI.
>
> The discussion I'm after isn't so much about changing
> Java to RoR, but hypothetically what does one lose by
> leaving Java for RoR and can the apparent benefits of
> RoR be obtained in a Java based OFBiz?
>
> If the answer is that you don't lose much by switching
> to RoR and the benefits of RoR cannot be easily
> obtained in a Java based OFBiz, then the question
> should be about changing Java to RoR.  There seems to
> be a lot of interest in improving the UI in OFBiz, but
> not so much through the tools that currently exist.
> If you don't lose much with RoR on functionality, why
> reinvent the wheel, just throw on some new racing
> slicks ;)
>
> --- BJ Freeman <[hidden email]> wrote:
>
>> Not sure why as discussion about changing java to
>> RoR.
>> that is the same as saying change compiere to ofbiz.
>>
>> That would be one big undertaking, as it is now,
>> there are enough people
>> doing testing ofbiz.
>> That I would think would be a more constructive
>> discussion.
>>
>>
>> Chris Howe sent the following on 8/4/2006 8:30 PM:
>>> Judging by the responses I think I misunderstand
>> RoR.
>>> In my newly introduced mind I see RoR being of the
>>> same kind of animal as the OFBiz framework.  In
>> that
>>> mindset it would be a replacement of sorts.
>>>
>>> I was trying to weigh whether it would be easier
>> to
>>> expand OFBiz's UI capabilities with AJAX and
>> getting a
>>> consensus on what an OFBiz template should and
>> should
>>> not include (ie OFBiz standards) for modularity
>> sake
>>> and what not or to rewrite OFBiz's busines logic
>> in
>>> RoR.  
>>>
>>> The majority of the actual usefulness that I saw
>> with
>>> RoR was the way it "consumes" data be it from a
>> local
>>> database or a webservice.
>>>
>>> So, my question was more towards what is the ofbiz
>>> framework giving us that Ror can't or doesn't
>> easily.
>>> And what benefits does RoR offer that can/can't be
>>> replicated in OFBiz?
>>>
>>> --- David E Jones <[hidden email]>
>>> wrote:
>>>
>>>> This is an interesting topic from an
>> infrastructure
>>>> perspective. It  
>>>> sounds like there is some suggestion of
>>>> incorporating it into the  
>>>> framework and moving to it as the standard UI
>> layer
>>>> tool set...
>>>>
>>>> Has anyone done any conversions of existing OFBiz
>>>> artifacts to  
>>>> compare size and complexity and establish some
>>>> prospective tools or  
>>>> patterns for integration with other pieces and
>> such?
>>>> Actually, from a  
>>>> PoC perspective once could do the same things we
>> did
>>>> early on with  
>>>> OFBiz: define the artifacts and make sure we can
>>>> define everything we  
>>>> want, and then build the engine behind them. In
>>>> other words we  
>>>> defined XSD (or DTD in the early days) files, and
>>>> some text XML files  
>>>> based on them to develop towards and support.
>> These
>>>> were written to  
>>>> replace specific pages, usually picking a more
>>>> complicated one. For  
>>>> example, the first form widget form in OFBiz was
>> the
>>>> EditProduct form  
>>>> with the two columns and such, and that form
>>>> definition existed even  
>>>> before the form widget engine.
>>>>
>>>> This sort of PoC effort would be the first step
>> for
>>>> anything like this.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Aug 4, 2006, at 6:45 PM, Leon Torres wrote:
>>>>
>>>>> Yeah we've been looking into this kind of thing
>>>> and talking to some  
>>>>> people about Rails and OFBiz.  This is actually
>> a
>>>> huge topic which  
>>>>> might be better discussed at a conference or
>>>> something.
>>>>> - Leon
>>>>>
>>>>>
>>>>> Chris Howe wrote:
>>>>>> Si and Leon and others,
>>>>>> I just started to look at some Ruby on Rails
>>>> stuff and
>>>>>> was curious as to your impressions of what
>>>> aspects of
>>>>>> OFBiz could not be replicated in RoR.  Or is it
>>>>>> possible to get off Java entirely?  How much of
>>>> OFBiz
>>>>>> could be entirely reused vs. how much would
>> just
>>>> be
>>>>>> translating templates, etc?
>>>
>
>

[cjhowe]

Wow, I didn't say it was wrong.  Where'd that come
from?

--- BJ Freeman <[hidden email]> wrote:

> My curiosity is if you feel all this is wrong, which
> is the impression i
> get from your communication here, why not go off and
> do your own thing.
>
> Chris Howe sent the following on 8/4/2006 9:40 PM:
> > My curiosity is that there are several reasons why
> > various people are attracted to this project
> > 1) The data model (data layer)
> > 2) The framework (database manipulation, etc)
> > 3) The applications (business logic)
> > 4) The widgets (presentation layer)
> > 5) and so on
> >
> > The data model is what it is and can be used in
> any
> > framework.
> >
> > The time consuming part of the business logic
> doesn't
> > come from the lines of code, but the thought
> process.
> > Since the thought process is fairly straight
> forward,
> > rewriting the business logic in another language
> would
> > be a fairly small project.
> >
> > Half of the presentation layer (at least on the
> > backend) is created automatically with RoR's
> scaffold.
> >  So, that's a fairly small project to translate
> with
> > huge UI benefits compared to the OFBiz community
> > project's current UI.
> >
> > The discussion I'm after isn't so much about
> changing
> > Java to RoR, but hypothetically what does one lose
> by
> > leaving Java for RoR and can the apparent benefits
> of
> > RoR be obtained in a Java based OFBiz?
> >
> > If the answer is that you don't lose much by
> switching
> > to RoR and the benefits of RoR cannot be easily
> > obtained in a Java based OFBiz, then the question
> > should be about changing Java to RoR.  There seems
> to
> > be a lot of interest in improving the UI in OFBiz,
> but
> > not so much through the tools that currently
> exist.
> > If you don't lose much with RoR on functionality,
> why
> > reinvent the wheel, just throw on some new racing
> > slicks ;)
> >
> > --- BJ Freeman <[hidden email]> wrote:
> >
> >> Not sure why as discussion about changing java to
> >> RoR.
> >> that is the same as saying change compiere to
> ofbiz.
> >>
> >> That would be one big undertaking, as it is now,
> >> there are enough people
> >> doing testing ofbiz.
> >> That I would think would be a more constructive
> >> discussion.
> >>
> >>
> >> Chris Howe sent the following on 8/4/2006 8:30
> PM:
> >>> Judging by the responses I think I misunderstand
> >> RoR.
> >>> In my newly introduced mind I see RoR being of
> the
> >>> same kind of animal as the OFBiz framework.  In
> >> that
> >>> mindset it would be a replacement of sorts.
> >>>
> >>> I was trying to weigh whether it would be easier
> >> to
> >>> expand OFBiz's UI capabilities with AJAX and
> >> getting a
> >>> consensus on what an OFBiz template should and
> >> should
> >>> not include (ie OFBiz standards) for modularity
> >> sake
> >>> and what not or to rewrite OFBiz's busines logic
> >> in
> >>> RoR.  
> >>>
> >>> The majority of the actual usefulness that I saw
> >> with
> >>> RoR was the way it "consumes" data be it from a
> >> local
> >>> database or a webservice.
> >>>
> >>> So, my question was more towards what is the
> ofbiz
> >>> framework giving us that Ror can't or doesn't
> >> easily.
> >>> And what benefits does RoR offer that can/can't
> be
> >>> replicated in OFBiz?
> >>>
> >>> --- David E Jones
> <[hidden email]>
> >>> wrote:
> >>>
> >>>> This is an interesting topic from an
> >> infrastructure
> >>>> perspective. It  
> >>>> sounds like there is some suggestion of
> >>>> incorporating it into the  
> >>>> framework and moving to it as the standard UI
> >> layer
> >>>> tool set...
> >>>>
> >>>> Has anyone done any conversions of existing
> OFBiz
> >>>> artifacts to  
> >>>> compare size and complexity and establish some
> >>>> prospective tools or  
> >>>> patterns for integration with other pieces and
> >> such?
> >>>> Actually, from a  
> >>>> PoC perspective once could do the same things
> we
> >> did
> >>>> early on with  
> >>>> OFBiz: define the artifacts and make sure we
> can
> >>>> define everything we  
> >>>> want, and then build the engine behind them. In
> >>>> other words we  
> >>>> defined XSD (or DTD in the early days) files,
> and
> >>>> some text XML files  
> >>>> based on them to develop towards and support.
> >> These
> >>>> were written to  
> >>>> replace specific pages, usually picking a more
> >>>> complicated one. For  
> >>>> example, the first form widget form in OFBiz
> was
> >> the
> >>>> EditProduct form  
> >>>> with the two columns and such, and that form
> >>>> definition existed even  
> >>>> before the form widget engine.
> >>>>
> >>>> This sort of PoC effort would be the first step
> >> for
> >>>> anything like this.
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>> On Aug 4, 2006, at 6:45 PM, Leon Torres wrote:
> >>>>
> >>>>> Yeah we've been looking into this kind of
> thing
> >>>> and talking to some  
> >>>>> people about Rails and OFBiz.  This is
> actually
> >> a
> >>>> huge topic which  
> >>>>> might be better discussed at a conference or
> >>>> something.
> >>>>> - Leon
> >>>>>
> >>>>>
> >>>>> Chris Howe wrote:
> >>>>>> Si and Leon and others,
> >>>>>> I just started to look at some Ruby on Rails
> >>>> stuff and
> >>>>>> was curious as to your impressions of what
> >>>> aspects of
> >>>>>> OFBiz could not be replicated in RoR.  Or is
> it
> >>>>>> possible to get off Java entirely?  How much
> of
> >>>> OFBiz
> >>>>>> could be entirely reused vs. how much would
> >> just
> >>>> be
> >>>>>> translating templates, etc?
> >>>
> >
> >
>

[David E Jones-2]

It's an interesting thought, but keep in mind we're talking about a  
few hundred thousand lines of user interface level artifacts in OFBiz.

If it is significantly more efficient, and I mean really significant  
proven by moving a couple of areas over and comparing the code  
complexity between the two, then it might be a good way to go. To be  
honest, this would surprise me somewhat, but such surprises are often  
eventually good ones. In a way I'd like to see this done because I  
think this sort of efficiency is an area where OFBiz shines a bit  
more than you seem to be guessing... ;)

But being "a fairly small project"... rewriting this much business  
logic is not easy in any language. It would be a major undertaking  
requiring tens of thousands of hours of effort by careful and fairly  
skilled developers.

-David


On Aug 4, 2006, at 10:40 PM, Chris Howe wrote:

> My curiosity is that there are several reasons why
> various people are attracted to this project
> 1) The data model (data layer)
> 2) The framework (database manipulation, etc)
> 3) The applications (business logic)
> 4) The widgets (presentation layer)
> 5) and so on
>
> The data model is what it is and can be used in any
> framework.
>
> The time consuming part of the business logic doesn't
> come from the lines of code, but the thought process.
> Since the thought process is fairly straight forward,
> rewriting the business logic in another language would
> be a fairly small project.
>
> Half of the presentation layer (at least on the
> backend) is created automatically with RoR's scaffold.
>  So, that's a fairly small project to translate with
> huge UI benefits compared to the OFBiz community
> project's current UI.
>
> The discussion I'm after isn't so much about changing
> Java to RoR, but hypothetically what does one lose by
> leaving Java for RoR and can the apparent benefits of
> RoR be obtained in a Java based OFBiz?
>
> If the answer is that you don't lose much by switching
> to RoR and the benefits of RoR cannot be easily
> obtained in a Java based OFBiz, then the question
> should be about changing Java to RoR.  There seems to
> be a lot of interest in improving the UI in OFBiz, but
> not so much through the tools that currently exist.
> If you don't lose much with RoR on functionality, why
> reinvent the wheel, just throw on some new racing
> slicks ;)
>
> --- BJ Freeman <[hidden email]> wrote:
>
>> Not sure why as discussion about changing java to
>> RoR.
>> that is the same as saying change compiere to ofbiz.
>>
>> That would be one big undertaking, as it is now,
>> there are enough people
>> doing testing ofbiz.
>> That I would think would be a more constructive
>> discussion.
>>
>>
>> Chris Howe sent the following on 8/4/2006 8:30 PM:
>>> Judging by the responses I think I misunderstand
>> RoR.
>>> In my newly introduced mind I see RoR being of the
>>> same kind of animal as the OFBiz framework.  In
>> that
>>> mindset it would be a replacement of sorts.
>>>
>>> I was trying to weigh whether it would be easier
>> to
>>> expand OFBiz's UI capabilities with AJAX and
>> getting a
>>> consensus on what an OFBiz template should and
>> should
>>> not include (ie OFBiz standards) for modularity
>> sake
>>> and what not or to rewrite OFBiz's busines logic
>> in
>>> RoR.
>>>
>>> The majority of the actual usefulness that I saw
>> with
>>> RoR was the way it "consumes" data be it from a
>> local
>>> database or a webservice.
>>>
>>> So, my question was more towards what is the ofbiz
>>> framework giving us that Ror can't or doesn't
>> easily.
>>>
>>> And what benefits does RoR offer that can/can't be
>>> replicated in OFBiz?
>>>
>>> --- David E Jones <[hidden email]>
>>> wrote:
>>>
>>>> This is an interesting topic from an
>> infrastructure
>>>> perspective. It
>>>> sounds like there is some suggestion of
>>>> incorporating it into the
>>>> framework and moving to it as the standard UI
>> layer
>>>> tool set...
>>>>
>>>> Has anyone done any conversions of existing OFBiz
>>>> artifacts to
>>>> compare size and complexity and establish some
>>>> prospective tools or
>>>> patterns for integration with other pieces and
>> such?
>>>> Actually, from a
>>>> PoC perspective once could do the same things we
>> did
>>>> early on with
>>>> OFBiz: define the artifacts and make sure we can
>>>> define everything we
>>>> want, and then build the engine behind them. In
>>>> other words we
>>>> defined XSD (or DTD in the early days) files, and
>>>> some text XML files
>>>> based on them to develop towards and support.
>> These
>>>> were written to
>>>> replace specific pages, usually picking a more
>>>> complicated one. For
>>>> example, the first form widget form in OFBiz was
>> the
>>>> EditProduct form
>>>> with the two columns and such, and that form
>>>> definition existed even
>>>> before the form widget engine.
>>>>
>>>> This sort of PoC effort would be the first step
>> for
>>>> anything like this.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Aug 4, 2006, at 6:45 PM, Leon Torres wrote:
>>>>
>>>>> Yeah we've been looking into this kind of thing
>>>> and talking to some
>>>>> people about Rails and OFBiz.  This is actually
>> a
>>>> huge topic which
>>>>> might be better discussed at a conference or
>>>> something.
>>>>> - Leon
>>>>>
>>>>>
>>>>> Chris Howe wrote:
>>>>>> Si and Leon and others,
>>>>>> I just started to look at some Ruby on Rails
>>>> stuff and
>>>>>> was curious as to your impressions of what
>>>> aspects of
>>>>>> OFBiz could not be replicated in RoR.  Or is it
>>>>>> possible to get off Java entirely?  How much of
>>>> OFBiz
>>>>>> could be entirely reused vs. how much would
>> just
>>>> be
>>>>>> translating templates, etc?
>>>>
>>>
>>>
>>
>

[cjhowe]

I'm not saying that OFBiz is a small project or that
the original implementation weren't dificult or that
it the original implementation didn't take very
knowledgable people.

But once you know that a certain sequence of business
logic works, you can copy it into another language
fairly quickly.

If you take the catalog manager for example.  There
are 107 views. That probably equates to what? 5, 10,
15000 lines of code?  To repeat their functionality,
97 of them are handled by the scaffold in RoR.

That's removing every screen that's called and every
template or widget that that screen calls with 97
lines of code (itty bitty lines too).  Different
application's milage will vary of course.


--- "David E. Jones" <[hidden email]>
wrote:

>
> It's an interesting thought, but keep in mind we're
> talking about a  
> few hundred thousand lines of user interface level
> artifacts in OFBiz.
>
> If it is significantly more efficient, and I mean
> really significant  
> proven by moving a couple of areas over and
> comparing the code  
> complexity between the two, then it might be a good
> way to go. To be  
> honest, this would surprise me somewhat, but such
> surprises are often  
> eventually good ones. In a way I'd like to see this
> done because I  
> think this sort of efficiency is an area where OFBiz
> shines a bit  
> more than you seem to be guessing... ;)
>
> But being "a fairly small project"... rewriting this
> much business  
> logic is not easy in any language. It would be a
> major undertaking  
> requiring tens of thousands of hours of effort by
> careful and fairly  
> skilled developers.
>
> -David
>
>
> On Aug 4, 2006, at 10:40 PM, Chris Howe wrote:
>
> > My curiosity is that there are several reasons why
> > various people are attracted to this project
> > 1) The data model (data layer)
> > 2) The framework (database manipulation, etc)
> > 3) The applications (business logic)
> > 4) The widgets (presentation layer)
> > 5) and so on
> >
> > The data model is what it is and can be used in
> any
> > framework.
> >
> > The time consuming part of the business logic
> doesn't
> > come from the lines of code, but the thought
> process.
> > Since the thought process is fairly straight
> forward,
> > rewriting the business logic in another language
> would
> > be a fairly small project.
> >
> > Half of the presentation layer (at least on the
> > backend) is created automatically with RoR's
> scaffold.
> >  So, that's a fairly small project to translate
> with
> > huge UI benefits compared to the OFBiz community
> > project's current UI.
> >
> > The discussion I'm after isn't so much about
> changing
> > Java to RoR, but hypothetically what does one lose
> by
> > leaving Java for RoR and can the apparent benefits
> of
> > RoR be obtained in a Java based OFBiz?
> >
> > If the answer is that you don't lose much by
> switching
> > to RoR and the benefits of RoR cannot be easily
> > obtained in a Java based OFBiz, then the question
> > should be about changing Java to RoR.  There seems
> to
> > be a lot of interest in improving the UI in OFBiz,
> but
> > not so much through the tools that currently
> exist.
> > If you don't lose much with RoR on functionality,
> why
> > reinvent the wheel, just throw on some new racing
> > slicks ;)
> >
> > --- BJ Freeman <[hidden email]> wrote:
> >
> >> Not sure why as discussion about changing java to
> >> RoR.
> >> that is the same as saying change compiere to
> ofbiz.
> >>
> >> That would be one big undertaking, as it is now,
> >> there are enough people
> >> doing testing ofbiz.
> >> That I would think would be a more constructive
> >> discussion.
> >>
> >>
> >> Chris Howe sent the following on 8/4/2006 8:30
> PM:
> >>> Judging by the responses I think I misunderstand
> >> RoR.
> >>> In my newly introduced mind I see RoR being of
> the
> >>> same kind of animal as the OFBiz framework.  In
> >> that
> >>> mindset it would be a replacement of sorts.
> >>>
> >>> I was trying to weigh whether it would be easier
> >> to
> >>> expand OFBiz's UI capabilities with AJAX and
> >> getting a
> >>> consensus on what an OFBiz template should and
> >> should
> >>> not include (ie OFBiz standards) for modularity
> >> sake
> >>> and what not or to rewrite OFBiz's busines logic
> >> in
> >>> RoR.
> >>>
> >>> The majority of the actual usefulness that I saw
> >> with
> >>> RoR was the way it "consumes" data be it from a
> >> local
> >>> database or a webservice.
> >>>
> >>> So, my question was more towards what is the
> ofbiz
> >>> framework giving us that Ror can't or doesn't
> >> easily.
> >>>
> >>> And what benefits does RoR offer that can/can't
> be
> >>> replicated in OFBiz?
> >>>
> >>> --- David E Jones
> <[hidden email]>
> >>> wrote:
> >>>
> >>>> This is an interesting topic from an
> >> infrastructure
> >>>> perspective. It
> >>>> sounds like there is some suggestion of
> >>>> incorporating it into the
> >>>> framework and moving to it as the standard UI
> >> layer
> >>>> tool set...
> >>>>
> >>>> Has anyone done any conversions of existing
> OFBiz
> >>>> artifacts to
> >>>> compare size and complexity and establish some
> >>>> prospective tools or
> >>>> patterns for integration with other pieces and
> >> such?
> >>>> Actually, from a
> >>>> PoC perspective once could do the same things
> we
> >> did
> >>>> early on with
> >>>> OFBiz: define the artifacts and make sure we
> can
> >>>> define everything we
> >>>> want, and then build the engine behind them. In
> >>>> other words we
> >>>> defined XSD (or DTD in the early days) files,
> and
> >>>> some text XML files
> >>>> based on them to develop towards and support.
> >> These
> >>>> were written to
> >>>> replace specific pages, usually picking a more
> >>>> complicated one. For
> >>>> example, the first form widget form in OFBiz
> was
> >> the
> >>>> EditProduct form
> >>>> with the two columns and such, and that form
> >>>> definition existed even
> >>>> before the form widget engine.
> >>>>
> >>>> This sort of PoC effort would be the first step
> >> for
> >>>> anything like this.
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>> On Aug 4, 2006, at 6:45 PM, Leon Torres wrote:
> >>>>
> >>>>> Yeah we've been looking into this kind of
> thing
> >>>> and talking to some
> >>>>> people about Rails and OFBiz.  This is
> actually
> >> a
> >>>> huge topic which
> >>>>> might be better discussed at a conference or
> >>>> something.
>

=== message truncated ===

[BJ Freeman]

massive changes that completely changes the nature of design, is an
indirect statement that it is wrong, IMHO.

Also I don't all the design criteria is covered so far.

I did a brief look at ROR. Like all high level language, it can lead to
  code bloat, at the machine level. Then you have to get into Code
optimization.
if you have been around the transition from C to C++ the generated code
went from 2k to 150K for simple apps. The means larger hardware, faster
CPU's and memory requirements.
It realize on cgi, which if not handled properly can leave gaping
security holes.

If you want to get into business logic and high level You can Use a
modeling system that then complies to web applications. Then you don't
even write as much as you do in ROR. However then you have to put the
energy in make the compiler efficient.

Guess what I am saying is there is no real good answer to have a end
result be fast, efficient, and easy to code. then you add need for security.


Chris Howe sent the following on 8/4/2006 10:17 PM:

> Wow, I didn't say it was wrong.  Where'd that come
> from?
>
> --- BJ Freeman <[hidden email]> wrote:
>
>> My curiosity is if you feel all this is wrong, which
>> is the impression i
>> get from your communication here, why not go off and
>> do your own thing.
>>
>> Chris Howe sent the following on 8/4/2006 9:40 PM:
>>> My curiosity is that there are several reasons why
>>> various people are attracted to this project
>>> 1) The data model (data layer)
>>> 2) The framework (database manipulation, etc)
>>> 3) The applications (business logic)
>>> 4) The widgets (presentation layer)
>>> 5) and so on
>>>
>>> The data model is what it is and can be used in
>> any
>>> framework.
>>>
>>> The time consuming part of the business logic
>> doesn't
>>> come from the lines of code, but the thought
>> process.
>>> Since the thought process is fairly straight
>> forward,
>>> rewriting the business logic in another language
>> would
>>> be a fairly small project.
>>>
>>> Half of the presentation layer (at least on the
>>> backend) is created automatically with RoR's
>> scaffold.
>>>  So, that's a fairly small project to translate
>> with
>>> huge UI benefits compared to the OFBiz community
>>> project's current UI.
>>>
>>> The discussion I'm after isn't so much about
>> changing
>>> Java to RoR, but hypothetically what does one lose
>> by
>>> leaving Java for RoR and can the apparent benefits
>> of
>>> RoR be obtained in a Java based OFBiz?
>>>
>>> If the answer is that you don't lose much by
>> switching
>>> to RoR and the benefits of RoR cannot be easily
>>> obtained in a Java based OFBiz, then the question
>>> should be about changing Java to RoR.  There seems
>> to
>>> be a lot of interest in improving the UI in OFBiz,
>> but
>>> not so much through the tools that currently
>> exist.
>>> If you don't lose much with RoR on functionality,
>> why
>>> reinvent the wheel, just throw on some new racing
>>> slicks ;)
>>>
>>> --- BJ Freeman <[hidden email]> wrote:
>>>
>>>> Not sure why as discussion about changing java to
>>>> RoR.
>>>> that is the same as saying change compiere to
>> ofbiz.
>>>> That would be one big undertaking, as it is now,
>>>> there are enough people
>>>> doing testing ofbiz.
>>>> That I would think would be a more constructive
>>>> discussion.
>>>>
>>>>
>>>> Chris Howe sent the following on 8/4/2006 8:30
>> PM:
>>>>> Judging by the responses I think I misunderstand
>>>> RoR.
>>>>> In my newly introduced mind I see RoR being of
>> the
>>>>> same kind of animal as the OFBiz framework.  In
>>>> that
>>>>> mindset it would be a replacement of sorts.
>>>>>
>>>>> I was trying to weigh whether it would be easier
>>>> to
>>>>> expand OFBiz's UI capabilities with AJAX and
>>>> getting a
>>>>> consensus on what an OFBiz template should and
>>>> should
>>>>> not include (ie OFBiz standards) for modularity
>>>> sake
>>>>> and what not or to rewrite OFBiz's busines logic
>>>> in
>>>>> RoR.  
>>>>>
>>>>> The majority of the actual usefulness that I saw
>>>> with
>>>>> RoR was the way it "consumes" data be it from a
>>>> local
>>>>> database or a webservice.
>>>>>
>>>>> So, my question was more towards what is the
>> ofbiz
>>>>> framework giving us that Ror can't or doesn't
>>>> easily.
>>>>> And what benefits does RoR offer that can/can't
>> be
>>>>> replicated in OFBiz?
>>>>>
>>>>> --- David E Jones
>> <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> This is an interesting topic from an
>>>> infrastructure
>>>>>> perspective. It  
>>>>>> sounds like there is some suggestion of
>>>>>> incorporating it into the  
>>>>>> framework and moving to it as the standard UI
>>>> layer
>>>>>> tool set...
>>>>>>
>>>>>> Has anyone done any conversions of existing
>> OFBiz
>>>>>> artifacts to  
>>>>>> compare size and complexity and establish some
>>>>>> prospective tools or  
>>>>>> patterns for integration with other pieces and
>>>> such?
>>>>>> Actually, from a  
>>>>>> PoC perspective once could do the same things
>> we
>>>> did
>>>>>> early on with  
>>>>>> OFBiz: define the artifacts and make sure we
>> can
>>>>>> define everything we  
>>>>>> want, and then build the engine behind them. In
>>>>>> other words we  
>>>>>> defined XSD (or DTD in the early days) files,
>> and
>>>>>> some text XML files  
>>>>>> based on them to develop towards and support.
>>>> These
>>>>>> were written to  
>>>>>> replace specific pages, usually picking a more
>>>>>> complicated one. For  
>>>>>> example, the first form widget form in OFBiz
>> was
>>>> the
>>>>>> EditProduct form  
>>>>>> with the two columns and such, and that form
>>>>>> definition existed even  
>>>>>> before the form widget engine.
>>>>>>
>>>>>> This sort of PoC effort would be the first step
>>>> for
>>>>>> anything like this.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Aug 4, 2006, at 6:45 PM, Leon Torres wrote:
>>>>>>
>>>>>>> Yeah we've been looking into this kind of
>> thing
>>>>>> and talking to some  
>>>>>>> people about Rails and OFBiz.  This is
>> actually
>>>> a
>>>>>> huge topic which  
>>>>>>> might be better discussed at a conference or
>>>>>> something.
>>>>>>> - Leon
>>>>>>>
>>>>>>>
>>>>>>> Chris Howe wrote:
>>>>>>>> Si and Leon and others,
>>>>>>>> I just started to look at some Ruby on Rails
>>>>>> stuff and
>>>>>>>> was curious as to your impressions of what
>>>>>> aspects of
>>>>>>>> OFBiz could not be replicated in RoR.  Or is
>> it
>>>>>>>> possible to get off Java entirely?  How much
>> of
>>>>>> OFBiz
>>>>>>>> could be entirely reused vs. how much would
>>>> just
>>>>>> be
>>>>>>>> translating templates, etc?
>>>
>
>

[davidnwelton]

> My curiosity is that there are several reasons why
> various people are attracted to this project
> 1) The data model (data layer)

Yes!

> 2) The framework (database manipulation, etc)

It works.

> 3) The applications (business logic)

Definitely.

> 4) The widgets (presentation layer)
> 5) and so on

The community - being able to interact with others who have similar
ideas and needs.

> The data model is what it is and can be used in any
> framework.

I'm a huge Ruby on Rails fan, and have basically switched to using it
for all my own stuff.  I think for a small application, it's
significantly more productive and efficient than the OFBiz framework.
However... I think you seem to have some misconceptions about RoR.
For instance, the OFBiz data model could not be used as is with RoR
because some tables have multiple primary keys, something that RoR
takes care of with an artificial primary key.

> The time consuming part of the business logic doesn't
> come from the lines of code, but the thought process.
> Since the thought process is fairly straight forward,
> rewriting the business logic in another language would
> be a fairly small project.

I'm skeptical.

> Half of the presentation layer (at least on the
> backend) is created automatically with RoR's scaffold.

I think you misunderstand what scaffolding gives you.  Its true value
is that it gives you a starting point, but it doesn't give you a final
version.  You would almost never want to put scaffolding code into
production.  What's handy about it is that it gives you a skeleton to
start modifying, which makes things quicker and easier because it's
very easy to see how things are done.

>  So, that's a fairly small project to translate with
> huge UI benefits compared to the OFBiz community
> project's current UI.

What I feel are the strengths of RoR are:

*) You use just enough code to say what you mean and no more.  Instead
of stuff like setVariable("foobar", foobar), you just have @foobar =
12, and you can use that in both the controller and the view.

*) It's so easy to get started and crank out functional code.

*) It's got a big, relatively intelligent development community.

What it doesn't have is the specific business knowledge that the OFBiz
community has.  Perhaps Java is also a performance win, as well.

> The discussion I'm after isn't so much about changing
> Java to RoR, but hypothetically what does one lose by
> leaving Java for RoR and can the apparent benefits of
> RoR be obtained in a Java based OFBiz?

I think some of the principals are applicable, but Java just isn't as
dynamic as Ruby...  I don't know OFBiz' internals well enough to
comment on specifics, but I definitely think that for the core guys,
spending a few days with RoR to get some ideas would probably be a
beneficial use of their time.  One of my favorite things about RoR,
for instance, is "don't repeat yourself" - you write stuff only once,
if possible, and the framework figures out the rest for you.  OFBiz
tends to have the same, or similar names scattered all over the place.
 In most cases, you don't really want to configure stuff much... good
defaults would work well enough.

OTOH, OFBiz is pretty big, and what works in Rails might start to
creak under such a big load.

> If the answer is that you don't lose much by switching
> to RoR and the benefits of RoR cannot be easily
> obtained in a Java based OFBiz, then the question
> should be about changing Java to RoR.  There seems to
> be a lot of interest in improving the UI in OFBiz, but
> not so much through the tools that currently exist.
> If you don't lose much with RoR on functionality, why
> reinvent the wheel, just throw on some new racing
> slicks ;)

My guess is that isn't likely to happen.  It probably just makes more
sense to start a RailsBiz project from the ground up in order to
structure things in such a way to conform to how rails does things.
It wouldn't be an easy undertaking, though...  There's a lot of
knowledge and experience wrapped up in OFBiz.

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/

[David E Jones-2]

On Aug 5, 2006, at 11:09 AM, David Welton wrote:

> I think some of the principals are applicable, but Java just isn't as
> dynamic as Ruby...  I don't know OFBiz' internals well enough to
> comment on specifics, but I definitely think that for the core guys,
> spending a few days with RoR to get some ideas would probably be a
> beneficial use of their time.  One of my favorite things about RoR,
> for instance, is "don't repeat yourself" - you write stuff only once,
> if possible, and the framework figures out the rest for you.  OFBiz
> tends to have the same, or similar names scattered all over the place.
> In most cases, you don't really want to configure stuff much... good
> defaults would work well enough.
>
> OTOH, OFBiz is pretty big, and what works in Rails might start to
> creak under such a big load.

This is a good point about the OFBiz framework, and is a nice  
distinguishing factor comparing it to other tools. The intention is  
not to have a minimal set of tools where you define a field once an  
never again, but rather to have a true multi-tier enterprise  
architecture with each tool taking care of a special purpose.

We do have things in place to allow higher level artifacts to  
"inherit" or auto-define things based on lower level artifacts to  
make this easier, but for more complicated software that is meant to  
be customized, having it all in one place can be a real problem. It  
limits flexibility and introduces unexpected side-effects, or to  
avoid those side effects because of limited inherent re-usability it  
forces you to reuse less and have in reality more redundancy...

So, the point of the way the OFBiz architecture is designed is to  
support the type of software we are building: an extensive set of  
base, best-practice applications that can be easily customized and  
extended to meet the needs of a wide variety of businesses and  
industries. This does lead to a lot more work required to tie pieces  
together (hence a fairly large artifact reference diagram for the  
framework), but every single one of those touch point becomes a point  
of flexibility and re-usability in the bigger picture and becomes  
worth many times the initial effort required to set it up in ease of  
use and reuse later on. It's very much a big picture driven  
architecture with business needs as the highest priority, and  
technical elegance just under that.

Of course, to ease the inconvenience there are some tools that have  
been discussed that will hopefully exist for navigating among OFBiz  
artifacts, and even perhaps filling in missing ones and such. I  
talked with J. Aaron Farr at OSCON and he has quite a bit of  
experience with Eclipse plugin authoring and is interested in working  
on this, so who knows... this may exist sooner (and free-er) than  
expected.

-David

[Adam Heath-2]

Alex Caudill wrote:
> The way I see it, a set of Ruby on Rails models which interface with OFBiz
> via SOAP seems like the path of least resistance at this particular
> moment. My intention was to use Rails to implement a much less complex,
> user-friendly web-facing
> application, using a subdomain-as-account-key model to handle
> multi-tenancy,
> while still managing backoffice operations with OFBiz itself.

Actually, there's a much simpler approach.

We've got a product that can run javascript(rhino), ruby(jruby),
php(quercus), java(janino), python(jython) as events, and velocity,
freemarker, and php as templates.  You can also run any standard servlet.

So, why invent some unique interface to connect separate processes
together, when you can just run these languages all inside java, and can
call java classes, methods, and objects directly?