Projects tagged ‘dependencyinjection’ and ‘ioc’

JGentle's features are referred to as Inversion of Control (IoC) Container or Lightweight Container. The adoption of JGentle in an application ensures the use of certain design principles which ... [More] improve encapsulation, modularization, testability and reusability, offering configuration via Dependency Injection, Definition Management, Annotation Injection, and declarative services via AOP (Aspect Oriented Programming). [Less]

DotNet dependency injection internal DSL. Separates application wiring from classes, making objects into building blocks.

GWToolboxWelcome to the GWToolbox project. The GWToolbox project provides a collection of modules to help developers create robust web 2.0 / Ajax applications using the Google Web Toolkit (GWT). ... [More] Current modulesCurrently the following modules are provided: gwtoolbox-commons: A library with common utility classes which are used by other modules and can also be used by other GWT applications. This collection of utilities is largely based on common Java Open Source projects (e.g. Spring, apache commons, etc..) gwtoolbox-bean: A library that brings the power of Java bean programming to GWT applications. Constructs like PropertyDescriptor, BeanInfo, and PropertyChangeListeners can now be used and applied transparently on a simple GWT Java bean. This module also comes with bean binding and validation support. gwtoolbox-ioc: This module bring IoC to GWT applications. Heavily based on Spring, users can now define all object/widgets/components of their GWT application within Spring application context and wire them declaratively. This is now yet another Spring-like ioc container, but rather a container that can read actual Spring configuration files. This brings along many of the power tools Spring comes with: AspectJ-like AOP support, bean life-cycle management (including lazy/eager initialization), scopes (singleton/prototype), and even Spring namespaces. Users can now create proprietary namespaces for their GWT components. Modules in developmentThe following modules are currently in development: gwtoolbox-widget: A set of generic model based widget classes with concrete implementations of bean backed models. These widgets/models highly depend on the gwtoolbox-bean module. Getting startedTake a look at our Getting Started Guide to get started using GWToolbox to build better GWT applications. Quick StartTo quickly create a GWToolbox based project, you can use the following link. This will redirect you to a form which will help you create an initial maven2 project using a dedicated maven archetype: http://gwtoolboxarchetype.appspot.com [Less]

SmartyPants IOCWelcomeWelcome to the main repository for SmartyPants IOC, which is a dependency injection framework designed for use with Adobe Flex. Why SmartyPants?There are a few IOC frameworks ... [More] around at the moment: Prana (now Spring Actionscript) was probably the first serious DI framework for Flex to get much notice. There's also Swiz, and others. What sets Smartypants apart from these frameworks? The competition is (mostly) inspired by Spring, whereas SmartyPants is inspired by Guice. This is simply my preference, it may or may not be yours. SmartyPants-IOC is just for dependency injection. You may use any application framework you please. I recommend RobotLegs AS3. It does things the way I like, and you can even replace SmartyPants with another injector if you need to. SmartyPants defines the bindings / application structure via ActionScript code, not via XML. Again, this is a stylistic preference. Put your run-time configuration in configuration files, not in your application structure. Injection requests are specified with annotations, like Guice, Spring 2(.5?), and Swiz. You can also use a similar DSL to request instances from the injector. SmartyPants provides live injection - think "the love child of regular dependency injection and Flex data-binding" Getting startedDownload the .swc file from here, or checkout the code via SVN. The project is young, and the docs are growing, but grow they will! Check out the wiki here, or join the discussion group if you'd like to know more. The !ASDocs are currently offline but will return very shortly! A simple example [Less]

Lightweight dependency injection solution for ActionScript 3

A simple, lightweight Python dependency injection framework based on google-guice.

Simple template based Dependecy Injection framework for C++.

I always dreamed of composing applications from collaborating independent parts. That's what I think object-oriented programming was supposed to be about. These libraries are my ongoing effort to ... [More] achieve that dream. NOTE: This is a work in progress hence no release versions or downloads are available yet and some APIs are likely to change. NOTE: Documentation is forthcoming. NOTE: You need Maven 2.0.9+ to build or (conveniently) use these libraries. Getting the CodeThe sources for these libraries can be checked out like so: $ svn checkout http://fluid-tools.googlecode.com/svn/trunk fluid-toolsBuilding the LibrariesOne of the essential Maven plugins in this project makes use of a feature in Apache BCEL that is available from version 5.3, namely Java 5 annotation support. Before you can build these libraries, you will need to check out the BCEL trunk and build it yourself: $ svn checkout http://svn.apache.org/repos/asf/jakarta/bcel/trunk bcel $ (cd bcel; mvn install)From then on, you use Maven to build these libraries: $ cd fluid-tools $ mvn installDoing that for the first time will take a while as Maven downloads and caches in your file system the various libraries needed to run Maven and to compile Fluid Tools. As Fluid Tools evolves, there may sometimes be a need to do a clean build. In fact, it is safe to do that every time you update your working copy. To get a clean build, you simply do $ mvn clean installHowever, a pedantic clean build consists of first clearing the cached libraries from your local Maven repository: $ cd $HOME/.m2/repository $ rm -rf org/fluidityNOTE: the commands above assume you are working on a Unix system. Windows users will need to figure out how to achieve the same effects in their individual development enviroment. TODO: Deployment modules Move all deploy* classes to the deployment modules Deployer application in executable .war inside package Control centre discovery protocol Heartbeat protocol Service announcement protocol Service activation protocol Monitoring extension API (client) Management extension API (server) Find ways to make modules self-documenting both for human readers and for automated dependency resolution See how to make the build fail when not all dependencies can be resolved from the modules packaged into the application ... [Less]

The imind-php library is a set of classes, that extend Zend Framework and Doctrine. It also contains a dependency injection library and a javascript/css builder. Parts of the library: ... [More] Imind_Context: a dependency injection library Imind_Build: building minimized and cacheble js and css files (using YUICompressor) and outputing them using a proxy or view helpers Imind_Version: working with version numbers (eg: 1.0.1) Imind_Auth_Adapter_DoctrineTable: authentication using a Doctrine Table Imind_Profiler_Doctrine_Firebug: providing Doctrine profiling information through Firebug and FirePHP Controller Action Plugins: Imind_Controller_Plugin_Auth: an authentication plugin Controller Action Helpers: Imind_Controller_Action_Helper_Raw: sending raw output from a controller action Imind_Controller_Action_Helper_BuildProxy: js or css urls sent out with HeadLinkProxy::merge or HeadScriptProxy::merge, can be processed and sent out from a controller action View Helpers: Imind_View_Helper_HeadLinkProxy: css files built by Imind_Build can be inserted into views Imind_View_Helper_HeadScriptProxy: js files built by Imind_Build can be inserted into views There is an article about integrating Zend Framework and Doctrine together by Ruben Vermeersch here: http://ruben.savanne.be/articles/integrating-zend-framework-and-doctrine For bugs, features and questions use the Google group imind-php. [Less]

PocoCapsule is an Inversion of Control (IoC) container, a.k.a Dependency Injection (DI) framework (see article IoC vs DI), as well as a Domain Specific Modeling (DSM) engine (see article DSM in IoC). ... [More] The main goals of PocoCapsule are to support declarative assemblying/deploying/configuring of component-based C/C++ applications and also to provide a platform that can easily be used even by domain users to quickly build other component frameworks in a descriptive modeling approach. PocoCapsule is non-invasive and enforces neither a proprietary component programming model (such as their base classes or a set of pre-defined methods) nor any component-container couplings (such as registry or context lookup). It accepts container-agnostic plain-old C/C++ objects (POCO) as components. Examples of such components include instances of arbitrary C++ classes, template classes (such as all STL container classes), K&R structs, arrays, and even functions (as function pointers). PocoCapsule supports almost all useful IoC invocation scenarios regardless the numbers of their value/reference inject arguments (in various types, aggregated types, and even user defined types). These invocations include: Constructors (and destructors in lifecycle control) of arbitrary C++ classes/structs/unions/arrays. Global C or C++ functions, operators, and variables. Non-static member functions and operators of C++ classes/structs. Static member functions of C++ classes/structs. Non-static data members of C++ classes/structs. Static data members of C++ classes/structs. Union field accesses. Array (as well as C++ classes/structs with index operator) indexed accesses. PocoCapsule supports component lifecycle control with any of the following methods specified by user: constructors of C++ classes/structs/unions/arrays global or static factory methods non-static factory methods of factory-beans global or static ref duplicate methods non-static duplicate methods of the beans themselves global or static ref release/destroy methods (and destructors) non-static ref release/destroy methods of destroy-beans. non-static release/destroy methods of the beans themselves. PocoCapsule ensures type safety. All type conversions are validated statically in building dynamic invocation proxies. The dynamic reflection engine only uses proxies that exactly match the signatures of IoC invocations. PocoCapsule supports dynamic wiring that allows application to be deployed without immediately being wired with dependent services. These services can be wired or rewired to applications transparently after or upon they (these services) become available or being replaced. PocoCapsule seamlessly supports user-defined domain specific modeling schemas through model transformations. These DSM schemas describe applications architectures at higher abstraction levels. This mechanism not only largely avoids problems of the verbose, error-prone, and primitive core IoC schema but also makes the PocoCapsule a framework that can be used by domain users to quickly and easily build other user-defined or committee-designed component frameworks. Several such DSM frameworks are presented in PocoCapsule out-of-the-box or from third parties, such as: PocoCapsule for WebServices: supports wiring and deployment of component-based WebServices applications. It also includes an implementation of the OpenSOA's SCA (now OASIS OpenCSA) assembly container (SCA as a DSM). See the article and examples. PocoCapsule for robotic systems: supports wiring and configuring of robotic component applications. It also includes an assembly model for OMG-RTC applications. See the article and examples in user-defined component model and OMG-RTC component model. PocoCapsule for SDR: supports wiring and configuring of software defined radio (SDR) waveform applications. It also includes an implementation of the assembly container of JTRS-SCA core framework (CF). See the article and examples in both non-CORBA non-JTRS-SCA models and JTRS-SCA (CF) component and assembly models. PocoCapsule for OMG-DDS: A deployment model for component based OMG Data Distribution Service (OMG-DDS) applications. See the example. PocoCapsule for CORBA: (available from Pocomatic Software) supports assembly and deployment of component-based CORBA server and OMG-Event/Notification applications. See examples PocoCapsule is portable to almost all Unix/Windows and realtime embedded operating systems (such as VxWorks and Symbian OS). The 1.0 source code can be built on Linux, Solaris, Windows, and VxWorks out-of-the-box. [Less]