On Oct 1, 2013, at 3:37 PM, Barry Books wrote: > The distributed configurations craeated by things like > contibuteTranslatorSource > > On Tuesday, October 1, 2013, Thiago H de Paula Figueiredo wrote: > >> On Tue, 01 Oct 2013 10:12:29 -0300, Barry Books <trs...@gmail.com> wrote: >> >> I have looked at those. What I'm really searching for is how to get the >>> IOC configurations. At this point I'm ok with private methods >>> >> >> What do you mean by IoC configurations? Symbol values? Distributed >> configuration?
Some time ago I tried a similar thing but without no luck (see [1]), but I think still think that some effort should be invested to fill the "Distributed Documentation" gap. My main motivations for working towards filling that gap are the following: - Provide better knowledge to developer when the T5 distributed approach to configuration will increase over the "single"-man capability limit. Imagine that you use several modules provided by different parties that have mixed configurations (some of them overwriting defaults, and other modules' settings) and that rely on "Meta"-level constraints, such as, for example invocation orders. In such a case, developers may have hard time to figure out why the application does not work, and also why it works :) - Provide better tooling (yes, Documentation belongs to the *development tools* category ;) ) to involve more people into T5, and to "design" guidelines (or at least sketch trails) for app development (and eventually to reduce the learning curve steepness). More practically it may be easier to start from common scenarios (from development point of view) and see how/if they can be addressed. For example, depending on your needs it can be useful, given an application under development composed of code and libs/jars to know: - at module level: what are the modules, submodules, and relative dependencies - at module-service level: which module builds/provides/configure a given service, what are the services "touched" by a module - at service level: what are the dependencies of a given service ? what and where a service gets contributed ? what type of service is (Chain ? Pipeline ? etc.? ) Advisors: - What "advisors" are defined ? where do they impact ? For the web part: - what pages and components are provided by a module ? - What are the dependencies of each page, component ? - What events does a page/component listen to? what are the(exposed) properties of a page/component ? ... Of course we can go deeper in the description of each single entity: - If the service is a chain, what is the order of its contributions ? - Does a contributed service act before, after or both compared to it's delegate ? Hope we can figure out what are the really important information to disclose to developers and what are information of limited value. Cheers -- Alessio [1] http://mail-archives.apache.org/mod_mbox/tapestry-dev/201212.mbox/thread : "Gathering some knowledge about T5" http://mail-archives.apache.org/mod_mbox/tapestry-dev/201212.mbox/%3c5eb21da0-78db-46a3-bafc-686b4a38e...@gmail.com%3E >> >> -- >> Thiago H. de Paula Figueiredo >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >>
