Marketing OFBiz and the OFBiz non-object approach (was Re: Wicket in OFBiz)

[David E. Jones-2]

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" <[hidden email]>
>>>> 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" <[hidden email]>
>>>>>>> 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.
>
>

[BJ Freeman]

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"<[hidden email]>
>>>>> 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"<[hidden email]>
>>>>>>>> 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.
>>
>>
>
>

[David E. Jones-2]

This discussion started with a discussion of Wicket, leading to a discussion of the approach used in the framework.

The big question is not how to market OFBiz as a whole, but instead how to market the OFBiz Framework and the non-object-mapping approach that the OFBiz Framework uses.

In other words, how do you sell the framework to developers? Selling the entire projects to business users and decision makers is another question entirely.

-David


On Jan 24, 2011, at 5:59 PM, BJ Freeman wrote:

> 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"<[hidden email]>
>>>>>> 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"<[hidden email]>
>>>>>>>>> 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.
>>>
>>>
>>
>>

[BJ Freeman]

only thing I can share is that I had a lot of background with many
"systems". when i say ofbiz and the description I knew it would fit my
criteria and hence adopted it.

the one hold back to me was UI, ofbiz let me handle that with only a few
changes, so got the flexibility of the entity mapping to pages but have
a more user friendly UI for the users.






David E Jones sent the following on 1/24/2011 6:12 PM:

>
> This discussion started with a discussion of Wicket, leading to a discussion of the approach used in the framework.
>
> The big question is not how to market OFBiz as a whole, but instead how to market the OFBiz Framework and the non-object-mapping approach that the OFBiz Framework uses.
>
> In other words, how do you sell the framework to developers? Selling the entire projects to business users and decision makers is another question entirely.
>
> -David
>
>
> On Jan 24, 2011, at 5:59 PM, BJ Freeman wrote:
>
>> 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"<[hidden email]>
>>>>>>> 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"<[hidden email]>
>>>>>>>>>> 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.
>>>>
>>>>
>>>
>>>
>
>

[Adrian Crum-3]

I have always viewed business applications in a simplistic way: A
program that stores and retrieves data. Different business application
frameworks may take different approaches, but they all do basically the
same thing - store and retrieve data.

What attracted me to OFBiz is its ability to work on any database, and
any app server. If someone had pitched the advantage of the "OFBiz
Approach" versus ORM at the time, I wouldn't have known what they were
referring to, let alone understand the differences.

After reading Martin Fowler's Analysis Patterns, I saw a good similarity
between his objects and OFBiz entities. There is a strong temptation to
map OFBiz entities to those objects, and some good arguments could be
made in favor of them. The downside is the loss of flexibility in
accommodating table changes - any change made to a table must be
reflected in the object. So, I have come to the conclusion that the
"OFBiz Approach" is the most flexible one. I'm not sure that epiphany
could have come from marketing literature.

Having said that, I believe some things in OFBiz could benefit from ORM.
Like a postal address for example. A postal address entity could be
supplied to an object factory to create a postal address object. That
object could have built-in behaviors - like rendering itself correctly
based on its locale. Or knowing its geolocation. Little things like that
might benefit from ORM,

The last time I checked in on OpenTaps they seemed to be going in the
direction of ORM and DSL. Maybe there could be some lessons learned from
that.

-Adrian

On 1/24/2011 3:48 PM, David E Jones wrote:

> 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"<[hidden email]>
>>>>> 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"<[hidden email]>
>>>>>>>> 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.
>>

[Jacopo Cappellato-4]

This is a really interesting thread.
On Jan 25, 2011, at 3:12 AM, David E Jones wrote:

>
> This discussion started with a discussion of Wicket, leading to a discussion of the approach used in the framework.
>
> The big question is not how to market OFBiz as a whole, but instead how to market the OFBiz Framework and the non-object-mapping approach that the OFBiz Framework uses.
>
> In other words, how do you sell the framework to developers? Selling the entire projects to business users and decision makers is another question entirely.

IMO we try to sell the OFBiz framework as a framework optimized for the development of ERP like applications i.e. applications where relational data model and (rather simple but in a large number) business rules play a big part of the game.
Something like: if you are planning to build a videogame then pick framework ABC or CDE (there are plenty of them), but if you are planning to build an ERP application (or part of it) then OFBiz is the best choice for you.
As a side note: of course OFBiz can be used for more than this, but in my opinion if we, as a community, will find an agreement on the very generic goal of the project (but limiting its scope like I did here) this will be beneficial for the diffusion of the project and also for the community (it will be easier to define the framework vs applications etc...)

Just my 2 cents,

Jacopo

>
> -David
>
>
> On Jan 24, 2011, at 5:59 PM, BJ Freeman wrote:
>
>> 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"<[hidden email]>
>>>>>>> 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"<[hidden email]>
>>>>>>>>>> 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.
>>>>
>>>>
>>>
>>>
>

[David E. Jones-2]

On Jan 24, 2011, at 9:20 PM, Adrian Crum wrote:

> Having said that, I believe some things in OFBiz could benefit from ORM. Like a postal address for example. A postal address entity could be supplied to an object factory to create a postal address object. That object could have built-in behaviors - like rendering itself correctly based on its locale. Or knowing its geolocation. Little things like that might benefit from ORM,

Perhaps I am too set in my ways, but when I think of creating something generic to format an address I think of that as a UI-level thing, preferably represented in something as close to the UI as possible.

Based on that I'd rather have an FTL macro (or a few for different output types, different preferred formats like one line versus many lines, etc), and when that doesn't fit then do a custom template based on the data itself.

> The last time I checked in on OpenTaps they seemed to be going in the direction of ORM and DSL. Maybe there could be some lessons learned from that.

Old habits die hard. I imagine that OpenTaps gets as much, or likely more, pressure to use "standard" technologies than OFBiz itself does. They have also had key developers from the very beginning that didn't like the patterns in the OFBiz Framework and they immediately started replacing it and writing new code using different tools. The result is quite an impressive pile of code and list of tools used (even larger than the amazingly bloated list for OFBiz!).

For those who haven't spent much time developing with object-mapping-oriented tools and don't believe that they are more of a pain, by all means try a small project. Grab the JBoss Seam stack (for example) and try building the OFBiz Example application (the main parts of it anyway, not the various JS/etc demo screens that have been added more recently) with it (after reading the docs about recommended practices of course, make sure you know what they think of as a slick way to develop to be fair).

I've worked with a number of people whose first exposure to enterprise app programming was with OFBiz and later had just such an experience, and the responses tend to be consistent in a way you can probably imagine.

All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.

-David

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>

> On Jan 24, 2011, at 9:20 PM, Adrian Crum wrote:
>
>> Having said that, I believe some things in OFBiz could benefit from ORM. Like a postal address for example. A postal address
>> entity could be supplied to an object factory to create a postal address object. That object could have built-in behaviors - like
>> rendering itself correctly based on its locale. Or knowing its geolocation. Little things like that might benefit from ORM,
>
> Perhaps I am too set in my ways, but when I think of creating something generic to format an address I think of that as a UI-level
> thing, preferably represented in something as close to the UI as possible.
>
> Based on that I'd rather have an FTL macro (or a few for different output types, different preferred formats like one line versus
> many lines, etc), and when that doesn't fit then do a custom template based on the data itself.
>
>> The last time I checked in on OpenTaps they seemed to be going in the direction of ORM and DSL. Maybe there could be some lessons
>> learned from that.
>
> Old habits die hard. I imagine that OpenTaps gets as much, or likely more, pressure to use "standard" technologies than OFBiz
> itself does. They have also had key developers from the very beginning that didn't like the patterns in the OFBiz Framework and
> they immediately started replacing it and writing new code using different tools. The result is quite an impressive pile of code
> and list of tools used (even larger than the amazingly bloated list for OFBiz!).
>
> For those who haven't spent much time developing with object-mapping-oriented tools and don't believe that they are more of a
> pain, by all means try a small project. Grab the JBoss Seam stack (for example) and try building the OFBiz Example application
> (the main parts of it anyway, not the various JS/etc demo screens that have been added more recently) with it (after reading the
> docs about recommended practices of course, make sure you know what they think of as a slick way to develop to be fair).
>
> I've worked with a number of people whose first exposure to enterprise app programming was with OFBiz and later had just such an
> experience, and the responses tend to be consistent in a way you can probably imagine.
>
> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many
> ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny
> quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.

It might be interesting to have a list of the principle issues you think about..

Jacques

> -David
>
>

[jonatan soto]

Very interesting threat indeed.

As a developer I find Ofbiz hard to sell because it has no impact on the
mass market where "cutting-edge" technologies rules it, like Struts was or
Spring, Hibernate, etc are for example. Companies are demanding concrete
skills to developers so it's obvious that developers tries to adjust to this
market.

It's almost a year since I started a full time dedication in Ofbiz
customization for my own company and I found it a very productive and
very entertaining. I've learned a lot and I'm still learning, but for some
reasons I have to seek for a job as a developer on a external company. Every
interview I've done they weren't so exited when I said "I'm starting up a
retail company and it's based on an ERP called Ofbiz". I almost dare to say
that Ofbiz is unknown in the IT scenario in Spain. On the other hand
OpenBravo for example it's more well-know because their alliances to the big
companies, as David said, they rule the IT market in general. Another reason
perhaps is the legislation adaptation and business process orientation to
this country that makes OpenBravo easy to sell.

I'm starting a new little project and I wanted to use the Ofbiz framework
only. I'm aware about the efforts done to have this ready but in order keep
updated my skills for this mass marketed IT companies so I finally decided
to do it with GWT+Spring+Hibernate. I need to sell myself.

Regards.

On Tue, Jan 25, 2011 at 9:30 AM, Jacques Le Roux <
[hidden email]> wrote:

> From: "David E Jones" <[hidden email]>
>
>> On Jan 24, 2011, at 9:20 PM, Adrian Crum wrote:
>>
>>
>>  Having said that, I believe some things in OFBiz could benefit from ORM.
>>> Like a postal address for example. A postal address
>>> entity could be supplied to an object factory to create a postal address
>>> object. That object could have built-in behaviors - like
>>> rendering itself correctly based on its locale. Or knowing its
>>> geolocation. Little things like that might benefit from ORM,
>>>
>>
>> Perhaps I am too set in my ways, but when I think of creating something
>> generic to format an address I think of that as a UI-level
>> thing, preferably represented in something as close to the UI as possible.
>>
>> Based on that I'd rather have an FTL macro (or a few for different output
>> types, different preferred formats like one line versus
>> many lines, etc), and when that doesn't fit then do a custom template
>> based on the data itself.
>>
>>  The last time I checked in on OpenTaps they seemed to be going in the
>>> direction of ORM and DSL. Maybe there could be some lessons
>>> learned from that.
>>>
>>
>> Old habits die hard. I imagine that OpenTaps gets as much, or likely more,
>> pressure to use "standard" technologies than OFBiz
>> itself does. They have also had key developers from the very beginning
>> that didn't like the patterns in the OFBiz Framework and
>> they immediately started replacing it and writing new code using different
>> tools. The result is quite an impressive pile of code
>> and list of tools used (even larger than the amazingly bloated list for
>> OFBiz!).
>>
>> For those who haven't spent much time developing with
>> object-mapping-oriented tools and don't believe that they are more of a
>> pain, by all means try a small project. Grab the JBoss Seam stack (for
>> example) and try building the OFBiz Example application
>> (the main parts of it anyway, not the various JS/etc demo screens that
>> have been added more recently) with it (after reading the
>> docs about recommended practices of course, make sure you know what they
>> think of as a slick way to develop to be fair).
>>
>> I've worked with a number of people whose first exposure to enterprise app
>> programming was with OFBiz and later had just such an
>> experience, and the responses tend to be consistent in a way you can
>> probably imagine.
>>
>> All of that said, now that Moqui is starting to take shape I find the
>> OFBiz Framework to be cumbersome and inconsistent in many
>> ways (things that are hard to fix, but that are not surprising given the
>> pioneering history of the OFBiz Framework). Those funny
>> quirky things are likely a turn-off to prospective developers and I'm
>> hoping to remove that impediment to adopting the approach.
>>
>
> It might be interesting to have a list of the principle issues you think
> about..
>
> Jacques
>
>  -David
>>
>>
>>
>
>

--
-----

Jonatan Soto

[samhamilton]

Can I perhaps ask the stupid question of the thread, the non-developer as I am reading the dev list... as I understand it when OFBiz was started there were no mature frameworks that did what OFBiz wanted to do so you guys created one to fill the void which over time has evolved into what I gather as a monster of code. My question is why reinvent the framework again now that there are so many mature java based frameworks in existence http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Java why create another one, why not instead ride on the back of a project that will take care of itself much like OFBiz does with Tomcat? Surly there are going to be plus and minus points to everything and anything that is used?



On 25 Jan 2011, at 16:30, Jacques Le Roux wrote:

> From: "David E Jones" <[hidden email]>
>> On Jan 24, 2011, at 9:20 PM, Adrian Crum wrote:
>>
>>> Having said that, I believe some things in OFBiz could benefit from ORM. Like a postal address for example. A postal address
>>> entity could be supplied to an object factory to create a postal address object. That object could have built-in behaviors - like
>>> rendering itself correctly based on its locale. Or knowing its geolocation. Little things like that might benefit from ORM,
>>
>> Perhaps I am too set in my ways, but when I think of creating something generic to format an address I think of that as a UI-level
>> thing, preferably represented in something as close to the UI as possible.
>>
>> Based on that I'd rather have an FTL macro (or a few for different output types, different preferred formats like one line versus
>> many lines, etc), and when that doesn't fit then do a custom template based on the data itself.
>>
>>> The last time I checked in on OpenTaps they seemed to be going in the direction of ORM and DSL. Maybe there could be some lessons
>>> learned from that.
>>
>> Old habits die hard. I imagine that OpenTaps gets as much, or likely more, pressure to use "standard" technologies than OFBiz
>> itself does. They have also had key developers from the very beginning that didn't like the patterns in the OFBiz Framework and
>> they immediately started replacing it and writing new code using different tools. The result is quite an impressive pile of code
>> and list of tools used (even larger than the amazingly bloated list for OFBiz!).
>>
>> For those who haven't spent much time developing with object-mapping-oriented tools and don't believe that they are more of a
>> pain, by all means try a small project. Grab the JBoss Seam stack (for example) and try building the OFBiz Example application
>> (the main parts of it anyway, not the various JS/etc demo screens that have been added more recently) with it (after reading the
>> docs about recommended practices of course, make sure you know what they think of as a slick way to develop to be fair).
>>
>> I've worked with a number of people whose first exposure to enterprise app programming was with OFBiz and later had just such an
>> experience, and the responses tend to be consistent in a way you can probably imagine.
>>
>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many
>> ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny
>> quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>
> It might be interesting to have a list of the principle issues you think about..
>
> Jacques
>
>> -David
>>
>>
>
>

[Jacques Le Roux]

OFBiz is not even in this list, I believe because it's not only a web framework but rather an ERP using mostly web as UI (we could
add it though?)

Jacques

Sam Hamilton wrote:

> Can I perhaps ask the stupid question of the thread, the non-developer as I am reading the dev list... as I understand it when
> OFBiz was started there were no mature frameworks that did what OFBiz wanted to do so you guys created one to fill the void which
> over time has evolved into what I gather as a monster of code. My question is why reinvent the framework again now that there are
> so many mature java based frameworks in existence http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Java why
> create another one, why not instead ride on the back of a project that will take care of itself much like OFBiz does with Tomcat?
> Surly there are going to be plus and minus points to everything and anything that is used?
>
>
>
> On 25 Jan 2011, at 16:30, Jacques Le Roux wrote:
>
>> From: "David E Jones" <[hidden email]>
>>> On Jan 24, 2011, at 9:20 PM, Adrian Crum wrote:
>>>
>>>> Having said that, I believe some things in OFBiz could benefit from ORM. Like a postal address for example. A postal address
>>>> entity could be supplied to an object factory to create a postal address object. That object could have built-in behaviors -
>>>> like rendering itself correctly based on its locale. Or knowing its geolocation. Little things like that might benefit from
>>>> ORM,
>>>
>>> Perhaps I am too set in my ways, but when I think of creating something generic to format an address I think of that as a
>>> UI-level thing, preferably represented in something as close to the UI as possible.
>>>
>>> Based on that I'd rather have an FTL macro (or a few for different output types, different preferred formats like one line
>>> versus many lines, etc), and when that doesn't fit then do a custom template based on the data itself.
>>>
>>>> The last time I checked in on OpenTaps they seemed to be going in the direction of ORM and DSL. Maybe there could be some
>>>> lessons learned from that.
>>>
>>> Old habits die hard. I imagine that OpenTaps gets as much, or likely more, pressure to use "standard" technologies than OFBiz
>>> itself does. They have also had key developers from the very beginning that didn't like the patterns in the OFBiz Framework and
>>> they immediately started replacing it and writing new code using different tools. The result is quite an impressive pile of code
>>> and list of tools used (even larger than the amazingly bloated list for OFBiz!).
>>>
>>> For those who haven't spent much time developing with object-mapping-oriented tools and don't believe that they are more of a
>>> pain, by all means try a small project. Grab the JBoss Seam stack (for example) and try building the OFBiz Example application
>>> (the main parts of it anyway, not the various JS/etc demo screens that have been added more recently) with it (after reading the
>>> docs about recommended practices of course, make sure you know what they think of as a slick way to develop to be fair).
>>>
>>> I've worked with a number of people whose first exposure to enterprise app programming was with OFBiz and later had just such an
>>> experience, and the responses tend to be consistent in a way you can probably imagine.
>>>
>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many
>>> ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny
>>> quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>
>> It might be interesting to have a list of the principle issues you think about..
>>
>> Jacques
>>
>>> -David

[Ashish Vijaywargiya-5]

 >> (we could add it though?)

Yes, we should add OFBiz in the list.

--
Regards
Ashish Vijaywargiya
HotWax Media - est. 1997


On Tuesday 25 January 2011 04:11 PM, Jacques Le Roux wrote:

> OFBiz is not even in this list, I believe because it's not only a web
> framework but rather an ERP using mostly web as UI (we could add it
> though?)
>
> Jacques
>
> Sam Hamilton wrote:
>> Can I perhaps ask the stupid question of the thread, the
>> non-developer as I am reading the dev list... as I understand it when
>> OFBiz was started there were no mature frameworks that did what OFBiz
>> wanted to do so you guys created one to fill the void which
>> over time has evolved into what I gather as a monster of code. My
>> question is why reinvent the framework again now that there are
>> so many mature java based frameworks in existence
>> http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Java 
>> why
>> create another one, why not instead ride on the back of a project
>> that will take care of itself much like OFBiz does with Tomcat?
>> Surly there are going to be plus and minus points to everything and
>> anything that is used?
>>
>>
>

[Jacques Le Roux]

Interesting to note that you did not turn to OpenBravo (joke ;o)

Jacques

Jonatan Soto wrote:

> Very interesting threat indeed.
>
> As a developer I find Ofbiz hard to sell because it has no impact on the
> mass market where "cutting-edge" technologies rules it, like Struts was or
> Spring, Hibernate, etc are for example. Companies are demanding concrete
> skills to developers so it's obvious that developers tries to adjust to this
> market.
>
> It's almost a year since I started a full time dedication in Ofbiz
> customization for my own company and I found it a very productive and
> very entertaining. I've learned a lot and I'm still learning, but for some
> reasons I have to seek for a job as a developer on a external company. Every
> interview I've done they weren't so exited when I said "I'm starting up a
> retail company and it's based on an ERP called Ofbiz". I almost dare to say
> that Ofbiz is unknown in the IT scenario in Spain. On the other hand
> OpenBravo for example it's more well-know because their alliances to the big
> companies, as David said, they rule the IT market in general. Another reason
> perhaps is the legislation adaptation and business process orientation to
> this country that makes OpenBravo easy to sell.
>
> I'm starting a new little project and I wanted to use the Ofbiz framework
> only. I'm aware about the efforts done to have this ready but in order keep
> updated my skills for this mass marketed IT companies so I finally decided
> to do it with GWT+Spring+Hibernate. I need to sell myself.
>
> Regards.
>
> On Tue, Jan 25, 2011 at 9:30 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> From: "David E Jones" <[hidden email]>
>>
>>> On Jan 24, 2011, at 9:20 PM, Adrian Crum wrote:
>>>
>>>
>>>  Having said that, I believe some things in OFBiz could benefit from ORM.
>>>> Like a postal address for example. A postal address
>>>> entity could be supplied to an object factory to create a postal address
>>>> object. That object could have built-in behaviors - like
>>>> rendering itself correctly based on its locale. Or knowing its
>>>> geolocation. Little things like that might benefit from ORM,
>>>>
>>>
>>> Perhaps I am too set in my ways, but when I think of creating something
>>> generic to format an address I think of that as a UI-level
>>> thing, preferably represented in something as close to the UI as possible.
>>>
>>> Based on that I'd rather have an FTL macro (or a few for different output
>>> types, different preferred formats like one line versus
>>> many lines, etc), and when that doesn't fit then do a custom template
>>> based on the data itself.
>>>
>>>  The last time I checked in on OpenTaps they seemed to be going in the
>>>> direction of ORM and DSL. Maybe there could be some lessons
>>>> learned from that.
>>>>
>>>
>>> Old habits die hard. I imagine that OpenTaps gets as much, or likely more,
>>> pressure to use "standard" technologies than OFBiz
>>> itself does. They have also had key developers from the very beginning
>>> that didn't like the patterns in the OFBiz Framework and
>>> they immediately started replacing it and writing new code using different
>>> tools. The result is quite an impressive pile of code
>>> and list of tools used (even larger than the amazingly bloated list for
>>> OFBiz!).
>>>
>>> For those who haven't spent much time developing with
>>> object-mapping-oriented tools and don't believe that they are more of a
>>> pain, by all means try a small project. Grab the JBoss Seam stack (for
>>> example) and try building the OFBiz Example application
>>> (the main parts of it anyway, not the various JS/etc demo screens that
>>> have been added more recently) with it (after reading the
>>> docs about recommended practices of course, make sure you know what they
>>> think of as a slick way to develop to be fair).
>>>
>>> I've worked with a number of people whose first exposure to enterprise app
>>> programming was with OFBiz and later had just such an
>>> experience, and the responses tend to be consistent in a way you can
>>> probably imagine.
>>>
>>> All of that said, now that Moqui is starting to take shape I find the
>>> OFBiz Framework to be cumbersome and inconsistent in many
>>> ways (things that are hard to fix, but that are not surprising given the
>>> pioneering history of the OFBiz Framework). Those funny
>>> quirky things are likely a turn-off to prospective developers and I'm
>>> hoping to remove that impediment to adopting the approach.
>>>
>>
>> It might be interesting to have a list of the principle issues you think
>> about..
>>
>> Jacques
>>
>>  -David

[David E. Jones-2]

This is a good question that basically provides context for what we've been discussing. Why use a framework like the OFBiz Framework or Moqui when there are so many other frameworks out there?

1. nearly all frameworks out there follow and "object-mapping" approach (everything is mapped to objects) instead of domain-specific artifact approach (ie instead of defining a Java class that represents a screen, just define a screen using a "language" designed for defining screens; same with services, relational data/entities, etc, etc)

2. even among the object-mapping crowd there are not many comprehensive frameworks, mostly just a bunch of tools and you have to cobble them together and fill in the gaps; I often use JBoss Seam as an example since they have a pretty complete stack, but just try using it compared to the OFBiz Framework and you'll see that there are LOTS of little gaps to fill and LOTS of decisions about how you're going to use the tools (no strong best practices as there are with OFBiz Framework); Rails and Grails are other frameworks that allow you to make and use DSLs (domain-specific-languages) but the resulting DSLs are not very self-describing and while it is easy to create them these frameworks only come with a very limited and weak set of standard DSLs that do not come close to the feature set of the OFBiz or Moqui frameworks

3. sort of related to #2, most "frameworks" seem to be moving more and more in the direction of smaller and more reusable pieces which results in a bunch of little things that don't work well together and tools that don't know about and/or don't use other tools that would be of value; the OFBiz and Moqui approach is to have a comprehensive set of tools that work well together; for example: the forms know about the services and entities, as do the screens; in Moqui the security configuration knows about all of the various artifacts and allows for run-time inheritable authorization on each; with tools that are all meant to operate in a stand-alone way you can't do that; another innovation that this makes impossible is the idea of a shared execution context that is available for all tools and that has all of the information about what is running and by who and such for the tools to easily handle more advanced features; this was started but never finished in OFBiz, and is the basis for the API design in Moqui (ie the ExecutionContext and all of the related interfaces)

So, yes, it's true that the main reason for creating so many framework tools initially was that good tools were hard to find. Over the years the tools out there have improved, and there are many more of the, but they are pretty much all trying to do a better job of the same old thing. Object-Relational-Mapping and general object-mapping and the crazy object bias that exists is unfortunate, and while those approaches are getting better tools the whole idea is flawed to start with. Or, perhaps better said, there are better paradigms to operate under that result in leaner artifacts that are easier to create and maintain, especially for larger applications.

In short, if you want to spend a good deal of time being a framework hobbyist along with your application development then the host of tools out there can provide you with endless hours of joy. If you want to focus on building applications and let the framework deal with the low-level crap, then a framework like OFBiz or Moqui is a better choice.

-David


On Jan 25, 2011, at 1:52 AM, Sam Hamilton wrote:

> Can I perhaps ask the stupid question of the thread, the non-developer as I am reading the dev list... as I understand it when OFBiz was started there were no mature frameworks that did what OFBiz wanted to do so you guys created one to fill the void which over time has evolved into what I gather as a monster of code. My question is why reinvent the framework again now that there are so many mature java based frameworks in existence http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Java why create another one, why not instead ride on the back of a project that will take care of itself much like OFBiz does with Tomcat? Surly there are going to be plus and minus points to everything and anything that is used?
>
>
>
> On 25 Jan 2011, at 16:30, Jacques Le Roux wrote:
>
>> From: "David E Jones" <[hidden email]>
>>> On Jan 24, 2011, at 9:20 PM, Adrian Crum wrote:
>>>
>>>> Having said that, I believe some things in OFBiz could benefit from ORM. Like a postal address for example. A postal address
>>>> entity could be supplied to an object factory to create a postal address object. That object could have built-in behaviors - like
>>>> rendering itself correctly based on its locale. Or knowing its geolocation. Little things like that might benefit from ORM,
>>>
>>> Perhaps I am too set in my ways, but when I think of creating something generic to format an address I think of that as a UI-level
>>> thing, preferably represented in something as close to the UI as possible.
>>>
>>> Based on that I'd rather have an FTL macro (or a few for different output types, different preferred formats like one line versus
>>> many lines, etc), and when that doesn't fit then do a custom template based on the data itself.
>>>
>>>> The last time I checked in on OpenTaps they seemed to be going in the direction of ORM and DSL. Maybe there could be some lessons
>>>> learned from that.
>>>
>>> Old habits die hard. I imagine that OpenTaps gets as much, or likely more, pressure to use "standard" technologies than OFBiz
>>> itself does. They have also had key developers from the very beginning that didn't like the patterns in the OFBiz Framework and
>>> they immediately started replacing it and writing new code using different tools. The result is quite an impressive pile of code
>>> and list of tools used (even larger than the amazingly bloated list for OFBiz!).
>>>
>>> For those who haven't spent much time developing with object-mapping-oriented tools and don't believe that they are more of a
>>> pain, by all means try a small project. Grab the JBoss Seam stack (for example) and try building the OFBiz Example application
>>> (the main parts of it anyway, not the various JS/etc demo screens that have been added more recently) with it (after reading the
>>> docs about recommended practices of course, make sure you know what they think of as a slick way to develop to be fair).
>>>
>>> I've worked with a number of people whose first exposure to enterprise app programming was with OFBiz and later had just such an
>>> experience, and the responses tend to be consistent in a way you can probably imagine.
>>>
>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many
>>> ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny
>>> quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>
>> It might be interesting to have a list of the principle issues you think about..
>>
>> Jacques
>>
>>> -David
>>>
>>>
>>
>>
>

[Pierre Smits]

IMO, marketing has to do with managing (and steering) expectations. For the
generally accepted explanation, see http://en.wikipedia.org/wiki/Marketing

Marketing OFBiz to either the development community or others will always be
an uphill battle, when you don't have a plan. And I think that is the
underlying issue. More on this later...

Since 2006 I have followed the mailing lists (all of them of OFBiz),
reacting on entries there, occasionally created awareness for issues (by
registering them in JIRA) and providing patches and improvements. Like all
of us I have only limited time available for OFBiz (the project), as it is
not the source of income.

And I see a lot of involved and enthousiast persons doing the same as I do.
When feeling a pain with OFBiz (the product) I try to take the pain away.
And if there is time to spare I bring back to OFBiz (the community). Without
any (perceived) commitment or responsibility. The general approach seems to
be: 'Yes, it will happen when it happens'. I even see committers taking this
further: plemping code straight into the trunk (or removing from) without
prior consensus of the community, and then thumping their chests and
hailing (marketing) their prowess.

Is this how it's supposed to be in this project/communtiy?

Back to the underlying issue.
I have come to believe that OFBiz is a project without a plan. Yes, we have
the marketing documents (about the product, project and the community
members), but only about what is/was and what has happened. But we have
nothing to say about what is going to be or happen. Maybe on an individual
(member) level to an individual customer (group). But not as WE the
community/project. And this should change if we want to able give more
praise, business, etc to our members. How can we get new followers and old
interested when we can't even say:

Look guys. This is what we are working on and it *will* be available at such
and such moment. Please come back here to check on our progress and other
plans.

Journalists and other followers are looking for this. And this is what we
have to do and do it regularly.
But we can't do this when we don't have a clue what is going to happen with
the product and project. We can only comment vaguely about what is happening
in JIRA and in mailing lists. But not about the way forward. And not to loud
as it might bite us in the behind.

Maybe it is time for a change. But another change than implementing yet
another wheel (or bathtub) on the car. Or replacing one working wheel with
another.

Regards,

Pierre Smits

[David E. Jones-2]

It is certainly true that the OFBiz Framework includes web application framework elements, but many of the tools listed on that wikipedia page are ONLY web app frameworks and are not more comprehensive enterprise app frameworks. In other words they are mostly UI level things without the service/logic and data layers (though many support Hibernate or the like for persistence).

It would be interested to see OFBiz as a framework listed in more places, but given the difficulty in separating out the OFBiz Framework from the rest of the project I don't know how popular it would ever be for that (yeah, back to that same old discussion of priorities and rules for this and that...).

-David


On Jan 25, 2011, at 2:41 AM, Jacques Le Roux wrote:

> OFBiz is not even in this list, I believe because it's not only a web framework but rather an ERP using mostly web as UI (we could add it though?)
>
> Jacques
>
> Sam Hamilton wrote:
>> Can I perhaps ask the stupid question of the thread, the non-developer as I am reading the dev list... as I understand it when
>> OFBiz was started there were no mature frameworks that did what OFBiz wanted to do so you guys created one to fill the void which
>> over time has evolved into what I gather as a monster of code. My question is why reinvent the framework again now that there are
>> so many mature java based frameworks in existence http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Java why
>> create another one, why not instead ride on the back of a project that will take care of itself much like OFBiz does with Tomcat?
>> Surly there are going to be plus and minus points to everything and anything that is used?
>>
>>
>>
>> On 25 Jan 2011, at 16:30, Jacques Le Roux wrote:
>>
>>> From: "David E Jones" <[hidden email]>
>>>> On Jan 24, 2011, at 9:20 PM, Adrian Crum wrote:
>>>>
>>>>> Having said that, I believe some things in OFBiz could benefit from ORM. Like a postal address for example. A postal address
>>>>> entity could be supplied to an object factory to create a postal address object. That object could have built-in behaviors -
>>>>> like rendering itself correctly based on its locale. Or knowing its geolocation. Little things like that might benefit from
>>>>> ORM,
>>>>
>>>> Perhaps I am too set in my ways, but when I think of creating something generic to format an address I think of that as a
>>>> UI-level thing, preferably represented in something as close to the UI as possible.
>>>>
>>>> Based on that I'd rather have an FTL macro (or a few for different output types, different preferred formats like one line
>>>> versus many lines, etc), and when that doesn't fit then do a custom template based on the data itself.
>>>>
>>>>> The last time I checked in on OpenTaps they seemed to be going in the direction of ORM and DSL. Maybe there could be some
>>>>> lessons learned from that.
>>>>
>>>> Old habits die hard. I imagine that OpenTaps gets as much, or likely more, pressure to use "standard" technologies than OFBiz
>>>> itself does. They have also had key developers from the very beginning that didn't like the patterns in the OFBiz Framework and
>>>> they immediately started replacing it and writing new code using different tools. The result is quite an impressive pile of code
>>>> and list of tools used (even larger than the amazingly bloated list for OFBiz!).
>>>>
>>>> For those who haven't spent much time developing with object-mapping-oriented tools and don't believe that they are more of a
>>>> pain, by all means try a small project. Grab the JBoss Seam stack (for example) and try building the OFBiz Example application
>>>> (the main parts of it anyway, not the various JS/etc demo screens that have been added more recently) with it (after reading the
>>>> docs about recommended practices of course, make sure you know what they think of as a slick way to develop to be fair).
>>>>
>>>> I've worked with a number of people whose first exposure to enterprise app programming was with OFBiz and later had just such an
>>>> experience, and the responses tend to be consistent in a way you can probably imagine.
>>>>
>>>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many
>>>> ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny
>>>> quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
>>>
>>> It might be interesting to have a list of the principle issues you think about..
>>>
>>> Jacques
>>>
>>>> -David
>
>

[Pierre Smits]

When you do a search on 'Business Application Framework' in either google or
wikipedia you'll see a lot of references. In wikipedia I see the Oracle
Application Framework and the SAP Composite Application Framework. But not
OFBiz on the first page. It ranks somewhere around 70.

As we all agree that OFBiz is also a Framework we should rethink the wording
in Wikipedia and in other marketing documents. And expand on the fact that
is a Business Application Framework. That will create room to both the core
and extensions, etc.

Regards,

Pierre

[Ruth Hoffman-2]

Having just spend 6 months working in a mixed OpenTaps, OFBiz 9.x
environment, all I can say is: "What a mess". Thankfully I do not have
to support the core project base - only my small piece. I still have not
found the value in the OpenTaps/Hibernate implementation. Maybe,
someday, I'll see that light.

David - Please see my other comment inline. I'm particularly interested
in the recurring theme of yours as articulated below:

On 1/25/11 2:06 AM, David E Jones wrote:

> On Jan 24, 2011, at 9:20 PM, Adrian Crum wrote:
>
>> Having said that, I believe some things in OFBiz could benefit from ORM. Like a postal address for example. A postal address entity could be supplied to an object factory to create a postal address object. That object could have built-in behaviors - like rendering itself correctly based on its locale. Or knowing its geolocation. Little things like that might benefit from ORM,
> Perhaps I am too set in my ways, but when I think of creating something generic to format an address I think of that as a UI-level thing, preferably represented in something as close to the UI as possible.
>
> Based on that I'd rather have an FTL macro (or a few for different output types, different preferred formats like one line versus many lines, etc), and when that doesn't fit then do a custom template based on the data itself.
>
>> The last time I checked in on OpenTaps they seemed to be going in the direction of ORM and DSL. Maybe there could be some lessons learned from that.
> Old habits die hard. I imagine that OpenTaps gets as much, or likely more, pressure to use "standard" technologies than OFBiz itself does. They have also had key developers from the very beginning that didn't like the patterns in the OFBiz Framework and they immediately started replacing it and writing new code using different tools. The result is quite an impressive pile of code and list of tools used (even larger than the amazingly bloated list for OFBiz!).
>
> For those who haven't spent much time developing with object-mapping-oriented tools and don't believe that they are more of a pain, by all means try a small project. Grab the JBoss Seam stack (for example) and try building the OFBiz Example application (the main parts of it anyway, not the various JS/etc demo screens that have been added more recently) with it (after reading the docs about recommended practices of course, make sure you know what they think of as a slick way to develop to be fair).
>
> I've worked with a number of people whose first exposure to enterprise app programming was with OFBiz and later had just such an experience, and the responses tend to be consistent in a way you can probably imagine.
>
> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.

David - you keep saying this..Please provide some examples of
"cumbersome and inconsistent" within the framework. And why not try and
fix these? Instead of reinventing the wheel. What "funny quirky" things
have turned of prospective developers? Do you have an specific examples?
> -David
>
>
>

[Ruth Hoffman-2]

Well said!
I would only add..."leadership" to the mix. A plan needs leadership to
galvanize the community to move in a positive direction.
Regards,
Ruth

On 1/25/11 6:43 AM, Pierre Smits wrote:

> IMO, marketing has to do with managing (and steering) expectations. For the
> generally accepted explanation, see http://en.wikipedia.org/wiki/Marketing
>
> Marketing OFBiz to either the development community or others will always be
> an uphill battle, when you don't have a plan. And I think that is the
> underlying issue. More on this later...
>
> Since 2006 I have followed the mailing lists (all of them of OFBiz),
> reacting on entries there, occasionally created awareness for issues (by
> registering them in JIRA) and providing patches and improvements. Like all
> of us I have only limited time available for OFBiz (the project), as it is
> not the source of income.
>
> And I see a lot of involved and enthousiast persons doing the same as I do.
> When feeling a pain with OFBiz (the product) I try to take the pain away.
> And if there is time to spare I bring back to OFBiz (the community). Without
> any (perceived) commitment or responsibility. The general approach seems to
> be: 'Yes, it will happen when it happens'. I even see committers taking this
> further: plemping code straight into the trunk (or removing from) without
> prior consensus of the community, and then thumping their chests and
> hailing (marketing) their prowess.
>
> Is this how it's supposed to be in this project/communtiy?
>
> Back to the underlying issue.
> I have come to believe that OFBiz is a project without a plan. Yes, we have
> the marketing documents (about the product, project and the community
> members), but only about what is/was and what has happened. But we have
> nothing to say about what is going to be or happen. Maybe on an individual
> (member) level to an individual customer (group). But not as WE the
> community/project. And this should change if we want to able give more
> praise, business, etc to our members. How can we get new followers and old
> interested when we can't even say:
>
> Look guys. This is what we are working on and it *will* be available at such
> and such moment. Please come back here to check on our progress and other
> plans.
>
> Journalists and other followers are looking for this. And this is what we
> have to do and do it regularly.
> But we can't do this when we don't have a clue what is going to happen with
> the product and project. We can only comment vaguely about what is happening
> in JIRA and in mailing lists. But not about the way forward. And not to loud
> as it might bite us in the behind.
>
> Maybe it is time for a change. But another change than implementing yet
> another wheel (or bathtub) on the car. Or replacing one working wheel with
> another.
>
> Regards,
>
> Pierre Smits
>

[David E. Jones-2]

On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:

> On 1/25/11 2:06 AM, David E Jones wrote:
>> All of that said, now that Moqui is starting to take shape I find the OFBiz Framework to be cumbersome and inconsistent in many ways (things that are hard to fix, but that are not surprising given the pioneering history of the OFBiz Framework). Those funny quirky things are likely a turn-off to prospective developers and I'm hoping to remove that impediment to adopting the approach.
> David - you keep saying this..Please provide some examples of "cumbersome and inconsistent" within the framework. And why not try and fix these? Instead of reinventing the wheel. What "funny quirky" things have turned of prospective developers? Do you have an specific examples?

Yes, I have mentioned these many times especially in the last 2-3 years. Some of them I have tried to fix in OFBiz itself and ran into rather large problems. These are not easy changes to make in a large and mature project like OFBiz, and after trying a few times I decided that a new framework was the only way forward (another thing I've written before and made very clear).

These are the things that led to many aspects of the design of Moqui, and the best summary of them is the document I wrote about the differences between the Moqui and OFBiz frameworks:

http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296

To sum up here are some of the major inconsistencies and annoyances in the current OFBiz framework that bug me frequently while I'm developing:

1. XML actions are different in each widget and in the simple-methods; they share some underlying code but there are so many differences

2. scriptlets and expressions are a messy combination of BeanShell, UEL, and Groovy and keeping track of which is a pain, plus the Groovy syntax and capabilities are SO much better than the others so I find myself almost always using ${groovy:...} instead of the default, and in annoying places like the form.field.@use-when attribute since it is always BeanShell I just use a set action to prepare a boolean and then check it in the use-when (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML attributes)

3. the controller.xml file gets HUGE for larger applications, and if split it becomes harder to find requests and views; *Screen.xml files also tend to get HUGE with large numbers of screens in them; both are not organized in the same way as the application, also generally making things harder to find; views/screens and requests don't define incoming parameters so when doing request-redirect you have to specify the parameters to use in a larger number of places

4. another on the topic of why so many files: service groups and simple-methods are just XML, why not include them inline in the service definition (especially for smaller services), and encourage fewer services per file

5. loading of artifacts is not very lazy, meaning lots of unused screens, forms, services, entities and so on that are not used are loaded anyway; also many artifacts are difficult to reload by cache clearing and so that has limited support in OFBiz; this slows things down reloading lots of stuff in development, and results in more resources used than needed in production

6. the deployment model of OFBiz is limited and the use of static fields for initialization makes it difficult to deploy in other ways; there are few init/destroy methods and object instances that would make more deployment models easier and more flexible; also because of this it is difficult to get data from other parts of the framework (for example the audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and visitId down since there is no other good way of doing it); in other words, the tools don't share a context

7. no API for apps; the framework is made up of an enormous number of classes that follow a bunch of different "patterns" (in quotes because the use of the term is generous) because of various people "cleaning" things up over time (also in quotes because the use of the term is generous), and there is no distinction between the API that apps are intended to use and the internal implementation of that API; this has the nasty side effect of making it difficult to find the object and method you want, AND it makes backward compatibility problems REALLY nasty because it gets people believing that EVERY SINGLE object needs to ALWAYS be backward compatible... and that results in more and more piles of trash code lying around over time, and all of that code and differing patterns makes framework changes error-prone and unnecessarily difficult (and this is true for some of the app code in OFBiz too)

I should get back to work... there's a short list anyway...

The trick is how to solve these without abandoning backward compatibility, and requiring a refactor of much of the framework and then based on that the updating of massive numbers of application artifacts... and that is just the stuff in OFBiz itself... not including everything that everyone else has written outside the project that they may want to update. And, ALL of that would have to be retested. Plus, it would take so long to get all of this done in a branch with huge numbers of changes while others are making incremental changes in the trunk making it nearly impossible to merge the branch into the trunk, so it would basically be a fork anyway...

-David