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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]>
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?
