Tech Weby

We use this Pattern when we require don't want to give a direct access to object under some scenario and rather offer a surrogate object  or proxy object which  provides the functionality in place of the real object. There could be several scenario where we would want this kind of functionality. The  real object  has some sensitive operation which would be risky to expose. The real object creation is memory extensive so we want to control the behavior of its creation. The real object is remotely located and rather we want to interact through a local copy using proxy which is actually   aware of it location. So lets look at the UML diagram of the same. So here we have Subject interface which is implemented by both the Proxy and RealObject  and proxy object has  reference to the real object , now the client will  instantiate Proxy object to perform some action and , proxy object will delegate the call to RealSubject to perform the same.

Bridge design pattern which is also a structural design pattern is a pattern where you can decouple the abstraction and implementation using a bridge so that both can vary without effecting each other. Let’s take the above class diagram as our use case where a circle can be drawn in different colors using the same abstract class method but different bridge implementer’s class. So here we have abstract class shape and it has method draw which can vary, so we have abstracted it out to an interface using aggregation to bridge interface "DrawAPI" and it is responsibility of its implementer’s to draw different color circle.   ** "Bridge Implementor" */ interface DrawingAPI {     public void drawCircle(final double x, final double y, final double radius); } /** "ConcreteImplementor"  1/2 */ class DrawingAPI1 implements DrawingAPI {     public void drawCircle(final double x, final double y, final double radius) {         System.out.printf("AP

Sling Pipes is a new tool which can extract, transform and load the underlying content using set of configuration. Here you can load a resource tree based on a pipe, a pipe can have an input a reader/writer or container pipes. A pipe is nothing but a jcr node which has some distinctive characteristics. ·          sling:resourceType property – Must be a pipe type registered by the plumber ·          name property – Used in bindings as an id ·          path property – Defines pipe’s input ·          expr property – Expression through which the pipe will execute ·          additionalBinding node – Node you can add to set “global” bindings (property=value) in pipe execution ·          additionalScripts – Multivalue property to declare scripts that can be reused in expressions ·          conf child node – Contains addition configuration of the pipe There are three types of pipe container pipe which acts as a container for other two types of pipe reader and writer.

It is behavioral pattern which is used solve the problem how two object interact using the principle of abstraction to achieve certain goal.In this  pattern we have 4 main players  client ,invoker , command and receiver . Receiver : This Object has the actual algorithm to perform the task , which is abstracted from the outer world. Command : This Object has the reference of the Receiver class which it executes method on the receiver . Invoker :Is aware of the command to be executed , only executes the command on the command Object. Client : Keeps   invoker object and list of all the command objects and decides which command to execute when , client invokes the  particular command using the invoker object. So Switch is classic case of command design pattern  ,which is invoker class and has the list of all the commands to be executed and we have command interface with a execute method now we can have two implementation of the Command interface switchON and switchOff which will

Component are those classes which are marked with @Component annotation and whose life cycle is managed by felix.  A component is an active participant in the OSGi system , a component can be reinitialized through osgi properties through the methods annotated in the class using the activate and deactivate methods. In order to mark class as component in  aem ecosystem provide @component annotation provided through java package "org.apache.felix.scr.annotations.Component".Please refer the example below. Code sample are for illustration purpose only Following are annotation used are some of basic annotation which should always be used while you are creating component. @label-This is generally used as a title for the object described by the meta type. @description-This is generally used as a description for the object described by the meta type. @metatype-If marked as true it will create a metatype.xml within meta type folder in meta-inf folder in bundle and als

In AEM 6.0 version, as part of social communities’ project AEM implemented a handlebar script files in place of JSP scripts.  As part of this project AEM SCF community implemented a handle bar engine which in turn uses handlebars.java(jknack) library to compile and execute handlebar templates. Example: Let’s say I have a component called helloworld and the path of component  is  /apps/mysite/components/content/helloworld. Below three steps we need to do to implement header component. 1.       Register a HBS component To register HBS component we need to implement SocialComponentFactory interface and then we need to override methods. In “getSupportedResourceType” method we need to return component path to register it to handlebar engine.  Once we register a component json response will automatically available to handlebar script file. Example: The key aspect is to override getSocialComponent method(Resource).