not sure if you look at the UI but there are permission you can use for which UI are available to which login via permissions and roles. as far as components you can hide a whole component in the web.xml and still have access to it.
The artifact in webtools lets you see association with services, eca, controller, UI the basic design is the entity controls the database and UI data. Christopher Snow sent the following on 2/7/2010 12:17 AM: > Also, splitting components down into small functional areas could have > the benefit that if you just want WorkEffort core + parties, you > wouldn't get the UI contributions from WorkEffort fixed assets. > > Development would be more difficult as you would be working across > multiple files. However, maybe the eclipse ofbiz IDE could provide a > consolidated view? > > Cheers, > > Chris > > Christopher Snow wrote: >> Good work Bruno! I'm putting some thought into the dependency issues >> - I will provide some more feedback when I have a clearer view. >> However, my current view is this: >> 1) Developers should be able have a standalone framework >> 2) Developers should be able to install components to meet certain >> functional areas without having to install most of the other >> components. E.g. install WorkEffort as a standalone component without >> having to install Accounting, Party management, etc. >> >> The current implementation of ofbiz does not support (2) without >> breaking each component up into a number of smaller modules such as: >> >> WorkEffortCore module (has no external dependency) >> WorkEffortFixedAsset module (requires FixedAsset core module) >> WorkEffortParties module (requires Party core module) >> >> Option (2) would give maximum reuse of code and would facilitate >> developers in learning ofbiz as they would only need to focus on the >> business processes within those modules. >> >> Anyway, I'm going to play around with the above concept when I have >> time... >> >> >> Bruno Busco wrote: >>> The complete url for the confluence page is: >>> http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution >>> >>> >>> >>> 2010/2/6 Bruno Busco <[email protected]>: >>> >>>> I have updated the framework-only confluence page with an excel sheet >>>> that we could use to track the dependecies issue down. >>>> http://cwiki.apache.org/confluence/download/attachments/9373097/OFBIZ+COMP+DEPENDENCIES.xls?version=1 >>>> >>>> >>>> Hope this helps. It is not yet completed. >>>> Please fille free to contribute to update it. >>>> The black "X" are dependecies that we want in the code base. >>>> The red "X" are dependencies that are there but should not. >>>> >>>> -Bruno >>>> >>>> 2010/2/6 Matt Warnock <[email protected]>: >>>> >>>>> On Fri, 2010-02-05 at 23:42 -0800, Adrian Crum wrote: >>>>> >>>>>> Chris, >>>>>> >>>>>> Framework independence has been a goal for quite a while. There is no >>>>>> disagreement that the framework should run on its own. The >>>>>> disagreements arise in what constitutes the framework. >>>>>> >>>>>> Let's assume for a moment that framework independence means >>>>>> running the >>>>>> components in the framework folder independently from anything >>>>>> else in >>>>>> OFBiz. Right away the problem with that idea is that visual >>>>>> themes are >>>>>> in a separate folder outside the framework folder. Does framework >>>>>> independence include the visual themes folder? That has not been >>>>>> discussed. Then there are the multitude of dependencies upon the >>>>>> applications folder. >>>>>> >>>>> I'm a newbie here, but I have a lot of gray hair. Seems like >>>>> trying to >>>>> separate dependencies by folder or subject matter is an exercise >>>>> doomed >>>>> to failure. >>>>> >>>>> TCP/IP has taken over the world because it has a clear model based on >>>>> separate layers (the 7-layer OSI model). Changes on one level (like >>>>> 10-base-T, to 100baseTX to Gigabit to 802.11a/b/g/n) don't affect the >>>>> rest. Likewise, you can use LDAP, NIS, DNS, /etc/hostnames, or other >>>>> means to map IP addresses to hostnames at the application layer-- >>>>> TCP/IP >>>>> doesn't care. >>>>> >>>>> >>>>>> From my perspective, achieving this objective will require a two >>>>>> pronged approach: 1) Identify the framework dependencies on outside >>>>>> components, and 2) avoid introducing new framework dependencies on >>>>>> outside components. >>>>>> >>>>> This assumes the "framework" is the lowest level. If the framework >>>>> depends on outside components, then the hierarchy has been upset, and >>>>> spaghetti dependencies are the inevitable result. Dependencies >>>>> HAVE to >>>>> be unidirectional, or you never get out of the maze. IMHO, the >>>>> biggest >>>>> problem with MVC is that it has never seemed to me that the layers are >>>>> very well defined. Everything seems pretty interdependent, and you >>>>> quickly get into a rock/paper/scissors kind of analysis, as you >>>>> describe. >>>>> >>>>> Is there a comprehensible map of the layers in OFBiz? All I have seen >>>>> is very detailed charts that seem to obfuscate, rather than >>>>> clarify, the >>>>> relationships of the various modules. But I'm sure I have not seen >>>>> everything. Is there a 30,000-foot overview of the software levels? >>>>> >>>>> >>>>>> The first prong can be accomplished through contributions from people >>>>>> like you - find the dependencies and create patches to fix them. >>>>>> >>>>>> The responsibility of the second prong is up to the committers. We >>>>>> need >>>>>> to be more vigilant to guard against introducing new dependencies. >>>>>> >>>>> Which requires a clear model of what layer the code under >>>>> consideration >>>>> belongs to, and what are the well-defined layers below it that can be >>>>> dependencies. >>>>> >>>>>> Personally I believe it will be possible, BUT it won't be easy. The >>>>>> obstacles to overcome will be getting people to contribute to the >>>>>> effort, and getting committers to avoid introducing new >>>>>> dependencies. >>>>>> >>>>> Again, I think we need to reduce the learning curve by providing clear >>>>> maps. You shouldn't need to know everything to be able to contribute >>>>> meaningful and error-free code. >>>>> >>>>>> -Adrian >>>>>> >>>>>> >>>>>> --- On Fri, 2/5/10, Christopher Snow <[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> From: Christopher Snow <[email protected]> >>>>>>> Subject: what a mess! is framework independence ever going to be >>>>>>> possible? >>>>>>> To: [email protected] >>>>>>> Date: Friday, February 5, 2010, 10:58 PM >>>>>>> I'm back to the process of working >>>>>>> out how to get a standalone framework running based on >>>>>>> trunk, but I have found that the dependencies have got out >>>>>>> of hand (if I've understood the code right): >>>>>>> >>>>>>> Framework depends on Themes >>>>>>> Themes depends on Content >>>>>>> Content depends on Party >>>>>>> >>>>>>> The questions I'm starting to ask myself are: >>>>>>> >>>>>>> "Is is ever going to be possible to have framework >>>>>>> independence in trunk? Independence in 9.04 is >>>>>>> relatively trivial (rewrite security screens) perhaps the >>>>>>> most sensible thing would be to do a fork of 9.04 and then >>>>>>> back port all framework related commits from trunk? " >>>>>>> >>>>>>> Any ideas anyone? >>>>>>> >>>>>>> Many thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> -- >>>>> Matt Warnock <[email protected]> >>>>> RidgeCrest Herbals, Inc. >>>>> >>>>> >>>>> >> > >
