http://ofbiz.116.s1.nabble.com/Ofbiz-and-Ruby-on-Rails-tp170367p170383.html
If you take the catalog manager for example. There
are 107 views. That probably equates to what? 5, 10,
lines of code (itty bitty lines too). Different
--- "David E. Jones" <
>
> 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.
>