Mailing-List: contact ofbiz-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ofbiz-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=CX85D8S6iTK4qbOq+M7RpcSa+WDqWitX5wpfzNtXbpVBg4Ot78nAIr7LXDwg27t6SpdoPWSjdoC2NqWWJ2tUVY+QWyL6mbtMGh3C9mANXakKMmyaUmlrMflwjFbLYl2GxtsTcpOFQ374Exm4uUvkD7+rsyPjnxSFDEFeD/IyN4Y=
  ;
Message-ID: <20060805044000.11421.qmail@web80604.mail.yahoo.com>
Date: Fri, 4 Aug 2006 21:40:00 -0700 (PDT)
From: Chris Howe <cjhowe76013@yahoo.com>
Subject: Re: Ofbiz and Ruby on Rails
To: ofbiz-dev@incubator.apache.org
In-Reply-To: <44D413E4.6010106@free-man.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

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 <bjfree@free-man.net> 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 <jonesde@undersunconsulting.com>
> > 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?
> >>
> > 
> > 
>