Component and Component Set Dependencies

[David E Jones-3]

This is a topic that came up at the conference, and has come up over  
time on the mailing lists.

To help answer questions about this I've written up some details and  
put together a diagram which is now available on this page on the docs  
site:

http://docs.ofbiz.org/display/OFBADMIN/Component+and+Component+Set+Dependencies

All committers should understand this pattern, and of course we should  
refine it over time. Hopefully this will help us have, and understand,  
a little more order in our efforts to organize components.

Please send along comments! This is a first draft and I'd like to  
discuss it and such so we can move toward following the patterns and  
making this a "policy" of sorts.

-David

[Jacques Le Roux]

IMO It seems complete and good enough to be put somewhere in "OFBiz Technical Documentation" rather than in OFBiz Project
Administration Workspace
BTW should we not try to organize ourselves to better organize the documentation in Wiki ?
Some months ago, I began to do it in the open part (The Open For Business Project Wiki) by trying, as much as possible, to create a
tree from Home there.

WDYT ?

Jacques

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

>
> This is a topic that came up at the conference, and has come up over  time on the mailing lists.
>
> To help answer questions about this I've written up some details and  put together a diagram which is now available on this page
> on the docs  site:
>
> http://docs.ofbiz.org/display/OFBADMIN/Component+and+Component+Set+Dependencies
>
> All committers should understand this pattern, and of course we should  refine it over time. Hopefully this will help us have, and
> understand,  a little more order in our efforts to organize components.
>
> Please send along comments! This is a first draft and I'd like to  discuss it and such so we can move toward following the
> patterns and  making this a "policy" of sorts.
>
> -David
>

[David E Jones-3]

On Nov 15, 2008, at 6:23 AM, Jacques Le Roux wrote:

> IMO It seems complete and good enough to be put somewhere in "OFBiz  
> Technical Documentation" rather than in OFBiz Project Administration  
> Workspace

Why would this go in the technical documentation space? It has nothing  
to do with technical things like the framework and programming.  
Actually it's nearly completely about the base applications and stuff  
above that.

In other words, the project admin space is the final place I intend  
for it. The project admin space is not some temporary place for things  
that may eventually move to other spaces, like the wiki space is, it  
is a place for controlled documentation about administration of the  
project, including "policies", practices, recommendations,  
introductory materials, keeping track of people and libraries, and so  
on. This fits in perfectly there, IMO.

> BTW should we not try to organize ourselves to better organize the  
> documentation in Wiki ?
> Some months ago, I began to do it in the open part (The Open For  
> Business Project Wiki) by trying, as much as possible, to create a  
> tree from Home there.

Yes, it is a good thing to organize and make things more accessible.  
It's always difficult though... unless it is simple and there is a  
"natural" way to organize things, or an existing organization you can  
just follow, then you have the problem where one man's organization is  
another man's total chaos.

The above is a good example... ;)

-David

> From: "David E Jones" <[hidden email]>
>>
>> This is a topic that came up at the conference, and has come up  
>> over  time on the mailing lists.
>>
>> To help answer questions about this I've written up some details  
>> and  put together a diagram which is now available on this page on  
>> the docs  site:
>>
>> http://docs.ofbiz.org/display/OFBADMIN/Component+and+Component+Set+Dependencies
>>
>> All committers should understand this pattern, and of course we  
>> should  refine it over time. Hopefully this will help us have, and  
>> understand,  a little more order in our efforts to organize  
>> components.
>>
>> Please send along comments! This is a first draft and I'd like to  
>> discuss it and such so we can move toward following the patterns  
>> and  making this a "policy" of sorts.
>>
>> -David
>

[Jacques Le Roux]

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

>
> On Nov 15, 2008, at 6:23 AM, Jacques Le Roux wrote:
>
>> IMO It seems complete and good enough to be put somewhere in "OFBiz  Technical Documentation" rather than in OFBiz Project
>> Administration  Workspace
>
> Why would this go in the technical documentation space? It has nothing  to do with technical things like the framework and
> programming.  Actually it's nearly completely about the base applications and stuff  above that. In other words, the project admin
> space is the final place I intend  for it. The project admin space is not some temporary place for things  that may eventually
> move to other spaces, like the wiki space is, it  is a place for controlled documentation about administration of the  project,
> including "policies", practices, recommendations,  introductory materials, keeping track of people and libraries, and so  on. This
> fits in perfectly there, IMO.
>
>> BTW should we not try to organize ourselves to better organize the  documentation in Wiki ?
>> Some months ago, I began to do it in the open part (The Open For  Business Project Wiki) by trying, as much as possible, to
>> create a  tree from Home there.
>
> Yes, it is a good thing to organize and make things more accessible.  It's always difficult though... unless it is simple and
> there is a  "natural" way to organize things, or an existing organization you can  just follow, then you have the problem where
> one man's organization is  another man's total chaos.
>
> The above is a good example... ;)

Indeed :o)

One old rule I always try to remember, is not to have too much deep in documentation trees (remember the macintosh UI rule : no more
than 3 nodes before a in menus)
We could try to group things a bit, to have a less sparse documentation. I agree that how to group things is sometimes subjective...
BTW, same idea for our menus in UI, some regroupment and vertical menus could help.

Jacques

>
> -David
>
>
>> From: "David E Jones" <[hidden email]>
>>>
>>> This is a topic that came up at the conference, and has come up  over  time on the mailing lists.
>>>
>>> To help answer questions about this I've written up some details  and  put together a diagram which is now available on this
>>> page on  the docs  site:
>>>
>>> http://docs.ofbiz.org/display/OFBADMIN/Component+and+Component+Set+Dependencies
>>>
>>> All committers should understand this pattern, and of course we  should  refine it over time. Hopefully this will help us have,
>>> and  understand,  a little more order in our efforts to organize  components.
>>>
>>> Please send along comments! This is a first draft and I'd like to   discuss it and such so we can move toward following the
>>> patterns  and  making this a "policy" of sorts.
>>>
>>> -David
>>
>

[Jacques Le Roux]

Oops, a word missing below.

[snip]
> One old rule I always try to remember, is not to have too much deep in documentation trees (remember the macintosh UI rule : no
> more than 3 nodes before a in menus)
[snip]

One old rule I always try to remember, is not to have too much deep in documentation trees (remember the macintosh UI rule : no more
than 3 nodes before a leave in menus)

Jacques
PS : (for BJ) I remember having read a document with such rules in early nineties, maybe it's still available. Old rules are not
always gold rules, some are.