You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by PRONZATO Cedric RD-BIZZ-GRE <ce...@orange-ftgroup.com> on 2007/02/09 10:50:48 UTC
General questions
Hi everybody,
I am reading OFBiz and mailing list since a few months (I say that for previous talks about the presence of noobs involved).
This said I will expose you things that I think could be enhanced in some parts of OFBiz:
1 - We (OFBiz) need better real life data showing firstly the whole possibility of applications (many tables are empty) and secondly a full range of items and catalogs.
I hope someone could export its data (I am sure also open source projects use OFBiz and are not constrained by commercial stuff). That is really needed when you want to develop new functionalities in OFBiz.
As for example, I would like to implement, test ... a "collaborative engine" but the task is already hard without have to make virtual products ...
So what do you think about that?
2 - I also think we could enhance the project building and perhaps the "project development speed" by using a better eclipse "layout". I am not an expert but I don't think have a so big project which is modularized in a single eclipse project.
Firstly have a subproject for each module will allow using eclipse compiler instead of using ant after editing files.
Secondly we can only open the sub projects we really need for the task we want to do.
Some times ago I tired to do it, but I did it on the wrong OFBiz subversion which caused to lose all my stuff to use the proper subversion. (Well that is the life).
So what do you think about that?
3 - I wanted to make a SMS demonstration application (sending and receiving), I based my code on the mail container because I feel they are same on much points. But I lack of knowledge about the design/pattern I must use to do it properly into the OFBiz architecture. As I am sure I am not alone on the question "how about to make a properly designed OFBiz application", there are perhaps some docs to do about that.
Once I am more formalized on questions and needs I will let you know and hope it will help as input to make these docs.
So what do you think about that?
Thx for the people who have reach the end of the mail and have read its content.
Regards,
Cédric
Re: General questions
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Feb 9, 2007, at 3:12 AM, Chandresh Turakhia wrote:
> 3 - I wanted to make a SMS demonstration application (sending and
> receiving), I based my code on the mail container because I feel
> they are same on much points. But I lack of knowledge about the
> design/pattern I must use to do it properly into the OFBiz
> architecture. As I am sure I am not alone on the question "how
> about to make a properly designed OFBiz application", there are
> perhaps some docs to do about that.
>
> Once I am more formalized on questions and needs I will let you
> know and hope it will help as input to make these docs.
>
> So what do you think about that?
>
> A3)
>
> Step 1 )ofbiz\framework\minilang\src\org\ofbiz\minilang\method
> \callops or some directory Like CallService.java , make
> CallSMSHandler.java
>
> All you might have to do is call http hit on kannel url.
>
> Step 2 ) ofbiz\framework\minilang\dtd . IN simple-methods.xsd ;
> define tag "call-sms" for it
>
> Step 3 ) In ofbiz\framework\minilang\src\org\ofbiz\minilang , Add
> following code in SimpleMethod.java
>
> if ("call-sms".equals(nodeName)) {
> methodOperations.add(new
> org.ofbiz.minilang.method.callops.CallSMSHandler(curOperElem,
> simpleMethod));
> }
>
>
> Hope I am right :)
Why would you do it that way and not just create a service to do this?
The simple-methods are not meant to have every little thing in it as
an operation, that is why we have the service architecture...
-David
Re: General questions + Servicemiz + ofbiz
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Feb 9, 2007, at 4:08 AM, Chandresh Turakhia wrote:
> Add ServiceMix to the jingle. :)
>
> I am not the best fan of Ofbiz web controller. It is nice and
> simple but still needs help for multimodal architecture.
>
> Also look at http://cargo.codehaus.org/ if you plan to start stop
> SMS Container for reliability reasons in case of multiple kannels.
> I could not till now make it work. But it should technically.
>
>>>> pay, command (anything you may ever think using a cell phone).
>
> Separate Instances of the ofbiz as "WebController" ofbiz and
> "Service Engine" ofbiz. Struts2 can be morphed into great
> MultiModalContainer ( No longer WebContainer ). Try Putting
> "Service Engines" of ofbiz as ServiceEngine of ServiceMiz.
>
> This is what I am trying to achieve. Shall do it.
It sounds like a nice thing, but what would be the point? In other
words, what problems are you running into that it would solve?
-David
Re: General questions + Servicemiz + ofbiz
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Feb 9, 2007, at 4:08 AM, Chandresh Turakhia wrote:
> Add ServiceMix to the jingle. :)
>
> I am not the best fan of Ofbiz web controller. It is nice and
> simple but still needs help for multimodal architecture.
>
> Also look at http://cargo.codehaus.org/ if you plan to start stop
> SMS Container for reliability reasons in case of multiple kannels.
> I could not till now make it work. But it should technically.
>
>>>> pay, command (anything you may ever think using a cell phone).
>
> Separate Instances of the ofbiz as "WebController" ofbiz and
> "Service Engine" ofbiz. Struts2 can be morphed into great
> MultiModalContainer ( No longer WebContainer ). Try Putting
> "Service Engines" of ofbiz as ServiceEngine of ServiceMiz.
>
> This is what I am trying to achieve. Shall do it.
It sounds like a nice thing, but what would be the point? In other
words, what problems are you running into that it would solve?
-David
Re: Servimiz + AMQP
Posted by Chandresh Turakhia <ch...@bhartitelesoft.com>.
Thanks....
----- Original Message -----
From: "James Strachan" <ja...@gmail.com>
To: <se...@geronimo.apache.org>
Sent: Friday, February 09, 2007 4:40 AM
Subject: Re: Servimiz + AMQP
> On 2/9/07, Chandresh Turakhia <ch...@bhartitelesoft.com> wrote:
>> Team,
>>
>> Any pointers as to how to integrating AMQP with JMS. Dirty hack also
>> ok.
>> I understand from newsgroup there is discrepancy between JMS and
>> AMQP.
>> http://www.rabbitmq.com/
>>
>> Need AMQP for Erisson Switch integration,
>>
>> Thanks in advance.
>> Chand
>
> Apache Qpid has a JMS provider for AMQP, so just use that with
> ServiceMix's JMS components
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
Re: Servimiz + AMQP
Posted by James Strachan <ja...@gmail.com>.
On 2/9/07, Chandresh Turakhia <ch...@bhartitelesoft.com> wrote:
> Team,
>
> Any pointers as to how to integrating AMQP with JMS. Dirty hack also ok.
> I understand from newsgroup there is discrepancy between JMS and AMQP.
> http://www.rabbitmq.com/
>
> Need AMQP for Erisson Switch integration,
>
> Thanks in advance.
> Chand
Apache Qpid has a JMS provider for AMQP, so just use that with
ServiceMix's JMS components
--
James
-------
http://radio.weblogs.com/0112098/
Servimiz + AMQP
Posted by Chandresh Turakhia <ch...@bhartitelesoft.com>.
Team,
Any pointers as to how to integrating AMQP with JMS. Dirty hack also ok.
I understand from newsgroup there is discrepancy between JMS and AMQP.
http://www.rabbitmq.com/
Need AMQP for Erisson Switch integration,
Thanks in advance.
Chand
Re: General questions + Servicemiz + ofbiz
Posted by Chandresh Turakhia <ch...@bhartitelesoft.com>.
Add ServiceMix to the jingle. :)
I am not the best fan of Ofbiz web controller. It is nice and simple but
still needs help for multimodal architecture.
Also look at http://cargo.codehaus.org/ if you plan to start stop SMS
Container for reliability reasons in case of multiple kannels. I could not
till now make it work. But it should technically.
>>>pay, command (anything you may ever think using a cell phone).
Separate Instances of the ofbiz as "WebController" ofbiz and "Service
Engine" ofbiz. Struts2 can be morphed into great MultiModalContainer ( No
longer WebContainer ). Try Putting "Service Engines" of ofbiz as
ServiceEngine of ServiceMiz.
This is what I am trying to achieve. Shall do it.
>> Pay --- ofbiz has lot of Connectors but No banking Connectors :( . German
>> Banking or european banking connector is available in opensource. Please
>> check which helps you. Indian banking does not believe in
>> standardizations.
----- Original Message -----
From: "PRONZATO Cedric RD-BIZZ-GRE" <ce...@orange-ftgroup.com>
To: <us...@ofbiz.apache.org>
Sent: Friday, February 09, 2007 2:34 AM
Subject: RE: General questions
> Hi,
>
> Okay, I understand what you did. The component I planned to do was able to
> also act as a SMS Service (you know these short numbers) using the SMSC
> protocol. As for exemple it could allow you to pay, command (anything you
> may ever think using a cell phone).
> But you points me out a new part (for me) of OFBiz and that confirms the
> need of documentations related to: "how about to make my component well
> designed in this or this case".
>
> Thx,
> Cédric
>
> -----Message d'origine-----
> De : Chandresh Turakhia [mailto:chand.turakhia@bhartitelesoft.com]
> Envoyé : vendredi 9 février 2007 11:12
> À : user@ofbiz.apache.org
> Objet : Re: General questions
>
> Hi,
>
> I will try to answer Q3 ) Did some work on the same. Check (A3)
>
> Team , Please double check my answer. My hacks may not be the best . There
> is always better way !! and let the best win.
>
> Chand
> ----- Original Message -----
> From: "PRONZATO Cedric RD-BIZZ-GRE" <ce...@orange-ftgroup.com>
> To: <us...@ofbiz.apache.org>
> Sent: Friday, February 09, 2007 1:50 AM
> Subject: General questions
>
>
> Hi everybody,
>
>
>
> I am reading OFBiz and mailing list since a few months (I say that for
> previous talks about the presence of noobs involved).
>
> This said I will expose you things that I think could be enhanced in some
> parts of OFBiz:
>
>
>
> 1 - We (OFBiz) need better real life data showing firstly the whole
> possibility of applications (many tables are empty) and secondly a full
> range of items and catalogs.
>
> I hope someone could export its data (I am sure also open source projects
> use OFBiz and are not constrained by commercial stuff). That is really
> needed when you want to develop new functionalities in OFBiz.
>
> As for example, I would like to implement, test ... a "collaborative
> engine"
> but the task is already hard without have to make virtual products ...
>
> So what do you think about that?
>
>
>
> 2 - I also think we could enhance the project building and perhaps the
> "project development speed" by using a better eclipse "layout". I am not
> an
> expert but I don't think have a so big project which is modularized in a
> single eclipse project.
>
> Firstly have a subproject for each module will allow using eclipse
> compiler
> instead of using ant after editing files.
>
> Secondly we can only open the sub projects we really need for the task we
> want to do.
>
> Some times ago I tired to do it, but I did it on the wrong OFBiz
> subversion
> which caused to lose all my stuff to use the proper subversion. (Well that
> is the life).
>
> So what do you think about that?
>
>
>
> 3 - I wanted to make a SMS demonstration application (sending and
> receiving), I based my code on the mail container because I feel they are
> same on much points. But I lack of knowledge about the design/pattern I
> must
> use to do it properly into the OFBiz architecture. As I am sure I am not
> alone on the question "how about to make a properly designed OFBiz
> application", there are perhaps some docs to do about that.
>
> Once I am more formalized on questions and needs I will let you know and
> hope it will help as input to make these docs.
>
> So what do you think about that?
>
> A3)
>
> Step 1 )ofbiz\framework\minilang\src\org\ofbiz\minilang\method\callops or
> some directory Like CallService.java , make CallSMSHandler.java
>
> All you might have to do is call http hit on kannel url.
>
> Step 2 ) ofbiz\framework\minilang\dtd . IN simple-methods.xsd ; define
> tag
> "call-sms" for it
>
> Step 3 ) In ofbiz\framework\minilang\src\org\ofbiz\minilang , Add
> following
> code in SimpleMethod.java
>
> if ("call-sms".equals(nodeName)) {
> methodOperations.add(new
> org.ofbiz.minilang.method.callops.CallSMSHandler(curOperElem,
> simpleMethod));
> }
>
>
> Hope I am right :)
>
> Thx for the people who have reach the end of the mail and have read its
> content.
>
>
>
> Regards,
>
> Cédric
>
>
>
>
>
Re: General questions
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
Pre-emptive design? That'd be cool.
For best practices and other such information, see the docs site here:
http://docs.ofbiz.org/display/OFBADMIN/Development
-David
On Feb 9, 2007, at 3:34 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
> Hi,
>
> Okay, I understand what you did. The component I planned to do was
> able to also act as a SMS Service (you know these short numbers)
> using the SMSC protocol. As for exemple it could allow you to pay,
> command (anything you may ever think using a cell phone).
> But you points me out a new part (for me) of OFBiz and that
> confirms the need of documentations related to: "how about to make
> my component well designed in this or this case".
>
> Thx,
> Cédric
>
> -----Message d'origine-----
> De : Chandresh Turakhia [mailto:chand.turakhia@bhartitelesoft.com]
> Envoyé : vendredi 9 février 2007 11:12
> À : user@ofbiz.apache.org
> Objet : Re: General questions
>
> Hi,
>
> I will try to answer Q3 ) Did some work on the same. Check (A3)
>
> Team , Please double check my answer. My hacks may not be the
> best . There is always better way !! and let the best win.
>
> Chand
> ----- Original Message -----
> From: "PRONZATO Cedric RD-BIZZ-GRE" <cedric.pronzato@orange-
> ftgroup.com>
> To: <us...@ofbiz.apache.org>
> Sent: Friday, February 09, 2007 1:50 AM
> Subject: General questions
>
>
> Hi everybody,
>
>
>
> I am reading OFBiz and mailing list since a few months (I say that for
> previous talks about the presence of noobs involved).
>
> This said I will expose you things that I think could be enhanced
> in some
> parts of OFBiz:
>
>
>
> 1 - We (OFBiz) need better real life data showing firstly the whole
> possibility of applications (many tables are empty) and secondly a
> full
> range of items and catalogs.
>
> I hope someone could export its data (I am sure also open source
> projects
> use OFBiz and are not constrained by commercial stuff). That is really
> needed when you want to develop new functionalities in OFBiz.
>
> As for example, I would like to implement, test ... a
> "collaborative engine"
> but the task is already hard without have to make virtual products ...
>
> So what do you think about that?
>
>
>
> 2 - I also think we could enhance the project building and perhaps the
> "project development speed" by using a better eclipse "layout". I
> am not an
> expert but I don't think have a so big project which is modularized
> in a
> single eclipse project.
>
> Firstly have a subproject for each module will allow using eclipse
> compiler
> instead of using ant after editing files.
>
> Secondly we can only open the sub projects we really need for the
> task we
> want to do.
>
> Some times ago I tired to do it, but I did it on the wrong OFBiz
> subversion
> which caused to lose all my stuff to use the proper subversion.
> (Well that
> is the life).
>
> So what do you think about that?
>
>
>
> 3 - I wanted to make a SMS demonstration application (sending and
> receiving), I based my code on the mail container because I feel
> they are
> same on much points. But I lack of knowledge about the design/
> pattern I must
> use to do it properly into the OFBiz architecture. As I am sure I
> am not
> alone on the question "how about to make a properly designed OFBiz
> application", there are perhaps some docs to do about that.
>
> Once I am more formalized on questions and needs I will let you
> know and
> hope it will help as input to make these docs.
>
> So what do you think about that?
>
> A3)
>
> Step 1 )ofbiz\framework\minilang\src\org\ofbiz\minilang\method
> \callops or
> some directory Like CallService.java , make CallSMSHandler.java
>
> All you might have to do is call http hit on kannel url.
>
> Step 2 ) ofbiz\framework\minilang\dtd . IN simple-methods.xsd ;
> define tag
> "call-sms" for it
>
> Step 3 ) In ofbiz\framework\minilang\src\org\ofbiz\minilang , Add
> following
> code in SimpleMethod.java
>
> if ("call-sms".equals(nodeName)) {
> methodOperations.add(new
> org.ofbiz.minilang.method.callops.CallSMSHandler(curOperElem,
> simpleMethod));
> }
>
>
> Hope I am right :)
>
> Thx for the people who have reach the end of the mail and have read
> its
> content.
>
>
>
> Regards,
>
> Cédric
>
>
>
Re: General questions + Servicemiz + ofbiz
Posted by Chandresh Turakhia <ch...@bhartitelesoft.com>.
Add ServiceMix to the jingle. :)
I am not the best fan of Ofbiz web controller. It is nice and simple but
still needs help for multimodal architecture.
Also look at http://cargo.codehaus.org/ if you plan to start stop SMS
Container for reliability reasons in case of multiple kannels. I could not
till now make it work. But it should technically.
>>>pay, command (anything you may ever think using a cell phone).
Separate Instances of the ofbiz as "WebController" ofbiz and "Service
Engine" ofbiz. Struts2 can be morphed into great MultiModalContainer ( No
longer WebContainer ). Try Putting "Service Engines" of ofbiz as
ServiceEngine of ServiceMiz.
This is what I am trying to achieve. Shall do it.
>> Pay --- ofbiz has lot of Connectors but No banking Connectors :( . German
>> Banking or european banking connector is available in opensource. Please
>> check which helps you. Indian banking does not believe in
>> standardizations.
----- Original Message -----
From: "PRONZATO Cedric RD-BIZZ-GRE" <ce...@orange-ftgroup.com>
To: <us...@ofbiz.apache.org>
Sent: Friday, February 09, 2007 2:34 AM
Subject: RE: General questions
> Hi,
>
> Okay, I understand what you did. The component I planned to do was able to
> also act as a SMS Service (you know these short numbers) using the SMSC
> protocol. As for exemple it could allow you to pay, command (anything you
> may ever think using a cell phone).
> But you points me out a new part (for me) of OFBiz and that confirms the
> need of documentations related to: "how about to make my component well
> designed in this or this case".
>
> Thx,
> Cédric
>
> -----Message d'origine-----
> De : Chandresh Turakhia [mailto:chand.turakhia@bhartitelesoft.com]
> Envoyé : vendredi 9 février 2007 11:12
> À : user@ofbiz.apache.org
> Objet : Re: General questions
>
> Hi,
>
> I will try to answer Q3 ) Did some work on the same. Check (A3)
>
> Team , Please double check my answer. My hacks may not be the best . There
> is always better way !! and let the best win.
>
> Chand
> ----- Original Message -----
> From: "PRONZATO Cedric RD-BIZZ-GRE" <ce...@orange-ftgroup.com>
> To: <us...@ofbiz.apache.org>
> Sent: Friday, February 09, 2007 1:50 AM
> Subject: General questions
>
>
> Hi everybody,
>
>
>
> I am reading OFBiz and mailing list since a few months (I say that for
> previous talks about the presence of noobs involved).
>
> This said I will expose you things that I think could be enhanced in some
> parts of OFBiz:
>
>
>
> 1 - We (OFBiz) need better real life data showing firstly the whole
> possibility of applications (many tables are empty) and secondly a full
> range of items and catalogs.
>
> I hope someone could export its data (I am sure also open source projects
> use OFBiz and are not constrained by commercial stuff). That is really
> needed when you want to develop new functionalities in OFBiz.
>
> As for example, I would like to implement, test ... a "collaborative
> engine"
> but the task is already hard without have to make virtual products ...
>
> So what do you think about that?
>
>
>
> 2 - I also think we could enhance the project building and perhaps the
> "project development speed" by using a better eclipse "layout". I am not
> an
> expert but I don't think have a so big project which is modularized in a
> single eclipse project.
>
> Firstly have a subproject for each module will allow using eclipse
> compiler
> instead of using ant after editing files.
>
> Secondly we can only open the sub projects we really need for the task we
> want to do.
>
> Some times ago I tired to do it, but I did it on the wrong OFBiz
> subversion
> which caused to lose all my stuff to use the proper subversion. (Well that
> is the life).
>
> So what do you think about that?
>
>
>
> 3 - I wanted to make a SMS demonstration application (sending and
> receiving), I based my code on the mail container because I feel they are
> same on much points. But I lack of knowledge about the design/pattern I
> must
> use to do it properly into the OFBiz architecture. As I am sure I am not
> alone on the question "how about to make a properly designed OFBiz
> application", there are perhaps some docs to do about that.
>
> Once I am more formalized on questions and needs I will let you know and
> hope it will help as input to make these docs.
>
> So what do you think about that?
>
> A3)
>
> Step 1 )ofbiz\framework\minilang\src\org\ofbiz\minilang\method\callops or
> some directory Like CallService.java , make CallSMSHandler.java
>
> All you might have to do is call http hit on kannel url.
>
> Step 2 ) ofbiz\framework\minilang\dtd . IN simple-methods.xsd ; define
> tag
> "call-sms" for it
>
> Step 3 ) In ofbiz\framework\minilang\src\org\ofbiz\minilang , Add
> following
> code in SimpleMethod.java
>
> if ("call-sms".equals(nodeName)) {
> methodOperations.add(new
> org.ofbiz.minilang.method.callops.CallSMSHandler(curOperElem,
> simpleMethod));
> }
>
>
> Hope I am right :)
>
> Thx for the people who have reach the end of the mail and have read its
> content.
>
>
>
> Regards,
>
> Cédric
>
>
>
>
>
RE: General questions
Posted by PRONZATO Cedric RD-BIZZ-GRE <ce...@orange-ftgroup.com>.
Hi,
Okay, I understand what you did. The component I planned to do was able to also act as a SMS Service (you know these short numbers) using the SMSC protocol. As for exemple it could allow you to pay, command (anything you may ever think using a cell phone).
But you points me out a new part (for me) of OFBiz and that confirms the need of documentations related to: "how about to make my component well designed in this or this case".
Thx,
Cédric
-----Message d'origine-----
De : Chandresh Turakhia [mailto:chand.turakhia@bhartitelesoft.com]
Envoyé : vendredi 9 février 2007 11:12
À : user@ofbiz.apache.org
Objet : Re: General questions
Hi,
I will try to answer Q3 ) Did some work on the same. Check (A3)
Team , Please double check my answer. My hacks may not be the best . There is always better way !! and let the best win.
Chand
----- Original Message -----
From: "PRONZATO Cedric RD-BIZZ-GRE" <ce...@orange-ftgroup.com>
To: <us...@ofbiz.apache.org>
Sent: Friday, February 09, 2007 1:50 AM
Subject: General questions
Hi everybody,
I am reading OFBiz and mailing list since a few months (I say that for
previous talks about the presence of noobs involved).
This said I will expose you things that I think could be enhanced in some
parts of OFBiz:
1 - We (OFBiz) need better real life data showing firstly the whole
possibility of applications (many tables are empty) and secondly a full
range of items and catalogs.
I hope someone could export its data (I am sure also open source projects
use OFBiz and are not constrained by commercial stuff). That is really
needed when you want to develop new functionalities in OFBiz.
As for example, I would like to implement, test ... a "collaborative engine"
but the task is already hard without have to make virtual products ...
So what do you think about that?
2 - I also think we could enhance the project building and perhaps the
"project development speed" by using a better eclipse "layout". I am not an
expert but I don't think have a so big project which is modularized in a
single eclipse project.
Firstly have a subproject for each module will allow using eclipse compiler
instead of using ant after editing files.
Secondly we can only open the sub projects we really need for the task we
want to do.
Some times ago I tired to do it, but I did it on the wrong OFBiz subversion
which caused to lose all my stuff to use the proper subversion. (Well that
is the life).
So what do you think about that?
3 - I wanted to make a SMS demonstration application (sending and
receiving), I based my code on the mail container because I feel they are
same on much points. But I lack of knowledge about the design/pattern I must
use to do it properly into the OFBiz architecture. As I am sure I am not
alone on the question "how about to make a properly designed OFBiz
application", there are perhaps some docs to do about that.
Once I am more formalized on questions and needs I will let you know and
hope it will help as input to make these docs.
So what do you think about that?
A3)
Step 1 )ofbiz\framework\minilang\src\org\ofbiz\minilang\method\callops or
some directory Like CallService.java , make CallSMSHandler.java
All you might have to do is call http hit on kannel url.
Step 2 ) ofbiz\framework\minilang\dtd . IN simple-methods.xsd ; define tag
"call-sms" for it
Step 3 ) In ofbiz\framework\minilang\src\org\ofbiz\minilang , Add following
code in SimpleMethod.java
if ("call-sms".equals(nodeName)) {
methodOperations.add(new
org.ofbiz.minilang.method.callops.CallSMSHandler(curOperElem,
simpleMethod));
}
Hope I am right :)
Thx for the people who have reach the end of the mail and have read its
content.
Regards,
Cédric
Re: General questions
Posted by Chandresh Turakhia <ch...@bhartitelesoft.com>.
Hi,
I will try to answer Q3 ) Did some work on the same. Check (A3)
Team , Please double check my answer. My hacks may not be the best . There
is always better way !! and let the best win.
Chand
----- Original Message -----
From: "PRONZATO Cedric RD-BIZZ-GRE" <ce...@orange-ftgroup.com>
To: <us...@ofbiz.apache.org>
Sent: Friday, February 09, 2007 1:50 AM
Subject: General questions
Hi everybody,
I am reading OFBiz and mailing list since a few months (I say that for
previous talks about the presence of noobs involved).
This said I will expose you things that I think could be enhanced in some
parts of OFBiz:
1 - We (OFBiz) need better real life data showing firstly the whole
possibility of applications (many tables are empty) and secondly a full
range of items and catalogs.
I hope someone could export its data (I am sure also open source projects
use OFBiz and are not constrained by commercial stuff). That is really
needed when you want to develop new functionalities in OFBiz.
As for example, I would like to implement, test ... a "collaborative engine"
but the task is already hard without have to make virtual products ...
So what do you think about that?
2 - I also think we could enhance the project building and perhaps the
"project development speed" by using a better eclipse "layout". I am not an
expert but I don't think have a so big project which is modularized in a
single eclipse project.
Firstly have a subproject for each module will allow using eclipse compiler
instead of using ant after editing files.
Secondly we can only open the sub projects we really need for the task we
want to do.
Some times ago I tired to do it, but I did it on the wrong OFBiz subversion
which caused to lose all my stuff to use the proper subversion. (Well that
is the life).
So what do you think about that?
3 - I wanted to make a SMS demonstration application (sending and
receiving), I based my code on the mail container because I feel they are
same on much points. But I lack of knowledge about the design/pattern I must
use to do it properly into the OFBiz architecture. As I am sure I am not
alone on the question "how about to make a properly designed OFBiz
application", there are perhaps some docs to do about that.
Once I am more formalized on questions and needs I will let you know and
hope it will help as input to make these docs.
So what do you think about that?
A3)
Step 1 )ofbiz\framework\minilang\src\org\ofbiz\minilang\method\callops or
some directory Like CallService.java , make CallSMSHandler.java
All you might have to do is call http hit on kannel url.
Step 2 ) ofbiz\framework\minilang\dtd . IN simple-methods.xsd ; define tag
"call-sms" for it
Step 3 ) In ofbiz\framework\minilang\src\org\ofbiz\minilang , Add following
code in SimpleMethod.java
if ("call-sms".equals(nodeName)) {
methodOperations.add(new
org.ofbiz.minilang.method.callops.CallSMSHandler(curOperElem,
simpleMethod));
}
Hope I am right :)
Thx for the people who have reach the end of the mail and have read its
content.
Regards,
Cédric
Re: General questions
Posted by Adrian Crum <ad...@hlmksw.com>.
PRONZATO Cedric RD-BIZZ-GRE wrote:
> 1 - We (OFBiz) need better real life data showing firstly the whole possibility of applications (many tables are empty) and secondly a full range of items and catalogs.
+1
Re: [2] General questions
Posted by Jeff Mahurin <jl...@yahoo.com>.
I find it an irony, the quest to the top of the world is littered with the
defeated bodies of those who where unable to meet the final challenge.
Returning from the top of the world. That said building a website should not
be like climbing Mount Everest, always weary of the next step because you
don't know which rope someone else put out that might get you killed on the
way down more often than on the way up!
I must admit that many who venture here seem to be looking for tools that
can be reshaped. Others seem to be here looking to learn or for a
pleasurable journey, shared in good company. As for me I enjoy learning from
a well written, well organized and graphically illustrated/interesting
book/web site. These can be both relaxing, enlightening and invigorating. In
my time I have learned things we do with ease we also do with grace, and
such things soon take on a life that is vibrant and impossible to hide. This
inspires creativity and loosens the soul.
The other side to this coin is in space no one can hear you scream because
you don't have 15 minutes to string together an obstacle course represented
by a series of laborious documents and a labyrinth of hints.
;¬)
jonwimp wrote:
>
> Andrew,
>
> You're right. I've seen too many refactors and manhours wasted. But don't
> you often wish you had
> programmers who could hit the ground sprinting? I guess I do have this
> problem of telling
> everybody "you can do it, in minutes".
>
> I think all newbies should at least try to get the ML's help to review
> methods before proceeding
> (like I did).
>
> Be it bottom-up or top-down learning of OFBiz, I still say OFBiz is easy
> to pick up. And once we
> do, we'd wonder how to get on without it.
>
> I guess, in general (to answer the "General Questions"), there really is a
> point to learn OFBiz,
> whether it's tough or easy to learn. David wrote somewhere that OFBiz does
> try to use open source
> tools whenever feasible. OFBiz framework is a feasible tool, far as I can
> tell. (There ARE great
> tools out there that a quite infeasible, at least in some situations.)
>
> And now, other less important/general stuff.
>
> "Exhaustive study" to me equals an "evil automated language-processing
> heuristics search across
> all OFBiz examples and templates to catch candidates possible for use".
> Yeah, I did that. Every
> widget entity I use, I take apart that entity's insides, know how it works
> inside-out, then employ
> it (if it's appropriate).
>
> As for avoiding refactoring, there's always some "enough is enough" point
> where I leap off of my
> "let's make an ultra extensible structure" pre-project project. I've
> looked at Si Chen's examples
> of insulating codes from OFBiz core, looked at other examples outside of
> hot-deploy. Even studied
> database transactional integrity with the various methods (eca hook-ons,
> chained requests,
> extends, implements, etc). (Thanks especially to Jacopo and Chris Howe for
> some final-touch
> reviews of my "methods").
>
> So yeah, all newbies should be careful not to plunge in swimming in all
> the wrong directions. I
> like drowning, so don't follow me. I'm not a newbie, perhaps; I'm a nobody
> gone mad. Hmm. You
> could call David a similar nobody too (I just read his "usual approach"
> that looks like "wickedly
> agile R&D" to me).
>
> Jonathon
>
> Andrew Sykes wrote:
>> Jonathon,
>>
>> I think it's great that you found it so easy to learn, but I'd have to
>> urge caution to any newbie who thinks setting aside a time period
>> measured in minutes will be enough to get productive.
>>
>> Generally I find the longer people study the less refactoring they find
>> themselves doing down the line.
>>
>> Be very careful of writing code before you've undertaken an exhaustive
>> study!
>>
>> - Andrew
>>
>>
>> On Tue, 2007-02-13 at 14:20 +0800, Jonathon -- Improov wrote:
>>> Cedric,
>>>
>>> > Jonathon, a collaboration? Yes, why not? But I am sure I will not
>>> show you
>>> > much things because you are more experienced than me =)
>>>
>>> I started looking at OFBiz framework in Jan 07 (last month). I probably
>>> spent no more than a
>>> week(?) on learning OFBiz framework itself; much of my time was spent on
>>> data mapping and
>>> struggling(!!) with freeing my boss' data from legacy systems, and also
>>> on comparing OFBiz with
>>> other solutions (he kept knocking OFBiz big-time). I had no docs, no
>>> references (save xsd
>>> schemas), I even missed the cookbooks altogether (which really are quite
>>> skeletal, anyway).
>>>
>>> Believe me, OFBiz is easy to pick up.
>>>
>>> Somewhat exact time requirements (in case your boss asks):
>>>
>>> 1. 10 minutes to learn structure of OFBiz, so you know how to move
>>> around.
>>>
>>> 2. 1-2 minutes to look up anything related to OFBiz, since you'll be
>>> reading
>>> OFBiz like an open REFERENCE book.
>>>
>>> > there are questions about the use of screen/form widgets and
>>> > Beanshell/minilang. I am not well experienced but I don't know if
>>> developers
>>> > will like to learn these new things instead of working with what they
>>> know.
>>>
>>> As I mentioned in other threads, it IS possible to learn OFBiz inside of
>>> 10 minutes.
>>>
>>> But you could be right. IMHO, the lack of clear OFBiz framework
>>> references (not videos that are
>>> unsearchable) may be hindering the explosive growth of the OFBiz-enabled
>>> engineer population. Also
>>> IMHO, an explosion in the number of OFBiz-enabled engineers will likely
>>> feed back into OFBiz very
>>> rapidly. And further IMHO, David Jones (creator of OFBiz) will then
>>> probably have a whole army of
>>> willing volunteers to choose from (many open source projects employ
>>> ULTRA STRINGENT qualifying
>>> criteria to screen volunteers before making them committers; you do get
>>> many top brains in open
>>> source projects, so good that you/I probably can't ever argue with
>>> those).
>>>
>>> And finally, IMHO, I could be entirely wrong in above paragraph. I am
>>> not David Jones; I never
>>> created an open source project myself.
>>>
>>> Bottom line. OFBiz framework is solid (may need tweaks, but enhancements
>>> are on the way all the
>>> time). I'll be sorry if I missed it.
>>>
>>> Jonathon
>>>
>>> PRONZATO Cedric RD-BIZZ-GRE wrote:
>>>> Hi all,
>>>>
>>>> Yes, you are all true! My approach is bottom-up learning. All of you
>>>> here seem to read in me like an opened book; I now know that OFBiz is a
>>>> training area for FBI Profilers. :)
>>>>
>>>> My aim (I think) was to fully understand the framework to be able to
>>>> change/replace/add new *core* functionalities and test them in a real
>>>> ecommerce environment.
>>>> Yet I never played with 'call to a service' or so as the documents
>>>> about that was enough clear. I said: All should be OK on this part.
>>>> Entity engine and Service engine are clear and in respect of all the
>>>> common and trusted laws of java development. (By the way is there any
>>>> plan to turn to the new standards? OFBiz was in advance in 2000 but now
>>>> much developer well knows Spring just to name one ...)
>>>> So after these 2 majors things there are questions about the use of
>>>> screen/form widgets and Beanshell/minilang. I am not well experienced
>>>> but I don't know if developers will like to learn these new things
>>>> instead of working with what they know. So I decided to not investigate
>>>> it much.
>>>>
>>>> Jonathon, a collaboration? Yes, why not? But I am sure I will not show
>>>> you much things because you are more experienced than me =)
>>>> I will check about what I am allowed to do with my company policy but I
>>>> am confidant as OFBiz is a personal choice not too much tied to a
>>>> project need. I stay you tuned.
>>>>
>>>> I now have to think about what is wrong on this approach, think about
>>>> what is the next thing I have to investigate ...
>>>>
>>>> Thank you all,
>>>> Regards,
>>>> Cédric
>>>>
>>>> -----Message d'origine-----
>>>> De : Jonathon -- Improov [mailto:jonw@improov.com]
>>>> Envoyé : vendredi 9 février 2007 20:12
>>>> À : user@ofbiz.apache.org
>>>> Objet : Re: General questions
>>>>
>>>> Cedric,
>>>>
>>>> I get the same impression as Adrian too.
>>>>
>>>> Since you're from the R&D department, I suppose you're as much of a
>>>> freak as I am. I took apart OFBiz at the source code level too.
>>>>
>>>> Unless you're employing some language-processing heuristics in your
>>>> reverse-engineering, you'll be spending way too much time doing
>>>> brute-force studies from the bottom-up. Better to just learn from
>>>> playing with OFBiz framework (not the framework source codes), such as
>>>> service engine and entity engine, in this case.
>>>>
>>>> While it is true that learning by playing with the framework will
>>>> certainly be faster, I do admit it is not as easy as many would hope.
>>>> Technical references for working the OFBiz framework are not all in one
>>>> place, or even complete (mostly still in form of cookbooks at the
>>>> moment). Ie, there are no "javadocs equivalent" for the OFBiz
>>>> framework, except at
>>>> http://www.undersunconsulting.com/ecommerce/control/main .
>>>>
>>>> In fact, some folks here have never gotten around to using all of the
>>>> OFBiz framework. Some don't use screen/form widgets, but FTL instead.
>>>> Some use Beanshell rather than Minilang.
>>>>
>>>> I guess what I'm trying to say is this. Since you're from the R&D
>>>> department, it would be "within your scope" to learn the OFBiz
>>>> framework in any way possible, such as from studying the source codes
>>>> or playing with the framework itself. No use complaining what isn't
>>>> there; better to get things working somehow.
>>>>
>>>> For those not from the R&D department, though, then yes I do admit
>>>> OFBiz doesn't have a nice polished expensive "welcome mat/carpet" for
>>>> new users.
>>>>
>>>> If you do want to get help learning the OFBiz framework, you can either
>>>> work with me and write down all that I've discovered through my own
>>>> reverse-engineering, or you can employ some of the experts here to
>>>> teach you. I'll have to train some staff on OFBiz before I sign off my
>>>> current project, so your help here would be much appreciated.
>>>>
>>>> Hope you enjoy OFBiz as much as I have. :)
>>>>
>>>> Jonathon
>>>>
>>>> Adrian Crum wrote:
>>>>> Cedric,
>>>>>
>>>>> I might be wrong, but I get the impression you are trying to approach
>>>>> OFBiz from the bottom up (examining java classes versus examining
>>>>> higher-level layers). I made that mistake when I first got involved
>>>>> with OFBiz.
>>>>>
>>>>> It would be better to look at things like the service engine, entity
>>>>> engine, screen widgets, etc. Get an idea of how the presentation layer
>>>>> works, then work your way down to the service layer, then down to the
>>>>> database schema, etc.
>>>>>
>>>>> Typically, the only reason anyone would want to get into the java
>>>>> source would be to fix a bug or make a modification at a very low
>>>>> level of the architecture "stack."
>>>>>
>>>>>
>>>>>
>>>>> PRONZATO Cedric RD-BIZZ-GRE wrote:
>>>>>
>>>>>> Re,
>>>>>>
>>>>>> Yes you are true but I think I didn't explained myself.
>>>>>> These questions may have been answered in the javadocs. I am sure you
>>>>>> know (you that architects of OFBiz) why you decided to make a
>>>>>> Container class and so on.
>>>>>> So perhaps a little enhancement of javadoc on foundation classes to
>>>>>> explain why and where to use it would be so nice.
>>>>>>
>>>>>> I hope I do not look like too much arrogant with my questions on that
>>>>>> thread "General questions"; I just expose the problems I was faced
>>>>>> to.
>>>>>>
>>>>>> Regards,
>>>>>> Cédric
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : David E. Jones [mailto:jonesde@hotwaxmedia.com] Envoyé :
>>>>>> vendredi
>>>>>> 9 février 2007 18:12
>>>>>> À : user@ofbiz.apache.org
>>>>>> Objet : Re: General questions
>>>>>>
>>>>>>
>>>>>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
>>>>>>
>>>>>>
>>>>>>> A related problem is how to do "framework" components, I mean
>>>>>>> patterns. I think about my SMSC component, I base my code on the
>>>>>>> mail container and questions arised:
>>>>>>> - When do I have to make my own xml language (ie. MCA for the mail
>>>>>>> container)?
>>>>>>> - When do I have to make a Container? I guess the answer is if you
>>>>>>> have to manage the lifetime (create/release connections, ...).
>>>>>>> - When do I have to make an Engine?
>>>>>>> - ...
>>>>>>>
>>>>>>> So I guess we can finish with the following statement: "How to
>>>>>>> *use* is quite well documented but how to *make* is a bit less".
>>>>>> Have you ever found such a document for anything?
>>>>>>
>>>>>> My usual approach is generally something like:
>>>>>>
>>>>>> 1. understand everything that exists, or research anything that is
>>>>>> unclear 2. write something manually a number of times so you know
>>>>>> what is always the same, and what varies 3. see if a paramerized tool
>>>>>> would be helpful 4. apply a significant amount of "genius"
>>>>>> 5. apply even more "sweat" to try stuff 6. create an incredible tool
>>>>>> or service or however it is best implemented
>>>>>>
>>>>>> If there was a way to make creation deterministic, what would be the
>>>>>> point of creativity?
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>
>
>
>
--
View this message in context: http://www.nabble.com/General-questions-tf3199396.html#a8960121
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: General questions
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Feb 9, 2007, at 5:14 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
>>> 3 - I wanted to make a SMS demonstration application (sending and
>>> receiving), I based my code on the mail container because I feel
>>> they are same on much points. But I lack of knowledge about the
>>> design/pattern I must use to do it properly into the OFBiz
>>> >>architecture. As I am sure I am not alone on the question "how
>>> about to make a properly designed OFBiz application", there >>are
>>> perhaps some docs to do about that.
>
>> Did you read the Data Model Ressource Book (at least Vol. 1)
>> recommended in http://ofbiz.apache.org/documents.html ?
> I have to admin that the answer is no. But what is needed is a
> documentation on that point related to OFBiz architecture only.
> "Not a general book."
Check out docs.ofbiz.org. There is lots of good stuff there.
For an introduction to the framework, look at:
Framework Introduction Videos and Diagrams: http://docs.ofbiz.org/x/PQM
-David
RE: General questions
Posted by PRONZATO Cedric RD-BIZZ-GRE <ce...@orange-ftgroup.com>.
Re Jacques,
-----Message d'origine-----
De : Jacques Le Roux [mailto:jacques.le.roux@les7arts.com]
Envoyé : vendredi 9 février 2007 11:38
À : user@ofbiz.apache.org
Objet : Re: General questions
>Cedric,
>Only responses to 2 and 3
>>2 - I also think we could enhance the project building and perhaps the
>>"project development speed" by using a better eclipse
>>"layout". I am not an expert but I don't think have a so big project which is modularized in a single eclipse project.
>>Firstly have a subproject for each module will allow using eclipse compiler instead of using ant after editing files.
>Why not running only the component build.xml thru ant in Eclipse (Contextual menu Run As/Ant Build) ?
The aim would be at the end to have tomcat running in auto "auto redeploy" on file change. Well, I am the kind of people who use the result to drive the input (aka noobs or whatever you call this behaviour). So having to use ant and so on to redeploy the application is a bit heavy.
By the way I don't know if it is crappy to do that or no, that is why I ask =)
>>Secondly we can only open the sub projects we really need for the task we want to do.
>Not sure this makes really sense as there is some interdependance between components
Well, there are dependencies but right now we don't see them much (the "depends-on" tags is never used in the current components).
So having the "depends-on" filled and having the mimic in eclipse subprojects is, I think, a good idea.
>>3 - I wanted to make a SMS demonstration application (sending and
>>receiving), I based my code on the mail container because I feel
>>they are same on much points. But I lack of knowledge about the design/pattern I must use to do it properly into the OFBiz >>architecture. As I am sure I am not alone on the question "how about to make a properly designed OFBiz application", there >>are perhaps some docs to do about that.
>Did you read the Data Model Ressource Book (at least Vol. 1) recommended in http://ofbiz.apache.org/documents.html ?
I have to admin that the answer is no. But what is needed is a documentation on that point related to OFBiz architecture only. "Not a general book."
>>Jacques
Cédric,
Re: General questions
Posted by Jacques Le Roux <ja...@les7arts.com>.
Chris,
> I'm shocked Jacques, this is a perfect opportunity to plug Mylar :-)
Mylar is great, but I'm not sure it would be useful in what Cedric wants to achieve :p
Either I'm no sure to have clearly understood what he tries to achieve, so perhaps you are right ;o)
Jacques
Re: General questions
Posted by Chandresh Turakhia <ch...@bhartitelesoft.com>.
Cédric .
You asked what I was afraid to ask and spent too much time.Can I answer a bit quickly.shall answer again later. Will enlarge questions a bit.
This is how I did bit of my hacking.
> - What is the strategy to use to extend functionalities of a component?
---
--- How do add / delete predefined columns in database ===> entity*.xml
NOTE : it does not remove columns after run-install. But still manageale.
---- will it affect my code. How many places should I have change the code if 1 field is added or removed.
No exact answer... Can someone help.
--- How do change the business process.
--- Shark is being added.
Hopefully it becomes simpler
There needs to "Strategy" Pattern to be used. SubClass can vary functionality.
> - What is the strategy to use to only change the presentation of a component?
-- CSS only change. Could not do anything.
-- Can I request THIS FEATURE. Ofbiz Uses FreeMarker, but I feel there is still room for improvement.
a.. Store .html files and .ftl related code in separate files and make .ftl using XSLT in ant-pre-built.
b.. In this way normal HTML editors can be used. I could find any editor ftl good enough.
c.. This allows integration with Device Management XSLT easily. ( Device based Widget creation )
> - What is the strategy to use to change the implementation of a component?
Need Better IOC :) Check ML archieve.
More later. Nice if some one can discuss the feature I would like have - pros and cons.
Chand
----- Original Message -----
From: "PRONZATO Cedric RD-BIZZ-GRE" <ce...@orange-ftgroup.com>
To: <us...@ofbiz.apache.org>
Sent: Friday, February 09, 2007 4:35 AM
Subject: RE: General questions
> Hi Chris,
>
> Indeed it was for customizations, and yes I saw that modifying the existing source code is not the best. But even that, isn't that bad to have this component view into eclipse either? I don't know if a bench exists somewhere to tell us if it has a performance sense to only open the subsprojects you really need.
>
> Customization question is the second question any OFBiz user is faced. I still not have answered to it because yet I didn't make any component for OFBiz.
> I am not sure to have see a topic on that in the wiki, if you (gods) have the time to make to us (beginners) a little section about that.
> - What is the strategy to use to extend functionalities of a component?
> - What is the strategy to use to only change the presentation of a component?
> - What is the strategy to use to change the implementation of a component?
> - ...
> - What is the strategy to use to make a new component (this one is the only one I can answer and being sure: hotdeploy folder)
>
> These questions are perhaps not the best, it is just a try to explain to you.
>
> Beside that I am also still not sure about the subversion strategy to use to handle my customizations. I am aware software vendor branches (also explain in the wiki) but till I did not try it for real I will not be sure because it seems to be painful.
>
> Thx,
> Cédric
>
> -----Message d'origine-----
> De : Chris Howe [mailto:cjhowe76013@yahoo.com]
> Envoyé : vendredi 9 février 2007 12:04
> À : user@ofbiz.apache.org; Jacques Le Roux
> Objet : Re: General questions
>
> I'm shocked Jacques, this is a perfect opportunity to plug Mylar :-)
>
> --- Jacques Le Roux <ja...@les7arts.com> wrote in reply to
> Cédric:
>> >Secondly we can only open the sub projects we really need for the
>> task we want to do.
>> Not sure this makes really sense as there is some interdependance
>> between components
>>
>
> You should really checkout the Mylar http://www.eclipse.org/mylar/ plugin for eclipse. It will really help you to be task focused given the interdependence that exists. Especially the interdependence you will be creating with your custom applications.
>
> Cédric,
> I hope I am wrong on this, but your question regarding the eclipse layout suggests to me you might be customizing OFBiz by editing OFBiz components themselves (ie making changes in the applications/ecommerce/... folder directly) instead of extending OFBiz with your own custom components (ie hotdeploy/myapp/...). This can get you in a big mess when you go to update OFBiz. If you could confirm how you are customizing, the community and I may be able to help you get things reorganized and save your "such is life" headache from occurring again.
>
>
Re: General questions
Posted by Jacques Le Roux <ja...@les7arts.com>.
I don't know if it's Cedric's case but I made the same mistake.
Jacques
> Cedric,
>
> I might be wrong, but I get the impression you are trying to approach OFBiz from
> the bottom up (examining java classes versus examining higher-level layers). I
> made that mistake when I first got involved with OFBiz.
>
> It would be better to look at things like the service engine, entity engine,
> screen widgets, etc. Get an idea of how the presentation layer works, then work
> your way down to the service layer, then down to the database schema, etc.
>
> Typically, the only reason anyone would want to get into the java source would
> be to fix a bug or make a modification at a very low level of the architecture
> "stack."
>
>
>
> PRONZATO Cedric RD-BIZZ-GRE wrote:
>
> > Re,
> >
> > Yes you are true but I think I didn't explained myself.
> > These questions may have been answered in the javadocs. I am sure you know (you that architects of OFBiz) why you decided to
make a Container class and so on.
> > So perhaps a little enhancement of javadoc on foundation classes to explain why and where to use it would be so nice.
> >
> > I hope I do not look like too much arrogant with my questions on that thread "General questions"; I just expose the problems I
was faced to.
> >
> > Regards,
> > Cédric
> >
> > -----Message d'origine-----
> > De : David E. Jones [mailto:jonesde@hotwaxmedia.com]
> > Envoyé : vendredi 9 février 2007 18:12
> > À : user@ofbiz.apache.org
> > Objet : Re: General questions
> >
> >
> > On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
> >
> >
> >>A related problem is how to do "framework" components, I mean
> >>patterns. I think about my SMSC component, I base my code on the mail
> >>container and questions arised:
> >> - When do I have to make my own xml language (ie. MCA for the mail
> >>container)?
> >> - When do I have to make a Container? I guess the answer is if you
> >>have to manage the lifetime (create/release connections, ...).
> >> - When do I have to make an Engine?
> >> - ...
> >>
> >>So I guess we can finish with the following statement: "How to
> >>*use* is quite well documented but how to *make* is a bit less".
> >
> >
> > Have you ever found such a document for anything?
> >
> > My usual approach is generally something like:
> >
> > 1. understand everything that exists, or research anything that is unclear 2. write something manually a number of times so you
know what is always the same, and what varies 3. see if a paramerized tool would be helpful 4. apply a significant amount of
"genius"
> > 5. apply even more "sweat" to try stuff
> > 6. create an incredible tool or service or however it is best implemented
> >
> > If there was a way to make creation deterministic, what would be the point of creativity?
> >
> > -David
> >
> >
Re: General questions
Posted by David Goodenough <da...@linkchoose.co.uk>.
On Monday 12 February 2007 09:38, Chandresh Turakhia wrote:
> Please be thanked to read into details of my 2 cents
>
> We all are from R&D teams. Can we pool up resources to add few stuff to
> OFbiz.
>
> I agree challenge with ofbiz it was ahead of time but "Open Source Changes
> Everything".
>
> Things / Ideas I want to add to ofbiz
>
> (1) C-JDBC drivers. --- I know it is LPGL. I want to understand the
> benefits of C-JDBC if add to the mix
HA-JDBC would be a lot easier to do. It only requires a change to the
JDBC URLs and there are things that C-JDBC does not support that I think
OfBiz needs.
David
> (2) OpenTerracotta --- For seamless clustering if possible.
> http://www.terracotta.org/confluence/display/orgsite/Download
>
> Note : Lots of open source uses struts ; spring. They keep adding to the
> established Open source as value add.
>
> Any pointers of usefullness of (1) and (2) and how much it can add to
> performance.
>
> Chand
>
> ----- Original Message -----
> From: "PRONZATO Cedric RD-BIZZ-GRE" <ce...@orange-ftgroup.com>
> To: <us...@ofbiz.apache.org>
> Sent: Monday, February 12, 2007 1:07 AM
> Subject: RE: General questions
>
> > Hi all,
> >
> > Yes, you are all true! My approach is bottom-up learning. All of you here
> > seem to read in me like an opened book; I now know that OFBiz is a
> > training area for FBI Profilers. :)
> >
> > My aim (I think) was to fully understand the framework to be able to
> > change/replace/add new *core* functionalities and test them in a real
> > ecommerce environment.
> > Yet I never played with 'call to a service' or so as the documents about
> > that was enough clear. I said: All should be OK on this part.
> > Entity engine and Service engine are clear and in respect of all the
> > common and trusted laws of java development. (By the way is there any
> > plan to turn to the new standards? OFBiz was in advance in 2000 but now
> > much developer well knows Spring just to name one ...)
> > So after these 2 majors things there are questions about the use of
> > screen/form widgets and Beanshell/minilang. I am not well experienced but
> > I don't know if developers will like to learn these new things instead of
> > working with what they know. So I decided to not investigate it much.
> >
> > Jonathon, a collaboration? Yes, why not? But I am sure I will not show
> > you much things because you are more experienced than me =)
> > I will check about what I am allowed to do with my company policy but I
> > am confidant as OFBiz is a personal choice not too much tied to a project
> > need. I stay you tuned.
> >
> > I now have to think about what is wrong on this approach, think about
> > what is the next thing I have to investigate ...
> >
> > Thank you all,
> > Regards,
> > Cédric
> >
> > -----Message d'origine-----
> > De : Jonathon -- Improov [mailto:jonw@improov.com]
> > Envoyé : vendredi 9 février 2007 20:12
> > À : user@ofbiz.apache.org
> > Objet : Re: General questions
> >
> > Cedric,
> >
> > I get the same impression as Adrian too.
> >
> > Since you're from the R&D department, I suppose you're as much of a freak
> > as I am. I took apart OFBiz at the source code level too.
> >
> > Unless you're employing some language-processing heuristics in your
> > reverse-engineering, you'll be spending way too much time doing
> > brute-force studies from the bottom-up. Better to just learn from playing
> > with OFBiz framework (not the framework source codes), such as service
> > engine and entity engine, in this case.
> >
> > While it is true that learning by playing with the framework will
> > certainly be faster, I do admit it is not as easy as many would hope.
> > Technical references for working the OFBiz framework are not all in one
> > place, or even complete (mostly still in form of cookbooks at the
> > moment). Ie, there are no "javadocs equivalent" for the OFBiz framework,
> > except at http://www.undersunconsulting.com/ecommerce/control/main .
> >
> > In fact, some folks here have never gotten around to using all of the
> > OFBiz framework. Some don't use screen/form widgets, but FTL instead.
> > Some use Beanshell rather than Minilang.
> >
> > I guess what I'm trying to say is this. Since you're from the R&D
> > department, it would be "within your scope" to learn the OFBiz framework
> > in any way possible, such as from studying the source codes or playing
> > with the framework itself. No use complaining what isn't there; better to
> > get things working somehow.
> >
> > For those not from the R&D department, though, then yes I do admit OFBiz
> > doesn't have a nice polished expensive "welcome mat/carpet" for new
> > users.
> >
> > If you do want to get help learning the OFBiz framework, you can either
> > work with me and write down all that I've discovered through my own
> > reverse-engineering, or you can employ some of the experts here to teach
> > you. I'll have to train some staff on OFBiz before I sign off my current
> > project, so your help here would be much appreciated.
> >
> > Hope you enjoy OFBiz as much as I have. :)
> >
> > Jonathon
> >
> > Adrian Crum wrote:
> >> Cedric,
> >>
> >> I might be wrong, but I get the impression you are trying to approach
> >> OFBiz from the bottom up (examining java classes versus examining
> >> higher-level layers). I made that mistake when I first got involved
> >> with OFBiz.
> >>
> >> It would be better to look at things like the service engine, entity
> >> engine, screen widgets, etc. Get an idea of how the presentation layer
> >> works, then work your way down to the service layer, then down to the
> >> database schema, etc.
> >>
> >> Typically, the only reason anyone would want to get into the java
> >> source would be to fix a bug or make a modification at a very low
> >> level of the architecture "stack."
> >>
> >> PRONZATO Cedric RD-BIZZ-GRE wrote:
> >>> Re,
> >>>
> >>> Yes you are true but I think I didn't explained myself.
> >>> These questions may have been answered in the javadocs. I am sure you
> >>> know (you that architects of OFBiz) why you decided to make a
> >>> Container class and so on.
> >>> So perhaps a little enhancement of javadoc on foundation classes to
> >>> explain why and where to use it would be so nice.
> >>>
> >>> I hope I do not look like too much arrogant with my questions on that
> >>> thread "General questions"; I just expose the problems I was faced to.
> >>>
> >>> Regards,
> >>> Cédric
> >>>
> >>> -----Message d'origine-----
> >>> De : David E. Jones [mailto:jonesde@hotwaxmedia.com] Envoyé :
> >>> vendredi
> >>> 9 février 2007 18:12
> >>> À : user@ofbiz.apache.org
> >>> Objet : Re: General questions
> >>>
> >>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
> >>>> A related problem is how to do "framework" components, I mean
> >>>> patterns. I think about my SMSC component, I base my code on the
> >>>> mail container and questions arised:
> >>>> - When do I have to make my own xml language (ie. MCA for the mail
> >>>> container)?
> >>>> - When do I have to make a Container? I guess the answer is if you
> >>>> have to manage the lifetime (create/release connections, ...).
> >>>> - When do I have to make an Engine?
> >>>> - ...
> >>>>
> >>>> So I guess we can finish with the following statement: "How to
> >>>> *use* is quite well documented but how to *make* is a bit less".
> >>>
> >>> Have you ever found such a document for anything?
> >>>
> >>> My usual approach is generally something like:
> >>>
> >>> 1. understand everything that exists, or research anything that is
> >>> unclear 2. write something manually a number of times so you know
> >>> what is always the same, and what varies 3. see if a paramerized tool
> >>> would be helpful 4. apply a significant amount of "genius"
> >>> 5. apply even more "sweat" to try stuff 6. create an incredible tool
> >>> or service or however it is best implemented
> >>>
> >>> If there was a way to make creation deterministic, what would be the
> >>> point of creativity?
> >>>
> >>> -David
Re: General questions
Posted by Chandresh Turakhia <ch...@bhartitelesoft.com>.
Please be thanked to read into details of my 2 cents
We all are from R&D teams. Can we pool up resources to add few stuff to
OFbiz.
I agree challenge with ofbiz it was ahead of time but "Open Source Changes
Everything".
Things / Ideas I want to add to ofbiz
(1) C-JDBC drivers. --- I know it is LPGL. I want to understand the benefits
of C-JDBC if add to the mix
(2) OpenTerracotta --- For seamless clustering if possible.
http://www.terracotta.org/confluence/display/orgsite/Download
Note : Lots of open source uses struts ; spring. They keep adding to the
established Open source as value add.
Any pointers of usefullness of (1) and (2) and how much it can add to
performance.
Chand
----- Original Message -----
From: "PRONZATO Cedric RD-BIZZ-GRE" <ce...@orange-ftgroup.com>
To: <us...@ofbiz.apache.org>
Sent: Monday, February 12, 2007 1:07 AM
Subject: RE: General questions
> Hi all,
>
> Yes, you are all true! My approach is bottom-up learning. All of you here
> seem to read in me like an opened book; I now know that OFBiz is a
> training area for FBI Profilers. :)
>
> My aim (I think) was to fully understand the framework to be able to
> change/replace/add new *core* functionalities and test them in a real
> ecommerce environment.
> Yet I never played with 'call to a service' or so as the documents about
> that was enough clear. I said: All should be OK on this part.
> Entity engine and Service engine are clear and in respect of all the
> common and trusted laws of java development. (By the way is there any plan
> to turn to the new standards? OFBiz was in advance in 2000 but now much
> developer well knows Spring just to name one ...)
> So after these 2 majors things there are questions about the use of
> screen/form widgets and Beanshell/minilang. I am not well experienced but
> I don't know if developers will like to learn these new things instead of
> working with what they know. So I decided to not investigate it much.
>
> Jonathon, a collaboration? Yes, why not? But I am sure I will not show you
> much things because you are more experienced than me =)
> I will check about what I am allowed to do with my company policy but I am
> confidant as OFBiz is a personal choice not too much tied to a project
> need. I stay you tuned.
>
> I now have to think about what is wrong on this approach, think about what
> is the next thing I have to investigate ...
>
> Thank you all,
> Regards,
> Cédric
>
> -----Message d'origine-----
> De : Jonathon -- Improov [mailto:jonw@improov.com]
> Envoyé : vendredi 9 février 2007 20:12
> À : user@ofbiz.apache.org
> Objet : Re: General questions
>
> Cedric,
>
> I get the same impression as Adrian too.
>
> Since you're from the R&D department, I suppose you're as much of a freak
> as I am. I took apart OFBiz at the source code level too.
>
> Unless you're employing some language-processing heuristics in your
> reverse-engineering, you'll be spending way too much time doing
> brute-force studies from the bottom-up. Better to just learn from playing
> with OFBiz framework (not the framework source codes), such as service
> engine and entity engine, in this case.
>
> While it is true that learning by playing with the framework will
> certainly be faster, I do admit it is not as easy as many would hope.
> Technical references for working the OFBiz framework are not all in one
> place, or even complete (mostly still in form of cookbooks at the moment).
> Ie, there are no "javadocs equivalent" for the OFBiz framework, except at
> http://www.undersunconsulting.com/ecommerce/control/main .
>
> In fact, some folks here have never gotten around to using all of the
> OFBiz framework. Some don't use screen/form widgets, but FTL instead. Some
> use Beanshell rather than Minilang.
>
> I guess what I'm trying to say is this. Since you're from the R&D
> department, it would be "within your scope" to learn the OFBiz framework
> in any way possible, such as from studying the source codes or playing
> with the framework itself. No use complaining what isn't there; better to
> get things working somehow.
>
> For those not from the R&D department, though, then yes I do admit OFBiz
> doesn't have a nice polished expensive "welcome mat/carpet" for new users.
>
> If you do want to get help learning the OFBiz framework, you can either
> work with me and write down all that I've discovered through my own
> reverse-engineering, or you can employ some of the experts here to teach
> you. I'll have to train some staff on OFBiz before I sign off my current
> project, so your help here would be much appreciated.
>
> Hope you enjoy OFBiz as much as I have. :)
>
> Jonathon
>
> Adrian Crum wrote:
>> Cedric,
>>
>> I might be wrong, but I get the impression you are trying to approach
>> OFBiz from the bottom up (examining java classes versus examining
>> higher-level layers). I made that mistake when I first got involved
>> with OFBiz.
>>
>> It would be better to look at things like the service engine, entity
>> engine, screen widgets, etc. Get an idea of how the presentation layer
>> works, then work your way down to the service layer, then down to the
>> database schema, etc.
>>
>> Typically, the only reason anyone would want to get into the java
>> source would be to fix a bug or make a modification at a very low
>> level of the architecture "stack."
>>
>>
>>
>> PRONZATO Cedric RD-BIZZ-GRE wrote:
>>
>>> Re,
>>>
>>> Yes you are true but I think I didn't explained myself.
>>> These questions may have been answered in the javadocs. I am sure you
>>> know (you that architects of OFBiz) why you decided to make a
>>> Container class and so on.
>>> So perhaps a little enhancement of javadoc on foundation classes to
>>> explain why and where to use it would be so nice.
>>>
>>> I hope I do not look like too much arrogant with my questions on that
>>> thread "General questions"; I just expose the problems I was faced to.
>>>
>>> Regards,
>>> Cédric
>>>
>>> -----Message d'origine-----
>>> De : David E. Jones [mailto:jonesde@hotwaxmedia.com] Envoyé :
>>> vendredi
>>> 9 février 2007 18:12
>>> À : user@ofbiz.apache.org
>>> Objet : Re: General questions
>>>
>>>
>>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
>>>
>>>
>>>> A related problem is how to do "framework" components, I mean
>>>> patterns. I think about my SMSC component, I base my code on the
>>>> mail container and questions arised:
>>>> - When do I have to make my own xml language (ie. MCA for the mail
>>>> container)?
>>>> - When do I have to make a Container? I guess the answer is if you
>>>> have to manage the lifetime (create/release connections, ...).
>>>> - When do I have to make an Engine?
>>>> - ...
>>>>
>>>> So I guess we can finish with the following statement: "How to
>>>> *use* is quite well documented but how to *make* is a bit less".
>>>
>>>
>>> Have you ever found such a document for anything?
>>>
>>> My usual approach is generally something like:
>>>
>>> 1. understand everything that exists, or research anything that is
>>> unclear 2. write something manually a number of times so you know
>>> what is always the same, and what varies 3. see if a paramerized tool
>>> would be helpful 4. apply a significant amount of "genius"
>>> 5. apply even more "sweat" to try stuff 6. create an incredible tool
>>> or service or however it is best implemented
>>>
>>> If there was a way to make creation deterministic, what would be the
>>> point of creativity?
>>>
>>> -David
>>>
>>>
>>
>
>
>
Re: General questions
Posted by Jacopo Cappellato <ti...@sastau.it>.
David E. Jones wrote:
> If there were other open source projects we could lean on to eliminate
> framework tools, I'd totally push for it, but I have yet to see anything
> that would do the trick.
>
> -David
>
>
And I'd say that an higher priority is to find out a good alternative
for the OFBiz connection pool (still based on an old/customized version
of Minerva)... we also recently tried to find a good open source tool
that could fit the requirements of OFBiz but without too luck.
Jacopo
Re: General questions ( ServiceMiz )
Posted by Chandresh Turakhia <ch...@bhartitelesoft.com>.
Team,
My Question ) Whats the quickest hack to make Ofbiz services as ServiceMiz
SE ?
Question asked to me )
Usecase for ServiceMiz. Answering "why you want to use ServiceMiz ".
Distributed JBI ( Celtrix ) can save us lot on Roaming charges - Lot term
view.
Answer )
http://www.logicblaze.com/ ( ServiceMiz and Fuse )
On the minimum front , decoupling the request ( HTTP , Wireless ) and
actual service is good. Also integrating Telecom Authentication from jNetX
( Telecom Application server - SOA of telecom ) integration could be easily
scritable in ServiceMiz.
We telecom company needs such functionality even if it hurts a bit on
performance. Binding component for request handlers. Some of the services
needs to trigger based on arrival of file ( ftp ).
ServiceMiz uses
http://www.enterpriseintegrationpatterns.com/DynamicRouter.html Dynamic
router pattern to send servicerequest on different instances on ofbiz based
on different request parametetrs. It is scriptable to implement in
ServiceMIX.
e.g. We might have
ofbiz service server 1 with data for Northern India and code
customized for Northern indian law. - small changes.
ofbiz service server 2 with data from southern India
ofbiz service server 3 with data from rest of india.
We may want to direct to different servers EVEN if the code is same. Help
legal issues.
Also Cost consideration , the return SMS needs to sent from NEAREST
location so telecom bill is less.
Also different circles have different telecom infrastructure :) so based on
the location the logic changes. e.g Sometimes we do not get XXX information
if the request comes from XYZ zone, so there is lot of hacking code around.
There is lot of "dumb" reason which we need separate service integrator.
Chand
>
> On Feb 13, 2007, at 1:15 AM, Chandresh Turakhia wrote:
>
>> David & team
>>
>> We do need cross pollination between Apache projects - Lets bank on it.
>> Open source works on Word of mouth.
>>
>> (1) ServiceMix - Fuse framework for services - James from Logicblaze
>> might appreciate too.
>
> IMO ServiceMix is a good alternative to Axis (and much more flexible) and
> would complement the Service Engine in OFBiz, but it would in no way
> would it be able to replace it.
>
Re: General questions
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Feb 13, 2007, at 1:15 AM, Chandresh Turakhia wrote:
> David & team
>
> We do need cross pollination between Apache projects - Lets bank on
> it. Open source works on Word of mouth.
>
> (1) ServiceMix - Fuse framework for services - James from
> Logicblaze might appreciate too.
IMO ServiceMix is a good alternative to Axis (and much more flexible)
and would complement the Service Engine in OFBiz, but it would in no
way would it be able to replace it.
> (2) XAL - Let me talk to Bob from nexaweb, we can help you convert
> in mass to XAL-HTML . Think about it.
This looks like a nice tool and it would be great to use it going
forward.
I don't like the idea of doing any sort of mass conversion because
many pages simply don't need AJAX-like functionality, and it would be
best to keep these as simple and multi-browser friendly as possible.
Simplicity has other advantages too, like being easier to create and
maintain in general.
> (3) C-JDBC
This is a cool tool and great for use in production to be used as
part of deployment efforts. I guess the best thing to do for this is
document how to use it with OFBiz.
> Ofbiz was way ahead of time...... But open source changes
> everything. Please understand the "drop-out" candidates due to lots
> of new learning.
I guess I'm missing something... how would use of these other
projects reduce the learning curve for OFBiz?
In general the OFBiz framework is still unique in my opinion. From
the beginning we have tried to use other open source projects
wherever possible, but so many popular approaches are just no good
for development and maintenance of large scale enterprise
applications. If there were other open source projects we could lean
on to eliminate framework tools, I'd totally push for it, but I have
yet to see anything that would do the trick.
-David
Re: General questions
Posted by Chandresh Turakhia <ch...@bhartitelesoft.com>.
David & team
We do need cross pollination between Apache projects - Lets bank on it. Open source works on Word of mouth.
(1) ServiceMix - Fuse framework for services - James from Logicblaze might appreciate too.
(2) XAL - Let me talk to Bob from nexaweb, we can help you convert in mass to XAL-HTML . Think about it.
(3) C-JDBC
Ofbiz was way ahead of time...... But open source changes everything. Please understand the "drop-out" candidates due to lots of new learning.
my 2 cents on acceptance of framework.
Half of career has being in US telecom and rest in India. It is culturally more challenging in India / Asia for non - standard approaches for web frameworks.
e.g Verizon for VXML ( Voice XML ) decided to use customized Struts.Verizon Software team wrote extensions back in 2000. VXML needs something like SCXML for reusable dialogs which finally came in Struts2. While it is not possible in Asian scenarios.You have back ur decisions with case studies. Better if case study is that field - finance to win the debate. e.g I see some value in C-JDBC . But it is 3 months and I am still backing my case.
It is funny that moment something becomes defacto standard and is asked by US CLIENTS , Indian Software companies churn out guys well-versed in that software in millions :) but very few take the first risk even if it architecturally beautiful. While French simply cannot stop appreciately good architecture. Someone found it challenging to make them accept standard software like JSP. You are bound to loose them in architectural debate.
Open Source is to some extent about credibility of suggestions. I was not the best fan of Freemarket but http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse Mark Rabbies article on Freemaker made me feel JSP 2.0 is more or less Freemarker. we had managed to get Appfuse in Large bank's Archtiecture and Mark article made me Look at Freemarker with better frame of mind. It clicked.
Chand
----- Original Message -----
From: "David E. Jones" <jo...@hotwaxmedia.com>
To: <us...@ofbiz.apache.org>
Sent: Monday, February 12, 2007 11:38 PM
Subject: Re: General questions
>
> On Feb 12, 2007, at 11:20 PM, Jonathon -- Improov wrote:
>
>> But you could be right. IMHO, the lack of clear OFBiz framework
>> references (not videos that are unsearchable) may be hindering the
>> explosive growth of the OFBiz-enabled engineer population. Also
>> IMHO, an explosion in the number of OFBiz-enabled engineers will
>> likely feed back into OFBiz very rapidly. And further IMHO, David
>> Jones (creator of OFBiz) will then probably have a whole army of
>> willing volunteers to choose from (many open source projects employ
>> ULTRA STRINGENT qualifying criteria to screen volunteers before
>> making them committers; you do get many top brains in open source
>> projects, so good that you/I probably can't ever argue with those).
>>
>> And finally, IMHO, I could be entirely wrong in above paragraph. I
>> am not David Jones; I never created an open source project myself.
>
> If this were the only factor I would release those materials under
> the Apache license right away.
>
> As far as causality goes, knowing about OFBiz is a "necessary" cause
> for contribution, but not a "sufficient" cause. If knowing about
> OFBiz was a sufficient cause for heavy involvement in contributing to
> OFBiz, we would have at least twenty to thirty active (ie daily)
> committers, and we would probably go through easily 100 Jira issues a
> week from outside contributors.
>
> For an excellent thesis on causality, I recommend "Causality and
> Chance in Modern Physics" by David Bohm and Louis De Broglie,
> especially the first few chapters which apply to a good deal other
> than just physics (though of course honest physics involves a great
> deal of real life so very little imagination is required to bridge
> the gap). Actually, that book is more of a philosophy of science book
> than a book about the results of science.
>
> -David
>
>
Re: General questions
Posted by Jonathon -- Improov <jo...@improov.com>.
> If this were the only factor I would release those materials under the
> Apache license right away.
Agreed. I would've put full muscle behind writing down what I learned about OFBiz. I kinda gave up
after dishing out detailed explanations of form/screen widget entities and seeing... zilch in return.
> As far as causality goes, knowing about OFBiz is a "necessary" cause for
> contribution, but not a "sufficient" cause. If knowing about OFBiz was a
> sufficient cause for heavy involvement in contributing to OFBiz, we
> would have at least twenty to thirty active (ie daily) committers, and
> we would probably go through easily 100 Jira issues a week from outside
> contributors.
Agreed.
Currently, I'm unable to contribute myself due to time constraints (or mad rush for business
profit?). After I'm done with my project, I may examine myself and find out why I can/cannot
contribute back actively to OFBiz. At least start studying the phenomenon 1 case at a time,
starting with myself.
Jonathon
David E. Jones wrote:
>
> On Feb 12, 2007, at 11:20 PM, Jonathon -- Improov wrote:
>
>> But you could be right. IMHO, the lack of clear OFBiz framework
>> references (not videos that are unsearchable) may be hindering the
>> explosive growth of the OFBiz-enabled engineer population. Also IMHO,
>> an explosion in the number of OFBiz-enabled engineers will likely feed
>> back into OFBiz very rapidly. And further IMHO, David Jones (creator
>> of OFBiz) will then probably have a whole army of willing volunteers
>> to choose from (many open source projects employ ULTRA STRINGENT
>> qualifying criteria to screen volunteers before making them
>> committers; you do get many top brains in open source projects, so
>> good that you/I probably can't ever argue with those).
>>
>> And finally, IMHO, I could be entirely wrong in above paragraph. I am
>> not David Jones; I never created an open source project myself.
>
> If this were the only factor I would release those materials under the
> Apache license right away.
>
> As far as causality goes, knowing about OFBiz is a "necessary" cause for
> contribution, but not a "sufficient" cause. If knowing about OFBiz was a
> sufficient cause for heavy involvement in contributing to OFBiz, we
> would have at least twenty to thirty active (ie daily) committers, and
> we would probably go through easily 100 Jira issues a week from outside
> contributors.
>
> For an excellent thesis on causality, I recommend "Causality and Chance
> in Modern Physics" by David Bohm and Louis De Broglie, especially the
> first few chapters which apply to a good deal other than just physics
> (though of course honest physics involves a great deal of real life so
> very little imagination is required to bridge the gap). Actually, that
> book is more of a philosophy of science book than a book about the
> results of science.
>
> -David
>
Re: General questions
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Feb 12, 2007, at 11:20 PM, Jonathon -- Improov wrote:
> But you could be right. IMHO, the lack of clear OFBiz framework
> references (not videos that are unsearchable) may be hindering the
> explosive growth of the OFBiz-enabled engineer population. Also
> IMHO, an explosion in the number of OFBiz-enabled engineers will
> likely feed back into OFBiz very rapidly. And further IMHO, David
> Jones (creator of OFBiz) will then probably have a whole army of
> willing volunteers to choose from (many open source projects employ
> ULTRA STRINGENT qualifying criteria to screen volunteers before
> making them committers; you do get many top brains in open source
> projects, so good that you/I probably can't ever argue with those).
>
> And finally, IMHO, I could be entirely wrong in above paragraph. I
> am not David Jones; I never created an open source project myself.
If this were the only factor I would release those materials under
the Apache license right away.
As far as causality goes, knowing about OFBiz is a "necessary" cause
for contribution, but not a "sufficient" cause. If knowing about
OFBiz was a sufficient cause for heavy involvement in contributing to
OFBiz, we would have at least twenty to thirty active (ie daily)
committers, and we would probably go through easily 100 Jira issues a
week from outside contributors.
For an excellent thesis on causality, I recommend "Causality and
Chance in Modern Physics" by David Bohm and Louis De Broglie,
especially the first few chapters which apply to a good deal other
than just physics (though of course honest physics involves a great
deal of real life so very little imagination is required to bridge
the gap). Actually, that book is more of a philosophy of science book
than a book about the results of science.
-David
Re: General questions
Posted by Jacopo Cappellato <ti...@sastau.it>.
To all,
please ignore this troll.
Jacopo
Ian McNulty wrote:
> Jonathon,
>
> Have just been thinking about what you've been saying about learning the
> OFBiz framework inside of 10 minutes and how to read OFBiz 'like an open
> REFERENCE book.'
>
> A short document describing exactly how to go about such a thing
> couldn't take more than 10 minutes to read by definition, and probably
> wouldn't take you much longer than that to write.
>
> I'd certainly be interested in reading such a thing and I bet a lot of
> other people would too. It could be a major drawing point for our site.
>
> Just a thought! (Or a wish fulfilment on my part perhaps. Wading through
> the 1000+ pages of awful, miserable rubbish generated by Les Austin, the
> technical writer drafted in by David at apparently huge expense. Wishing
> I could find something myself that I could put together in a couple of
> hours rather than a couple of months!)
>
> Ian
>
>
>
>
> Jonathon -- Improov wrote:
>> Cedric,
>>
>> > Jonathon, a collaboration? Yes, why not? But I am sure I will not
>> show you
>> > much things because you are more experienced than me =)
>>
>> I started looking at OFBiz framework in Jan 07 (last month). I
>> probably spent no more than a week(?) on learning OFBiz framework
>> itself; much of my time was spent on data mapping and struggling(!!)
>> with freeing my boss' data from legacy systems, and also on comparing
>> OFBiz with other solutions (he kept knocking OFBiz big-time). I had no
>> docs, no references (save xsd schemas), I even missed the cookbooks
>> altogether (which really are quite skeletal, anyway).
>>
>> Believe me, OFBiz is easy to pick up.
>>
>> Somewhat exact time requirements (in case your boss asks):
>>
>> 1. 10 minutes to learn structure of OFBiz, so you know how to move
>> around.
>>
>> 2. 1-2 minutes to look up anything related to OFBiz, since you'll be
>> reading
>> OFBiz like an open REFERENCE book.
>>
>> > there are questions about the use of screen/form widgets and
>> > Beanshell/minilang. I am not well experienced but I don't know if
>> developers
>> > will like to learn these new things instead of working with what
>> they know.
>>
>> As I mentioned in other threads, it IS possible to learn OFBiz inside
>> of 10 minutes.
>>
>> But you could be right. IMHO, the lack of clear OFBiz framework
>> references (not videos that are unsearchable) may be hindering the
>> explosive growth of the OFBiz-enabled engineer population. Also IMHO,
>> an explosion in the number of OFBiz-enabled engineers will likely feed
>> back into OFBiz very rapidly. And further IMHO, David Jones (creator
>> of OFBiz) will then probably have a whole army of willing volunteers
>> to choose from (many open source projects employ ULTRA STRINGENT
>> qualifying criteria to screen volunteers before making them
>> committers; you do get many top brains in open source projects, so
>> good that you/I probably can't ever argue with those).
>>
>> And finally, IMHO, I could be entirely wrong in above paragraph. I am
>> not David Jones; I never created an open source project myself.
>>
>> Bottom line. OFBiz framework is solid (may need tweaks, but
>> enhancements are on the way all the time). I'll be sorry if I missed it.
>>
>> Jonathon
>>
>> PRONZATO Cedric RD-BIZZ-GRE wrote:
>>> Hi all,
>>>
>>> Yes, you are all true! My approach is bottom-up learning. All of you
>>> here seem to read in me like an opened book; I now know that OFBiz is
>>> a training area for FBI Profilers. :)
>>>
>>> My aim (I think) was to fully understand the framework to be able to
>>> change/replace/add new *core* functionalities and test them in a real
>>> ecommerce environment.
>>> Yet I never played with 'call to a service' or so as the documents
>>> about that was enough clear. I said: All should be OK on this part.
>>> Entity engine and Service engine are clear and in respect of all the
>>> common and trusted laws of java development. (By the way is there any
>>> plan to turn to the new standards? OFBiz was in advance in 2000 but
>>> now much developer well knows Spring just to name one ...)
>>> So after these 2 majors things there are questions about the use of
>>> screen/form widgets and Beanshell/minilang. I am not well experienced
>>> but I don't know if developers will like to learn these new things
>>> instead of working with what they know. So I decided to not
>>> investigate it much.
>>>
>>> Jonathon, a collaboration? Yes, why not? But I am sure I will not
>>> show you much things because you are more experienced than me =) I
>>> will check about what I am allowed to do with my company policy but I
>>> am confidant as OFBiz is a personal choice not too much tied to a
>>> project need. I stay you tuned.
>>>
>>> I now have to think about what is wrong on this approach, think about
>>> what is the next thing I have to investigate ...
>>>
>>> Thank you all,
>>> Regards,
>>> Cédric
>>>
>>> -----Message d'origine-----
>>> De : Jonathon -- Improov [mailto:jonw@improov.com] Envoyé : vendredi
>>> 9 février 2007 20:12
>>> À : user@ofbiz.apache.org
>>> Objet : Re: General questions
>>>
>>> Cedric,
>>>
>>> I get the same impression as Adrian too.
>>>
>>> Since you're from the R&D department, I suppose you're as much of a
>>> freak as I am. I took apart OFBiz at the source code level too.
>>>
>>> Unless you're employing some language-processing heuristics in your
>>> reverse-engineering, you'll be spending way too much time doing
>>> brute-force studies from the bottom-up. Better to just learn from
>>> playing with OFBiz framework (not the framework source codes), such
>>> as service engine and entity engine, in this case.
>>>
>>> While it is true that learning by playing with the framework will
>>> certainly be faster, I do admit it is not as easy as many would hope.
>>> Technical references for working the OFBiz framework are not all in
>>> one place, or even complete (mostly still in form of cookbooks at the
>>> moment). Ie, there are no "javadocs equivalent" for the OFBiz
>>> framework, except at
>>> http://www.undersunconsulting.com/ecommerce/control/main .
>>>
>>> In fact, some folks here have never gotten around to using all of the
>>> OFBiz framework. Some don't use screen/form widgets, but FTL instead.
>>> Some use Beanshell rather than Minilang.
>>>
>>> I guess what I'm trying to say is this. Since you're from the R&D
>>> department, it would be "within your scope" to learn the OFBiz
>>> framework in any way possible, such as from studying the source codes
>>> or playing with the framework itself. No use complaining what isn't
>>> there; better to get things working somehow.
>>>
>>> For those not from the R&D department, though, then yes I do admit
>>> OFBiz doesn't have a nice polished expensive "welcome mat/carpet" for
>>> new users.
>>>
>>> If you do want to get help learning the OFBiz framework, you can
>>> either work with me and write down all that I've discovered through
>>> my own reverse-engineering, or you can employ some of the experts
>>> here to teach you. I'll have to train some staff on OFBiz before I
>>> sign off my current project, so your help here would be much
>>> appreciated.
>>>
>>> Hope you enjoy OFBiz as much as I have. :)
>>>
>>> Jonathon
>>>
>>> Adrian Crum wrote:
>>>> Cedric,
>>>>
>>>> I might be wrong, but I get the impression you are trying to
>>>> approach OFBiz from the bottom up (examining java classes versus
>>>> examining higher-level layers). I made that mistake when I first got
>>>> involved with OFBiz.
>>>>
>>>> It would be better to look at things like the service engine, entity
>>>> engine, screen widgets, etc. Get an idea of how the presentation
>>>> layer works, then work your way down to the service layer, then down
>>>> to the database schema, etc.
>>>>
>>>> Typically, the only reason anyone would want to get into the java
>>>> source would be to fix a bug or make a modification at a very low
>>>> level of the architecture "stack."
>>>>
>>>>
>>>>
>>>> PRONZATO Cedric RD-BIZZ-GRE wrote:
>>>>
>>>>> Re,
>>>>>
>>>>> Yes you are true but I think I didn't explained myself.
>>>>> These questions may have been answered in the javadocs. I am sure
>>>>> you know (you that architects of OFBiz) why you decided to make a
>>>>> Container class and so on.
>>>>> So perhaps a little enhancement of javadoc on foundation classes to
>>>>> explain why and where to use it would be so nice.
>>>>>
>>>>> I hope I do not look like too much arrogant with my questions on
>>>>> that thread "General questions"; I just expose the problems I was
>>>>> faced to.
>>>>>
>>>>> Regards,
>>>>> Cédric
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : David E. Jones [mailto:jonesde@hotwaxmedia.com] Envoyé : vendredi
>>>>> 9 février 2007 18:12
>>>>> À : user@ofbiz.apache.org
>>>>> Objet : Re: General questions
>>>>>
>>>>>
>>>>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
>>>>>
>>>>>
>>>>>> A related problem is how to do "framework" components, I mean
>>>>>> patterns. I think about my SMSC component, I base my code on the
>>>>>> mail container and questions arised:
>>>>>> - When do I have to make my own xml language (ie. MCA for the mail
>>>>>> container)?
>>>>>> - When do I have to make a Container? I guess the answer is if you
>>>>>> have to manage the lifetime (create/release connections, ...).
>>>>>> - When do I have to make an Engine?
>>>>>> - ...
>>>>>>
>>>>>> So I guess we can finish with the following statement: "How to
>>>>>> *use* is quite well documented but how to *make* is a bit less".
>>>>>
>>>>> Have you ever found such a document for anything?
>>>>>
>>>>> My usual approach is generally something like:
>>>>>
>>>>> 1. understand everything that exists, or research anything that is
>>>>> unclear 2. write something manually a number of times so you know
>>>>> what is always the same, and what varies 3. see if a paramerized
>>>>> tool would be helpful 4. apply a significant amount of "genius"
>>>>> 5. apply even more "sweat" to try stuff 6. create an incredible
>>>>> tool or service or however it is best implemented
>>>>>
>>>>> If there was a way to make creation deterministic, what would be
>>>>> the point of creativity?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>
>>>
>>
>>
>>
>
Re: General questions
Posted by Jonathon -- Improov <jo...@improov.com>.
Ian,
As discussed before, you would/could write whatever user docs you could just by using and testing
OFBiz. For any other functionalities you can't easily figure out that way, you can then pop a
quick question to me, and I'll do a 2-minute rip through the source codes to give you a definitive
answer (aka a "source codes say so, and that's how it works" kinda answer).
As for 10 minutes to know OFBiz, look through David's "overview of OFBiz framework".
As for reading OFBiz like an open REFERENCE book, it has to do with the ability to rip through the
source codes inside of minutes to conclusively figure out what buttons do what actions/effects.
Jonathon
Ian McNulty wrote:
> Jonathon,
>
> Have just been thinking about what you've been saying about learning the
> OFBiz framework inside of 10 minutes and how to read OFBiz 'like an open
> REFERENCE book.'
>
> A short document describing exactly how to go about such a thing
> couldn't take more than 10 minutes to read by definition, and probably
> wouldn't take you much longer than that to write.
>
> I'd certainly be interested in reading such a thing and I bet a lot of
> other people would too. It could be a major drawing point for our site.
>
> Just a thought! (Or a wish fulfilment on my part perhaps. Wading through
> the 1000+ pages of awful, miserable rubbish generated by Les Austin, the
> technical writer drafted in by David at apparently huge expense. Wishing
> I could find something myself that I could put together in a couple of
> hours rather than a couple of months!)
>
> Ian
>
>
>
>
> Jonathon -- Improov wrote:
>> Cedric,
>>
>> > Jonathon, a collaboration? Yes, why not? But I am sure I will not
>> show you
>> > much things because you are more experienced than me =)
>>
>> I started looking at OFBiz framework in Jan 07 (last month). I
>> probably spent no more than a week(?) on learning OFBiz framework
>> itself; much of my time was spent on data mapping and struggling(!!)
>> with freeing my boss' data from legacy systems, and also on comparing
>> OFBiz with other solutions (he kept knocking OFBiz big-time). I had no
>> docs, no references (save xsd schemas), I even missed the cookbooks
>> altogether (which really are quite skeletal, anyway).
>>
>> Believe me, OFBiz is easy to pick up.
>>
>> Somewhat exact time requirements (in case your boss asks):
>>
>> 1. 10 minutes to learn structure of OFBiz, so you know how to move
>> around.
>>
>> 2. 1-2 minutes to look up anything related to OFBiz, since you'll be
>> reading
>> OFBiz like an open REFERENCE book.
>>
>> > there are questions about the use of screen/form widgets and
>> > Beanshell/minilang. I am not well experienced but I don't know if
>> developers
>> > will like to learn these new things instead of working with what
>> they know.
>>
>> As I mentioned in other threads, it IS possible to learn OFBiz inside
>> of 10 minutes.
>>
>> But you could be right. IMHO, the lack of clear OFBiz framework
>> references (not videos that are unsearchable) may be hindering the
>> explosive growth of the OFBiz-enabled engineer population. Also IMHO,
>> an explosion in the number of OFBiz-enabled engineers will likely feed
>> back into OFBiz very rapidly. And further IMHO, David Jones (creator
>> of OFBiz) will then probably have a whole army of willing volunteers
>> to choose from (many open source projects employ ULTRA STRINGENT
>> qualifying criteria to screen volunteers before making them
>> committers; you do get many top brains in open source projects, so
>> good that you/I probably can't ever argue with those).
>>
>> And finally, IMHO, I could be entirely wrong in above paragraph. I am
>> not David Jones; I never created an open source project myself.
>>
>> Bottom line. OFBiz framework is solid (may need tweaks, but
>> enhancements are on the way all the time). I'll be sorry if I missed it.
>>
>> Jonathon
>>
>> PRONZATO Cedric RD-BIZZ-GRE wrote:
>>> Hi all,
>>>
>>> Yes, you are all true! My approach is bottom-up learning. All of you
>>> here seem to read in me like an opened book; I now know that OFBiz is
>>> a training area for FBI Profilers. :)
>>>
>>> My aim (I think) was to fully understand the framework to be able to
>>> change/replace/add new *core* functionalities and test them in a real
>>> ecommerce environment.
>>> Yet I never played with 'call to a service' or so as the documents
>>> about that was enough clear. I said: All should be OK on this part.
>>> Entity engine and Service engine are clear and in respect of all the
>>> common and trusted laws of java development. (By the way is there any
>>> plan to turn to the new standards? OFBiz was in advance in 2000 but
>>> now much developer well knows Spring just to name one ...)
>>> So after these 2 majors things there are questions about the use of
>>> screen/form widgets and Beanshell/minilang. I am not well experienced
>>> but I don't know if developers will like to learn these new things
>>> instead of working with what they know. So I decided to not
>>> investigate it much.
>>>
>>> Jonathon, a collaboration? Yes, why not? But I am sure I will not
>>> show you much things because you are more experienced than me =) I
>>> will check about what I am allowed to do with my company policy but I
>>> am confidant as OFBiz is a personal choice not too much tied to a
>>> project need. I stay you tuned.
>>>
>>> I now have to think about what is wrong on this approach, think about
>>> what is the next thing I have to investigate ...
>>>
>>> Thank you all,
>>> Regards,
>>> Cédric
>>>
>>> -----Message d'origine-----
>>> De : Jonathon -- Improov [mailto:jonw@improov.com] Envoyé : vendredi
>>> 9 février 2007 20:12
>>> À : user@ofbiz.apache.org
>>> Objet : Re: General questions
>>>
>>> Cedric,
>>>
>>> I get the same impression as Adrian too.
>>>
>>> Since you're from the R&D department, I suppose you're as much of a
>>> freak as I am. I took apart OFBiz at the source code level too.
>>>
>>> Unless you're employing some language-processing heuristics in your
>>> reverse-engineering, you'll be spending way too much time doing
>>> brute-force studies from the bottom-up. Better to just learn from
>>> playing with OFBiz framework (not the framework source codes), such
>>> as service engine and entity engine, in this case.
>>>
>>> While it is true that learning by playing with the framework will
>>> certainly be faster, I do admit it is not as easy as many would hope.
>>> Technical references for working the OFBiz framework are not all in
>>> one place, or even complete (mostly still in form of cookbooks at the
>>> moment). Ie, there are no "javadocs equivalent" for the OFBiz
>>> framework, except at
>>> http://www.undersunconsulting.com/ecommerce/control/main .
>>>
>>> In fact, some folks here have never gotten around to using all of the
>>> OFBiz framework. Some don't use screen/form widgets, but FTL instead.
>>> Some use Beanshell rather than Minilang.
>>>
>>> I guess what I'm trying to say is this. Since you're from the R&D
>>> department, it would be "within your scope" to learn the OFBiz
>>> framework in any way possible, such as from studying the source codes
>>> or playing with the framework itself. No use complaining what isn't
>>> there; better to get things working somehow.
>>>
>>> For those not from the R&D department, though, then yes I do admit
>>> OFBiz doesn't have a nice polished expensive "welcome mat/carpet" for
>>> new users.
>>>
>>> If you do want to get help learning the OFBiz framework, you can
>>> either work with me and write down all that I've discovered through
>>> my own reverse-engineering, or you can employ some of the experts
>>> here to teach you. I'll have to train some staff on OFBiz before I
>>> sign off my current project, so your help here would be much
>>> appreciated.
>>>
>>> Hope you enjoy OFBiz as much as I have. :)
>>>
>>> Jonathon
>>>
>>> Adrian Crum wrote:
>>>> Cedric,
>>>>
>>>> I might be wrong, but I get the impression you are trying to
>>>> approach OFBiz from the bottom up (examining java classes versus
>>>> examining higher-level layers). I made that mistake when I first got
>>>> involved with OFBiz.
>>>>
>>>> It would be better to look at things like the service engine, entity
>>>> engine, screen widgets, etc. Get an idea of how the presentation
>>>> layer works, then work your way down to the service layer, then down
>>>> to the database schema, etc.
>>>>
>>>> Typically, the only reason anyone would want to get into the java
>>>> source would be to fix a bug or make a modification at a very low
>>>> level of the architecture "stack."
>>>>
>>>>
>>>>
>>>> PRONZATO Cedric RD-BIZZ-GRE wrote:
>>>>
>>>>> Re,
>>>>>
>>>>> Yes you are true but I think I didn't explained myself.
>>>>> These questions may have been answered in the javadocs. I am sure
>>>>> you know (you that architects of OFBiz) why you decided to make a
>>>>> Container class and so on.
>>>>> So perhaps a little enhancement of javadoc on foundation classes to
>>>>> explain why and where to use it would be so nice.
>>>>>
>>>>> I hope I do not look like too much arrogant with my questions on
>>>>> that thread "General questions"; I just expose the problems I was
>>>>> faced to.
>>>>>
>>>>> Regards,
>>>>> Cédric
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : David E. Jones [mailto:jonesde@hotwaxmedia.com] Envoyé : vendredi
>>>>> 9 février 2007 18:12
>>>>> À : user@ofbiz.apache.org
>>>>> Objet : Re: General questions
>>>>>
>>>>>
>>>>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
>>>>>
>>>>>
>>>>>> A related problem is how to do "framework" components, I mean
>>>>>> patterns. I think about my SMSC component, I base my code on the
>>>>>> mail container and questions arised:
>>>>>> - When do I have to make my own xml language (ie. MCA for the mail
>>>>>> container)?
>>>>>> - When do I have to make a Container? I guess the answer is if you
>>>>>> have to manage the lifetime (create/release connections, ...).
>>>>>> - When do I have to make an Engine?
>>>>>> - ...
>>>>>>
>>>>>> So I guess we can finish with the following statement: "How to
>>>>>> *use* is quite well documented but how to *make* is a bit less".
>>>>>
>>>>> Have you ever found such a document for anything?
>>>>>
>>>>> My usual approach is generally something like:
>>>>>
>>>>> 1. understand everything that exists, or research anything that is
>>>>> unclear 2. write something manually a number of times so you know
>>>>> what is always the same, and what varies 3. see if a paramerized
>>>>> tool would be helpful 4. apply a significant amount of "genius"
>>>>> 5. apply even more "sweat" to try stuff 6. create an incredible
>>>>> tool or service or however it is best implemented
>>>>>
>>>>> If there was a way to make creation deterministic, what would be
>>>>> the point of creativity?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>
>>>
>>
>>
>>
>
Re: General questions
Posted by Ian McNulty <ia...@mcnultymedia.co.uk>.
David,
David E. Jones wrote:
>
> On Feb 13, 2007, at 11:14 AM, Ian McNulty wrote:
>
>> I'm sure David and Les did an excellent job under the circumstances.
>> It's just that the pdfs contain so many html tags and complicated
>> paragraph numbers which need to be cut out. I've been suffering from
>> RSI in my mouse arm for several years now and dragging and dropping
>> 1000 pages of text is causing me a lot of misery and pain. I blasted
>> off a reply to Jonathon's over-bounding enthusiasm without stopping
>> to count to 10.
>
> Is that what you find terrible about the documentation? The formatting?
Yes. Primarily. The enormous amount of work that has gone into creating
those 1000+ pages is evident. I just find it so difficult to scan
through is all.
> I hope you didn't think these PDFs were designed to be this way...
Well, yes I did actually. Why would I assume otherwise?
>
> You may have already guessed that this documentation was made for an
> online system, not to go into PDFs.
Ehr, no I'm afraid I didn't. I just took them at face value and tried to
work with them as they are.
> The reason they are in PDFs and we won't let people access the online
> system anymore is that we don't want to maintain and pay for the
> hosting and manually grant people permission when they ask (and for
> the most part have not contributed to the migration and editing effort
> as promised in order to get the access).
OK. Fair do's. I've already had enough of a kicking from this ML and
don't want to lay myself open to any more. I appreciate all the work and
expense that's gone into creating all this stuff and apologise for any
comments I may have made which could be interpreted as negative,
critical or counter-productive in any way.
Ian
Re: General questions
Posted by Ian McNulty <ia...@mcnultymedia.co.uk>.
Hi Jacopo,
Thank you.
Will do.
Ian
Jacopo Cappellato wrote:
> Hi Ian,
>
> Ian McNulty wrote:
>>
>> I understand from http://issues.apache.org/jira/browse/OFBIZ-568 that
>> this space requires special permissions. How would I go about getting
>> that?
>>
>
> You can create the new documents in the open wiki space, then we will
> review and move to the moderated space.
>
> Thanks,
>
> Jacopo
>
>
All Manager Reference PDFs Now Migrated to Wiki
Posted by Ian McNulty <ia...@mcnultymedia.co.uk>.
All,
David E. Jones wrote:
> There is a lot of work to be done on editing and structuring and
> reformatting the OFBiz documentation. In short, we need your help!
I've just completed migration of the entire set of Undersun Manager
Reference PDFs to the Wiki. I couldn't get access to the OFBiz End-User
Documentation section so I've put them under my Confluence Home page at:
http://docs.ofbiz.org/display/~ian@mcnultymedia.co.uk/Manager+References
or
http://docs.ofbiz.org/x/0gQ
Would somebody be kind enough to transfer them to their proper place at
http://docs.ofbiz.org/display/OFBENDUSER/Manager+References
Currently there is only half of the Catalog Manager Reference in that
location, so I decided to redo the whole of it from scratch for simplicity.
On this 'first pass' through I have tried to preserve the original PDF
structure where possible and haven't edited anything. Hopefully, now
they have been transformed into an editable form they can be developed
further.
Ian
Jacopo Cappellato wrote:
> Ian,
>
> since a page location can be easily moved from one place to another,
> you can just select what you prefer; maybe the best choice is to place
> it under your Confluence Home page.
> I'm a bit vague now but the doc site seems down at the moment...
>
> Jacopo
>
>
> Ian McNulty wrote:
>> Hi again Jacopo,
>>
>> I'd appreciate a bit more help on this please.
>>
>> I've managed to create a Confluence account and got to grips with the
>> Wiki interface in just a couple of minutes but have been back and
>> forward over the tree structure for more than an hour and a half now
>> and am still unable to understand where to migrate the PDFs to.
>>
>> There seem to be at least 4 possible locations with various fragments
>> of these documents already in place:
>>
>> Application Reference for Users
>> <http://docs.ofbiz.org/display/OFBIZ/Application+Reference+for+Users>
>>
>> * Application Reference for Manufacturing Manager Application (Tab)
>>
>> <http://docs.ofbiz.org/display/OFBIZ/Application+Reference+for+Manufacturing+Manager+Application+%28Tab%29>
>>
>> * User Reference for Accounting Manager Application (Tab)
>>
>> <http://docs.ofbiz.org/display/OFBIZ/User+Reference+for+Accounting+Manager+Application+%28Tab%29>
>>
>> o User Reference for Accounting Manager - Agreements (Tab)
>>
>> <http://docs.ofbiz.org/display/OFBIZ/User+Reference+for+Accounting+Manager+-+Agreements+%28Tab%29>
>>
>>
>> Sandbox <http://docs.ofbiz.org/display/OFBIZ/Sandbox>
>>
>> * Application Screen Reference
>> <http://docs.ofbiz.org/display/OFBIZ/Application+Screen+Reference>
>>
>> * Accounting Screens Reference
>>
>> <http://docs.ofbiz.org/display/OFBIZ/Accounting+Screens+Reference>
>> * Catalog Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Catalog+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Content Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Content+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Example Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Example+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Facility Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Facility+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Manufacturing Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Manufacturing+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Marketing Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Marketing+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Order Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Order+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Party Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Party+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Shark Workflow Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Shark+Workflow+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * WorkEffort Screens Reference
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=WorkEffort+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>>
>> * CATALOG <http://docs.ofbiz.org/display/OFBIZ/CATALOG>
>>
>> * Introduction <http://docs.ofbiz.org/display/OFBIZ/Introduction>
>> * Search Products
>> <http://docs.ofbiz.org/display/OFBIZ/Search+Products>
>> * Browse Catalogs
>> <http://docs.ofbiz.org/display/OFBIZ/Browse+Catalogs>
>> * Browse Categories
>> <http://docs.ofbiz.org/display/OFBIZ/Browse+Categories>
>> * Category Products
>> <http://docs.ofbiz.org/display/OFBIZ/Category+Products>
>> * Catalog Administration Main Page
>>
>> <http://docs.ofbiz.org/display/OFBIZ/Catalog+Administration+Main+Page>
>> * Catalog - Edit Product Catalog screens
>>
>> <http://docs.ofbiz.org/display/OFBIZ/Catalog+-+Edit+Product+Catalog+screens>
>>
>> * Category - Edit Category screens
>>
>> <http://docs.ofbiz.org/display/OFBIZ/Category+-+Edit+Category+screens>
>> * Tab - Catalog Features^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Features&linkCreation=true&fromPageId=250>
>>
>> * Tab - Catalog Promos^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Promos&linkCreation=true&fromPageId=250>
>>
>> * Tab - Catalog PriceRules^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+PriceRules&linkCreation=true&fromPageId=250>
>>
>> * Tab - Catalog Stores^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Stores&linkCreation=true&fromPageId=250>
>>
>> * Tab - Catalog Thesaurus^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Thesaurus&linkCreation=true&fromPageId=250>
>>
>> * Tab - Catalog Reviews^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Reviews&linkCreation=true&fromPageId=250>
>>
>> * Tab - Configurations
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Configurations&linkCreation=true&fromPageId=250>
>>
>>
>> * OFBiz Applications User Manual
>>
>> <http://docs.ofbiz.org/display/OFBIZ/OFBiz+Applications+User+Manual>
>> o Catalogs <http://docs.ofbiz.org/display/OFBIZ/Catalogs>
>>
>>
>> Please advise which location I should migrate the PDFs to.
>>
>> Thanks in advance.
>>
>> Ian
>>
>>
>>
>> Jacopo Cappellato wrote:
>>> Hi Ian,
>>>
>>> Ian McNulty wrote:
>>>>
>>>> I understand from http://issues.apache.org/jira/browse/OFBIZ-568
>>>> that this space requires special permissions. How would I go about
>>>> getting that?
>>>>
>>>
>>> You can create the new documents in the open wiki space, then we
>>> will review and move to the moderated space.
>>>
>>> Thanks,
>>>
>>> Jacopo
>>>
>>>
>
>
>
>
--
----------------------------------------------------------------------------------------------
mcnultyMEDIA
60 Birkdale Gardens
Durham
DH1 2UL
t: +44 (0)191 384 4736
e: ian@mcnultymedia.co.uk
w: www.mcnultymedia.co.uk
==============================================================================================
This communication is for the exclusive use of the intended recipient(s) named above and is confidential. Any form of distribution, copying, discussion or use of this communication, its contents, or any information contained herein without prior consent is strictly prohibited. If you receive this communication in error, please notify the sender by email or by telephone on +44 (0)191 384 4736
This email has been checked for viruses, however, we cannot accept any liability sustained as a result of software viruses and would recommend that you carry out your own virus checks before opening any attachment.
==============================================================================================
Re: General questions
Posted by Ian McNulty <ia...@mcnultymedia.co.uk>.
Jacopo,
Wilco.
FYI doc site is working fine this end.
Thanks
Ian
Jacopo Cappellato wrote:
> Ian,
>
> since a page location can be easily moved from one place to another,
> you can just select what you prefer; maybe the best choice is to place
> it under your Confluence Home page.
> I'm a bit vague now but the doc site seems down at the moment...
>
> Jacopo
>
>
> Ian McNulty wrote:
>> Hi again Jacopo,
>>
>> I'd appreciate a bit more help on this please.
>>
>> I've managed to create a Confluence account and got to grips with the
>> Wiki interface in just a couple of minutes but have been back and
>> forward over the tree structure for more than an hour and a half now
>> and am still unable to understand where to migrate the PDFs to.
>>
>> There seem to be at least 4 possible locations with various fragments
>> of these documents already in place:
>>
>> Application Reference for Users
>> <http://docs.ofbiz.org/display/OFBIZ/Application+Reference+for+Users>
>>
>> * Application Reference for Manufacturing Manager Application (Tab)
>>
>> <http://docs.ofbiz.org/display/OFBIZ/Application+Reference+for+Manufacturing+Manager+Application+%28Tab%29>
>>
>> * User Reference for Accounting Manager Application (Tab)
>>
>> <http://docs.ofbiz.org/display/OFBIZ/User+Reference+for+Accounting+Manager+Application+%28Tab%29>
>>
>> o User Reference for Accounting Manager - Agreements (Tab)
>>
>> <http://docs.ofbiz.org/display/OFBIZ/User+Reference+for+Accounting+Manager+-+Agreements+%28Tab%29>
>>
>>
>> Sandbox <http://docs.ofbiz.org/display/OFBIZ/Sandbox>
>>
>> * Application Screen Reference
>> <http://docs.ofbiz.org/display/OFBIZ/Application+Screen+Reference>
>>
>> * Accounting Screens Reference
>>
>> <http://docs.ofbiz.org/display/OFBIZ/Accounting+Screens+Reference>
>> * Catalog Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Catalog+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Content Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Content+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Example Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Example+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Facility Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Facility+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Manufacturing Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Manufacturing+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Marketing Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Marketing+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Order Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Order+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Party Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Party+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * Shark Workflow Screens Reference^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Shark+Workflow+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>> * WorkEffort Screens Reference
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=WorkEffort+Screens+Reference&linkCreation=true&fromPageId=452>
>>
>>
>> * CATALOG <http://docs.ofbiz.org/display/OFBIZ/CATALOG>
>>
>> * Introduction <http://docs.ofbiz.org/display/OFBIZ/Introduction>
>> * Search Products
>> <http://docs.ofbiz.org/display/OFBIZ/Search+Products>
>> * Browse Catalogs
>> <http://docs.ofbiz.org/display/OFBIZ/Browse+Catalogs>
>> * Browse Categories
>> <http://docs.ofbiz.org/display/OFBIZ/Browse+Categories>
>> * Category Products
>> <http://docs.ofbiz.org/display/OFBIZ/Category+Products>
>> * Catalog Administration Main Page
>>
>> <http://docs.ofbiz.org/display/OFBIZ/Catalog+Administration+Main+Page>
>> * Catalog - Edit Product Catalog screens
>>
>> <http://docs.ofbiz.org/display/OFBIZ/Catalog+-+Edit+Product+Catalog+screens>
>>
>> * Category - Edit Category screens
>>
>> <http://docs.ofbiz.org/display/OFBIZ/Category+-+Edit+Category+screens>
>> * Tab - Catalog Features^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Features&linkCreation=true&fromPageId=250>
>>
>> * Tab - Catalog Promos^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Promos&linkCreation=true&fromPageId=250>
>>
>> * Tab - Catalog PriceRules^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+PriceRules&linkCreation=true&fromPageId=250>
>>
>> * Tab - Catalog Stores^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Stores&linkCreation=true&fromPageId=250>
>>
>> * Tab - Catalog Thesaurus^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Thesaurus&linkCreation=true&fromPageId=250>
>>
>> * Tab - Catalog Reviews^
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Reviews&linkCreation=true&fromPageId=250>
>>
>> * Tab - Configurations
>>
>> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Configurations&linkCreation=true&fromPageId=250>
>>
>>
>> * OFBiz Applications User Manual
>>
>> <http://docs.ofbiz.org/display/OFBIZ/OFBiz+Applications+User+Manual>
>> o Catalogs <http://docs.ofbiz.org/display/OFBIZ/Catalogs>
>>
>>
>> Please advise which location I should migrate the PDFs to.
>>
>> Thanks in advance.
>>
>> Ian
>>
>>
>>
>> Jacopo Cappellato wrote:
>>> Hi Ian,
>>>
>>> Ian McNulty wrote:
>>>>
>>>> I understand from http://issues.apache.org/jira/browse/OFBIZ-568
>>>> that this space requires special permissions. How would I go about
>>>> getting that?
>>>>
>>>
>>> You can create the new documents in the open wiki space, then we
>>> will review and move to the moderated space.
>>>
>>> Thanks,
>>>
>>> Jacopo
>>>
Re: General questions
Posted by Jacopo Cappellato <ti...@sastau.it>.
Ian,
since a page location can be easily moved from one place to another, you
can just select what you prefer; maybe the best choice is to place it
under your Confluence Home page.
I'm a bit vague now but the doc site seems down at the moment...
Jacopo
Ian McNulty wrote:
> Hi again Jacopo,
>
> I'd appreciate a bit more help on this please.
>
> I've managed to create a Confluence account and got to grips with the
> Wiki interface in just a couple of minutes but have been back and
> forward over the tree structure for more than an hour and a half now and
> am still unable to understand where to migrate the PDFs to.
>
> There seem to be at least 4 possible locations with various fragments of
> these documents already in place:
>
> Application Reference for Users
> <http://docs.ofbiz.org/display/OFBIZ/Application+Reference+for+Users>
>
> * Application Reference for Manufacturing Manager Application (Tab)
>
> <http://docs.ofbiz.org/display/OFBIZ/Application+Reference+for+Manufacturing+Manager+Application+%28Tab%29>
>
> * User Reference for Accounting Manager Application (Tab)
>
> <http://docs.ofbiz.org/display/OFBIZ/User+Reference+for+Accounting+Manager+Application+%28Tab%29>
>
> o User Reference for Accounting Manager - Agreements (Tab)
>
> <http://docs.ofbiz.org/display/OFBIZ/User+Reference+for+Accounting+Manager+-+Agreements+%28Tab%29>
>
>
> Sandbox <http://docs.ofbiz.org/display/OFBIZ/Sandbox>
>
> * Application Screen Reference
> <http://docs.ofbiz.org/display/OFBIZ/Application+Screen+Reference>
>
> * Accounting Screens Reference
> <http://docs.ofbiz.org/display/OFBIZ/Accounting+Screens+Reference>
> * Catalog Screens Reference^
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Catalog+Screens+Reference&linkCreation=true&fromPageId=452>
>
> * Content Screens Reference^
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Content+Screens+Reference&linkCreation=true&fromPageId=452>
>
> * Example Screens Reference^
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Example+Screens+Reference&linkCreation=true&fromPageId=452>
>
> * Facility Screens Reference^
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Facility+Screens+Reference&linkCreation=true&fromPageId=452>
>
> * Manufacturing Screens Reference^
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Manufacturing+Screens+Reference&linkCreation=true&fromPageId=452>
>
> * Marketing Screens Reference^
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Marketing+Screens+Reference&linkCreation=true&fromPageId=452>
>
> * Order Screens Reference^
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Order+Screens+Reference&linkCreation=true&fromPageId=452>
>
> * Party Screens Reference^
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Party+Screens+Reference&linkCreation=true&fromPageId=452>
>
> * Shark Workflow Screens Reference^
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Shark+Workflow+Screens+Reference&linkCreation=true&fromPageId=452>
>
> * WorkEffort Screens Reference
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=WorkEffort+Screens+Reference&linkCreation=true&fromPageId=452>
>
>
> * CATALOG <http://docs.ofbiz.org/display/OFBIZ/CATALOG>
>
> * Introduction <http://docs.ofbiz.org/display/OFBIZ/Introduction>
> * Search Products
> <http://docs.ofbiz.org/display/OFBIZ/Search+Products>
> * Browse Catalogs
> <http://docs.ofbiz.org/display/OFBIZ/Browse+Catalogs>
> * Browse Categories
> <http://docs.ofbiz.org/display/OFBIZ/Browse+Categories>
> * Category Products
> <http://docs.ofbiz.org/display/OFBIZ/Category+Products>
> * Catalog Administration Main Page
>
> <http://docs.ofbiz.org/display/OFBIZ/Catalog+Administration+Main+Page>
> * Catalog - Edit Product Catalog screens
>
> <http://docs.ofbiz.org/display/OFBIZ/Catalog+-+Edit+Product+Catalog+screens>
>
> * Category - Edit Category screens
>
> <http://docs.ofbiz.org/display/OFBIZ/Category+-+Edit+Category+screens>
> * Tab - Catalog Features^
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Features&linkCreation=true&fromPageId=250>
>
> * Tab - Catalog Promos^
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Promos&linkCreation=true&fromPageId=250>
>
> * Tab - Catalog PriceRules^
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+PriceRules&linkCreation=true&fromPageId=250>
>
> * Tab - Catalog Stores^
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Stores&linkCreation=true&fromPageId=250>
>
> * Tab - Catalog Thesaurus^
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Thesaurus&linkCreation=true&fromPageId=250>
>
> * Tab - Catalog Reviews^
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Reviews&linkCreation=true&fromPageId=250>
>
> * Tab - Configurations
>
> <http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Configurations&linkCreation=true&fromPageId=250>
>
>
> * OFBiz Applications User Manual
> <http://docs.ofbiz.org/display/OFBIZ/OFBiz+Applications+User+Manual>
> o Catalogs <http://docs.ofbiz.org/display/OFBIZ/Catalogs>
>
>
> Please advise which location I should migrate the PDFs to.
>
> Thanks in advance.
>
> Ian
>
>
>
> Jacopo Cappellato wrote:
>> Hi Ian,
>>
>> Ian McNulty wrote:
>>>
>>> I understand from http://issues.apache.org/jira/browse/OFBIZ-568 that
>>> this space requires special permissions. How would I go about getting
>>> that?
>>>
>>
>> You can create the new documents in the open wiki space, then we will
>> review and move to the moderated space.
>>
>> Thanks,
>>
>> Jacopo
>>
>>
Re: General questions
Posted by Ian McNulty <ia...@mcnultymedia.co.uk>.
Hi again Jacopo,
I'd appreciate a bit more help on this please.
I've managed to create a Confluence account and got to grips with the
Wiki interface in just a couple of minutes but have been back and
forward over the tree structure for more than an hour and a half now and
am still unable to understand where to migrate the PDFs to.
There seem to be at least 4 possible locations with various fragments of
these documents already in place:
Application Reference for Users
<http://docs.ofbiz.org/display/OFBIZ/Application+Reference+for+Users>
* Application Reference for Manufacturing Manager Application (Tab)
<http://docs.ofbiz.org/display/OFBIZ/Application+Reference+for+Manufacturing+Manager+Application+%28Tab%29>
* User Reference for Accounting Manager Application (Tab)
<http://docs.ofbiz.org/display/OFBIZ/User+Reference+for+Accounting+Manager+Application+%28Tab%29>
o User Reference for Accounting Manager - Agreements (Tab)
<http://docs.ofbiz.org/display/OFBIZ/User+Reference+for+Accounting+Manager+-+Agreements+%28Tab%29>
Sandbox <http://docs.ofbiz.org/display/OFBIZ/Sandbox>
* Application Screen Reference
<http://docs.ofbiz.org/display/OFBIZ/Application+Screen+Reference>
* Accounting Screens Reference
<http://docs.ofbiz.org/display/OFBIZ/Accounting+Screens+Reference>
* Catalog Screens Reference^
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Catalog+Screens+Reference&linkCreation=true&fromPageId=452>
* Content Screens Reference^
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Content+Screens+Reference&linkCreation=true&fromPageId=452>
* Example Screens Reference^
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Example+Screens+Reference&linkCreation=true&fromPageId=452>
* Facility Screens Reference^
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Facility+Screens+Reference&linkCreation=true&fromPageId=452>
* Manufacturing Screens Reference^
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Manufacturing+Screens+Reference&linkCreation=true&fromPageId=452>
* Marketing Screens Reference^
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Marketing+Screens+Reference&linkCreation=true&fromPageId=452>
* Order Screens Reference^
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Order+Screens+Reference&linkCreation=true&fromPageId=452>
* Party Screens Reference^
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Party+Screens+Reference&linkCreation=true&fromPageId=452>
* Shark Workflow Screens Reference^
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Shark+Workflow+Screens+Reference&linkCreation=true&fromPageId=452>
* WorkEffort Screens Reference
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=WorkEffort+Screens+Reference&linkCreation=true&fromPageId=452>
* CATALOG <http://docs.ofbiz.org/display/OFBIZ/CATALOG>
* Introduction <http://docs.ofbiz.org/display/OFBIZ/Introduction>
* Search Products
<http://docs.ofbiz.org/display/OFBIZ/Search+Products>
* Browse Catalogs
<http://docs.ofbiz.org/display/OFBIZ/Browse+Catalogs>
* Browse Categories
<http://docs.ofbiz.org/display/OFBIZ/Browse+Categories>
* Category Products
<http://docs.ofbiz.org/display/OFBIZ/Category+Products>
* Catalog Administration Main Page
<http://docs.ofbiz.org/display/OFBIZ/Catalog+Administration+Main+Page>
* Catalog - Edit Product Catalog screens
<http://docs.ofbiz.org/display/OFBIZ/Catalog+-+Edit+Product+Catalog+screens>
* Category - Edit Category screens
<http://docs.ofbiz.org/display/OFBIZ/Category+-+Edit+Category+screens>
* Tab - Catalog Features^
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Features&linkCreation=true&fromPageId=250>
* Tab - Catalog Promos^
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Promos&linkCreation=true&fromPageId=250>
* Tab - Catalog PriceRules^
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+PriceRules&linkCreation=true&fromPageId=250>
* Tab - Catalog Stores^
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Stores&linkCreation=true&fromPageId=250>
* Tab - Catalog Thesaurus^
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Thesaurus&linkCreation=true&fromPageId=250>
* Tab - Catalog Reviews^
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Catalog+Reviews&linkCreation=true&fromPageId=250>
* Tab - Configurations
<http://docs.ofbiz.org/pages/createpage.action?spaceKey=OFBIZ&title=Tab+-+Configurations&linkCreation=true&fromPageId=250>
* OFBiz Applications User Manual
<http://docs.ofbiz.org/display/OFBIZ/OFBiz+Applications+User+Manual>
o Catalogs <http://docs.ofbiz.org/display/OFBIZ/Catalogs>
Please advise which location I should migrate the PDFs to.
Thanks in advance.
Ian
Jacopo Cappellato wrote:
> Hi Ian,
>
> Ian McNulty wrote:
>>
>> I understand from http://issues.apache.org/jira/browse/OFBIZ-568 that
>> this space requires special permissions. How would I go about getting
>> that?
>>
>
> You can create the new documents in the open wiki space, then we will
> review and move to the moderated space.
>
> Thanks,
>
> Jacopo
>
>
Re: General questions
Posted by Jacopo Cappellato <ti...@sastau.it>.
Hi Ian,
Ian McNulty wrote:
>
> I understand from http://issues.apache.org/jira/browse/OFBIZ-568 that
> this space requires special permissions. How would I go about getting that?
>
You can create the new documents in the open wiki space, then we will
review and move to the moderated space.
Thanks,
Jacopo
Re: General questions
Posted by Ian McNulty <ia...@mcnultymedia.co.uk>.
David,
David E. Jones wrote:
>
> You may have already guessed that this documentation was made for an
> online system, not to go into PDFs. The reason they are in PDFs and we
> won't let people access the online system anymore is that we don't
> want to maintain and pay for the hosting and manually grant people
> permission when they ask (and for the most part have not contributed
> to the migration and editing effort as promised in order to get the
> access).
>
> -David
>
By migration and editing effort do you mean transferring the PDFs into
OFBiz End-User Documentation
http://docs.ofbiz.org/display/OFBENDUSER/Manager+References ?
If so, I would like to try and help by migrating text and images from
the PDFs into this space if that would be useful.
I understand from http://issues.apache.org/jira/browse/OFBIZ-568 that
this space requires special permissions. How would I go about getting that?
My intention would be to start off getting to grips with the interface
and layout policy by completing the Catalog section (currently less than
half completed) if that would be acceptable.
Ian
Re: General questions
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Feb 13, 2007, at 11:14 AM, Ian McNulty wrote:
> I'm sure David and Les did an excellent job under the
> circumstances. It's just that the pdfs contain so many html tags
> and complicated paragraph numbers which need to be cut out. I've
> been suffering from RSI in my mouse arm for several years now and
> dragging and dropping 1000 pages of text is causing me a lot of
> misery and pain. I blasted off a reply to Jonathon's over-bounding
> enthusiasm without stopping to count to 10.
Is that what you find terrible about the documentation? The
formatting? I hope you didn't think these PDFs were designed to be
this way...
You may have already guessed that this documentation was made for an
online system, not to go into PDFs. The reason they are in PDFs and
we won't let people access the online system anymore is that we don't
want to maintain and pay for the hosting and manually grant people
permission when they ask (and for the most part have not contributed
to the migration and editing effort as promised in order to get the
access).
-David
Re: General questions
Posted by Ian McNulty <ia...@mcnultymedia.co.uk>.
OK Guys. I was hoping to keep quiet until I had something useful to
show, but the cat is now out of the bag. I've been sitting at my desk
solidly for 13 hours now trying to make a contribution by trying to pull
together the User pdfs into something useful and I'm rapidly losing my
marbles.
I'm sure David and Les did an excellent job under the circumstances.
It's just that the pdfs contain so many html tags and complicated
paragraph numbers which need to be cut out. I've been suffering from RSI
in my mouse arm for several years now and dragging and dropping 1000
pages of text is causing me a lot of misery and pain. I blasted off a
reply to Jonathon's over-bounding enthusiasm without stopping to count
to 10.
Not an excuse. Just some kind of an explanation, if such a thing is
possible.
I guess Jacopo proved to be right in the end. I have ended up as nothing
more than a troll. Sad or wot? :(
Ian
Ian McNulty wrote:
> Jonathon,
>
> Have just been thinking about what you've been saying about learning
> the OFBiz framework inside of 10 minutes and how to read OFBiz 'like
> an open REFERENCE book.'
>
> A short document describing exactly how to go about such a thing
> couldn't take more than 10 minutes to read by definition, and probably
> wouldn't take you much longer than that to write.
>
> I'd certainly be interested in reading such a thing and I bet a lot of
> other people would too. It could be a major drawing point for our site.
>
> Just a thought! (Or a wish fulfilment on my part perhaps. Wading
> through the 1000+ pages of awful, miserable rubbish generated by Les
> Austin, the technical writer drafted in by David at apparently huge
> expense. Wishing I could find something myself that I could put
> together in a couple of hours rather than a couple of months!)
>
> Ian
>
>
>
>
> Jonathon -- Improov wrote:
>> Cedric,
>>
>> > Jonathon, a collaboration? Yes, why not? But I am sure I will not
>> show you
>> > much things because you are more experienced than me =)
>>
>> I started looking at OFBiz framework in Jan 07 (last month). I
>> probably spent no more than a week(?) on learning OFBiz framework
>> itself; much of my time was spent on data mapping and struggling(!!)
>> with freeing my boss' data from legacy systems, and also on comparing
>> OFBiz with other solutions (he kept knocking OFBiz big-time). I had
>> no docs, no references (save xsd schemas), I even missed the
>> cookbooks altogether (which really are quite skeletal, anyway).
>>
>> Believe me, OFBiz is easy to pick up.
>>
>> Somewhat exact time requirements (in case your boss asks):
>>
>> 1. 10 minutes to learn structure of OFBiz, so you know how to move
>> around.
>>
>> 2. 1-2 minutes to look up anything related to OFBiz, since you'll be
>> reading
>> OFBiz like an open REFERENCE book.
>>
>> > there are questions about the use of screen/form widgets and
>> > Beanshell/minilang. I am not well experienced but I don't know if
>> developers
>> > will like to learn these new things instead of working with what
>> they know.
>>
>> As I mentioned in other threads, it IS possible to learn OFBiz inside
>> of 10 minutes.
>>
>> But you could be right. IMHO, the lack of clear OFBiz framework
>> references (not videos that are unsearchable) may be hindering the
>> explosive growth of the OFBiz-enabled engineer population. Also IMHO,
>> an explosion in the number of OFBiz-enabled engineers will likely
>> feed back into OFBiz very rapidly. And further IMHO, David Jones
>> (creator of OFBiz) will then probably have a whole army of willing
>> volunteers to choose from (many open source projects employ ULTRA
>> STRINGENT qualifying criteria to screen volunteers before making them
>> committers; you do get many top brains in open source projects, so
>> good that you/I probably can't ever argue with those).
>>
>> And finally, IMHO, I could be entirely wrong in above paragraph. I am
>> not David Jones; I never created an open source project myself.
>>
>> Bottom line. OFBiz framework is solid (may need tweaks, but
>> enhancements are on the way all the time). I'll be sorry if I missed it.
>>
>> Jonathon
>>
>> PRONZATO Cedric RD-BIZZ-GRE wrote:
>>> Hi all,
>>>
>>> Yes, you are all true! My approach is bottom-up learning. All of you
>>> here seem to read in me like an opened book; I now know that OFBiz
>>> is a training area for FBI Profilers. :)
>>>
>>> My aim (I think) was to fully understand the framework to be able to
>>> change/replace/add new *core* functionalities and test them in a
>>> real ecommerce environment.
>>> Yet I never played with 'call to a service' or so as the documents
>>> about that was enough clear. I said: All should be OK on this part.
>>> Entity engine and Service engine are clear and in respect of all the
>>> common and trusted laws of java development. (By the way is there
>>> any plan to turn to the new standards? OFBiz was in advance in 2000
>>> but now much developer well knows Spring just to name one ...)
>>> So after these 2 majors things there are questions about the use of
>>> screen/form widgets and Beanshell/minilang. I am not well
>>> experienced but I don't know if developers will like to learn these
>>> new things instead of working with what they know. So I decided to
>>> not investigate it much.
>>>
>>> Jonathon, a collaboration? Yes, why not? But I am sure I will not
>>> show you much things because you are more experienced than me =) I
>>> will check about what I am allowed to do with my company policy but
>>> I am confidant as OFBiz is a personal choice not too much tied to a
>>> project need. I stay you tuned.
>>>
>>> I now have to think about what is wrong on this approach, think
>>> about what is the next thing I have to investigate ...
>>>
>>> Thank you all,
>>> Regards,
>>> Cédric
>>>
>>> -----Message d'origine-----
>>> De : Jonathon -- Improov [mailto:jonw@improov.com] Envoyé : vendredi
>>> 9 février 2007 20:12
>>> À : user@ofbiz.apache.org
>>> Objet : Re: General questions
>>>
>>> Cedric,
>>>
>>> I get the same impression as Adrian too.
>>>
>>> Since you're from the R&D department, I suppose you're as much of a
>>> freak as I am. I took apart OFBiz at the source code level too.
>>>
>>> Unless you're employing some language-processing heuristics in your
>>> reverse-engineering, you'll be spending way too much time doing
>>> brute-force studies from the bottom-up. Better to just learn from
>>> playing with OFBiz framework (not the framework source codes), such
>>> as service engine and entity engine, in this case.
>>>
>>> While it is true that learning by playing with the framework will
>>> certainly be faster, I do admit it is not as easy as many would
>>> hope. Technical references for working the OFBiz framework are not
>>> all in one place, or even complete (mostly still in form of
>>> cookbooks at the moment). Ie, there are no "javadocs equivalent" for
>>> the OFBiz framework, except at
>>> http://www.undersunconsulting.com/ecommerce/control/main .
>>>
>>> In fact, some folks here have never gotten around to using all of
>>> the OFBiz framework. Some don't use screen/form widgets, but FTL
>>> instead. Some use Beanshell rather than Minilang.
>>>
>>> I guess what I'm trying to say is this. Since you're from the R&D
>>> department, it would be "within your scope" to learn the OFBiz
>>> framework in any way possible, such as from studying the source
>>> codes or playing with the framework itself. No use complaining what
>>> isn't there; better to get things working somehow.
>>>
>>> For those not from the R&D department, though, then yes I do admit
>>> OFBiz doesn't have a nice polished expensive "welcome mat/carpet"
>>> for new users.
>>>
>>> If you do want to get help learning the OFBiz framework, you can
>>> either work with me and write down all that I've discovered through
>>> my own reverse-engineering, or you can employ some of the experts
>>> here to teach you. I'll have to train some staff on OFBiz before I
>>> sign off my current project, so your help here would be much
>>> appreciated.
>>>
>>> Hope you enjoy OFBiz as much as I have. :)
>>>
>>> Jonathon
>>>
>>> Adrian Crum wrote:
>>>> Cedric,
>>>>
>>>> I might be wrong, but I get the impression you are trying to
>>>> approach OFBiz from the bottom up (examining java classes versus
>>>> examining higher-level layers). I made that mistake when I first
>>>> got involved with OFBiz.
>>>>
>>>> It would be better to look at things like the service engine,
>>>> entity engine, screen widgets, etc. Get an idea of how the
>>>> presentation layer works, then work your way down to the service
>>>> layer, then down to the database schema, etc.
>>>>
>>>> Typically, the only reason anyone would want to get into the java
>>>> source would be to fix a bug or make a modification at a very low
>>>> level of the architecture "stack."
>>>>
>>>>
>>>>
>>>> PRONZATO Cedric RD-BIZZ-GRE wrote:
>>>>
>>>>> Re,
>>>>>
>>>>> Yes you are true but I think I didn't explained myself.
>>>>> These questions may have been answered in the javadocs. I am sure
>>>>> you know (you that architects of OFBiz) why you decided to make a
>>>>> Container class and so on.
>>>>> So perhaps a little enhancement of javadoc on foundation classes
>>>>> to explain why and where to use it would be so nice.
>>>>>
>>>>> I hope I do not look like too much arrogant with my questions on
>>>>> that thread "General questions"; I just expose the problems I was
>>>>> faced to.
>>>>>
>>>>> Regards,
>>>>> Cédric
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : David E. Jones [mailto:jonesde@hotwaxmedia.com] Envoyé :
>>>>> vendredi
>>>>> 9 février 2007 18:12
>>>>> À : user@ofbiz.apache.org
>>>>> Objet : Re: General questions
>>>>>
>>>>>
>>>>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
>>>>>
>>>>>
>>>>>> A related problem is how to do "framework" components, I mean
>>>>>> patterns. I think about my SMSC component, I base my code on the
>>>>>> mail container and questions arised:
>>>>>> - When do I have to make my own xml language (ie. MCA for the
>>>>>> mail container)?
>>>>>> - When do I have to make a Container? I guess the answer is if
>>>>>> you have to manage the lifetime (create/release connections, ...).
>>>>>> - When do I have to make an Engine?
>>>>>> - ...
>>>>>>
>>>>>> So I guess we can finish with the following statement: "How to
>>>>>> *use* is quite well documented but how to *make* is a bit less".
>>>>>
>>>>> Have you ever found such a document for anything?
>>>>>
>>>>> My usual approach is generally something like:
>>>>>
>>>>> 1. understand everything that exists, or research anything that is
>>>>> unclear 2. write something manually a number of times so you know
>>>>> what is always the same, and what varies 3. see if a paramerized
>>>>> tool would be helpful 4. apply a significant amount of "genius"
>>>>> 5. apply even more "sweat" to try stuff 6. create an incredible
>>>>> tool or service or however it is best implemented
>>>>>
>>>>> If there was a way to make creation deterministic, what would be
>>>>> the point of creativity?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>
>>>
>>
>>
>>
>
--
----------------------------------------------------------------------------------------------
mcnultyMEDIA
60 Birkdale Gardens
Durham
DH1 2UL
t: +44 (0)191 384 4736
e: ian@mcnultymedia.co.uk
w: www.mcnultymedia.co.uk
==============================================================================================
This communication is for the exclusive use of the intended recipient(s) named above and is confidential. Any form of distribution, copying, discussion or use of this communication, its contents, or any information contained herein without prior consent is strictly prohibited. If you receive this communication in error, please notify the sender by email or by telephone on +44 (0)191 384 4736
This email has been checked for viruses, however, we cannot accept any liability sustained as a result of software viruses and would recommend that you carry out your own virus checks before opening any attachment.
==============================================================================================
Re: General questions
Posted by Ian McNulty <ia...@mcnultymedia.co.uk>.
Jonathon,
Have just been thinking about what you've been saying about learning the
OFBiz framework inside of 10 minutes and how to read OFBiz 'like an open
REFERENCE book.'
A short document describing exactly how to go about such a thing
couldn't take more than 10 minutes to read by definition, and probably
wouldn't take you much longer than that to write.
I'd certainly be interested in reading such a thing and I bet a lot of
other people would too. It could be a major drawing point for our site.
Just a thought! (Or a wish fulfilment on my part perhaps. Wading through
the 1000+ pages of awful, miserable rubbish generated by Les Austin, the
technical writer drafted in by David at apparently huge expense. Wishing
I could find something myself that I could put together in a couple of
hours rather than a couple of months!)
Ian
Jonathon -- Improov wrote:
> Cedric,
>
> > Jonathon, a collaboration? Yes, why not? But I am sure I will not
> show you
> > much things because you are more experienced than me =)
>
> I started looking at OFBiz framework in Jan 07 (last month). I
> probably spent no more than a week(?) on learning OFBiz framework
> itself; much of my time was spent on data mapping and struggling(!!)
> with freeing my boss' data from legacy systems, and also on comparing
> OFBiz with other solutions (he kept knocking OFBiz big-time). I had no
> docs, no references (save xsd schemas), I even missed the cookbooks
> altogether (which really are quite skeletal, anyway).
>
> Believe me, OFBiz is easy to pick up.
>
> Somewhat exact time requirements (in case your boss asks):
>
> 1. 10 minutes to learn structure of OFBiz, so you know how to move
> around.
>
> 2. 1-2 minutes to look up anything related to OFBiz, since you'll be
> reading
> OFBiz like an open REFERENCE book.
>
> > there are questions about the use of screen/form widgets and
> > Beanshell/minilang. I am not well experienced but I don't know if
> developers
> > will like to learn these new things instead of working with what
> they know.
>
> As I mentioned in other threads, it IS possible to learn OFBiz inside
> of 10 minutes.
>
> But you could be right. IMHO, the lack of clear OFBiz framework
> references (not videos that are unsearchable) may be hindering the
> explosive growth of the OFBiz-enabled engineer population. Also IMHO,
> an explosion in the number of OFBiz-enabled engineers will likely feed
> back into OFBiz very rapidly. And further IMHO, David Jones (creator
> of OFBiz) will then probably have a whole army of willing volunteers
> to choose from (many open source projects employ ULTRA STRINGENT
> qualifying criteria to screen volunteers before making them
> committers; you do get many top brains in open source projects, so
> good that you/I probably can't ever argue with those).
>
> And finally, IMHO, I could be entirely wrong in above paragraph. I am
> not David Jones; I never created an open source project myself.
>
> Bottom line. OFBiz framework is solid (may need tweaks, but
> enhancements are on the way all the time). I'll be sorry if I missed it.
>
> Jonathon
>
> PRONZATO Cedric RD-BIZZ-GRE wrote:
>> Hi all,
>>
>> Yes, you are all true! My approach is bottom-up learning. All of you
>> here seem to read in me like an opened book; I now know that OFBiz is
>> a training area for FBI Profilers. :)
>>
>> My aim (I think) was to fully understand the framework to be able to
>> change/replace/add new *core* functionalities and test them in a real
>> ecommerce environment.
>> Yet I never played with 'call to a service' or so as the documents
>> about that was enough clear. I said: All should be OK on this part.
>> Entity engine and Service engine are clear and in respect of all the
>> common and trusted laws of java development. (By the way is there any
>> plan to turn to the new standards? OFBiz was in advance in 2000 but
>> now much developer well knows Spring just to name one ...)
>> So after these 2 majors things there are questions about the use of
>> screen/form widgets and Beanshell/minilang. I am not well experienced
>> but I don't know if developers will like to learn these new things
>> instead of working with what they know. So I decided to not
>> investigate it much.
>>
>> Jonathon, a collaboration? Yes, why not? But I am sure I will not
>> show you much things because you are more experienced than me =) I
>> will check about what I am allowed to do with my company policy but I
>> am confidant as OFBiz is a personal choice not too much tied to a
>> project need. I stay you tuned.
>>
>> I now have to think about what is wrong on this approach, think about
>> what is the next thing I have to investigate ...
>>
>> Thank you all,
>> Regards,
>> Cédric
>>
>> -----Message d'origine-----
>> De : Jonathon -- Improov [mailto:jonw@improov.com] Envoyé : vendredi
>> 9 février 2007 20:12
>> À : user@ofbiz.apache.org
>> Objet : Re: General questions
>>
>> Cedric,
>>
>> I get the same impression as Adrian too.
>>
>> Since you're from the R&D department, I suppose you're as much of a
>> freak as I am. I took apart OFBiz at the source code level too.
>>
>> Unless you're employing some language-processing heuristics in your
>> reverse-engineering, you'll be spending way too much time doing
>> brute-force studies from the bottom-up. Better to just learn from
>> playing with OFBiz framework (not the framework source codes), such
>> as service engine and entity engine, in this case.
>>
>> While it is true that learning by playing with the framework will
>> certainly be faster, I do admit it is not as easy as many would hope.
>> Technical references for working the OFBiz framework are not all in
>> one place, or even complete (mostly still in form of cookbooks at the
>> moment). Ie, there are no "javadocs equivalent" for the OFBiz
>> framework, except at
>> http://www.undersunconsulting.com/ecommerce/control/main .
>>
>> In fact, some folks here have never gotten around to using all of the
>> OFBiz framework. Some don't use screen/form widgets, but FTL instead.
>> Some use Beanshell rather than Minilang.
>>
>> I guess what I'm trying to say is this. Since you're from the R&D
>> department, it would be "within your scope" to learn the OFBiz
>> framework in any way possible, such as from studying the source codes
>> or playing with the framework itself. No use complaining what isn't
>> there; better to get things working somehow.
>>
>> For those not from the R&D department, though, then yes I do admit
>> OFBiz doesn't have a nice polished expensive "welcome mat/carpet" for
>> new users.
>>
>> If you do want to get help learning the OFBiz framework, you can
>> either work with me and write down all that I've discovered through
>> my own reverse-engineering, or you can employ some of the experts
>> here to teach you. I'll have to train some staff on OFBiz before I
>> sign off my current project, so your help here would be much
>> appreciated.
>>
>> Hope you enjoy OFBiz as much as I have. :)
>>
>> Jonathon
>>
>> Adrian Crum wrote:
>>> Cedric,
>>>
>>> I might be wrong, but I get the impression you are trying to
>>> approach OFBiz from the bottom up (examining java classes versus
>>> examining higher-level layers). I made that mistake when I first got
>>> involved with OFBiz.
>>>
>>> It would be better to look at things like the service engine, entity
>>> engine, screen widgets, etc. Get an idea of how the presentation
>>> layer works, then work your way down to the service layer, then down
>>> to the database schema, etc.
>>>
>>> Typically, the only reason anyone would want to get into the java
>>> source would be to fix a bug or make a modification at a very low
>>> level of the architecture "stack."
>>>
>>>
>>>
>>> PRONZATO Cedric RD-BIZZ-GRE wrote:
>>>
>>>> Re,
>>>>
>>>> Yes you are true but I think I didn't explained myself.
>>>> These questions may have been answered in the javadocs. I am sure
>>>> you know (you that architects of OFBiz) why you decided to make a
>>>> Container class and so on.
>>>> So perhaps a little enhancement of javadoc on foundation classes to
>>>> explain why and where to use it would be so nice.
>>>>
>>>> I hope I do not look like too much arrogant with my questions on
>>>> that thread "General questions"; I just expose the problems I was
>>>> faced to.
>>>>
>>>> Regards,
>>>> Cédric
>>>>
>>>> -----Message d'origine-----
>>>> De : David E. Jones [mailto:jonesde@hotwaxmedia.com] Envoyé : vendredi
>>>> 9 février 2007 18:12
>>>> À : user@ofbiz.apache.org
>>>> Objet : Re: General questions
>>>>
>>>>
>>>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
>>>>
>>>>
>>>>> A related problem is how to do "framework" components, I mean
>>>>> patterns. I think about my SMSC component, I base my code on the
>>>>> mail container and questions arised:
>>>>> - When do I have to make my own xml language (ie. MCA for the mail
>>>>> container)?
>>>>> - When do I have to make a Container? I guess the answer is if you
>>>>> have to manage the lifetime (create/release connections, ...).
>>>>> - When do I have to make an Engine?
>>>>> - ...
>>>>>
>>>>> So I guess we can finish with the following statement: "How to
>>>>> *use* is quite well documented but how to *make* is a bit less".
>>>>
>>>> Have you ever found such a document for anything?
>>>>
>>>> My usual approach is generally something like:
>>>>
>>>> 1. understand everything that exists, or research anything that is
>>>> unclear 2. write something manually a number of times so you know
>>>> what is always the same, and what varies 3. see if a paramerized
>>>> tool would be helpful 4. apply a significant amount of "genius"
>>>> 5. apply even more "sweat" to try stuff 6. create an incredible
>>>> tool or service or however it is best implemented
>>>>
>>>> If there was a way to make creation deterministic, what would be
>>>> the point of creativity?
>>>>
>>>> -David
>>>>
>>>>
>>
>>
>
>
>
--
----------------------------------------------------------------------------------------------
mcnultyMEDIA
60 Birkdale Gardens
Durham
DH1 2UL
t: +44 (0)191 384 4736
e: ian@mcnultymedia.co.uk
w: www.mcnultymedia.co.uk
==============================================================================================
This communication is for the exclusive use of the intended recipient(s) named above and is confidential. Any form of distribution, copying, discussion or use of this communication, its contents, or any information contained herein without prior consent is strictly prohibited. If you receive this communication in error, please notify the sender by email or by telephone on +44 (0)191 384 4736
This email has been checked for viruses, however, we cannot accept any liability sustained as a result of software viruses and would recommend that you carry out your own virus checks before opening any attachment.
==============================================================================================
Re: General questions
Posted by Jonathon -- Improov <jo...@improov.com>.
Cedric,
> Jonathon, a collaboration? Yes, why not? But I am sure I will not show you
> much things because you are more experienced than me =)
I started looking at OFBiz framework in Jan 07 (last month). I probably spent no more than a
week(?) on learning OFBiz framework itself; much of my time was spent on data mapping and
struggling(!!) with freeing my boss' data from legacy systems, and also on comparing OFBiz with
other solutions (he kept knocking OFBiz big-time). I had no docs, no references (save xsd
schemas), I even missed the cookbooks altogether (which really are quite skeletal, anyway).
Believe me, OFBiz is easy to pick up.
Somewhat exact time requirements (in case your boss asks):
1. 10 minutes to learn structure of OFBiz, so you know how to move around.
2. 1-2 minutes to look up anything related to OFBiz, since you'll be reading
OFBiz like an open REFERENCE book.
> there are questions about the use of screen/form widgets and
> Beanshell/minilang. I am not well experienced but I don't know if developers
> will like to learn these new things instead of working with what they know.
As I mentioned in other threads, it IS possible to learn OFBiz inside of 10 minutes.
But you could be right. IMHO, the lack of clear OFBiz framework references (not videos that are
unsearchable) may be hindering the explosive growth of the OFBiz-enabled engineer population. Also
IMHO, an explosion in the number of OFBiz-enabled engineers will likely feed back into OFBiz very
rapidly. And further IMHO, David Jones (creator of OFBiz) will then probably have a whole army of
willing volunteers to choose from (many open source projects employ ULTRA STRINGENT qualifying
criteria to screen volunteers before making them committers; you do get many top brains in open
source projects, so good that you/I probably can't ever argue with those).
And finally, IMHO, I could be entirely wrong in above paragraph. I am not David Jones; I never
created an open source project myself.
Bottom line. OFBiz framework is solid (may need tweaks, but enhancements are on the way all the
time). I'll be sorry if I missed it.
Jonathon
PRONZATO Cedric RD-BIZZ-GRE wrote:
> Hi all,
>
> Yes, you are all true! My approach is bottom-up learning. All of you here seem to read in me like an opened book; I now know that OFBiz is a training area for FBI Profilers. :)
>
> My aim (I think) was to fully understand the framework to be able to change/replace/add new *core* functionalities and test them in a real ecommerce environment.
> Yet I never played with 'call to a service' or so as the documents about that was enough clear. I said: All should be OK on this part.
> Entity engine and Service engine are clear and in respect of all the common and trusted laws of java development. (By the way is there any plan to turn to the new standards? OFBiz was in advance in 2000 but now much developer well knows Spring just to name one ...)
> So after these 2 majors things there are questions about the use of screen/form widgets and Beanshell/minilang. I am not well experienced but I don't know if developers will like to learn these new things instead of working with what they know. So I decided to not investigate it much.
>
> Jonathon, a collaboration? Yes, why not? But I am sure I will not show you much things because you are more experienced than me =)
> I will check about what I am allowed to do with my company policy but I am confidant as OFBiz is a personal choice not too much tied to a project need. I stay you tuned.
>
> I now have to think about what is wrong on this approach, think about what is the next thing I have to investigate ...
>
> Thank you all,
> Regards,
> Cédric
>
> -----Message d'origine-----
> De : Jonathon -- Improov [mailto:jonw@improov.com]
> Envoyé : vendredi 9 février 2007 20:12
> À : user@ofbiz.apache.org
> Objet : Re: General questions
>
> Cedric,
>
> I get the same impression as Adrian too.
>
> Since you're from the R&D department, I suppose you're as much of a freak as I am. I took apart OFBiz at the source code level too.
>
> Unless you're employing some language-processing heuristics in your reverse-engineering, you'll be spending way too much time doing brute-force studies from the bottom-up. Better to just learn from playing with OFBiz framework (not the framework source codes), such as service engine and entity engine, in this case.
>
> While it is true that learning by playing with the framework will certainly be faster, I do admit it is not as easy as many would hope. Technical references for working the OFBiz framework are not all in one place, or even complete (mostly still in form of cookbooks at the moment). Ie, there are no "javadocs equivalent" for the OFBiz framework, except at http://www.undersunconsulting.com/ecommerce/control/main .
>
> In fact, some folks here have never gotten around to using all of the OFBiz framework. Some don't use screen/form widgets, but FTL instead. Some use Beanshell rather than Minilang.
>
> I guess what I'm trying to say is this. Since you're from the R&D department, it would be "within your scope" to learn the OFBiz framework in any way possible, such as from studying the source codes or playing with the framework itself. No use complaining what isn't there; better to get things working somehow.
>
> For those not from the R&D department, though, then yes I do admit OFBiz doesn't have a nice polished expensive "welcome mat/carpet" for new users.
>
> If you do want to get help learning the OFBiz framework, you can either work with me and write down all that I've discovered through my own reverse-engineering, or you can employ some of the experts here to teach you. I'll have to train some staff on OFBiz before I sign off my current project, so your help here would be much appreciated.
>
> Hope you enjoy OFBiz as much as I have. :)
>
> Jonathon
>
> Adrian Crum wrote:
>> Cedric,
>>
>> I might be wrong, but I get the impression you are trying to approach
>> OFBiz from the bottom up (examining java classes versus examining
>> higher-level layers). I made that mistake when I first got involved
>> with OFBiz.
>>
>> It would be better to look at things like the service engine, entity
>> engine, screen widgets, etc. Get an idea of how the presentation layer
>> works, then work your way down to the service layer, then down to the
>> database schema, etc.
>>
>> Typically, the only reason anyone would want to get into the java
>> source would be to fix a bug or make a modification at a very low
>> level of the architecture "stack."
>>
>>
>>
>> PRONZATO Cedric RD-BIZZ-GRE wrote:
>>
>>> Re,
>>>
>>> Yes you are true but I think I didn't explained myself.
>>> These questions may have been answered in the javadocs. I am sure you
>>> know (you that architects of OFBiz) why you decided to make a
>>> Container class and so on.
>>> So perhaps a little enhancement of javadoc on foundation classes to
>>> explain why and where to use it would be so nice.
>>>
>>> I hope I do not look like too much arrogant with my questions on that
>>> thread "General questions"; I just expose the problems I was faced to.
>>>
>>> Regards,
>>> Cédric
>>>
>>> -----Message d'origine-----
>>> De : David E. Jones [mailto:jonesde@hotwaxmedia.com] Envoyé :
>>> vendredi
>>> 9 février 2007 18:12
>>> À : user@ofbiz.apache.org
>>> Objet : Re: General questions
>>>
>>>
>>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
>>>
>>>
>>>> A related problem is how to do "framework" components, I mean
>>>> patterns. I think about my SMSC component, I base my code on the
>>>> mail container and questions arised:
>>>> - When do I have to make my own xml language (ie. MCA for the mail
>>>> container)?
>>>> - When do I have to make a Container? I guess the answer is if you
>>>> have to manage the lifetime (create/release connections, ...).
>>>> - When do I have to make an Engine?
>>>> - ...
>>>>
>>>> So I guess we can finish with the following statement: "How to
>>>> *use* is quite well documented but how to *make* is a bit less".
>>>
>>> Have you ever found such a document for anything?
>>>
>>> My usual approach is generally something like:
>>>
>>> 1. understand everything that exists, or research anything that is
>>> unclear 2. write something manually a number of times so you know
>>> what is always the same, and what varies 3. see if a paramerized tool
>>> would be helpful 4. apply a significant amount of "genius"
>>> 5. apply even more "sweat" to try stuff 6. create an incredible tool
>>> or service or however it is best implemented
>>>
>>> If there was a way to make creation deterministic, what would be the
>>> point of creativity?
>>>
>>> -David
>>>
>>>
>
>
Re: General questions
Posted by Jonathon -- Improov <jo...@improov.com>.
Andrew,
You're right. I've seen too many refactors and manhours wasted. But don't you often wish you had
programmers who could hit the ground sprinting? I guess I do have this problem of telling
everybody "you can do it, in minutes".
I think all newbies should at least try to get the ML's help to review methods before proceeding
(like I did).
Be it bottom-up or top-down learning of OFBiz, I still say OFBiz is easy to pick up. And once we
do, we'd wonder how to get on without it.
I guess, in general (to answer the "General Questions"), there really is a point to learn OFBiz,
whether it's tough or easy to learn. David wrote somewhere that OFBiz does try to use open source
tools whenever feasible. OFBiz framework is a feasible tool, far as I can tell. (There ARE great
tools out there that a quite infeasible, at least in some situations.)
And now, other less important/general stuff.
"Exhaustive study" to me equals an "evil automated language-processing heuristics search across
all OFBiz examples and templates to catch candidates possible for use". Yeah, I did that. Every
widget entity I use, I take apart that entity's insides, know how it works inside-out, then employ
it (if it's appropriate).
As for avoiding refactoring, there's always some "enough is enough" point where I leap off of my
"let's make an ultra extensible structure" pre-project project. I've looked at Si Chen's examples
of insulating codes from OFBiz core, looked at other examples outside of hot-deploy. Even studied
database transactional integrity with the various methods (eca hook-ons, chained requests,
extends, implements, etc). (Thanks especially to Jacopo and Chris Howe for some final-touch
reviews of my "methods").
So yeah, all newbies should be careful not to plunge in swimming in all the wrong directions. I
like drowning, so don't follow me. I'm not a newbie, perhaps; I'm a nobody gone mad. Hmm. You
could call David a similar nobody too (I just read his "usual approach" that looks like "wickedly
agile R&D" to me).
Jonathon
Andrew Sykes wrote:
> Jonathon,
>
> I think it's great that you found it so easy to learn, but I'd have to
> urge caution to any newbie who thinks setting aside a time period
> measured in minutes will be enough to get productive.
>
> Generally I find the longer people study the less refactoring they find
> themselves doing down the line.
>
> Be very careful of writing code before you've undertaken an exhaustive
> study!
>
> - Andrew
>
>
> On Tue, 2007-02-13 at 14:20 +0800, Jonathon -- Improov wrote:
>> Cedric,
>>
>> > Jonathon, a collaboration? Yes, why not? But I am sure I will not show you
>> > much things because you are more experienced than me =)
>>
>> I started looking at OFBiz framework in Jan 07 (last month). I probably spent no more than a
>> week(?) on learning OFBiz framework itself; much of my time was spent on data mapping and
>> struggling(!!) with freeing my boss' data from legacy systems, and also on comparing OFBiz with
>> other solutions (he kept knocking OFBiz big-time). I had no docs, no references (save xsd
>> schemas), I even missed the cookbooks altogether (which really are quite skeletal, anyway).
>>
>> Believe me, OFBiz is easy to pick up.
>>
>> Somewhat exact time requirements (in case your boss asks):
>>
>> 1. 10 minutes to learn structure of OFBiz, so you know how to move around.
>>
>> 2. 1-2 minutes to look up anything related to OFBiz, since you'll be reading
>> OFBiz like an open REFERENCE book.
>>
>> > there are questions about the use of screen/form widgets and
>> > Beanshell/minilang. I am not well experienced but I don't know if developers
>> > will like to learn these new things instead of working with what they know.
>>
>> As I mentioned in other threads, it IS possible to learn OFBiz inside of 10 minutes.
>>
>> But you could be right. IMHO, the lack of clear OFBiz framework references (not videos that are
>> unsearchable) may be hindering the explosive growth of the OFBiz-enabled engineer population. Also
>> IMHO, an explosion in the number of OFBiz-enabled engineers will likely feed back into OFBiz very
>> rapidly. And further IMHO, David Jones (creator of OFBiz) will then probably have a whole army of
>> willing volunteers to choose from (many open source projects employ ULTRA STRINGENT qualifying
>> criteria to screen volunteers before making them committers; you do get many top brains in open
>> source projects, so good that you/I probably can't ever argue with those).
>>
>> And finally, IMHO, I could be entirely wrong in above paragraph. I am not David Jones; I never
>> created an open source project myself.
>>
>> Bottom line. OFBiz framework is solid (may need tweaks, but enhancements are on the way all the
>> time). I'll be sorry if I missed it.
>>
>> Jonathon
>>
>> PRONZATO Cedric RD-BIZZ-GRE wrote:
>>> Hi all,
>>>
>>> Yes, you are all true! My approach is bottom-up learning. All of you here seem to read in me like an opened book; I now know that OFBiz is a training area for FBI Profilers. :)
>>>
>>> My aim (I think) was to fully understand the framework to be able to change/replace/add new *core* functionalities and test them in a real ecommerce environment.
>>> Yet I never played with 'call to a service' or so as the documents about that was enough clear. I said: All should be OK on this part.
>>> Entity engine and Service engine are clear and in respect of all the common and trusted laws of java development. (By the way is there any plan to turn to the new standards? OFBiz was in advance in 2000 but now much developer well knows Spring just to name one ...)
>>> So after these 2 majors things there are questions about the use of screen/form widgets and Beanshell/minilang. I am not well experienced but I don't know if developers will like to learn these new things instead of working with what they know. So I decided to not investigate it much.
>>>
>>> Jonathon, a collaboration? Yes, why not? But I am sure I will not show you much things because you are more experienced than me =)
>>> I will check about what I am allowed to do with my company policy but I am confidant as OFBiz is a personal choice not too much tied to a project need. I stay you tuned.
>>>
>>> I now have to think about what is wrong on this approach, think about what is the next thing I have to investigate ...
>>>
>>> Thank you all,
>>> Regards,
>>> Cédric
>>>
>>> -----Message d'origine-----
>>> De : Jonathon -- Improov [mailto:jonw@improov.com]
>>> Envoyé : vendredi 9 février 2007 20:12
>>> À : user@ofbiz.apache.org
>>> Objet : Re: General questions
>>>
>>> Cedric,
>>>
>>> I get the same impression as Adrian too.
>>>
>>> Since you're from the R&D department, I suppose you're as much of a freak as I am. I took apart OFBiz at the source code level too.
>>>
>>> Unless you're employing some language-processing heuristics in your reverse-engineering, you'll be spending way too much time doing brute-force studies from the bottom-up. Better to just learn from playing with OFBiz framework (not the framework source codes), such as service engine and entity engine, in this case.
>>>
>>> While it is true that learning by playing with the framework will certainly be faster, I do admit it is not as easy as many would hope. Technical references for working the OFBiz framework are not all in one place, or even complete (mostly still in form of cookbooks at the moment). Ie, there are no "javadocs equivalent" for the OFBiz framework, except at http://www.undersunconsulting.com/ecommerce/control/main .
>>>
>>> In fact, some folks here have never gotten around to using all of the OFBiz framework. Some don't use screen/form widgets, but FTL instead. Some use Beanshell rather than Minilang.
>>>
>>> I guess what I'm trying to say is this. Since you're from the R&D department, it would be "within your scope" to learn the OFBiz framework in any way possible, such as from studying the source codes or playing with the framework itself. No use complaining what isn't there; better to get things working somehow.
>>>
>>> For those not from the R&D department, though, then yes I do admit OFBiz doesn't have a nice polished expensive "welcome mat/carpet" for new users.
>>>
>>> If you do want to get help learning the OFBiz framework, you can either work with me and write down all that I've discovered through my own reverse-engineering, or you can employ some of the experts here to teach you. I'll have to train some staff on OFBiz before I sign off my current project, so your help here would be much appreciated.
>>>
>>> Hope you enjoy OFBiz as much as I have. :)
>>>
>>> Jonathon
>>>
>>> Adrian Crum wrote:
>>>> Cedric,
>>>>
>>>> I might be wrong, but I get the impression you are trying to approach
>>>> OFBiz from the bottom up (examining java classes versus examining
>>>> higher-level layers). I made that mistake when I first got involved
>>>> with OFBiz.
>>>>
>>>> It would be better to look at things like the service engine, entity
>>>> engine, screen widgets, etc. Get an idea of how the presentation layer
>>>> works, then work your way down to the service layer, then down to the
>>>> database schema, etc.
>>>>
>>>> Typically, the only reason anyone would want to get into the java
>>>> source would be to fix a bug or make a modification at a very low
>>>> level of the architecture "stack."
>>>>
>>>>
>>>>
>>>> PRONZATO Cedric RD-BIZZ-GRE wrote:
>>>>
>>>>> Re,
>>>>>
>>>>> Yes you are true but I think I didn't explained myself.
>>>>> These questions may have been answered in the javadocs. I am sure you
>>>>> know (you that architects of OFBiz) why you decided to make a
>>>>> Container class and so on.
>>>>> So perhaps a little enhancement of javadoc on foundation classes to
>>>>> explain why and where to use it would be so nice.
>>>>>
>>>>> I hope I do not look like too much arrogant with my questions on that
>>>>> thread "General questions"; I just expose the problems I was faced to.
>>>>>
>>>>> Regards,
>>>>> Cédric
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : David E. Jones [mailto:jonesde@hotwaxmedia.com] Envoyé :
>>>>> vendredi
>>>>> 9 février 2007 18:12
>>>>> À : user@ofbiz.apache.org
>>>>> Objet : Re: General questions
>>>>>
>>>>>
>>>>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
>>>>>
>>>>>
>>>>>> A related problem is how to do "framework" components, I mean
>>>>>> patterns. I think about my SMSC component, I base my code on the
>>>>>> mail container and questions arised:
>>>>>> - When do I have to make my own xml language (ie. MCA for the mail
>>>>>> container)?
>>>>>> - When do I have to make a Container? I guess the answer is if you
>>>>>> have to manage the lifetime (create/release connections, ...).
>>>>>> - When do I have to make an Engine?
>>>>>> - ...
>>>>>>
>>>>>> So I guess we can finish with the following statement: "How to
>>>>>> *use* is quite well documented but how to *make* is a bit less".
>>>>> Have you ever found such a document for anything?
>>>>>
>>>>> My usual approach is generally something like:
>>>>>
>>>>> 1. understand everything that exists, or research anything that is
>>>>> unclear 2. write something manually a number of times so you know
>>>>> what is always the same, and what varies 3. see if a paramerized tool
>>>>> would be helpful 4. apply a significant amount of "genius"
>>>>> 5. apply even more "sweat" to try stuff 6. create an incredible tool
>>>>> or service or however it is best implemented
>>>>>
>>>>> If there was a way to make creation deterministic, what would be the
>>>>> point of creativity?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>
Re: General questions
Posted by Andrew Sykes <an...@sykesdevelopment.com>.
Jonathon,
I think it's great that you found it so easy to learn, but I'd have to
urge caution to any newbie who thinks setting aside a time period
measured in minutes will be enough to get productive.
Generally I find the longer people study the less refactoring they find
themselves doing down the line.
Be very careful of writing code before you've undertaken an exhaustive
study!
- Andrew
On Tue, 2007-02-13 at 14:20 +0800, Jonathon -- Improov wrote:
> Cedric,
>
> > Jonathon, a collaboration? Yes, why not? But I am sure I will not show you
> > much things because you are more experienced than me =)
>
> I started looking at OFBiz framework in Jan 07 (last month). I probably spent no more than a
> week(?) on learning OFBiz framework itself; much of my time was spent on data mapping and
> struggling(!!) with freeing my boss' data from legacy systems, and also on comparing OFBiz with
> other solutions (he kept knocking OFBiz big-time). I had no docs, no references (save xsd
> schemas), I even missed the cookbooks altogether (which really are quite skeletal, anyway).
>
> Believe me, OFBiz is easy to pick up.
>
> Somewhat exact time requirements (in case your boss asks):
>
> 1. 10 minutes to learn structure of OFBiz, so you know how to move around.
>
> 2. 1-2 minutes to look up anything related to OFBiz, since you'll be reading
> OFBiz like an open REFERENCE book.
>
> > there are questions about the use of screen/form widgets and
> > Beanshell/minilang. I am not well experienced but I don't know if developers
> > will like to learn these new things instead of working with what they know.
>
> As I mentioned in other threads, it IS possible to learn OFBiz inside of 10 minutes.
>
> But you could be right. IMHO, the lack of clear OFBiz framework references (not videos that are
> unsearchable) may be hindering the explosive growth of the OFBiz-enabled engineer population. Also
> IMHO, an explosion in the number of OFBiz-enabled engineers will likely feed back into OFBiz very
> rapidly. And further IMHO, David Jones (creator of OFBiz) will then probably have a whole army of
> willing volunteers to choose from (many open source projects employ ULTRA STRINGENT qualifying
> criteria to screen volunteers before making them committers; you do get many top brains in open
> source projects, so good that you/I probably can't ever argue with those).
>
> And finally, IMHO, I could be entirely wrong in above paragraph. I am not David Jones; I never
> created an open source project myself.
>
> Bottom line. OFBiz framework is solid (may need tweaks, but enhancements are on the way all the
> time). I'll be sorry if I missed it.
>
> Jonathon
>
> PRONZATO Cedric RD-BIZZ-GRE wrote:
> > Hi all,
> >
> > Yes, you are all true! My approach is bottom-up learning. All of you here seem to read in me like an opened book; I now know that OFBiz is a training area for FBI Profilers. :)
> >
> > My aim (I think) was to fully understand the framework to be able to change/replace/add new *core* functionalities and test them in a real ecommerce environment.
> > Yet I never played with 'call to a service' or so as the documents about that was enough clear. I said: All should be OK on this part.
> > Entity engine and Service engine are clear and in respect of all the common and trusted laws of java development. (By the way is there any plan to turn to the new standards? OFBiz was in advance in 2000 but now much developer well knows Spring just to name one ...)
> > So after these 2 majors things there are questions about the use of screen/form widgets and Beanshell/minilang. I am not well experienced but I don't know if developers will like to learn these new things instead of working with what they know. So I decided to not investigate it much.
> >
> > Jonathon, a collaboration? Yes, why not? But I am sure I will not show you much things because you are more experienced than me =)
> > I will check about what I am allowed to do with my company policy but I am confidant as OFBiz is a personal choice not too much tied to a project need. I stay you tuned.
> >
> > I now have to think about what is wrong on this approach, think about what is the next thing I have to investigate ...
> >
> > Thank you all,
> > Regards,
> > Cédric
> >
> > -----Message d'origine-----
> > De : Jonathon -- Improov [mailto:jonw@improov.com]
> > Envoyé : vendredi 9 février 2007 20:12
> > À : user@ofbiz.apache.org
> > Objet : Re: General questions
> >
> > Cedric,
> >
> > I get the same impression as Adrian too.
> >
> > Since you're from the R&D department, I suppose you're as much of a freak as I am. I took apart OFBiz at the source code level too.
> >
> > Unless you're employing some language-processing heuristics in your reverse-engineering, you'll be spending way too much time doing brute-force studies from the bottom-up. Better to just learn from playing with OFBiz framework (not the framework source codes), such as service engine and entity engine, in this case.
> >
> > While it is true that learning by playing with the framework will certainly be faster, I do admit it is not as easy as many would hope. Technical references for working the OFBiz framework are not all in one place, or even complete (mostly still in form of cookbooks at the moment). Ie, there are no "javadocs equivalent" for the OFBiz framework, except at http://www.undersunconsulting.com/ecommerce/control/main .
> >
> > In fact, some folks here have never gotten around to using all of the OFBiz framework. Some don't use screen/form widgets, but FTL instead. Some use Beanshell rather than Minilang.
> >
> > I guess what I'm trying to say is this. Since you're from the R&D department, it would be "within your scope" to learn the OFBiz framework in any way possible, such as from studying the source codes or playing with the framework itself. No use complaining what isn't there; better to get things working somehow.
> >
> > For those not from the R&D department, though, then yes I do admit OFBiz doesn't have a nice polished expensive "welcome mat/carpet" for new users.
> >
> > If you do want to get help learning the OFBiz framework, you can either work with me and write down all that I've discovered through my own reverse-engineering, or you can employ some of the experts here to teach you. I'll have to train some staff on OFBiz before I sign off my current project, so your help here would be much appreciated.
> >
> > Hope you enjoy OFBiz as much as I have. :)
> >
> > Jonathon
> >
> > Adrian Crum wrote:
> >> Cedric,
> >>
> >> I might be wrong, but I get the impression you are trying to approach
> >> OFBiz from the bottom up (examining java classes versus examining
> >> higher-level layers). I made that mistake when I first got involved
> >> with OFBiz.
> >>
> >> It would be better to look at things like the service engine, entity
> >> engine, screen widgets, etc. Get an idea of how the presentation layer
> >> works, then work your way down to the service layer, then down to the
> >> database schema, etc.
> >>
> >> Typically, the only reason anyone would want to get into the java
> >> source would be to fix a bug or make a modification at a very low
> >> level of the architecture "stack."
> >>
> >>
> >>
> >> PRONZATO Cedric RD-BIZZ-GRE wrote:
> >>
> >>> Re,
> >>>
> >>> Yes you are true but I think I didn't explained myself.
> >>> These questions may have been answered in the javadocs. I am sure you
> >>> know (you that architects of OFBiz) why you decided to make a
> >>> Container class and so on.
> >>> So perhaps a little enhancement of javadoc on foundation classes to
> >>> explain why and where to use it would be so nice.
> >>>
> >>> I hope I do not look like too much arrogant with my questions on that
> >>> thread "General questions"; I just expose the problems I was faced to.
> >>>
> >>> Regards,
> >>> Cédric
> >>>
> >>> -----Message d'origine-----
> >>> De : David E. Jones [mailto:jonesde@hotwaxmedia.com] Envoyé :
> >>> vendredi
> >>> 9 février 2007 18:12
> >>> À : user@ofbiz.apache.org
> >>> Objet : Re: General questions
> >>>
> >>>
> >>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
> >>>
> >>>
> >>>> A related problem is how to do "framework" components, I mean
> >>>> patterns. I think about my SMSC component, I base my code on the
> >>>> mail container and questions arised:
> >>>> - When do I have to make my own xml language (ie. MCA for the mail
> >>>> container)?
> >>>> - When do I have to make a Container? I guess the answer is if you
> >>>> have to manage the lifetime (create/release connections, ...).
> >>>> - When do I have to make an Engine?
> >>>> - ...
> >>>>
> >>>> So I guess we can finish with the following statement: "How to
> >>>> *use* is quite well documented but how to *make* is a bit less".
> >>>
> >>> Have you ever found such a document for anything?
> >>>
> >>> My usual approach is generally something like:
> >>>
> >>> 1. understand everything that exists, or research anything that is
> >>> unclear 2. write something manually a number of times so you know
> >>> what is always the same, and what varies 3. see if a paramerized tool
> >>> would be helpful 4. apply a significant amount of "genius"
> >>> 5. apply even more "sweat" to try stuff 6. create an incredible tool
> >>> or service or however it is best implemented
> >>>
> >>> If there was a way to make creation deterministic, what would be the
> >>> point of creativity?
> >>>
> >>> -David
> >>>
> >>>
> >
> >
>
--
Kind Regards
Andrew Sykes <an...@sykesdevelopment.com>
Sykes Development Ltd
http://www.sykesdevelopment.com
RE: General questions
Posted by PRONZATO Cedric RD-BIZZ-GRE <ce...@orange-ftgroup.com>.
Hi all,
Yes, you are all true! My approach is bottom-up learning. All of you here seem to read in me like an opened book; I now know that OFBiz is a training area for FBI Profilers. :)
My aim (I think) was to fully understand the framework to be able to change/replace/add new *core* functionalities and test them in a real ecommerce environment.
Yet I never played with 'call to a service' or so as the documents about that was enough clear. I said: All should be OK on this part.
Entity engine and Service engine are clear and in respect of all the common and trusted laws of java development. (By the way is there any plan to turn to the new standards? OFBiz was in advance in 2000 but now much developer well knows Spring just to name one ...)
So after these 2 majors things there are questions about the use of screen/form widgets and Beanshell/minilang. I am not well experienced but I don't know if developers will like to learn these new things instead of working with what they know. So I decided to not investigate it much.
Jonathon, a collaboration? Yes, why not? But I am sure I will not show you much things because you are more experienced than me =)
I will check about what I am allowed to do with my company policy but I am confidant as OFBiz is a personal choice not too much tied to a project need. I stay you tuned.
I now have to think about what is wrong on this approach, think about what is the next thing I have to investigate ...
Thank you all,
Regards,
Cédric
-----Message d'origine-----
De : Jonathon -- Improov [mailto:jonw@improov.com]
Envoyé : vendredi 9 février 2007 20:12
À : user@ofbiz.apache.org
Objet : Re: General questions
Cedric,
I get the same impression as Adrian too.
Since you're from the R&D department, I suppose you're as much of a freak as I am. I took apart OFBiz at the source code level too.
Unless you're employing some language-processing heuristics in your reverse-engineering, you'll be spending way too much time doing brute-force studies from the bottom-up. Better to just learn from playing with OFBiz framework (not the framework source codes), such as service engine and entity engine, in this case.
While it is true that learning by playing with the framework will certainly be faster, I do admit it is not as easy as many would hope. Technical references for working the OFBiz framework are not all in one place, or even complete (mostly still in form of cookbooks at the moment). Ie, there are no "javadocs equivalent" for the OFBiz framework, except at http://www.undersunconsulting.com/ecommerce/control/main .
In fact, some folks here have never gotten around to using all of the OFBiz framework. Some don't use screen/form widgets, but FTL instead. Some use Beanshell rather than Minilang.
I guess what I'm trying to say is this. Since you're from the R&D department, it would be "within your scope" to learn the OFBiz framework in any way possible, such as from studying the source codes or playing with the framework itself. No use complaining what isn't there; better to get things working somehow.
For those not from the R&D department, though, then yes I do admit OFBiz doesn't have a nice polished expensive "welcome mat/carpet" for new users.
If you do want to get help learning the OFBiz framework, you can either work with me and write down all that I've discovered through my own reverse-engineering, or you can employ some of the experts here to teach you. I'll have to train some staff on OFBiz before I sign off my current project, so your help here would be much appreciated.
Hope you enjoy OFBiz as much as I have. :)
Jonathon
Adrian Crum wrote:
> Cedric,
>
> I might be wrong, but I get the impression you are trying to approach
> OFBiz from the bottom up (examining java classes versus examining
> higher-level layers). I made that mistake when I first got involved
> with OFBiz.
>
> It would be better to look at things like the service engine, entity
> engine, screen widgets, etc. Get an idea of how the presentation layer
> works, then work your way down to the service layer, then down to the
> database schema, etc.
>
> Typically, the only reason anyone would want to get into the java
> source would be to fix a bug or make a modification at a very low
> level of the architecture "stack."
>
>
>
> PRONZATO Cedric RD-BIZZ-GRE wrote:
>
>> Re,
>>
>> Yes you are true but I think I didn't explained myself.
>> These questions may have been answered in the javadocs. I am sure you
>> know (you that architects of OFBiz) why you decided to make a
>> Container class and so on.
>> So perhaps a little enhancement of javadoc on foundation classes to
>> explain why and where to use it would be so nice.
>>
>> I hope I do not look like too much arrogant with my questions on that
>> thread "General questions"; I just expose the problems I was faced to.
>>
>> Regards,
>> Cédric
>>
>> -----Message d'origine-----
>> De : David E. Jones [mailto:jonesde@hotwaxmedia.com] Envoyé :
>> vendredi
>> 9 février 2007 18:12
>> À : user@ofbiz.apache.org
>> Objet : Re: General questions
>>
>>
>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
>>
>>
>>> A related problem is how to do "framework" components, I mean
>>> patterns. I think about my SMSC component, I base my code on the
>>> mail container and questions arised:
>>> - When do I have to make my own xml language (ie. MCA for the mail
>>> container)?
>>> - When do I have to make a Container? I guess the answer is if you
>>> have to manage the lifetime (create/release connections, ...).
>>> - When do I have to make an Engine?
>>> - ...
>>>
>>> So I guess we can finish with the following statement: "How to
>>> *use* is quite well documented but how to *make* is a bit less".
>>
>>
>> Have you ever found such a document for anything?
>>
>> My usual approach is generally something like:
>>
>> 1. understand everything that exists, or research anything that is
>> unclear 2. write something manually a number of times so you know
>> what is always the same, and what varies 3. see if a paramerized tool
>> would be helpful 4. apply a significant amount of "genius"
>> 5. apply even more "sweat" to try stuff 6. create an incredible tool
>> or service or however it is best implemented
>>
>> If there was a way to make creation deterministic, what would be the
>> point of creativity?
>>
>> -David
>>
>>
>
Re: General questions
Posted by Jonathon -- Improov <jo...@improov.com>.
Cedric,
I get the same impression as Adrian too.
Since you're from the R&D department, I suppose you're as much of a freak as I am. I took apart
OFBiz at the source code level too.
Unless you're employing some language-processing heuristics in your reverse-engineering, you'll be
spending way too much time doing brute-force studies from the bottom-up. Better to just learn from
playing with OFBiz framework (not the framework source codes), such as service engine and entity
engine, in this case.
While it is true that learning by playing with the framework will certainly be faster, I do admit
it is not as easy as many would hope. Technical references for working the OFBiz framework are not
all in one place, or even complete (mostly still in form of cookbooks at the moment). Ie, there
are no "javadocs equivalent" for the OFBiz framework, except at
http://www.undersunconsulting.com/ecommerce/control/main .
In fact, some folks here have never gotten around to using all of the OFBiz framework. Some don't
use screen/form widgets, but FTL instead. Some use Beanshell rather than Minilang.
I guess what I'm trying to say is this. Since you're from the R&D department, it would be "within
your scope" to learn the OFBiz framework in any way possible, such as from studying the source
codes or playing with the framework itself. No use complaining what isn't there; better to get
things working somehow.
For those not from the R&D department, though, then yes I do admit OFBiz doesn't have a nice
polished expensive "welcome mat/carpet" for new users.
If you do want to get help learning the OFBiz framework, you can either work with me and write
down all that I've discovered through my own reverse-engineering, or you can employ some of the
experts here to teach you. I'll have to train some staff on OFBiz before I sign off my current
project, so your help here would be much appreciated.
Hope you enjoy OFBiz as much as I have. :)
Jonathon
Adrian Crum wrote:
> Cedric,
>
> I might be wrong, but I get the impression you are trying to approach
> OFBiz from the bottom up (examining java classes versus examining
> higher-level layers). I made that mistake when I first got involved with
> OFBiz.
>
> It would be better to look at things like the service engine, entity
> engine, screen widgets, etc. Get an idea of how the presentation layer
> works, then work your way down to the service layer, then down to the
> database schema, etc.
>
> Typically, the only reason anyone would want to get into the java source
> would be to fix a bug or make a modification at a very low level of the
> architecture "stack."
>
>
>
> PRONZATO Cedric RD-BIZZ-GRE wrote:
>
>> Re,
>>
>> Yes you are true but I think I didn't explained myself.
>> These questions may have been answered in the javadocs. I am sure you
>> know (you that architects of OFBiz) why you decided to make a
>> Container class and so on.
>> So perhaps a little enhancement of javadoc on foundation classes to
>> explain why and where to use it would be so nice.
>>
>> I hope I do not look like too much arrogant with my questions on that
>> thread "General questions"; I just expose the problems I was faced to.
>>
>> Regards,
>> Cédric
>>
>> -----Message d'origine-----
>> De : David E. Jones [mailto:jonesde@hotwaxmedia.com] Envoyé : vendredi
>> 9 février 2007 18:12
>> À : user@ofbiz.apache.org
>> Objet : Re: General questions
>>
>>
>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
>>
>>
>>> A related problem is how to do "framework" components, I mean
>>> patterns. I think about my SMSC component, I base my code on the mail
>>> container and questions arised:
>>> - When do I have to make my own xml language (ie. MCA for the mail
>>> container)?
>>> - When do I have to make a Container? I guess the answer is if you
>>> have to manage the lifetime (create/release connections, ...).
>>> - When do I have to make an Engine?
>>> - ...
>>>
>>> So I guess we can finish with the following statement: "How to
>>> *use* is quite well documented but how to *make* is a bit less".
>>
>>
>> Have you ever found such a document for anything?
>>
>> My usual approach is generally something like:
>>
>> 1. understand everything that exists, or research anything that is
>> unclear 2. write something manually a number of times so you know what
>> is always the same, and what varies 3. see if a paramerized tool would
>> be helpful 4. apply a significant amount of "genius"
>> 5. apply even more "sweat" to try stuff
>> 6. create an incredible tool or service or however it is best implemented
>>
>> If there was a way to make creation deterministic, what would be the
>> point of creativity?
>>
>> -David
>>
>>
>
Re: General questions
Posted by Adrian Crum <ad...@hlmksw.com>.
Cedric,
I might be wrong, but I get the impression you are trying to approach OFBiz from
the bottom up (examining java classes versus examining higher-level layers). I
made that mistake when I first got involved with OFBiz.
It would be better to look at things like the service engine, entity engine,
screen widgets, etc. Get an idea of how the presentation layer works, then work
your way down to the service layer, then down to the database schema, etc.
Typically, the only reason anyone would want to get into the java source would
be to fix a bug or make a modification at a very low level of the architecture
"stack."
PRONZATO Cedric RD-BIZZ-GRE wrote:
> Re,
>
> Yes you are true but I think I didn't explained myself.
> These questions may have been answered in the javadocs. I am sure you know (you that architects of OFBiz) why you decided to make a Container class and so on.
> So perhaps a little enhancement of javadoc on foundation classes to explain why and where to use it would be so nice.
>
> I hope I do not look like too much arrogant with my questions on that thread "General questions"; I just expose the problems I was faced to.
>
> Regards,
> Cédric
>
> -----Message d'origine-----
> De : David E. Jones [mailto:jonesde@hotwaxmedia.com]
> Envoyé : vendredi 9 février 2007 18:12
> À : user@ofbiz.apache.org
> Objet : Re: General questions
>
>
> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
>
>
>>A related problem is how to do "framework" components, I mean
>>patterns. I think about my SMSC component, I base my code on the mail
>>container and questions arised:
>> - When do I have to make my own xml language (ie. MCA for the mail
>>container)?
>> - When do I have to make a Container? I guess the answer is if you
>>have to manage the lifetime (create/release connections, ...).
>> - When do I have to make an Engine?
>> - ...
>>
>>So I guess we can finish with the following statement: "How to
>>*use* is quite well documented but how to *make* is a bit less".
>
>
> Have you ever found such a document for anything?
>
> My usual approach is generally something like:
>
> 1. understand everything that exists, or research anything that is unclear 2. write something manually a number of times so you know what is always the same, and what varies 3. see if a paramerized tool would be helpful 4. apply a significant amount of "genius"
> 5. apply even more "sweat" to try stuff
> 6. create an incredible tool or service or however it is best implemented
>
> If there was a way to make creation deterministic, what would be the point of creativity?
>
> -David
>
>
RE: General questions
Posted by PRONZATO Cedric RD-BIZZ-GRE <ce...@orange-ftgroup.com>.
Re,
Yes you are true but I think I didn't explained myself.
These questions may have been answered in the javadocs. I am sure you know (you that architects of OFBiz) why you decided to make a Container class and so on.
So perhaps a little enhancement of javadoc on foundation classes to explain why and where to use it would be so nice.
I hope I do not look like too much arrogant with my questions on that thread "General questions"; I just expose the problems I was faced to.
Regards,
Cédric
-----Message d'origine-----
De : David E. Jones [mailto:jonesde@hotwaxmedia.com]
Envoyé : vendredi 9 février 2007 18:12
À : user@ofbiz.apache.org
Objet : Re: General questions
On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
> A related problem is how to do "framework" components, I mean
> patterns. I think about my SMSC component, I base my code on the mail
> container and questions arised:
> - When do I have to make my own xml language (ie. MCA for the mail
> container)?
> - When do I have to make a Container? I guess the answer is if you
> have to manage the lifetime (create/release connections, ...).
> - When do I have to make an Engine?
> - ...
>
> So I guess we can finish with the following statement: "How to
> *use* is quite well documented but how to *make* is a bit less".
Have you ever found such a document for anything?
My usual approach is generally something like:
1. understand everything that exists, or research anything that is unclear 2. write something manually a number of times so you know what is always the same, and what varies 3. see if a paramerized tool would be helpful 4. apply a significant amount of "genius"
5. apply even more "sweat" to try stuff
6. create an incredible tool or service or however it is best implemented
If there was a way to make creation deterministic, what would be the point of creativity?
-David
Re: General questions
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote:
> A related problem is how to do "framework" components, I mean
> patterns. I think about my SMSC component, I base my code on the
> mail container and questions arised:
> - When do I have to make my own xml language (ie. MCA for the mail
> container)?
> - When do I have to make a Container? I guess the answer is if you
> have to manage the lifetime (create/release connections, ...).
> - When do I have to make an Engine?
> - ...
>
> So I guess we can finish with the following statement: "How to
> *use* is quite well documented but how to *make* is a bit less".
Have you ever found such a document for anything?
My usual approach is generally something like:
1. understand everything that exists, or research anything that is
unclear
2. write something manually a number of times so you know what is
always the same, and what varies
3. see if a paramerized tool would be helpful
4. apply a significant amount of "genius"
5. apply even more "sweat" to try stuff
6. create an incredible tool or service or however it is best
implemented
If there was a way to make creation deterministic, what would be the
point of creativity?
-David
RE: General questions
Posted by PRONZATO Cedric RD-BIZZ-GRE <ce...@orange-ftgroup.com>.
Re,
Okay, it is what I thought to do but now it is explicited. But is that working for all cases?
About the subverion, yes your files will not be impacted we doing updates but isn't it what we want? We want to know what gets modified, why, by who ... And with your solution it is hard and I guess bug prone.
A related problem is how to do "framework" components, I mean patterns. I think about my SMSC component, I base my code on the mail container and questions arised:
- When do I have to make my own xml language (ie. MCA for the mail container)?
- When do I have to make a Container? I guess the answer is if you have to manage the lifetime (create/release connections, ...).
- When do I have to make an Engine?
- ...
So I guess we can finish with the following statement: "How to *use* is quite well documented but how to *make* is a bit less".
PS: just for the background, my aim is not to use OFBiz in production. My aim is to use it as the ultimate *framework* that will help me to develop/show new functionalites/ideas. I am working in a R&D division, so perhaps my questions sounds a bit strange for some of you.
Thx,
Regards,
Cédric
-----Message d'origine-----
De : Chris Howe [mailto:cjhowe76013@yahoo.com]
Envoyé : vendredi 9 février 2007 14:17
À : user@ofbiz.apache.org
Objet : RE: General questions
comments inline.
--- PRONZATO Cedric RD-BIZZ-GRE <ce...@orange-ftgroup.com>
wrote:
> Hi Chris,
>
> Indeed it was for customizations, and yes I saw that modifying the
> existing source code is not the best. But even that, isn't that bad to
> have this component view into eclipse either? I don't know if a bench
> exists somewhere to tell us if it has a performance sense to only open
> the subsprojects you really need.
>
> Customization question is the second question any OFBiz user is faced.
> I still not have answered to it because yet I didn't make any
> component for OFBiz.
> I am not sure to have see a topic on that in the wiki, if you (gods)
no gods, we the people :-)
> have the time to make to us (beginners) a little section about that.
> - What is the strategy to use to extend functionalities of a
> component?
http://ofbizwiki.go-integral.com/Wiki.jsp?page=FAQ21
> - What is the strategy to use to only change the presentation of a
> component?
same. or if your change is only to the css, it's not that big of a headache to only change the maincss.css or ecommain.css
> - What is the strategy to use to change the implementation of a
> component?
same.
> - ...
> - What is the strategy to use to make a new component (this one is the
> only one I can answer and being sure: hotdeploy folder)
>
same.
> These questions are perhaps not the best, it is just a try to explain
> to you.
>
> Beside that I am also still not sure about the subversion strategy to
> use to handle my customizations. I am aware software vendor branches
> (also explain in the wiki) but till I did not try it for real I will
> not be sure because it seems to be painful.
If you follow that FAQ, you won't be touching OFBiz code so Subversion won't affect your customizations. You will need to take notice though if the functionality change in SVN changes the functionality of your customizations because your customizations are relying on the underlying OFBiz code. Following this strategy and reading over the documentation that exists for the widgets and simple-methods will be the quickest way to move down the learning curve. Caveat being that you're not creating whole new functionalities.
>
> Thx,
> Cédric
>
> -----Message d'origine-----
> De : Chris Howe [mailto:cjhowe76013@yahoo.com] Envoyé : vendredi 9
> février 2007 12:04 À : user@ofbiz.apache.org; Jacques Le Roux Objet :
> Re: General questions
>
> I'm shocked Jacques, this is a perfect opportunity to plug Mylar :-)
>
> --- Jacques Le Roux <ja...@les7arts.com> wrote in reply to
> Cédric:
> > >Secondly we can only open the sub projects we really need for the
> > task we want to do.
> > Not sure this makes really sense as there is some interdependance
> > between components
> >
>
> You should really checkout the Mylar http://www.eclipse.org/mylar/
> plugin for eclipse. It will really help you to be task focused given
> the interdependence that exists. Especially the interdependence you
> will be creating with your custom applications.
>
> Cédric,
> I hope I am wrong on this, but your question regarding the eclipse
> layout suggests to me you might be customizing OFBiz by editing OFBiz
> components themselves (ie making changes in the
> applications/ecommerce/... folder directly) instead of extending OFBiz
> with your own custom components (ie hotdeploy/myapp/...). This can
> get you in a big mess when you go to update OFBiz. If you could
> confirm how you are customizing, the community and I may be able to
> help you get things reorganized and save your "such is life" headache
> from occurring again.
>
RE: General questions
Posted by Chris Howe <cj...@yahoo.com>.
comments inline.
--- PRONZATO Cedric RD-BIZZ-GRE <ce...@orange-ftgroup.com>
wrote:
> Hi Chris,
>
> Indeed it was for customizations, and yes I saw that modifying the
> existing source code is not the best. But even that, isn't that bad
> to have this component view into eclipse either? I don't know if a
> bench exists somewhere to tell us if it has a performance sense to
> only open the subsprojects you really need.
>
> Customization question is the second question any OFBiz user is
> faced. I still not have answered to it because yet I didn't make any
> component for OFBiz.
> I am not sure to have see a topic on that in the wiki, if you (gods)
no gods, we the people :-)
> have the time to make to us (beginners) a little section about that.
> - What is the strategy to use to extend functionalities of a
> component?
http://ofbizwiki.go-integral.com/Wiki.jsp?page=FAQ21
> - What is the strategy to use to only change the presentation of a
> component?
same. or if your change is only to the css, it's not that big of a
headache to only change the maincss.css or ecommain.css
> - What is the strategy to use to change the implementation of a
> component?
same.
> - ...
> - What is the strategy to use to make a new component (this one is
> the only one I can answer and being sure: hotdeploy folder)
>
same.
> These questions are perhaps not the best, it is just a try to explain
> to you.
>
> Beside that I am also still not sure about the subversion strategy to
> use to handle my customizations. I am aware software vendor branches
> (also explain in the wiki) but till I did not try it for real I will
> not be sure because it seems to be painful.
If you follow that FAQ, you won't be touching OFBiz code so Subversion
won't affect your customizations. You will need to take notice though
if the functionality change in SVN changes the functionality of your
customizations because your customizations are relying on the
underlying OFBiz code. Following this strategy and reading over the
documentation that exists for the widgets and simple-methods will be
the quickest way to move down the learning curve. Caveat being that
you're not creating whole new functionalities.
>
> Thx,
> Cédric
>
> -----Message d'origine-----
> De : Chris Howe [mailto:cjhowe76013@yahoo.com]
> Envoyé : vendredi 9 février 2007 12:04
> À : user@ofbiz.apache.org; Jacques Le Roux
> Objet : Re: General questions
>
> I'm shocked Jacques, this is a perfect opportunity to plug Mylar :-)
>
> --- Jacques Le Roux <ja...@les7arts.com> wrote in reply to
> Cédric:
> > >Secondly we can only open the sub projects we really need for the
> > task we want to do.
> > Not sure this makes really sense as there is some interdependance
> > between components
> >
>
> You should really checkout the Mylar http://www.eclipse.org/mylar/
> plugin for eclipse. It will really help you to be task focused given
> the interdependence that exists. Especially the interdependence you
> will be creating with your custom applications.
>
> Cédric,
> I hope I am wrong on this, but your question regarding the eclipse
> layout suggests to me you might be customizing OFBiz by editing OFBiz
> components themselves (ie making changes in the
> applications/ecommerce/... folder directly) instead of extending
> OFBiz with your own custom components (ie hotdeploy/myapp/...). This
> can get you in a big mess when you go to update OFBiz. If you could
> confirm how you are customizing, the community and I may be able to
> help you get things reorganized and save your "such is life" headache
> from occurring again.
>
RE: General questions
Posted by PRONZATO Cedric RD-BIZZ-GRE <ce...@orange-ftgroup.com>.
Hi Chris,
Indeed it was for customizations, and yes I saw that modifying the existing source code is not the best. But even that, isn't that bad to have this component view into eclipse either? I don't know if a bench exists somewhere to tell us if it has a performance sense to only open the subsprojects you really need.
Customization question is the second question any OFBiz user is faced. I still not have answered to it because yet I didn't make any component for OFBiz.
I am not sure to have see a topic on that in the wiki, if you (gods) have the time to make to us (beginners) a little section about that.
- What is the strategy to use to extend functionalities of a component?
- What is the strategy to use to only change the presentation of a component?
- What is the strategy to use to change the implementation of a component?
- ...
- What is the strategy to use to make a new component (this one is the only one I can answer and being sure: hotdeploy folder)
These questions are perhaps not the best, it is just a try to explain to you.
Beside that I am also still not sure about the subversion strategy to use to handle my customizations. I am aware software vendor branches (also explain in the wiki) but till I did not try it for real I will not be sure because it seems to be painful.
Thx,
Cédric
-----Message d'origine-----
De : Chris Howe [mailto:cjhowe76013@yahoo.com]
Envoyé : vendredi 9 février 2007 12:04
À : user@ofbiz.apache.org; Jacques Le Roux
Objet : Re: General questions
I'm shocked Jacques, this is a perfect opportunity to plug Mylar :-)
--- Jacques Le Roux <ja...@les7arts.com> wrote in reply to
Cédric:
> >Secondly we can only open the sub projects we really need for the
> task we want to do.
> Not sure this makes really sense as there is some interdependance
> between components
>
You should really checkout the Mylar http://www.eclipse.org/mylar/ plugin for eclipse. It will really help you to be task focused given the interdependence that exists. Especially the interdependence you will be creating with your custom applications.
Cédric,
I hope I am wrong on this, but your question regarding the eclipse layout suggests to me you might be customizing OFBiz by editing OFBiz components themselves (ie making changes in the applications/ecommerce/... folder directly) instead of extending OFBiz with your own custom components (ie hotdeploy/myapp/...). This can get you in a big mess when you go to update OFBiz. If you could confirm how you are customizing, the community and I may be able to help you get things reorganized and save your "such is life" headache from occurring again.
Re: General questions
Posted by Chris Howe <cj...@yahoo.com>.
I'm shocked Jacques, this is a perfect opportunity to plug Mylar :-)
--- Jacques Le Roux <ja...@les7arts.com> wrote in reply to
Cédric:
> >Secondly we can only open the sub projects we really need for the
> task we want to do.
> Not sure this makes really sense as there is some interdependance
> between components
>
You should really checkout the Mylar http://www.eclipse.org/mylar/
plugin for eclipse. It will really help you to be task focused given
the interdependence that exists. Especially the interdependence you
will be creating with your custom applications.
Cédric,
I hope I am wrong on this, but your question regarding the eclipse
layout suggests to me you might be customizing OFBiz by editing OFBiz
components themselves (ie making changes in the
applications/ecommerce/... folder directly) instead of extending OFBiz
with your own custom components (ie hotdeploy/myapp/...). This can get
you in a big mess when you go to update OFBiz. If you could confirm
how you are customizing, the community and I may be able to help you
get things reorganized and save your "such is life" headache from
occurring again.
Re: General questions
Posted by Jacques Le Roux <ja...@les7arts.com>.
Cedric,
Only responses to 2 and 3
>2 - I also think we could enhance the project building and perhaps the "project development speed" by using a better eclipse
"layout". I am not an expert but I don't think have a so big project which is modularized in a single eclipse project.
>Firstly have a subproject for each module will allow using eclipse compiler instead of using ant after editing files.
Why not running only the component build.xml thru ant in Eclipse (Contextual menu Run As/Ant Build) ?
>Secondly we can only open the sub projects we really need for the task we want to do.
Not sure this makes really sense as there is some interdependance between components
>3 - I wanted to make a SMS demonstration application (sending and receiving), I based my code on the mail container because I feel
they are same on much points. But I lack of knowledge about the design/pattern I must use to do it properly into the OFBiz
architecture. As I am sure I am not alone on the question "how about to make a properly designed OFBiz application", there are
perhaps some docs to do about that.
Did you read the Data Model Ressource Book (at least Vol. 1) recommended in http://ofbiz.apache.org/documents.html ?
Jacques