View stunning SlideShares in full-screen with the new iOS app!Introducing SlideShare for AndroidExplore all your favorite topics in the SlideShare appGet the SlideShare app to Save for Later — even offline
View stunning SlideShares in full-screen with the new Android app!View stunning SlideShares in full-screen with the new iOS app!
Support for Portal features such as portlet communication, business user configuration, auto-deploy, single sign-on
“ Dynamic profiling” capability, to create multiple variations from a single set of source portlets
WebSphere Portlet Factory Rapid Portlet Creation and Customization Tooling IBM WebSphere Portlet Factory simplifies & accelerates the development, deployment, maintenance, and reuse of custom portlets and applications.
Expand Portlet Creation to developers of all skill level
Captures Design Patterns/Standardize Development Model
Lots of adapters
Strong XML/Web Service support
Code generation technology protects investment
Protecting against backend product upgrades
New vocabulary (learning curve)
Complex application, process intensive
There are so many choices? Portlet API JSF Framework Struts Portlet Framework Struts 2.0 My Servlet Framework There may be many valid and not so valid reasons to consider. Portlet Factory Spring 2.0 Apache Bridge
Don’t really need to understand to use Portlet MVC, but it is helpful.
From Spring Documentation:
The basic principle behind Dependency Injection (DI) is that objects define their dependencies (that is to say the other objects they work with) only through constructor arguments, arguments to a factory method, or properties which are set on the object instance after it has been constructed or returned from a factory method. Then, it is the job of the container to actually inject those dependencies when it creates the bean. This is fundamentally the inverse, hence the name Inversion of Control (IoC), of the bean itself being in control of instantiating or locating its dependencies on its own using direct construction of classes, or something like the Service Locator pattern.
It becomes evident upon usage that code gets much cleaner when the DI principle is applied, and reaching a higher grade of decoupling is much easier when beans do not look up their dependencies, but are provided with them (and additionally do not even know where the dependencies are located and of what actual class they are).