Over the last few weeks we have become interested in the idea proposed in
the forum about end user documentation and a wiki for that. Has that idea moved forward in recent weeks? Who would we talk to now about volunteering to contribute to this proposed effort? I think that the open source offering of OFBiz and opentaps would find more interest among users at the small business end, if the true end user documentation were advanced some more, and if there were an available knowledge base (wiki) for application end user questions. For smaller businesses, that resource needs to be supplied to them. Claude Feistel, President IntegraSphere Inc. Austin, TX 1-512-250-1710 www.integrasphere.com |
Claude, What sort of effort did you have in mind to contribute? If you'd like to help with the content migration from the Undersun doc site to the new docs.ofbiz.org site I'd be happy to help you get started on that. Whoever is working on it would need an account on the Undersun doc server. On docs.ofbiz.org new people can add things in the public wiki space (ID is OFBIZ), and then someone with permissions for the end-user doc space can review them and move them over to that final resting place. Once someone has demonstrated competence and some level of dedication in this area we'll be happy to give them write permissions for the end-user space (ID is OFBENDUSER). When beginning work on a certain area you should add a comment to this page in the end-user doc space: http://docs.ofbiz.org/display/OFBENDUSER/Areas+Being+Worked+On -David Claude Feistel wrote: > Over the last few weeks we have become interested in the idea proposed in > the forum about end user documentation and a wiki for that. Has that idea > moved forward in recent weeks? > > > > Who would we talk to now about volunteering to contribute to this proposed > effort? > > > > I think that the open source offering of OFBiz and opentaps would find more > interest among users at the small business end, if the true end user > documentation were advanced some more, and if there were an available > knowledge base (wiki) for application end user questions. For smaller > businesses, that resource needs to be supplied to them. > > > > Claude Feistel, President > > IntegraSphere Inc. > > Austin, TX > > 1-512-250-1710 > > www.integrasphere.com > > > > smime.p7s (4K) Download Attachment |
Yes, David, that way of getting started would be good. We also have some
areas of special interest where we might want to contribute additional material. Right now that includes discrete manufacturing business activity. Claude -----Original Message----- From: David E. Jones [mailto:[hidden email]] Sent: Monday, July 10, 2006 2:16 PM To: [hidden email] Subject: Re: Volunteer: OFBiz End User Documentation Claude, What sort of effort did you have in mind to contribute? If you'd like to help with the content migration from the Undersun doc site to the new docs.ofbiz.org site I'd be happy to help you get started on that. Whoever is working on it would need an account on the Undersun doc server. On docs.ofbiz.org new people can add things in the public wiki space (ID is OFBIZ), and then someone with permissions for the end-user doc space can review them and move them over to that final resting place. Once someone has demonstrated competence and some level of dedication in this area we'll be happy to give them write permissions for the end-user space (ID is OFBENDUSER). When beginning work on a certain area you should add a comment to this page in the end-user doc space: http://docs.ofbiz.org/display/OFBENDUSER/Areas+Being+Worked+On -David Claude Feistel wrote: > Over the last few weeks we have become interested in the idea proposed in > the forum about end user documentation and a wiki for that. Has that idea > moved forward in recent weeks? > > > > Who would we talk to now about volunteering to contribute to this proposed > effort? > > > > I think that the open source offering of OFBiz and opentaps would find > interest among users at the small business end, if the true end user > documentation were advanced some more, and if there were an available > knowledge base (wiki) for application end user questions. For smaller > businesses, that resource needs to be supplied to them. > > > > Claude Feistel, President > > IntegraSphere Inc. > > Austin, TX > > 1-512-250-1710 > > www.integrasphere.com > > > > |
Have you seen the existing documentation on manufacturing?
Si On Jul 10, 2006, at 4:47 PM, Claude Feistel wrote: > Yes, David, that way of getting started would be good. We also > have some > areas of special interest where we might want to contribute additional > material. Right now that includes discrete manufacturing business > activity. > > Claude > -----Original Message----- > From: David E. Jones [mailto:[hidden email]] > Sent: Monday, July 10, 2006 2:16 PM > To: [hidden email] > Subject: Re: Volunteer: OFBiz End User Documentation > > > Claude, > > What sort of effort did you have in mind to contribute? > > If you'd like to help with the content migration from the Undersun > doc site > to the new docs.ofbiz.org site I'd be happy to help you get started > on that. > Whoever is working on it would need an account on the Undersun doc > server. > > On docs.ofbiz.org new people can add things in the public wiki > space (ID is > OFBIZ), and then someone with permissions for the end-user doc > space can > review them and move them over to that final resting place. Once > someone has > demonstrated competence and some level of dedication in this area > we'll be > happy to give them write permissions for the end-user space (ID is > OFBENDUSER). > > When beginning work on a certain area you should add a comment to > this page > in the end-user doc space: > > http://docs.ofbiz.org/display/OFBENDUSER/Areas+Being+Worked+On > > -David > > > > Claude Feistel wrote: >> Over the last few weeks we have become interested in the idea >> proposed in >> the forum about end user documentation and a wiki for that. Has >> that > idea >> moved forward in recent weeks? >> >> >> >> Who would we talk to now about volunteering to contribute to this >> proposed >> effort? >> >> >> >> I think that the open source offering of OFBiz and opentaps would >> find > more >> interest among users at the small business end, if the true end user >> documentation were advanced some more, and if there were an available >> knowledge base (wiki) for application end user questions. For >> smaller >> businesses, that resource needs to be supplied to them. >> >> >> >> Claude Feistel, President >> >> IntegraSphere Inc. >> >> Austin, TX >> >> 1-512-250-1710 >> >> www.integrasphere.com >> >> >> >> > |
In reply to this post by Claude Feistel
Claude, That sounds fine. When you're ready to get started on this, create an account on the Undersun site (through the store or whatever), and then send the account details along with what sort of involvement you have in mind (short term, long term, moving content, editing, writing, formatting, whatever). -David Claude Feistel wrote: > Yes, David, that way of getting started would be good. We also have some > areas of special interest where we might want to contribute additional > material. Right now that includes discrete manufacturing business activity. > > Claude > -----Original Message----- > From: David E. Jones [mailto:[hidden email]] > Sent: Monday, July 10, 2006 2:16 PM > To: [hidden email] > Subject: Re: Volunteer: OFBiz End User Documentation > > > Claude, > > What sort of effort did you have in mind to contribute? > > If you'd like to help with the content migration from the Undersun doc site > to the new docs.ofbiz.org site I'd be happy to help you get started on that. > Whoever is working on it would need an account on the Undersun doc server. > > On docs.ofbiz.org new people can add things in the public wiki space (ID is > OFBIZ), and then someone with permissions for the end-user doc space can > review them and move them over to that final resting place. Once someone has > demonstrated competence and some level of dedication in this area we'll be > happy to give them write permissions for the end-user space (ID is > OFBENDUSER). > > When beginning work on a certain area you should add a comment to this page > in the end-user doc space: > > http://docs.ofbiz.org/display/OFBENDUSER/Areas+Being+Worked+On > > -David > > > > Claude Feistel wrote: >> Over the last few weeks we have become interested in the idea proposed in >> the forum about end user documentation and a wiki for that. Has that > idea >> moved forward in recent weeks? >> >> >> >> Who would we talk to now about volunteering to contribute to this proposed >> effort? >> >> >> >> I think that the open source offering of OFBiz and opentaps would find > more >> interest among users at the small business end, if the true end user >> documentation were advanced some more, and if there were an available >> knowledge base (wiki) for application end user questions. For smaller >> businesses, that resource needs to be supplied to them. >> >> >> >> Claude Feistel, President >> >> IntegraSphere Inc. >> >> Austin, TX >> >> 1-512-250-1710 >> >> www.integrasphere.com >> >> >> >> > > smime.p7s (4K) Download Attachment |
In reply to this post by Si Chen-2
Yes, I think I have that material from the documentation section of the
current site. Thanks, Si. Claude Feistel -----Original Message----- From: Si Chen [mailto:[hidden email]] Sent: Monday, July 10, 2006 7:03 PM To: [hidden email] Subject: Re: Volunteer: OFBiz End User Documentation Have you seen the existing documentation on manufacturing? Si On Jul 10, 2006, at 4:47 PM, Claude Feistel wrote: > Yes, David, that way of getting started would be good. We also > have some > areas of special interest where we might want to contribute additional > material. Right now that includes discrete manufacturing business > activity. > > Claude > -----Original Message----- > From: David E. Jones [mailto:[hidden email]] > Sent: Monday, July 10, 2006 2:16 PM > To: [hidden email] > Subject: Re: Volunteer: OFBiz End User Documentation > > > Claude, > > What sort of effort did you have in mind to contribute? > > If you'd like to help with the content migration from the Undersun > doc site > to the new docs.ofbiz.org site I'd be happy to help you get started > on that. > Whoever is working on it would need an account on the Undersun doc > server. > > On docs.ofbiz.org new people can add things in the public wiki > space (ID is > OFBIZ), and then someone with permissions for the end-user doc > space can > review them and move them over to that final resting place. Once > someone has > demonstrated competence and some level of dedication in this area > we'll be > happy to give them write permissions for the end-user space (ID is > OFBENDUSER). > > When beginning work on a certain area you should add a comment to > this page > in the end-user doc space: > > http://docs.ofbiz.org/display/OFBENDUSER/Areas+Being+Worked+On > > -David > > > > Claude Feistel wrote: >> Over the last few weeks we have become interested in the idea >> proposed in >> the forum about end user documentation and a wiki for that. Has >> that > idea >> moved forward in recent weeks? >> >> >> >> Who would we talk to now about volunteering to contribute to this >> proposed >> effort? >> >> >> >> I think that the open source offering of OFBiz and opentaps would >> find > more >> interest among users at the small business end, if the true end user >> documentation were advanced some more, and if there were an available >> knowledge base (wiki) for application end user questions. For >> smaller >> businesses, that resource needs to be supplied to them. >> >> >> >> Claude Feistel, President >> >> IntegraSphere Inc. >> >> Austin, TX >> >> 1-512-250-1710 >> >> www.integrasphere.com >> >> >> >> > |
Hi everyone
I've been tagging along an idea of documenting algorythms of ofbiz processes. Since I started working with ofbiz, as always I found myself having to dig into existing code I found that the clearest way to understand how modules work is to rebuild the algorithm behind a process . A process could be a complete run through from url to controller to to Service , run through the Service to result , to Screen ...etc. by writting down the main elements of a process this draws quite a clear map of the algorithm behind the process, and especially is easily transmitable and readable by others. This also keeps from having to run through all code , all processes which would be the next step after reading the algo. WDYT ? I think it would be enourmously enrichining for people like myself wanting to understand quickly what does what, and what is done behind the scenes. Sometimes these algos quite large for processes like the chekout process here's a sample I gathered up for the tellafriend process: I list Service , Maps, redirections... a std format needs to be set up Form : tellafriend input : message, sendTo, sendFrom >>>> controller event : org.ofbiz.product.product.ProductEvents" invoke="tellAFriend" >>> dans le service tellafriend [GenericEntity:ProductStoreEmailSetting] [bccAddress,null()][bodyScreenLocation,null()][ccAddress,null()][contentType,null()][createdStamp,2006-04-21 15:06:47.428(java.sql.Timestamp)] [createdTxStamp,2006-04-21 15:06:46.848(java.sql.Timestamp )][emailType,PRDS_TELL_FRIEND(java.lang.String)] [fromAddress,[hidden email](java.lang.String)][lastUpdatedStamp,2006-04-21 15:06:47.428(java.sql.Timestamp)] [lastUpdatedTxStamp,2006-04-21 15:06:46.848(java.sql.Timestamp )][productStoreId,910(java.lang.String)] [subject,${sendFrom} has sent you a link!(java.lang.String)] [templatePath,/applications/petitbateau/templates/email/tellafriend.ftl( java.lang.String)][xslfoAttachScreenLocation,null()] { templateData= [ sendFrom=[hidden email], message=qgfgsdf gsdf gsdf gsdfg sdf, sendTo=[hidden email], pageUrl=http://localhost/petitbateau/control/product?product_id=94451 ], sendTo=[hidden email], templateName=X:/X_Dev/sequoiaerp/applications/petitbateau/templates/email/tellafriend.ftl, sendCc=null, sendBcc=null, subject=[hidden email] has sent you a link!, sendFrom=[hidden email], contentType=null} >>>>dispatcher.runAsync("sendGenericNotificationEmail", context); >>>>org.ofbiz.content.email.NotificationServices" invoke="sendNotification(DispatchContext ctx, Map context) >>>>method prepareNotification(ctx, context); //builds the body of the mail by rendering the corresponding ftl >>>>if body != null >>>>dispatcher.runSync("sendMail", emailContext); org.ofbiz.content.email.EmailServices" invoke="sendMail" Regards Tibor |
I think that the easiest way to accomplish this is
through the logs. Documenting these processes for reference would be too burdonsome and maintenance would be quite tedious. --- tibor katelbach <[hidden email]> wrote: > Hi everyone > I've been tagging along an idea of documenting > algorythms of ofbiz > processes. > > Since I started working with ofbiz, as always I > found myself having to dig > into existing code > I found that the clearest way to understand how > modules work is to rebuild > the algorithm behind a process . > A process could be a complete run through from url > to controller to to > Service , run through the Service to result , to > Screen ...etc. > > by writting down the main elements of a process this > draws quite a clear map > of the algorithm behind the process, and especially > is easily transmitable and readable by others. This > also keeps from having > to run through all code , all processes which would > be the next step after > reading the algo. > > WDYT ? > > I think it would be enourmously enrichining for > people like myself wanting > to understand quickly what does what, and what is > done behind the scenes. > > Sometimes these algos quite large for processes like > the chekout process > here's a sample I gathered up for the tellafriend > process: > I list Service , Maps, redirections... a std format > needs to be set up > > Form : tellafriend > input : message, sendTo, sendFrom > > >>>> controller event : > org.ofbiz.product.product.ProductEvents" > invoke="tellAFriend" > > >>> dans le service tellafriend > > [GenericEntity:ProductStoreEmailSetting] > > 15:06:47.428(java.sql.Timestamp)] > [createdTxStamp,2006-04-21 > 15:06:46.848(java.sql.Timestamp > )][emailType,PRDS_TELL_FRIEND(java.lang.String)] > [fromAddress,[hidden email](java.lang.String)][lastUpdatedStamp,2006-04-21 > 15:06:47.428(java.sql.Timestamp)] > [lastUpdatedTxStamp,2006-04-21 > 15:06:46.848(java.sql.Timestamp > )][productStoreId,910(java.lang.String)] > [subject,${sendFrom} has sent you a > link!(java.lang.String)] > [templatePath,/applications/petitbateau/templates/email/tellafriend.ftl( > java.lang.String)][xslfoAttachScreenLocation,null()] > > { > templateData= > [ > sendFrom=[hidden email], > message=qgfgsdf gsdf gsdf gsdfg sdf, > sendTo=[hidden email], > pageUrl=http://localhost/petitbateau/control/product?product_id=94451 > ], > > sendTo=[hidden email], > templateName=X:/X_Dev/sequoiaerp/applications/petitbateau/templates/email/tellafriend.ftl, > > sendCc=null, > sendBcc=null, > subject=[hidden email] has sent you a link!, > sendFrom=[hidden email], > contentType=null} > > >>>>dispatcher.runAsync("sendGenericNotificationEmail", > context); > >>>>org.ofbiz.content.email.NotificationServices" > invoke="sendNotification(DispatchContext ctx, Map > context) > >>>>method prepareNotification(ctx, context); > //builds the body of the > mail by rendering the corresponding ftl > >>>>if body != null > >>>>dispatcher.runSync("sendMail", emailContext); > org.ofbiz.content.email.EmailServices" > invoke="sendMail" > > > > Regards > Tibor > |
I agree, that is the pb with such docs, they are heavy to write, because the
task is huge. But once it is done the main part is done, offcourse maintenance is heavy but it could also be a new way of spotting precisly what is new between versions and more readiable than a SVN upgrade. we all took the effort of understanding processes and this would be a way to share it. logs are shared but not exhaustive even the Verbose. I did it for quite a few processes and when I communicate these docs to other people needing a the same process, all they do is read it out. if what they need is in there , then they dig in. I often lost time by reading through loads of code and my answer was just waiting at the end, this way you go directly to the interesting section. offcourse this gets really interesting only if we all participate. just trying to help newcomers On 7/11/06, Chris Howe <[hidden email]> wrote: > > I think that the easiest way to accomplish this is > through the logs. Documenting these processes for > reference would be too burdonsome and maintenance > would be quite tedious. > > --- tibor katelbach <[hidden email]> wrote: > > > Hi everyone > > I've been tagging along an idea of documenting > > algorythms of ofbiz > > processes. > > > > Since I started working with ofbiz, as always I > > found myself having to dig > > into existing code > > I found that the clearest way to understand how > > modules work is to rebuild > > the algorithm behind a process . > > A process could be a complete run through from url > > to controller to to > > Service , run through the Service to result , to > > Screen ...etc. > > > > by writting down the main elements of a process this > > draws quite a clear map > > of the algorithm behind the process, and especially > > is easily transmitable and readable by others. This > > also keeps from having > > to run through all code , all processes which would > > be the next step after > > reading the algo. > > > > WDYT ? > > > > I think it would be enourmously enrichining for > > people like myself wanting > > to understand quickly what does what, and what is > > done behind the scenes. > > > > Sometimes these algos quite large for processes like > > the chekout process > > here's a sample I gathered up for the tellafriend > > process: > > I list Service , Maps, redirections... a std format > > needs to be set up > > > > Form : tellafriend > > input : message, sendTo, sendFrom > > > > >>>> controller event : > > org.ofbiz.product.product.ProductEvents" > > invoke="tellAFriend" > > > > >>> dans le service tellafriend > > > > [GenericEntity:ProductStoreEmailSetting] > > > > [bccAddress,null()][bodyScreenLocation,null()][ccAddress,null()][contentType,null()][createdStamp,2006-04-21 > > 15:06:47.428(java.sql.Timestamp)] > > [createdTxStamp,2006-04-21 > > 15:06:46.848(java.sql.Timestamp > > )][emailType,PRDS_TELL_FRIEND(java.lang.String)] > > > [fromAddress,[hidden email](java.lang.String > )][lastUpdatedStamp,2006-04-21 > > 15:06:47.428(java.sql.Timestamp)] > > [lastUpdatedTxStamp,2006-04-21 > > 15:06:46.848(java.sql.Timestamp > > )][productStoreId,910(java.lang.String)] > > [subject,${sendFrom} has sent you a > > link!(java.lang.String)] > > > [templatePath,/applications/petitbateau/templates/email/tellafriend.ftl( > > java.lang.String)][xslfoAttachScreenLocation,null()] > > > > { > > templateData= > > [ > > sendFrom=[hidden email], > > message=qgfgsdf gsdf gsdf gsdfg sdf, > > sendTo=[hidden email], > > > pageUrl=http://localhost/petitbateau/control/product?product_id=94451 > > ], > > > > sendTo=[hidden email], > > > > templateName=X:/X_Dev/sequoiaerp/applications/petitbateau/templates/email/tellafriend.ftl, > > > > sendCc=null, > > sendBcc=null, > > subject=[hidden email] has sent you a link!, > > sendFrom=[hidden email], > > contentType=null} > > > > > >>>>dispatcher.runAsync("sendGenericNotificationEmail", > > context); > > >>>>org.ofbiz.content.email.NotificationServices" > > invoke="sendNotification(DispatchContext ctx, Map > > context) > > >>>>method prepareNotification(ctx, context); > > //builds the body of the > > mail by rendering the corresponding ftl > > >>>>if body != null > > >>>>dispatcher.runSync("sendMail", emailContext); > > org.ofbiz.content.email.EmailServices" > > invoke="sendMail" > > > > > > > > Regards > > Tibor > > > > |
You'd be better off for being more encompassing by
going through the java files and putting in log.ObscenelyVerbose() after every java and simple method begins, right before each if statement, n+1 after each while statement, and right before the return of a java and simple method. Of course then, you'll get a million more timeout errors ;). --- tibor katelbach <[hidden email]> wrote: > I agree, that is the pb with such docs, they are > heavy to write, because the > task is huge. But once it is done the main part is > done, offcourse > maintenance is heavy but it could also be a new way > of spotting precisly > what is new between versions and more readiable than > a SVN upgrade. > > we all took the effort of understanding processes > and this would be a way to > share it. logs are shared but not exhaustive even > the Verbose. > > I did it for quite a few processes and when I > communicate these docs to > other people needing a the same process, all they do > is read it out. > if what they need is in there , then they dig in. > I often lost time by reading through loads of code > and my answer was just > waiting at the end, > this way you go directly to the interesting section. > > offcourse this gets really interesting only if we > all participate. > > just trying to help newcomers > > > On 7/11/06, Chris Howe <[hidden email]> > wrote: > > > > I think that the easiest way to accomplish this is > > through the logs. Documenting these processes for > > reference would be too burdonsome and maintenance > > would be quite tedious. > > > > --- tibor katelbach <[hidden email]> wrote: > > > > > Hi everyone > > > I've been tagging along an idea of documenting > > > algorythms of ofbiz > > > processes. > > > > > > Since I started working with ofbiz, as always I > > > found myself having to dig > > > into existing code > > > I found that the clearest way to understand how > > > modules work is to rebuild > > > the algorithm behind a process . > > > A process could be a complete run through from > url > > > to controller to to > > > Service , run through the Service to result , to > > > Screen ...etc. > > > > > > by writting down the main elements of a process > this > > > draws quite a clear map > > > of the algorithm behind the process, and > especially > > > is easily transmitable and readable by others. > This > > > also keeps from having > > > to run through all code , all processes which > would > > > be the next step after > > > reading the algo. > > > > > > WDYT ? > > > > > > I think it would be enourmously enrichining for > > > people like myself wanting > > > to understand quickly what does what, and what > is > > > done behind the scenes. > > > > > > Sometimes these algos quite large for processes > like > > > the chekout process > > > here's a sample I gathered up for the > tellafriend > > > process: > > > I list Service , Maps, redirections... a std > format > > > needs to be set up > > > > > > Form : tellafriend > > > input : message, sendTo, sendFrom > > > > > > >>>> controller event : > > > org.ofbiz.product.product.ProductEvents" > > > invoke="tellAFriend" > > > > > > >>> dans le service tellafriend > > > > > > [GenericEntity:ProductStoreEmailSetting] > > > > > > > > > > > 15:06:47.428(java.sql.Timestamp)] > > > [createdTxStamp,2006-04-21 > > > 15:06:46.848(java.sql.Timestamp > > > )][emailType,PRDS_TELL_FRIEND(java.lang.String)] > > > > > > [fromAddress,[hidden email](java.lang.String > > )][lastUpdatedStamp,2006-04-21 > > > 15:06:47.428(java.sql.Timestamp)] > > > [lastUpdatedTxStamp,2006-04-21 > > > 15:06:46.848(java.sql.Timestamp > > > )][productStoreId,910(java.lang.String)] > > > [subject,${sendFrom} has sent you a > > > link!(java.lang.String)] > > > > > > > > > > java.lang.String)][xslfoAttachScreenLocation,null()] > > > > > > { > > > templateData= > > > [ > > > sendFrom=[hidden email], > > > message=qgfgsdf gsdf gsdf gsdfg sdf, > > > sendTo=[hidden email], > > > > > > > > > ], > > > > > > sendTo=[hidden email], > > > > > > > > templateName=X:/X_Dev/sequoiaerp/applications/petitbateau/templates/email/tellafriend.ftl, > > > > > > sendCc=null, > > > sendBcc=null, > > > subject=[hidden email] has sent you a link!, > > > sendFrom=[hidden email], > > > contentType=null} > > > > > > > > > >>>>dispatcher.runAsync("sendGenericNotificationEmail", > > > context); > > > > >>>>org.ofbiz.content.email.NotificationServices" > > > invoke="sendNotification(DispatchContext ctx, > Map > > > context) > > > >>>>method prepareNotification(ctx, > context); > > > //builds the body of the > > > mail by rendering the corresponding ftl > > > >>>>if body != null > > > >>>>dispatcher.runSync("sendMail", > emailContext); > > > org.ofbiz.content.email.EmailServices" > > > invoke="sendMail" > > > > > > > > > > > > Regards > > > Tibor > > > > > > > > |
this is true for java services
but you don't get the entire process flow On 7/11/06, Chris Howe <[hidden email]> wrote: > > You'd be better off for being more encompassing by > going through the java files and putting in > log.ObscenelyVerbose() after every java and simple > method begins, right before each if statement, n+1 > after each while statement, and right before the > return of a java and simple method. Of course then, > you'll get a million more timeout errors ;). > > > --- tibor katelbach <[hidden email]> wrote: > > > I agree, that is the pb with such docs, they are > > heavy to write, because the > > task is huge. But once it is done the main part is > > done, offcourse > > maintenance is heavy but it could also be a new way > > of spotting precisly > > what is new between versions and more readiable than > > a SVN upgrade. > > > > we all took the effort of understanding processes > > and this would be a way to > > share it. logs are shared but not exhaustive even > > the Verbose. > > > > I did it for quite a few processes and when I > > communicate these docs to > > other people needing a the same process, all they do > > is read it out. > > if what they need is in there , then they dig in. > > I often lost time by reading through loads of code > > and my answer was just > > waiting at the end, > > this way you go directly to the interesting section. > > > > offcourse this gets really interesting only if we > > all participate. > > > > just trying to help newcomers > > > > > > On 7/11/06, Chris Howe <[hidden email]> > > wrote: > > > > > > I think that the easiest way to accomplish this is > > > through the logs. Documenting these processes for > > > reference would be too burdonsome and maintenance > > > would be quite tedious. > > > > > > --- tibor katelbach <[hidden email]> wrote: > > > > > > > Hi everyone > > > > I've been tagging along an idea of documenting > > > > algorythms of ofbiz > > > > processes. > > > > > > > > Since I started working with ofbiz, as always I > > > > found myself having to dig > > > > into existing code > > > > I found that the clearest way to understand how > > > > modules work is to rebuild > > > > the algorithm behind a process . > > > > A process could be a complete run through from > > url > > > > to controller to to > > > > Service , run through the Service to result , to > > > > Screen ...etc. > > > > > > > > by writting down the main elements of a process > > this > > > > draws quite a clear map > > > > of the algorithm behind the process, and > > especially > > > > is easily transmitable and readable by others. > > This > > > > also keeps from having > > > > to run through all code , all processes which > > would > > > > be the next step after > > > > reading the algo. > > > > > > > > WDYT ? > > > > > > > > I think it would be enourmously enrichining for > > > > people like myself wanting > > > > to understand quickly what does what, and what > > is > > > > done behind the scenes. > > > > > > > > Sometimes these algos quite large for processes > > like > > > > the chekout process > > > > here's a sample I gathered up for the > > tellafriend > > > > process: > > > > I list Service , Maps, redirections... a std > > format > > > > needs to be set up > > > > > > > > Form : tellafriend > > > > input : message, sendTo, sendFrom > > > > > > > > >>>> controller event : > > > > org.ofbiz.product.product.ProductEvents" > > > > invoke="tellAFriend" > > > > > > > > >>> dans le service tellafriend > > > > > > > > [GenericEntity:ProductStoreEmailSetting] > > > > > > > > > > > > > > [bccAddress,null()][bodyScreenLocation,null()][ccAddress,null()][contentType,null()][createdStamp,2006-04-21 > > > > 15:06:47.428(java.sql.Timestamp)] > > > > [createdTxStamp,2006-04-21 > > > > 15:06:46.848(java.sql.Timestamp > > > > )][emailType,PRDS_TELL_FRIEND(java.lang.String)] > > > > > > > > > [fromAddress,[hidden email](java.lang.String > > > )][lastUpdatedStamp,2006-04-21 > > > > 15:06:47.428(java.sql.Timestamp)] > > > > [lastUpdatedTxStamp,2006-04-21 > > > > 15:06:46.848(java.sql.Timestamp > > > > )][productStoreId,910(java.lang.String)] > > > > [subject,${sendFrom} has sent you a > > > > link!(java.lang.String)] > > > > > > > > > > [templatePath,/applications/petitbateau/templates/email/tellafriend.ftl( > > > > > > java.lang.String)][xslfoAttachScreenLocation,null()] > > > > > > > > { > > > > templateData= > > > > [ > > > > sendFrom=[hidden email], > > > > message=qgfgsdf gsdf gsdf gsdfg sdf, > > > > sendTo=[hidden email], > > > > > > > > > > pageUrl=http://localhost/petitbateau/control/product?product_id=94451 > > > > ], > > > > > > > > sendTo=[hidden email], > > > > > > > > > > > > > > templateName=X:/X_Dev/sequoiaerp/applications/petitbateau/templates/email/tellafriend.ftl, > > > > > > > > sendCc=null, > > > > sendBcc=null, > > > > subject=[hidden email] has sent you a link!, > > > > sendFrom=[hidden email], > > > > contentType=null} > > > > > > > > > > > > > > >>>>dispatcher.runAsync("sendGenericNotificationEmail", > > > > context); > > > > > > >>>>org.ofbiz.content.email.NotificationServices" > > > > invoke="sendNotification(DispatchContext ctx, > > Map > > > > context) > > > > >>>>method prepareNotification(ctx, > > context); > > > > //builds the body of the > > > > mail by rendering the corresponding ftl > > > > >>>>if body != null > > > > >>>>dispatcher.runSync("sendMail", > > emailContext); > > > > org.ofbiz.content.email.EmailServices" > > > > invoke="sendMail" > > > > > > > > > > > > > > > > Regards > > > > Tibor > > > > > > > > > > > > > > |
In reply to this post by oceatoon
Tibor,
I tried to do exactly what you're suggesting about a year ago when we developed the Financials module. I tried to write a document which described all the business logic, data model, and processes. If you look in the financials module there is a docs/ directory with a TechnicalDocs file in DocBook SGML format. What I found was that it was extremely cumbersome and difficult to do things this way, because I was writing a document and then writing code. If later the code couldn't follow exactly the original design, I'd have to fix the code, then fix the document again. It is not impossible but would require a tremendous amount of discipline and effort to do this. A better solution, in my opinion, is to comment the code better-- write more comments about the services, the Java methods, etc. that talk about what is going on, and comment the SECAs about what process each SECA is re-creating. This would create documentation which is easier for developers to maintain and which another developer who is familiar with the basic structure of OFBiz would be able to work with. This is what I'm trying to do know--as I look through code, I'm putting more comments and committing them. I would encourage you and everybody else to do the same. If you read through a service or some code that could use better comments, please send in a patch. Si On Jul 11, 2006, at 8:46 AM, tibor katelbach wrote: > I agree, that is the pb with such docs, they are heavy to write, > because the > task is huge. But once it is done the main part is done, offcourse > maintenance is heavy but it could also be a new way of spotting > precisly > what is new between versions and more readiable than a SVN upgrade. > > we all took the effort of understanding processes and this would be > a way to > share it. logs are shared but not exhaustive even the Verbose. > > I did it for quite a few processes and when I communicate these > docs to > other people needing a the same process, all they do is read it out. > if what they need is in there , then they dig in. > I often lost time by reading through loads of code and my answer > was just > waiting at the end, > this way you go directly to the interesting section. > > offcourse this gets really interesting only if we all participate. > > just trying to help newcomers > > > On 7/11/06, Chris Howe <[hidden email]> wrote: >> >> I think that the easiest way to accomplish this is >> through the logs. Documenting these processes for >> reference would be too burdonsome and maintenance >> would be quite tedious. >> >> --- tibor katelbach <[hidden email]> wrote: >> >> > Hi everyone >> > I've been tagging along an idea of documenting >> > algorythms of ofbiz >> > processes. >> > >> > Since I started working with ofbiz, as always I >> > found myself having to dig >> > into existing code >> > I found that the clearest way to understand how >> > modules work is to rebuild >> > the algorithm behind a process . >> > A process could be a complete run through from url >> > to controller to to >> > Service , run through the Service to result , to >> > Screen ...etc. >> > >> > by writting down the main elements of a process this >> > draws quite a clear map >> > of the algorithm behind the process, and especially >> > is easily transmitable and readable by others. This >> > also keeps from having >> > to run through all code , all processes which would >> > be the next step after >> > reading the algo. >> > >> > WDYT ? >> > >> > I think it would be enourmously enrichining for >> > people like myself wanting >> > to understand quickly what does what, and what is >> > done behind the scenes. >> > >> > Sometimes these algos quite large for processes like >> > the chekout process >> > here's a sample I gathered up for the tellafriend >> > process: >> > I list Service , Maps, redirections... a std format >> > needs to be set up >> > >> > Form : tellafriend >> > input : message, sendTo, sendFrom >> > >> > >>>> controller event : >> > org.ofbiz.product.product.ProductEvents" >> > invoke="tellAFriend" >> > >> > >>> dans le service tellafriend >> > >> > [GenericEntity:ProductStoreEmailSetting] >> > >> >> [bccAddress,null()][bodyScreenLocation,null()][ccAddress,null()] >> [contentType,null()][createdStamp,2006-04-21 >> > 15:06:47.428(java.sql.Timestamp)] >> > [createdTxStamp,2006-04-21 >> > 15:06:46.848(java.sql.Timestamp >> > )][emailType,PRDS_TELL_FRIEND(java.lang.String)] >> > >> [fromAddress,[hidden email](java.lang.String >> )][lastUpdatedStamp,2006-04-21 >> > 15:06:47.428(java.sql.Timestamp)] >> > [lastUpdatedTxStamp,2006-04-21 >> > 15:06:46.848(java.sql.Timestamp >> > )][productStoreId,910(java.lang.String)] >> > [subject,${sendFrom} has sent you a >> > link!(java.lang.String)] >> > >> [templatePath,/applications/petitbateau/templates/email/ >> tellafriend.ftl( >> > java.lang.String)][xslfoAttachScreenLocation,null()] >> > >> > { >> > templateData= >> > [ >> > sendFrom=[hidden email], >> > message=qgfgsdf gsdf gsdf gsdfg sdf, >> > sendTo=[hidden email], >> > >> pageUrl=http://localhost/petitbateau/control/product?product_id=94451 >> > ], >> > >> > sendTo=[hidden email], >> > >> >> templateName=X:/X_Dev/sequoiaerp/applications/petitbateau/ >> templates/email/tellafriend.ftl, >> > >> > sendCc=null, >> > sendBcc=null, >> > subject=[hidden email] has sent you a link!, >> > sendFrom=[hidden email], >> > contentType=null} >> > >> > >> >>>>dispatcher.runAsync("sendGenericNotificationEmail", >> > context); >> > >>>>org.ofbiz.content.email.NotificationServices" >> > invoke="sendNotification(DispatchContext ctx, Map >> > context) >> > >>>>method prepareNotification(ctx, context); >> > //builds the body of the >> > mail by rendering the corresponding ftl >> > >>>>if body != null >> > >>>>dispatcher.runSync("sendMail", emailContext); >> > org.ofbiz.content.email.EmailServices" >> > invoke="sendMail" >> > >> > >> > >> > Regards >> > Tibor >> > >> >> |
Administrator
|
From: "Si Chen" <[hidden email]> > Tibor, > > I tried to do exactly what you're suggesting about a year ago when we > developed the Financials module. I tried to write a document which > described all the business logic, data model, and processes. If you > look in the financials module there is a docs/ directory with a > TechnicalDocs file in DocBook SGML format. > > What I found was that it was extremely cumbersome and difficult to do > things this way, because I was writing a document and then writing > code. If later the code couldn't follow exactly the original design, > I'd have to fix the code, then fix the document again. It is not > impossible but would require a tremendous amount of discipline and > effort to do this. > > A better solution, in my opinion, is to comment the code better-- > write more comments about the services, the Java methods, etc. that > talk about what is going on, and comment the SECAs about what process > each SECA is re-creating. This would create documentation which is > easier for developers to maintain and which another developer who is > familiar with the basic structure of OFBiz would be able to work with. > > This is what I'm trying to do know--as I look through code, I'm > putting more comments and committing them. I would encourage you and > everybody else to do the same. If you read through a service or some > code that could use better comments, please send in a patch. > > Si I agree with Si, especially if everybody think to update comments when modifying code ... Jacques > On Jul 11, 2006, at 8:46 AM, tibor katelbach wrote: > > > I agree, that is the pb with such docs, they are heavy to write, > > because the > > task is huge. But once it is done the main part is done, offcourse > > maintenance is heavy but it could also be a new way of spotting > > precisly > > what is new between versions and more readiable than a SVN upgrade. > > > > we all took the effort of understanding processes and this would be > > a way to > > share it. logs are shared but not exhaustive even the Verbose. > > > > I did it for quite a few processes and when I communicate these > > docs to > > other people needing a the same process, all they do is read it out. > > if what they need is in there , then they dig in. > > I often lost time by reading through loads of code and my answer > > was just > > waiting at the end, > > this way you go directly to the interesting section. > > > > offcourse this gets really interesting only if we all participate. > > > > just trying to help newcomers > > > > > > On 7/11/06, Chris Howe <[hidden email]> wrote: > >> > >> I think that the easiest way to accomplish this is > >> through the logs. Documenting these processes for > >> reference would be too burdonsome and maintenance > >> would be quite tedious. > >> > >> --- tibor katelbach <[hidden email]> wrote: > >> > >> > Hi everyone > >> > I've been tagging along an idea of documenting > >> > algorythms of ofbiz > >> > processes. > >> > > >> > Since I started working with ofbiz, as always I > >> > found myself having to dig > >> > into existing code > >> > I found that the clearest way to understand how > >> > modules work is to rebuild > >> > the algorithm behind a process . > >> > A process could be a complete run through from url > >> > to controller to to > >> > Service , run through the Service to result , to > >> > Screen ...etc. > >> > > >> > by writting down the main elements of a process this > >> > draws quite a clear map > >> > of the algorithm behind the process, and especially > >> > is easily transmitable and readable by others. This > >> > also keeps from having > >> > to run through all code , all processes which would > >> > be the next step after > >> > reading the algo. > >> > > >> > WDYT ? > >> > > >> > I think it would be enourmously enrichining for > >> > people like myself wanting > >> > to understand quickly what does what, and what is > >> > done behind the scenes. > >> > > >> > Sometimes these algos quite large for processes like > >> > the chekout process > >> > here's a sample I gathered up for the tellafriend > >> > process: > >> > I list Service , Maps, redirections... a std format > >> > needs to be set up > >> > > >> > Form : tellafriend > >> > input : message, sendTo, sendFrom > >> > > >> > >>>> controller event : > >> > org.ofbiz.product.product.ProductEvents" > >> > invoke="tellAFriend" > >> > > >> > >>> dans le service tellafriend > >> > > >> > [GenericEntity:ProductStoreEmailSetting] > >> > > >> > >> [bccAddress,null()][bodyScreenLocation,null()][ccAddress,null()] > >> [contentType,null()][createdStamp,2006-04-21 > >> > 15:06:47.428(java.sql.Timestamp)] > >> > [createdTxStamp,2006-04-21 > >> > 15:06:46.848(java.sql.Timestamp > >> > )][emailType,PRDS_TELL_FRIEND(java.lang.String)] > >> > > >> [fromAddress,[hidden email](java.lang.String > >> )][lastUpdatedStamp,2006-04-21 > >> > 15:06:47.428(java.sql.Timestamp)] > >> > [lastUpdatedTxStamp,2006-04-21 > >> > 15:06:46.848(java.sql.Timestamp > >> > )][productStoreId,910(java.lang.String)] > >> > [subject,${sendFrom} has sent you a > >> > link!(java.lang.String)] > >> > > >> [templatePath,/applications/petitbateau/templates/email/ > >> tellafriend.ftl( > >> > java.lang.String)][xslfoAttachScreenLocation,null()] > >> > > >> > { > >> > templateData= > >> > [ > >> > sendFrom=[hidden email], > >> > message=qgfgsdf gsdf gsdf gsdfg sdf, > >> > sendTo=[hidden email], > >> > > >> pageUrl=http://localhost/petitbateau/control/product?product_id=94451 > >> > ], > >> > > >> > sendTo=[hidden email], > >> > > >> > >> templateName=X:/X_Dev/sequoiaerp/applications/petitbateau/ > >> templates/email/tellafriend.ftl, > >> > > >> > sendCc=null, > >> > sendBcc=null, > >> > subject=[hidden email] has sent you a link!, > >> > sendFrom=[hidden email], > >> > contentType=null} > >> > > >> > > >> >>>>dispatcher.runAsync("sendGenericNotificationEmail", > >> > context); > >> > >>>>org.ofbiz.content.email.NotificationServices" > >> > invoke="sendNotification(DispatchContext ctx, Map > >> > context) > >> > >>>>method prepareNotification(ctx, context); > >> > //builds the body of the > >> > mail by rendering the corresponding ftl > >> > >>>>if body != null > >> > >>>>dispatcher.runSync("sendMail", emailContext); > >> > org.ofbiz.content.email.EmailServices" > >> > invoke="sendMail" > >> > > >> > > >> > > >> > Regards > >> > Tibor > >> > > >> > >> |
In reply to this post by Si Chen-2
thx Si for your experience,
Commenting code is always a plus but eventhough it is heavy , I stick to this idea as a usefull way to give and instant image of the algo behind a process without having to go into every piece that constructs it. This type of documentation should be maintained only when major changes are made because it's not a detailed description. Which isn't that often is it ? in any case as I go forward I continue to gather them, and could commit them into a docs folder of each process containing application if you guys find an interest in them. Regards Tibor On 7/12/06, Si Chen <[hidden email] > wrote: > > Tibor, > > I tried to do exactly what you're suggesting about a year ago when we > developed the Financials module. I tried to write a document which > described all the business logic, data model, and processes. If you > look in the financials module there is a docs/ directory with a > TechnicalDocs file in DocBook SGML format. > > What I found was that it was extremely cumbersome and difficult to do > things this way, because I was writing a document and then writing > code. If later the code couldn't follow exactly the original design, > I'd have to fix the code, then fix the document again. It is not > impossible but would require a tremendous amount of discipline and > effort to do this. > > A better solution, in my opinion, is to comment the code better-- > write more comments about the services, the Java methods, etc. that > talk about what is going on, and comment the SECAs about what process > each SECA is re-creating. This would create documentation which is > easier for developers to maintain and which another developer who is > familiar with the basic structure of OFBiz would be able to work with. > > This is what I'm trying to do know--as I look through code, I'm > putting more comments and committing them. I would encourage you and > everybody else to do the same. If you read through a service or some > code that could use better comments, please send in a patch. > > Si > > On Jul 11, 2006, at 8:46 AM, tibor katelbach wrote: > > > I agree, that is the pb with such docs, they are heavy to write, > > because the > > task is huge. But once it is done the main part is done, offcourse > > maintenance is heavy but it could also be a new way of spotting > > precisly > > what is new between versions and more readiable than a SVN upgrade. > > > > we all took the effort of understanding processes and this would be > > a way to > > share it. logs are shared but not exhaustive even the Verbose. > > > > I did it for quite a few processes and when I communicate these > > docs to > > other people needing a the same process, all they do is read it out. > > if what they need is in there , then they dig in. > > I often lost time by reading through loads of code and my answer > > was just > > waiting at the end, > > this way you go directly to the interesting section. > > > > offcourse this gets really interesting only if we all participate. > > > > just trying to help newcomers > > > > > > On 7/11/06, Chris Howe <[hidden email]> wrote: > >> > >> I think that the easiest way to accomplish this is > >> through the logs. Documenting these processes for > >> reference would be too burdonsome and maintenance > >> would be quite tedious. > >> > >> --- tibor katelbach <[hidden email]> wrote: > >> > >> > Hi everyone > >> > I've been tagging along an idea of documenting > >> > algorythms of ofbiz > >> > processes. > >> > > >> > Since I started working with ofbiz, as always I > >> > found myself having to dig > >> > into existing code > >> > I found that the clearest way to understand how > >> > modules work is to rebuild > >> > the algorithm behind a process . > >> > A process could be a complete run through from url > >> > to controller to to > >> > Service , run through the Service to result , to > >> > Screen ...etc. > >> > > >> > by writting down the main elements of a process this > >> > draws quite a clear map > >> > of the algorithm behind the process, and especially > >> > is easily transmitable and readable by others. This > >> > also keeps from having > >> > to run through all code , all processes which would > >> > be the next step after > >> > reading the algo. > >> > > >> > WDYT ? > >> > > >> > I think it would be enourmously enrichining for > >> > people like myself wanting > >> > to understand quickly what does what, and what is > >> > done behind the scenes. > >> > > >> > Sometimes these algos quite large for processes like > >> > the chekout process > >> > here's a sample I gathered up for the tellafriend > >> > process: > >> > I list Service , Maps, redirections... a std format > >> > needs to be set up > >> > > >> > Form : tellafriend > >> > input : message, sendTo, sendFrom > >> > > >> > >>>> controller event : > >> > org.ofbiz.product.product.ProductEvents" > >> > invoke="tellAFriend" > >> > > >> > >>> dans le service tellafriend > >> > > >> > [GenericEntity:ProductStoreEmailSetting] > >> > > >> > >> [bccAddress,null()][bodyScreenLocation,null()][ccAddress,null()] > >> [contentType,null()][createdStamp,2006-04-21 > >> > 15:06:47.428(java.sql.Timestamp)] > >> > [createdTxStamp,2006-04-21 > >> > 15:06:46.848(java.sql.Timestamp > >> > )][emailType,PRDS_TELL_FRIEND(java.lang.String)] > >> > > >> [fromAddress,[hidden email](java.lang.String > >> )][lastUpdatedStamp,2006-04-21 > >> > 15:06:47.428(java.sql.Timestamp)] > >> > [lastUpdatedTxStamp,2006-04-21 > >> > 15:06: 46.848(java.sql.Timestamp > >> > )][productStoreId,910(java.lang.String)] > >> > [subject,${sendFrom} has sent you a > >> > link!(java.lang.String)] > >> > > >> [templatePath,/applications/petitbateau/templates/email/ > >> tellafriend.ftl( > >> > java.lang.String)][xslfoAttachScreenLocation,null()] > >> > > >> > { > >> > templateData= > >> > [ > >> > sendFrom= [hidden email], > >> > message=qgfgsdf gsdf gsdf gsdfg sdf, > >> > sendTo=[hidden email], > >> > > >> pageUrl= http://localhost/petitbateau/control/product?product_id=94451 > >> > ], > >> > > >> > sendTo=[hidden email], > >> > > >> > >> templateName=X:/X_Dev/sequoiaerp/applications/petitbateau/ > >> templates/email/tellafriend.ftl, > >> > > >> > sendCc=null, > >> > sendBcc=null, > >> > subject= [hidden email] has sent you a link!, > >> > sendFrom=[hidden email], > >> > contentType=null} > >> > > >> > > >> >>>> dispatcher.runAsync("sendGenericNotificationEmail", > >> > context); > >> > >>>>org.ofbiz.content.email.NotificationServices" > >> > invoke="sendNotification(DispatchContext ctx, Map > >> > context) > >> > >>>>method prepareNotification(ctx, context); > >> > //builds the body of the > >> > mail by rendering the corresponding ftl > >> > >>>>if body != null > >> > >>>>dispatcher.runSync("sendMail", emailContext); > >> > org.ofbiz.content.email.EmailServices" > >> > invoke="sendMail" > >> > > >> > > >> > > >> > Regards > >> > Tibor > >> > > >> > >> > > |
Administrator
|
Tibor,
IMHO every effort is welcome. Why not trying this way ? It may improve with action... Jacques From: "tibor katelbach" <[hidden email]> > thx Si for your experience, > Commenting code is always a plus but eventhough it is heavy , I stick to > this idea as a usefull way to give and instant image of the algo behind a > process without having to go into every piece that constructs it. > This type of documentation should be maintained only when major changes are > made because it's not a detailed description. > Which isn't that often is it ? > in any case as I go forward I continue to gather them, and could commit them > into a docs folder of each process containing application if you guys find > an interest in them. > > Regards > Tibor > > > On 7/12/06, Si Chen <[hidden email] > wrote: > > > > Tibor, > > > > I tried to do exactly what you're suggesting about a year ago when we > > developed the Financials module. I tried to write a document which > > described all the business logic, data model, and processes. If you > > look in the financials module there is a docs/ directory with a > > TechnicalDocs file in DocBook SGML format. > > > > What I found was that it was extremely cumbersome and difficult to do > > things this way, because I was writing a document and then writing > > code. If later the code couldn't follow exactly the original design, > > I'd have to fix the code, then fix the document again. It is not > > impossible but would require a tremendous amount of discipline and > > effort to do this. > > > > A better solution, in my opinion, is to comment the code better-- > > write more comments about the services, the Java methods, etc. that > > talk about what is going on, and comment the SECAs about what process > > each SECA is re-creating. This would create documentation which is > > easier for developers to maintain and which another developer who is > > familiar with the basic structure of OFBiz would be able to work with. > > > > This is what I'm trying to do know--as I look through code, I'm > > putting more comments and committing them. I would encourage you and > > everybody else to do the same. If you read through a service or some > > code that could use better comments, please send in a patch. > > > > Si > > > > On Jul 11, 2006, at 8:46 AM, tibor katelbach wrote: > > > > > I agree, that is the pb with such docs, they are heavy to write, > > > because the > > > task is huge. But once it is done the main part is done, offcourse > > > maintenance is heavy but it could also be a new way of spotting > > > precisly > > > what is new between versions and more readiable than a SVN upgrade. > > > > > > we all took the effort of understanding processes and this would be > > > a way to > > > share it. logs are shared but not exhaustive even the Verbose. > > > > > > I did it for quite a few processes and when I communicate these > > > docs to > > > other people needing a the same process, all they do is read it out. > > > if what they need is in there , then they dig in. > > > I often lost time by reading through loads of code and my answer > > > was just > > > waiting at the end, > > > this way you go directly to the interesting section. > > > > > > offcourse this gets really interesting only if we all participate. > > > > > > just trying to help newcomers > > > > > > > > > On 7/11/06, Chris Howe <[hidden email]> wrote: > > >> > > >> I think that the easiest way to accomplish this is > > >> through the logs. Documenting these processes for > > >> reference would be too burdonsome and maintenance > > >> would be quite tedious. > > >> > > >> --- tibor katelbach <[hidden email]> wrote: > > >> > > >> > Hi everyone > > >> > I've been tagging along an idea of documenting > > >> > algorythms of ofbiz > > >> > processes. > > >> > > > >> > Since I started working with ofbiz, as always I > > >> > found myself having to dig > > >> > into existing code > > >> > I found that the clearest way to understand how > > >> > modules work is to rebuild > > >> > the algorithm behind a process . > > >> > A process could be a complete run through from url > > >> > to controller to to > > >> > Service , run through the Service to result , to > > >> > Screen ...etc. > > >> > > > >> > by writting down the main elements of a process this > > >> > draws quite a clear map > > >> > of the algorithm behind the process, and especially > > >> > is easily transmitable and readable by others. This > > >> > also keeps from having > > >> > to run through all code , all processes which would > > >> > be the next step after > > >> > reading the algo. > > >> > > > >> > WDYT ? > > >> > > > >> > I think it would be enourmously enrichining for > > >> > people like myself wanting > > >> > to understand quickly what does what, and what is > > >> > done behind the scenes. > > >> > > > >> > Sometimes these algos quite large for processes like > > >> > the chekout process > > >> > here's a sample I gathered up for the tellafriend > > >> > process: > > >> > I list Service , Maps, redirections... a std format > > >> > needs to be set up > > >> > > > >> > Form : tellafriend > > >> > input : message, sendTo, sendFrom > > >> > > > >> > >>>> controller event : > > >> > org.ofbiz.product.product.ProductEvents" > > >> > invoke="tellAFriend" > > >> > > > >> > >>> dans le service tellafriend > > >> > > > >> > [GenericEntity:ProductStoreEmailSetting] > > >> > > > >> > > >> [bccAddress,null()][bodyScreenLocation,null()][ccAddress,null()] > > >> [contentType,null()][createdStamp,2006-04-21 > > >> > 15:06:47.428(java.sql.Timestamp)] > > >> > [createdTxStamp,2006-04-21 > > >> > 15:06:46.848(java.sql.Timestamp > > >> > )][emailType,PRDS_TELL_FRIEND(java.lang.String)] > > >> > > > >> [fromAddress,[hidden email](java.lang.String > > >> )][lastUpdatedStamp,2006-04-21 > > >> > 15:06:47.428(java.sql.Timestamp)] > > >> > [lastUpdatedTxStamp,2006-04-21 > > >> > 15:06: 46.848(java.sql.Timestamp > > >> > )][productStoreId,910(java.lang.String)] > > >> > [subject,${sendFrom} has sent you a > > >> > link!(java.lang.String)] > > >> > > > >> [templatePath,/applications/petitbateau/templates/email/ > > >> tellafriend.ftl( > > >> > java.lang.String)][xslfoAttachScreenLocation,null()] > > >> > > > >> > { > > >> > templateData= > > >> > [ > > >> > sendFrom= [hidden email], > > >> > message=qgfgsdf gsdf gsdf gsdfg sdf, > > >> > sendTo=[hidden email], > > >> > > > >> pageUrl= http://localhost/petitbateau/control/product?product_id=94451 > > >> > ], > > >> > > > >> > sendTo=[hidden email], > > >> > > > >> > > >> templateName=X:/X_Dev/sequoiaerp/applications/petitbateau/ > > >> templates/email/tellafriend.ftl, > > >> > > > >> > sendCc=null, > > >> > sendBcc=null, > > >> > subject= [hidden email] has sent you a link!, > > >> > sendFrom=[hidden email], > > >> > contentType=null} > > >> > > > >> > > > >> >>>> dispatcher.runAsync("sendGenericNotificationEmail", > > >> > context); > > >> > >>>>org.ofbiz.content.email.NotificationServices" > > >> > invoke="sendNotification(DispatchContext ctx, Map > > >> > context) > > >> > >>>>method prepareNotification(ctx, context); > > >> > //builds the body of the > > >> > mail by rendering the corresponding ftl > > >> > >>>>if body != null > > >> > >>>>dispatcher.runSync("sendMail", emailContext); > > >> > org.ofbiz.content.email.EmailServices" > > >> > invoke="sendMail" > > >> > > > >> > > > >> > > > >> > Regards > > >> > Tibor > > >> > > > >> > > >> > > > > > |
I'm one step from action just wanted validation from the community ,
and more important for the moderators to tell me where they beleive the best location for this would be ? in a doc folder of each application, and patched in the SVN ? in the wiki ? and in which one ? On 7/13/06, Jacques Le Roux <[hidden email]> wrote: > > Tibor, > > IMHO every effort is welcome. Why not trying this way ? It may improve > with > action... > > Jacques > > From: "tibor katelbach" <[hidden email] > > > > > thx Si for your experience, > > Commenting code is always a plus but eventhough it is heavy , I stick to > > this idea as a usefull way to give and instant image of the algo behind > a > > process without having to go into every piece that constructs it. > > This type of documentation should be maintained only when major changes > are > > made because it's not a detailed description. > > Which isn't that often is it ? > > in any case as I go forward I continue to gather them, and could commit > them > > into a docs folder of each process containing application if you guys > find > > an interest in them. > > > > Regards > > Tibor > > > > > > On 7/12/06, Si Chen < [hidden email] > wrote: > > > > > > Tibor, > > > > > > I tried to do exactly what you're suggesting about a year ago when we > > > developed the Financials module. I tried to write a document which > > > described all the business logic, data model, and processes. If you > > > look in the financials module there is a docs/ directory with a > > > TechnicalDocs file in DocBook SGML format. > > > > > > What I found was that it was extremely cumbersome and difficult to do > > > things this way, because I was writing a document and then writing > > > code. If later the code couldn't follow exactly the original design, > > > I'd have to fix the code, then fix the document again. It is not > > > impossible but would require a tremendous amount of discipline and > > > effort to do this. > > > > > > A better solution, in my opinion, is to comment the code better-- > > > write more comments about the services, the Java methods, etc. that > > > talk about what is going on, and comment the SECAs about what process > > > each SECA is re-creating. This would create documentation which is > > > easier for developers to maintain and which another developer who is > > > familiar with the basic structure of OFBiz would be able to work with. > > > > > > This is what I'm trying to do know--as I look through code, I'm > > > putting more comments and committing them. I would encourage you and > > > everybody else to do the same. If you read through a service or some > > > code that could use better comments, please send in a patch. > > > > > > Si > > > > > > On Jul 11, 2006, at 8:46 AM, tibor katelbach wrote: > > > > > > > I agree, that is the pb with such docs, they are heavy to write, > > > > because the > > > > task is huge. But once it is done the main part is done, offcourse > > > > maintenance is heavy but it could also be a new way of spotting > > > > precisly > > > > what is new between versions and more readiable than a SVN upgrade. > > > > > > > > we all took the effort of understanding processes and this would be > > > > a way to > > > > share it. logs are shared but not exhaustive even the Verbose. > > > > > > > > I did it for quite a few processes and when I communicate these > > > > docs to > > > > other people needing a the same process, all they do is read it out. > > > > if what they need is in there , then they dig in. > > > > I often lost time by reading through loads of code and my answer > > > > was just > > > > waiting at the end, > > > > this way you go directly to the interesting section. > > > > > > > > offcourse this gets really interesting only if we all participate. > > > > > > > > just trying to help newcomers > > > > > > > > > > > > On 7/11/06, Chris Howe < [hidden email]> wrote: > > > >> > > > >> I think that the easiest way to accomplish this is > > > >> through the logs. Documenting these processes for > > > >> reference would be too burdonsome and maintenance > > > >> would be quite tedious. > > > >> > > > >> --- tibor katelbach < [hidden email]> wrote: > > > >> > > > >> > Hi everyone > > > >> > I've been tagging along an idea of documenting > > > >> > algorythms of ofbiz > > > >> > processes. > > > >> > > > > >> > Since I started working with ofbiz, as always I > > > >> > found myself having to dig > > > >> > into existing code > > > >> > I found that the clearest way to understand how > > > >> > modules work is to rebuild > > > >> > the algorithm behind a process . > > > >> > A process could be a complete run through from url > > > >> > to controller to to > > > >> > Service , run through the Service to result , to > > > >> > Screen ...etc. > > > >> > > > > >> > by writting down the main elements of a process this > > > >> > draws quite a clear map > > > >> > of the algorithm behind the process, and especially > > > >> > is easily transmitable and readable by others. This > > > >> > also keeps from having > > > >> > to run through all code , all processes which would > > > >> > be the next step after > > > >> > reading the algo. > > > >> > > > > >> > WDYT ? > > > >> > > > > >> > I think it would be enourmously enrichining for > > > >> > people like myself wanting > > > >> > to understand quickly what does what, and what is > > > >> > done behind the scenes. > > > >> > > > > >> > Sometimes these algos quite large for processes like > > > >> > the chekout process > > > >> > here's a sample I gathered up for the tellafriend > > > >> > process: > > > >> > I list Service , Maps, redirections... a std format > > > >> > needs to be set up > > > >> > > > > >> > Form : tellafriend > > > >> > input : message, sendTo, sendFrom > > > >> > > > > >> > >>>> controller event : > > > >> > org.ofbiz.product.product.ProductEvents" > > > >> > invoke="tellAFriend" > > > >> > > > > >> > >>> dans le service tellafriend > > > >> > > > > >> > [GenericEntity:ProductStoreEmailSetting] > > > >> > > > > >> > > > >> [bccAddress,null()][bodyScreenLocation,null()][ccAddress,null()] > > > >> [contentType,null()][createdStamp,2006-04-21 > > > >> > 15:06: 47.428(java.sql.Timestamp)] > > > >> > [createdTxStamp,2006-04-21 > > > >> > 15:06:46.848(java.sql.Timestamp > > > >> > )][emailType,PRDS_TELL_FRIEND(java.lang.String)] > > > >> > > > > >> [fromAddress,[hidden email](java.lang.String > > > >> )][lastUpdatedStamp,2006-04-21 > > > >> > 15:06:47.428(java.sql.Timestamp)] > > > >> > [lastUpdatedTxStamp,2006-04-21 > > > >> > 15:06: 46.848(java.sql.Timestamp > > > >> > )][productStoreId,910(java.lang.String)] > > > >> > [subject,${sendFrom} has sent you a > > > >> > link!( java.lang.String)] > > > >> > > > > >> [templatePath,/applications/petitbateau/templates/email/ > > > >> tellafriend.ftl( > > > >> > java.lang.String)][xslfoAttachScreenLocation,null()] > > > >> > > > > >> > { > > > >> > templateData= > > > >> > [ > > > >> > sendFrom= [hidden email] , > > > >> > message=qgfgsdf gsdf gsdf gsdfg sdf, > > > >> > sendTo=[hidden email], > > > >> > > > > >> pageUrl= > http://localhost/petitbateau/control/product?product_id=94451 > > > >> > ], > > > >> > > > > >> > sendTo= [hidden email], > > > >> > > > > >> > > > >> templateName=X:/X_Dev/sequoiaerp/applications/petitbateau/ > > > >> templates/email/tellafriend.ftl, > > > >> > > > > >> > sendCc=null, > > > >> > sendBcc=null, > > > >> > subject= [hidden email] has sent you a link!, > > > >> > sendFrom=[hidden email], > > > >> > contentType=null} > > > >> > > > > >> > > > > >> >>>> dispatcher.runAsync("sendGenericNotificationEmail", > > > >> > context); > > > >> > >>>>org.ofbiz.content.email.NotificationServices" > > > >> > invoke="sendNotification(DispatchContext ctx, Map > > > >> > context) > > > >> > >>>>method prepareNotification(ctx, context); > > > >> > //builds the body of the > > > >> > mail by rendering the corresponding ftl > > > >> > >>>>if body != null > > > >> > >>>>dispatcher.runSync("sendMail", emailContext); > > > >> > org.ofbiz.content.email.EmailServices " > > > >> > invoke="sendMail" > > > >> > > > > >> > > > > >> > > > > >> > Regards > > > >> > Tibor > > > >> > > > > >> > > > >> > > > > > > > > > > |
The place for docs is on the docs server, which right now is docs.ofbiz.org. There is an open wiki space there as well as a "moderated" or "edited" end-user doc space which these could perhaps eventually end up in. -David tibor katelbach wrote: > I'm one step from action just wanted validation from the community , > and more important for the moderators to tell me where they beleive the > best > location for this would be ? > in a doc folder of each application, and patched in the SVN ? > in the wiki ? and in which one ? > > > On 7/13/06, Jacques Le Roux <[hidden email]> wrote: >> >> Tibor, >> >> IMHO every effort is welcome. Why not trying this way ? It may improve >> with >> action... >> >> Jacques >> >> From: "tibor katelbach" <[hidden email] > >> >> >> > thx Si for your experience, >> > Commenting code is always a plus but eventhough it is heavy , I >> stick to >> > this idea as a usefull way to give and instant image of the algo behind >> a >> > process without having to go into every piece that constructs it. >> > This type of documentation should be maintained only when major changes >> are >> > made because it's not a detailed description. >> > Which isn't that often is it ? >> > in any case as I go forward I continue to gather them, and could commit >> them >> > into a docs folder of each process containing application if you guys >> find >> > an interest in them. >> > >> > Regards >> > Tibor >> > >> > >> > On 7/12/06, Si Chen < [hidden email] > wrote: >> > > >> > > Tibor, >> > > >> > > I tried to do exactly what you're suggesting about a year ago when we >> > > developed the Financials module. I tried to write a document which >> > > described all the business logic, data model, and processes. If you >> > > look in the financials module there is a docs/ directory with a >> > > TechnicalDocs file in DocBook SGML format. >> > > >> > > What I found was that it was extremely cumbersome and difficult to do >> > > things this way, because I was writing a document and then writing >> > > code. If later the code couldn't follow exactly the original design, >> > > I'd have to fix the code, then fix the document again. It is not >> > > impossible but would require a tremendous amount of discipline and >> > > effort to do this. >> > > >> > > A better solution, in my opinion, is to comment the code better-- >> > > write more comments about the services, the Java methods, etc. that >> > > talk about what is going on, and comment the SECAs about what process >> > > each SECA is re-creating. This would create documentation which is >> > > easier for developers to maintain and which another developer who is >> > > familiar with the basic structure of OFBiz would be able to work >> with. >> > > >> > > This is what I'm trying to do know--as I look through code, I'm >> > > putting more comments and committing them. I would encourage you and >> > > everybody else to do the same. If you read through a service or some >> > > code that could use better comments, please send in a patch. >> > > >> > > Si >> > > >> > > On Jul 11, 2006, at 8:46 AM, tibor katelbach wrote: >> > > >> > > > I agree, that is the pb with such docs, they are heavy to write, >> > > > because the >> > > > task is huge. But once it is done the main part is done, offcourse >> > > > maintenance is heavy but it could also be a new way of spotting >> > > > precisly >> > > > what is new between versions and more readiable than a SVN upgrade. >> > > > >> > > > we all took the effort of understanding processes and this would be >> > > > a way to >> > > > share it. logs are shared but not exhaustive even the Verbose. >> > > > >> > > > I did it for quite a few processes and when I communicate these >> > > > docs to >> > > > other people needing a the same process, all they do is read it >> out. >> > > > if what they need is in there , then they dig in. >> > > > I often lost time by reading through loads of code and my answer >> > > > was just >> > > > waiting at the end, >> > > > this way you go directly to the interesting section. >> > > > >> > > > offcourse this gets really interesting only if we all participate. >> > > > >> > > > just trying to help newcomers >> > > > >> > > > >> > > > On 7/11/06, Chris Howe < [hidden email]> wrote: >> > > >> >> > > >> I think that the easiest way to accomplish this is >> > > >> through the logs. Documenting these processes for >> > > >> reference would be too burdonsome and maintenance >> > > >> would be quite tedious. >> > > >> >> > > >> --- tibor katelbach < [hidden email]> wrote: >> > > >> >> > > >> > Hi everyone >> > > >> > I've been tagging along an idea of documenting >> > > >> > algorythms of ofbiz >> > > >> > processes. >> > > >> > >> > > >> > Since I started working with ofbiz, as always I >> > > >> > found myself having to dig >> > > >> > into existing code >> > > >> > I found that the clearest way to understand how >> > > >> > modules work is to rebuild >> > > >> > the algorithm behind a process . >> > > >> > A process could be a complete run through from url >> > > >> > to controller to to >> > > >> > Service , run through the Service to result , to >> > > >> > Screen ...etc. >> > > >> > >> > > >> > by writting down the main elements of a process this >> > > >> > draws quite a clear map >> > > >> > of the algorithm behind the process, and especially >> > > >> > is easily transmitable and readable by others. This >> > > >> > also keeps from having >> > > >> > to run through all code , all processes which would >> > > >> > be the next step after >> > > >> > reading the algo. >> > > >> > >> > > >> > WDYT ? >> > > >> > >> > > >> > I think it would be enourmously enrichining for >> > > >> > people like myself wanting >> > > >> > to understand quickly what does what, and what is >> > > >> > done behind the scenes. >> > > >> > >> > > >> > Sometimes these algos quite large for processes like >> > > >> > the chekout process >> > > >> > here's a sample I gathered up for the tellafriend >> > > >> > process: >> > > >> > I list Service , Maps, redirections... a std format >> > > >> > needs to be set up >> > > >> > >> > > >> > Form : tellafriend >> > > >> > input : message, sendTo, sendFrom >> > > >> > >> > > >> > >>>> controller event : >> > > >> > org.ofbiz.product.product.ProductEvents" >> > > >> > invoke="tellAFriend" >> > > >> > >> > > >> > >>> dans le service tellafriend >> > > >> > >> > > >> > [GenericEntity:ProductStoreEmailSetting] >> > > >> > >> > > >> >> > > >> [bccAddress,null()][bodyScreenLocation,null()][ccAddress,null()] >> > > >> [contentType,null()][createdStamp,2006-04-21 >> > > >> > 15:06: 47.428(java.sql.Timestamp)] >> > > >> > [createdTxStamp,2006-04-21 >> > > >> > 15:06:46.848(java.sql.Timestamp >> > > >> > )][emailType,PRDS_TELL_FRIEND(java.lang.String)] >> > > >> > >> > > >> [fromAddress,[hidden email](java.lang.String >> > > >> )][lastUpdatedStamp,2006-04-21 >> > > >> > 15:06:47.428(java.sql.Timestamp)] >> > > >> > [lastUpdatedTxStamp,2006-04-21 >> > > >> > 15:06: 46.848(java.sql.Timestamp >> > > >> > )][productStoreId,910(java.lang.String)] >> > > >> > [subject,${sendFrom} has sent you a >> > > >> > link!( java.lang.String)] >> > > >> > >> > > >> [templatePath,/applications/petitbateau/templates/email/ >> > > >> tellafriend.ftl( >> > > >> > java.lang.String)][xslfoAttachScreenLocation,null()] >> > > >> > >> > > >> > { >> > > >> > templateData= >> > > >> > [ >> > > >> > sendFrom= [hidden email] , >> > > >> > message=qgfgsdf gsdf gsdf gsdfg sdf, >> > > >> > sendTo=[hidden email], >> > > >> > >> > > >> pageUrl= >> http://localhost/petitbateau/control/product?product_id=94451 >> > > >> > ], >> > > >> > >> > > >> > sendTo= [hidden email], >> > > >> > >> > > >> >> > > >> templateName=X:/X_Dev/sequoiaerp/applications/petitbateau/ >> > > >> templates/email/tellafriend.ftl, >> > > >> > >> > > >> > sendCc=null, >> > > >> > sendBcc=null, >> > > >> > subject= [hidden email] has sent you a link!, >> > > >> > sendFrom=[hidden email], >> > > >> > contentType=null} >> > > >> > >> > > >> > >> > > >> >>>> dispatcher.runAsync("sendGenericNotificationEmail", >> > > >> > context); >> > > >> > >>>>org.ofbiz.content.email.NotificationServices" >> > > >> > invoke="sendNotification(DispatchContext ctx, Map >> > > >> > context) >> > > >> > >>>>method prepareNotification(ctx, context); >> > > >> > //builds the body of the >> > > >> > mail by rendering the corresponding ftl >> > > >> > >>>>if body != null >> > > >> > >>>>dispatcher.runSync("sendMail", emailContext); >> > > >> > org.ofbiz.content.email.EmailServices " >> > > >> > invoke="sendMail" >> > > >> > >> > > >> > >> > > >> > >> > > >> > Regards >> > > >> > Tibor >> > > >> > >> > > >> >> > > >> >> > > >> > > >> > >> >> > smime.p7s (4K) Download Attachment |
In reply to this post by oceatoon
There is an "OFBiz Wiki" section in docs.ofbiz.org. How about start
putting it there? Si On Jul 13, 2006, at 6:01 AM, tibor katelbach wrote: > I'm one step from action just wanted validation from the community , > and more important for the moderators to tell me where they beleive > the best > location for this would be ? > in a doc folder of each application, and patched in the SVN ? > in the wiki ? and in which one ? > > > On 7/13/06, Jacques Le Roux <[hidden email]> wrote: >> >> Tibor, >> >> IMHO every effort is welcome. Why not trying this way ? It may >> improve >> with >> action... >> >> Jacques >> >> From: "tibor katelbach" <[hidden email] > >> >> >> > thx Si for your experience, >> > Commenting code is always a plus but eventhough it is heavy , I >> stick to >> > this idea as a usefull way to give and instant image of the algo >> behind >> a >> > process without having to go into every piece that constructs it. >> > This type of documentation should be maintained only when major >> changes >> are >> > made because it's not a detailed description. >> > Which isn't that often is it ? >> > in any case as I go forward I continue to gather them, and could >> commit >> them >> > into a docs folder of each process containing application if >> you guys >> find >> > an interest in them. >> > >> > Regards >> > Tibor >> > >> > >> > On 7/12/06, Si Chen < [hidden email] > wrote: >> > > >> > > Tibor, >> > > >> > > I tried to do exactly what you're suggesting about a year ago >> when we >> > > developed the Financials module. I tried to write a document >> which >> > > described all the business logic, data model, and processes. >> If you >> > > look in the financials module there is a docs/ directory with a >> > > TechnicalDocs file in DocBook SGML format. >> > > >> > > What I found was that it was extremely cumbersome and >> difficult to do >> > > things this way, because I was writing a document and then >> writing >> > > code. If later the code couldn't follow exactly the original >> design, >> > > I'd have to fix the code, then fix the document again. It is not >> > > impossible but would require a tremendous amount of discipline >> and >> > > effort to do this. >> > > >> > > A better solution, in my opinion, is to comment the code better-- >> > > write more comments about the services, the Java methods, etc. >> that >> > > talk about what is going on, and comment the SECAs about what >> process >> > > each SECA is re-creating. This would create documentation >> which is >> > > easier for developers to maintain and which another developer >> who is >> > > familiar with the basic structure of OFBiz would be able to >> work with. >> > > >> > > This is what I'm trying to do know--as I look through code, I'm >> > > putting more comments and committing them. I would encourage >> you and >> > > everybody else to do the same. If you read through a service >> or some >> > > code that could use better comments, please send in a patch. >> > > >> > > Si >> > > >> > > On Jul 11, 2006, at 8:46 AM, tibor katelbach wrote: >> > > >> > > > I agree, that is the pb with such docs, they are heavy to >> write, >> > > > because the >> > > > task is huge. But once it is done the main part is done, >> offcourse >> > > > maintenance is heavy but it could also be a new way of spotting >> > > > precisly >> > > > what is new between versions and more readiable than a SVN >> upgrade. >> > > > >> > > > we all took the effort of understanding processes and this >> would be >> > > > a way to >> > > > share it. logs are shared but not exhaustive even the Verbose. >> > > > >> > > > I did it for quite a few processes and when I communicate these >> > > > docs to >> > > > other people needing a the same process, all they do is read >> it out. >> > > > if what they need is in there , then they dig in. >> > > > I often lost time by reading through loads of code and my >> answer >> > > > was just >> > > > waiting at the end, >> > > > this way you go directly to the interesting section. >> > > > >> > > > offcourse this gets really interesting only if we all >> participate. >> > > > >> > > > just trying to help newcomers >> > > > >> > > > >> > > > On 7/11/06, Chris Howe < [hidden email]> wrote: >> > > >> >> > > >> I think that the easiest way to accomplish this is >> > > >> through the logs. Documenting these processes for >> > > >> reference would be too burdonsome and maintenance >> > > >> would be quite tedious. >> > > >> >> > > >> --- tibor katelbach < [hidden email]> wrote: >> > > >> >> > > >> > Hi everyone >> > > >> > I've been tagging along an idea of documenting >> > > >> > algorythms of ofbiz >> > > >> > processes. >> > > >> > >> > > >> > Since I started working with ofbiz, as always I >> > > >> > found myself having to dig >> > > >> > into existing code >> > > >> > I found that the clearest way to understand how >> > > >> > modules work is to rebuild >> > > >> > the algorithm behind a process . >> > > >> > A process could be a complete run through from url >> > > >> > to controller to to >> > > >> > Service , run through the Service to result , to >> > > >> > Screen ...etc. >> > > >> > >> > > >> > by writting down the main elements of a process this >> > > >> > draws quite a clear map >> > > >> > of the algorithm behind the process, and especially >> > > >> > is easily transmitable and readable by others. This >> > > >> > also keeps from having >> > > >> > to run through all code , all processes which would >> > > >> > be the next step after >> > > >> > reading the algo. >> > > >> > >> > > >> > WDYT ? >> > > >> > >> > > >> > I think it would be enourmously enrichining for >> > > >> > people like myself wanting >> > > >> > to understand quickly what does what, and what is >> > > >> > done behind the scenes. >> > > >> > >> > > >> > Sometimes these algos quite large for processes like >> > > >> > the chekout process >> > > >> > here's a sample I gathered up for the tellafriend >> > > >> > process: >> > > >> > I list Service , Maps, redirections... a std format >> > > >> > needs to be set up >> > > >> > >> > > >> > Form : tellafriend >> > > >> > input : message, sendTo, sendFrom >> > > >> > >> > > >> > >>>> controller event : >> > > >> > org.ofbiz.product.product.ProductEvents" >> > > >> > invoke="tellAFriend" >> > > >> > >> > > >> > >>> dans le service tellafriend >> > > >> > >> > > >> > [GenericEntity:ProductStoreEmailSetting] >> > > >> > >> > > >> >> > > >> [bccAddress,null()][bodyScreenLocation,null()] >> [ccAddress,null()] >> > > >> [contentType,null()][createdStamp,2006-04-21 >> > > >> > 15:06: 47.428(java.sql.Timestamp)] >> > > >> > [createdTxStamp,2006-04-21 >> > > >> > 15:06:46.848(java.sql.Timestamp >> > > >> > )][emailType,PRDS_TELL_FRIEND(java.lang.String)] >> > > >> > >> > > >> [fromAddress,[hidden email](java.lang.String >> > > >> )][lastUpdatedStamp,2006-04-21 >> > > >> > 15:06:47.428(java.sql.Timestamp)] >> > > >> > [lastUpdatedTxStamp,2006-04-21 >> > > >> > 15:06: 46.848(java.sql.Timestamp >> > > >> > )][productStoreId,910(java.lang.String)] >> > > >> > [subject,${sendFrom} has sent you a >> > > >> > link!( java.lang.String)] >> > > >> > >> > > >> [templatePath,/applications/petitbateau/templates/email/ >> > > >> tellafriend.ftl( >> > > >> > java.lang.String)][xslfoAttachScreenLocation,null()] >> > > >> > >> > > >> > { >> > > >> > templateData= >> > > >> > [ >> > > >> > sendFrom= [hidden email] , >> > > >> > message=qgfgsdf gsdf gsdf gsdfg sdf, >> > > >> > sendTo=[hidden email], >> > > >> > >> > > >> pageUrl= >> http://localhost/petitbateau/control/product?product_id=94451 >> > > >> > ], >> > > >> > >> > > >> > sendTo= [hidden email], >> > > >> > >> > > >> >> > > >> templateName=X:/X_Dev/sequoiaerp/applications/petitbateau/ >> > > >> templates/email/tellafriend.ftl, >> > > >> > >> > > >> > sendCc=null, >> > > >> > sendBcc=null, >> > > >> > subject= [hidden email] has sent you a link!, >> > > >> > sendFrom=[hidden email], >> > > >> > contentType=null} >> > > >> > >> > > >> > >> > > >> >>>> dispatcher.runAsync("sendGenericNotificationEmail", >> > > >> > context); >> > > >> > >>>>org.ofbiz.content.email.NotificationServices" >> > > >> > invoke="sendNotification(DispatchContext ctx, Map >> > > >> > context) >> > > >> > >>>>method prepareNotification(ctx, context); >> > > >> > //builds the body of the >> > > >> > mail by rendering the corresponding ftl >> > > >> > >>>>if body != null >> > > >> > >>>>dispatcher.runSync("sendMail", emailContext); >> > > >> > org.ofbiz.content.email.EmailServices " >> > > >> > invoke="sendMail" >> > > >> > >> > > >> > >> > > >> > >> > > >> > Regards >> > > >> > Tibor >> > > >> > >> > > >> >> > > >> >> > > >> > > >> > >> >> |
In reply to this post by Claude Feistel
Hi Everyone
I subscribed to your wiki (http://docs.ofbiz.org <http://docs.ofbiz.org/pages/listpages-dirview.action?key=OFBIZ>) but can't seem to be able to create new pages or to edit existing ones. I would like to create a new entry point called "flow and process description" or maybe you have a better name for it ? inside this page will be listed all the documented processes listed like this : promotions, chekout ,tellafriend , confirmation mails ...etc Can't do this directly? do rigths have to be opened ? Regards Tibor |
Administrator
|
Hi Tibor,
Everybody can add comments, this comments may be reviwed and included in the Wiki. That's the way Wikipedia is growing for instance. After some time you may be able to directly add documents and even more. That's meritocracy as it's called. Jacques > Hi Everyone > > I subscribed to your wiki (http://docs.ofbiz.org > <http://docs.ofbiz.org/pages/listpages-dirview.action?key=OFBIZ>) but > can't seem to be able to create new pages or to edit existing ones. > I would like to create a new entry point called > "flow and process description" or maybe you have a better name for it ? > inside this page will be listed all the documented processes listed like > this : > promotions, chekout ,tellafriend , confirmation mails ...etc > > Can't do this directly? do rigths have to be opened ? > Regards > Tibor |
Free forum by Nabble | Edit this page |