http://ofbiz.116.s1.nabble.com/Ofbiz-and-Ruby-on-Rails-tp170367p170381.html
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
went from 2k to 150K for simple apps. The means larger hardware, faster
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
result be fast, efficient, and easy to code. then you add need for security.
> 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?
>>>
>
>