The SDO stuff (that was originally WDO) seems to be more related to the service 
engine in OFBiz than to the entity engine. I might be misunderstanding that 
though...

Whatever the case, what is it that you like about SDO, or how does it make your 
life easier?

-David


On Mar 11, 2010, at 6:43 PM, Rodrigo Lima wrote:

> Hi David,
> 
> I believe it is worth following in a path parallel to the Entity Engine,
> which already has its
> value and trust already established.
> A model that looks interesting data model would be to create a layer as the
> SDO (Service Data Objects http://en.wikipedia.org/wiki/Service_Data_Objects)
> to
> services layer, which could easily be used by various technologies UI Tier.
> 
> A great detail is the question of objects typed and untyped.
> 
> Some might say that this issue is easily solved with Web Services, however,
> in practice, it is not so simple for many platforms.
> 
> Regards,
> 
> Rodrigo
> 
> 
> 2010/3/11 Nicolas Malin <[email protected]>
> 
>> -1
>> 
>> BJ, Ruth,
>> 
>> Saying that OFBiz should move in the same way that other projects is a bit
>> stupid, and show that you've not fully understand OFBiz and the entity
>> engine.
>> It is now 7 years I'm working on OFBiz, and I have made the same error at
>> the beginning as others, I did'nt understood at the moment the beauty of the
>> entityengine.
>> Looking back at my hard start, I'm glad having done this error, and now
>> more than mastering the entity engine, and all its abilities in tems of
>> connections, abstractions, and more.
>> The only fault I found was on huge customers projects where there were big
>> business needs.
>> 
>> At LibrenBerry and Nereide, we've then added generators to fill the gap,
>> and this remove nothing from the entity-engine capabilities, but add more
>> smoothness in its use. The combination form/screen/minilang is as strong as
>> before and more stronger. For big business needs, where java is needed, the
>> generated code is more reliable (who never has made on error on Strings ?).
>> for an example, you can take a look to neogia accounting code, to see how
>> entity-engine and code generation combination is valuable.
>> 
>> From our side, it is sure that helping development by generation is not
>> revolutionizing OFBiz, and should not do it, noone told to replace
>> entity-engine with hibernate.
>> Generation is adding a bigger flexibility and a more reliable product.
>> 
>> From my point of view, OFBiz is more than just an ERP. It is also a strong
>> base for any project, from the small ones to the big ones. Adding MDA tools
>> in its data model can only be a good thing.
>> 
>> Cheers,
>> Nicolas
>> 
>> Ruth Hoffman a écrit :
>> 
>> +1
>>> Thank you BJ.
>>> Ruth
>>> ----------------------------------------------------
>>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>>> [email protected]
>>> 
>>> BJ Freeman wrote:
>>> 
>>>> Let me ask this, if all these other approaches are better why is there
>>>> not a application like ofbiz done in them, without using ofbiz at all?
>>>> 
>>>> I keep getting the feeling that those that want major changes don't
>>>> really understand the design goals of ofbiz.
>>>> 
>>>> =======================
>>>> 
>>>> BJ Freeman
>>>> http://bjfreeman.elance.com
>>>> Strategic Power Office with Supplier Automation <
>>>> http://www.businessesnetwork.com/automation/viewforum.php?f=93>
>>>> Specialtymarket.com <http://www.specialtymarket.com/>
>>>> 
>>>> Systems Integrator-- Glad to Assist
>>>> 
>>>> Chat  Y! messenger: bjfr33man
>>>> Linkedin
>>>> <
>>>> http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>
>>>> 
>>>> 
>>>> 
>>>> [email protected] sent the following on 3/11/2010 8:50 AM:
>>>> 
>>>> 
>>>>> While reading the sentence "There are many people out there who don't
>>>>> understand the Entity Engine", I felt a problem implied in it: There are
>>>>> absolutely much more people "out there", and I'm sure the OFBIZ project
>>>>> want to attract them in. Why they keep on asking "Hibernate", "Spring",
>>>>> etc, though? Are they all wrong?
>>>>> 
>>>>> In my opinion, the OFBIZ framework DID do a right thing - to provide
>>>>> developers an integrated framework. What I mean is in OFBIZ, the
>>>>> developer can define entity in one place and share the entity definition
>>>>> across different tiers, form persistence to presentation. This kind of
>>>>> integration saved developers a lot from typings and preserved
>>>>> consistency across different application tiers. But, this is not what
>>>>> Entity Engine itself can provide. All gains come from the integration.
>>>>> If we simply separate the OFBIZ entity engine into a stand alone ORM
>>>>> like tool, I bet its not very attractive and only people familiar with
>>>>> OFBIZ already will use it.
>>>>> On the other hand, if there are another framework such as Grails that
>>>>> can provide at least same level of cross tier integration ability, while
>>>>> leverage the sophisticated and WELL KNOWN technologies (such as
>>>>> Hibernate/JPA for ORM, Spring for service tier component composition,
>>>>> Spring MVC for view tier framework). Sounds a little bit attractive than
>>>>> "home made" every thing, isn't it?
>>>>> 
>>>>> Regards,
>>>>> Miles.
>>>>> 
>>>>> On Thu, 2010-03-11 at 10:23 -0500, Ruth Hoffman wrote:
>>>>> 
>>>>> 
>>>>>> Hi David:
>>>>>> 
>>>>>> Nothing! I think this is an amazing piece of work. IMO, there are many
>>>>>> people out there who don't understand the Entity Engine value 
>>>>>> proposition.
>>>>>> That is why they keep asking for "Hibernate" etc.
>>>>>> 
>>>>>> Here's some things I'd consider as additions:
>>>>>> 
>>>>>>   * Maybe making a separate component/webapp to manage the Entity
>>>>>>     Engine. Take it out of WebTools.
>>>>>>   * Include in that webapp any security/role management specific to
>>>>>>     the Entity Engine.
>>>>>>   * Entity Engine performance tools (or more information on how to use
>>>>>>     existing tools).
>>>>>>   * Better backup tools (or more information on how to use existing
>>>>>>     tools).
>>>>>> 
>>>>>> More to come...
>>>>>> Ruth
>>>>>> ----------------------------------------------------
>>>>>> Find me on the web at http://www.myofbiz.com or Google keyword
>>>>>> "myofbiz"
>>>>>> [email protected]
>>>>>> 
>>>>>> David E Jones wrote:
>>>>>> 
>>>>>> 
>>>>>>> If you could change anything about the data tier in OFBiz (basically
>>>>>>> the Entity Engine), what would you change?
>>>>>>> 
>>>>>>> All comments are welcome. If there is another tool you'd like to see
>>>>>>> used instead of the Entity Engine, please describe what you like about 
>>>>>>> it
>>>>>>> (like "I want to have an Java class for each table in my database") 
>>>>>>> instead
>>>>>>> of just mentioning the tool (like "let's use Hibernate!").
>>>>>>> 
>>>>>>> Why am I asking? This topic comes up every once in a while, and it's
>>>>>>> true that many suggestions never get enough support to actually happen 
>>>>>>> (or
>>>>>>> on further research it is decided that the idea is not tenable), but
>>>>>>> brainstorming about them to get ideas in the open is still a great 
>>>>>>> thing.
>>>>>>> The history of OFBiz is full of things like this where users and more 
>>>>>>> casual
>>>>>>> contributors had ideas and saw possibilities that others, even more 
>>>>>>> involved
>>>>>>> contributors, totally missed or never looked at that way. What I think 
>>>>>>> would
>>>>>>> be fun, and ultimately useful too, is to keep this mostly to 
>>>>>>> brainstorming
>>>>>>> and not do too much comparing of ideas.
>>>>>>> 
>>>>>>> BTW, if you want to brainstorm about another tier (ie the Logic or UI
>>>>>>> tiers) please use the other threads on those. If you'd like to discuss
>>>>>>> things that aren't specific to a tier look for the "General" thread.
>>>>>>> 
>>>>>>> -David
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> --
>> Nicolas MALIN
>> Consultant
>> Tél : 06.17.66.40.06
>> Site projet : http://www.neogia.org/
>> -------
>> Société LibrenBerry
>> Tél : 02.48.02.56.12
>> Site : http://www.librenberry.net/
>> 
>> 

Reply via email to