Volunteer: OFBiz End User Documentation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Volunteer: OFBiz End User Documentation

Claude Feistel
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

 

Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

David E Jones-2

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
Reply | Threaded
Open this post in threaded view
|

RE: Volunteer: OFBiz End User Documentation

Claude Feistel
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
>
>  
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

Si Chen-2
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
>>
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

David E Jones-2
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
Reply | Threaded
Open this post in threaded view
|

RE: Volunteer: OFBiz End User Documentation

Claude Feistel
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
>>
>>
>>
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

oceatoon
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
Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

cjhowe
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

oceatoon
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
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

cjhowe
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
> > >
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

oceatoon
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
> > > >
> > >
> > >
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

Si Chen-2
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
>> >
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

Jacques Le Roux
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
> >> >
> >>
> >>

Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

oceatoon
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
> >> >
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

Jacques Le Roux
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
> > >> >
> > >>
> > >>
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

oceatoon
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
> > > >> >
> > > >>
> > > >>
> > >
> > >
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

David E Jones-2

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
Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

Si Chen-2
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
>> > > >> >
>> > > >>
>> > > >>
>> > >
>> > >
>> >
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

oceatoon
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
Reply | Threaded
Open this post in threaded view
|

Re: Volunteer: OFBiz End User Documentation

Jacques Le Roux
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

12