word to mouth is the cheapest way. Also give ready made clients.
I grew up in a industry that was built world wide on this principle.
I have built my business on the same word to mouth.
the stumbling block with ofbiz has been the size and learning curve.
even with "Consultants" most clients I deal with think 7days of training
is to much.
so when Ofbiz gets the reputation, with the end user, of a very big
program, that does everything they want; that is made for Dummies, it
will be an up hill effort.
Hence the effort for a Setup and screens with terminology the end user
is familiar with. Their Terminology is defined by the end users business
usage.
David E Jones sent the following on 1/24/2011 3:48 PM:
That brings up another good question: will any words written on paper convince
people? We have marketing material all over the place, and it has changed a
grown a lot over the years... and shrunken and been refined at times too.
We could write that the OFBiz Framework approach is way better than all of
those object-oriented (or rather, object-mapping) approaches out there, and we
could list all of the benefits and (for those interested) all of the reasons
why. Is anyone going to believe us?
Perhaps if there were a dozen well-known technology journalists who wrote these
things instead of us writing it, then more people would believe them.
But how do you get journalists (or more to the point the journals or media
outlets in general) to write such things, especially the really well-known and
well-read ones?
Well, that's what the marketing profession is for, including the public
relations branch of that profession. But, even they have their limitations...
and those limitations are mostly related to whatever budget they are given.
So, and this is a jaded perspective, but without a billion-dollar company
pimping out the technology, how does one compete with an approach (the
object-everything/object-mapping approach) that various billion-dollar corps
are pushing, and that thousands of smaller orgs and hundreds of thousands of
individuals are going along with, and that dates back around 40 years?
Actually, it doesn't date back that long. The object-oriented approach that I
don't like dates back more to the introduction of object-relational mapping,
and that resulted in object-everything mapping. It's a shame really. Objects
are a great way of modeling certain things. The problem is making EVERYTHING an
object.
Screens are screens, they aren't objects, and objects are a clunky way of
modeling a screen. When building a business app (or apps in general actually)
we want to deal with things like screens and services and relational data
structures (or hierarchical/node data structures like XML or JCR, or other such
things), squeezing all of those into the world of objects makes an chaotic,
redundant, and painful result. Yes, newer approaches of making objects more
like these other things are getting better, but they will never overcome that
conceptual mismatch. Never.
In some cases domain-specific "languages" have caught on and are a better
approach to this. However, they tend to be small and isolated things used for specific
purposes. Using them as a general approach for a framework is still pretty unique, with
the OFBiz Framework a pioneering effort in that and the Moqui Framework another step
toward refining it and making it easier and more efficient and flexible.
But, again, those are just descriptions of benefits... who would believe me?
People that already think the same thing would, but those who don't or have a
different bias won't. And, that brings us back the various billion-dollar corps.
And who knows... maybe something better than both will come along and wipe them
out anyway... ;)
-David
On Jan 24, 2011, at 2:59 PM, Jacques Le Roux wrote:
David: I think I will thought about that, it's a real good question! I think,
with a bit of sweetener, your answer below is a good start. We could discuss
it, enhance it and put it as an explanation on the OFBiz main page: *Why OFBiz
?*. It should not be too long, it's always harder to say more with lesser
words. Anyway, for the moment I will spleep on it.
That's also why I put my last efforts in jQuery. For me, at the moment, the
better way to improve OFBiz UI is still through such tools (javascript
frameworks, jQuery being the easier to use IMO). This because, I don't want to
be too far from the real code underneath. I don't, I have never trusted (so
far), generators and such (GWT, etc.). One day though, we will maybe have
enough power and perhaps they will be sufficiently smart and reliable, for the
moment they are still too much verbose for me... But all is stale because it's
always commercial powers struggling below (sometimes very well hidden), so it's
like building on sand. We are still in this crasy period, or at least still
feeling its madness.
James: this said, though I think we don't really need it in OFBiz, Apache
Wicket is also nice by itself. I was trying to understand, why you needed it. I
thought you had maybe to reuse legacy code in OFBiz and found a good way with
Wicket.
Jacques
David E Jones wrote:
That brings up a good question, how could we convince people?
-David
On Jan 24, 2011, at 2:19 PM, Jacques Le Roux wrote:
Thanks David,
It's a long way to convince people
Jacques
From: "David E Jones"<[email protected]>
James,
There is a difference between the design of a screen and the tools used to
implement it. The generic screens in OFBiz in the
business applications layer are meant to be just that: generic. They are not
designed around any particular business process
because there are SO many different possible business processes, and the more
unique yours is, the greater the chance that
custom screens will be required to meet the needs of your intended users.
This is not rare for OFBiz, or for business applications in general. In fact,
this is EXACTLY the situation that the OFBiz
framework, and many of the generic business application artifacts, are meant
for. These sorts of generic screens are far easier
to reuse than very custom screens would be, and depending on your needs some
may be far easier than building screens from
scratch (ie from just data model and services).
What you are proposing is a layer of Java objects to represent the data model,
and a tool (Wicket) to use Java objects to
represent the UI. That is a preference for Java objects, it is just a different
technology. It has nothing to do with what the
resulting UI will be like... that is simply a result of designing what you
want, and then implementing it. In other words,
technology bias has little to do with user interface design.
If you give the OFBiz framework a chance as-is I'm sure you'll find that what
you develop will be better organized, easier to
maintain, and the artifacts will be easier to reuse. This is even more true
with a certain next generation framework
(www.moqui.org) that is based on many ideas in the OFBiz framework, but with a
number of key differences and in general totally
rethought and rewritten.
Either way, the approach is not object-oriented for the business-level
artifacts. That is intentional. Objects are great for
implementing certain things, but for business development it tends to result in
massive amounts of poorly organized and highly
redundant code. This seems to be more true the larger the team gets, and is
true even when writing things that extend OFBiz
when the recommended tools and practices are not used. One extreme example of
this I've seen is a case where over 500,000 lines
of Java were written, just for an ecommerce application with around 20 screens.
The bulk of the problem was that there were 100
developers who were given license to develop in their preferred way and few of
them learned about the tools and practices and
reusable artifacts that could save them time and money.
So yes, you'll find bias against object-mapping here. What's the point in
mapping everything to objects, especially things that
do not naturally have an object-like structure? Why do object-relational
mapping, object-service mapping, object-html mapping,
object-everything mapping when you could just use the relational, service,
html, etc concepts more directly?
And yes, that concept applies no matter what kind of fancy clothing you try to
put on that pig. By fancy clothing I mean things
like annotations, inversion of control, and so on. A pig is a pig, and using
objects for everything is inefficient, redundant,
self-obfuscating, bloated, messy, and inflexible.
-David
On Jan 24, 2011, at 9:24 AM, james_sg wrote:
Hi Jacques,
Let me put it another way. I don't think this patch is good as it doesn't
reuse the screen definition.
Before any improvement can be made to use the screen definition, OFBiz
should understand why a layer of POJOs should exist between the screen
definition and renderers.
Why this component?
My client handles numerous orders each day. Each order have hundreds of
items. Their existing desktop based ERP system supports the order clerks
with that requirement efficiently. Now they want to move to web-based.
Many OFBiz's forms are based on the tables instead of business objects. This
mean the user have to click here and there in order to edit the forms. More
clicking means less efficiency.
This component was quickly put up so that I can rework the code to support
forms based on business object. That means having the request header,
request items etc on the same screen.
Regards,
James
Jacques Le Roux wrote:
James,
It's quite clear, and IMO you did an excellent and interesting work.
Unfortunately, I don't know if we will find enough interest in
the community to commit your patch. Mostly because it's a bit redundant
and not exactly in the spirit of OFBiz (less compilations
and reboots).
BTW why was the reason you created this component (apart that maybe you
are a huge fan of wicket ;o), did you miss something in
OFBiz?
Thanks
Jacques
From: "james_sg"<[email protected]>
Hi Jacques,
Ok, I agree one con about it, is maintenance.
The reason is because the screen renderer in OFBiz is tightly coupled
with
the screen definition.
Since this implementation is a quick hack, I go with the easier way of
coding the screen content in java instead of using the screen definition
way.
It will be good if OFbiz add a layer of POJOs between screen widgets and
the
renderer.
Hope I am clear.
Regards,
james
Jacques Le Roux wrote:
Hi devs,
James yong submitted a patch (simple enough to be quickly read)
proposing
to introduce Wicket as an OFBiz framework component. I's
be interested to read your comments about pros and cons
Note the urlrewrite stuff...
One cons I see is maintenance... (We will see if James is still around,
he
created the Jira issue in August)
Thanks
Jacques
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234277.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234461.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
