In the project which was ended long before, worked as a front-end developer, I faced the challenge that I needed to develop a suitable workflow for front-end development in AEM context. Besides the three well-known mundane front-end technologies – HTML, CSS and JavaScript, I managed to get another two good helpers – AngularJS and LESS, which were really great tools and contributed a lot to the final success of the project.

AngularJS

What is it?

Well, you can visit its website: https://angularjs.org/

Why use it?

In AEM context, basically what developers do is creating all kinds of ‘controls’ which package the appearance and functionalities inside. That means every control may have its own HTML makeup, CSS styles and JS code. As a result, there is obviously an intrinsic requirement for front-end developers that the code should be modularized.

There are a large number of solutions for front-end modularization. However, in my mind, as a rookie in this area, the most important criteria for selecting is – Popularity. If a technology is popular, then we can confirm two things: 1) the documentation won’t be too bad; 2) there are a large number of masters in the local and online communities, from whom we can ask for help when we are in trouble.

Tips

There’re many knowledge points in AngularJS, but we don’t need to know everything if our goal is just modularization. In that case, we just need to pay attention to a few things:

• Controller. Very basic concept.
• Data-binding. This is necessary because we want to let controls have data abstraction and encapsulation.
• Directive. We need to separate HTML markup for a controller from the whole page, and use customized tag to embed it. This is done by directive. Also, I believe this is one of the most wonderful feature of Angular.

In our case, we didn’t touch any topic at all, such as routing, service, and the inside process of compile, link and digest. All of them are very valuable topics to learn, of course, but since most of our team members are junior, being able to avoid involving too much unfamiliar knowledge was certainly very positive to make sure we could do current job well.

Learning Resources

Besides the official documentation, I found two MOOC (what is MOOC?) courses are very good:

• Shaping Up with AngularJS @ Code School
• 面向对象软件开发实践之专业技能训练 @ 网易云课堂

Both of them cover a lot of useful skills.

LESS

What is it?

Well, you can visit its website: http://LESScss.org/

Why use it?

The major jobs of LESS are achieving two things: CSS modularization and dynamic theme.

LESS is easy, intuitive and helpful. Conceptually, it’s just a CSS preprocessor which is very easy to understand. Practically, to use it in page, what we need to do is just changing the CSS file’s extension from CSS to LESS, and adding a script reference to its compiler. Syntactically, a very good feature of LESS is its compatibility with raw CSS, which means if you don’t know how to write code in LESS, you can just leave it as CSS.

In our project, the most valuable reward LESS offered was the ability to dynamically change the CSS theme of a page, it was quite challenging to achieve it in raw CSS, however in LESS, it’s a piece of cake. Details will be cover in the following section.

Tips

Merge all the styles into a single file

This also can be done in other ways, for example, build tools like Grunt or Gulp. But utilizing the build-in @import directive in LESS is more or less an intuitive way and easy to modify.

In our project, we imported LESS files for pages and components into a single style.less. In development stage, we linked this file directly into pages, so that we could modify and simply refresh the page to see the result, which I believe was the most comfortable way of coding; in release version of the pages, we replaced the .less file with a compiled .css (using task in Grunt script), so it would not impact the performance of the page.

Achieve dynamic theme changing

In a user’s perspective, dynamically changing theme means you can change a theme (e.g. from ‘theme-orange’ to ‘theme-red’) by simply change the class name on ‘body’ element.

This is done by mix-in feature of LESS. We have this mix-in:

In this code, you can see we defined three themes, ‘theme-orange’, ‘theme-red’ and ‘theme-white’.

In LESS code, you can use the mix-in this way:

Here the code means in ‘theme-orange’ it gives the elements (selected by this selector) an orange background, in ‘theme-red’ it gives a red one, and in ‘theme-white’ it gives a white one. The order of these themes is defined by the order of parameters in the mixed-in definition. Apparently, this syntax is extremely intuitive, and even a beginner can take up this task without difficulties.

Conclusion

It’s really a great journey to beat down all the major obstacles, and finally developed a successful product for clients. It’s even more amazing that we ourselves could learn some knowledge, pick some new skills and step forward to become better programmer. My team members and I now can add these two skills to our personal arsenal, we felt confident and proud, not only because the exciting success in our project, but also the future usage promising in new coming AEM projects.

Recently our team was working on Veracity Quick Start sprint, when I was trying to migrate the JMS provider implementation from Tibco EMS to ActiveMQ, I found that there are notable differences between these two JMS implementations on their JNDI support, which will be illustrated below.

1.  Code demonstration

The following codes show a main function which uses Java JNDI API to retrieve JMS queue and topic. We will try each implementation by putting relevant INITIAL_CONTEXT_FACTORY and PROVIDER_URL into the props object.

public class Main {

        public static void main(String[] args) throws Exception {

                        Properties props = new Properties();

                        // ActiveMQ

//                      props.put(Context.INITIAL_CONTEXT_FACTORY, “org.apache.activemq.jndi.ActiveMQInitialContextFactory”);

//                      props.put(Context.PROVIDER_URL, “tcp://localhost:61616”);

                        // Tibco

                        props.put(Context.INITIAL_CONTEXT_FACTORY, “com.tibco.tibjms.naming.TibjmsInitialContextFactory”);

                        props.put(Context.PROVIDER_URL, “tibjmsnaming://localhost:7222”);

                        // create a new intial context

                        javax.naming.Context ctx = new javax.naming.InitialContext(props);

                        // lookup an existing topic

                        javax.jms.Topic myTopic = (javax.jms.Topic) ctx.lookup(“MyTopic”);

                        System.out.println(myTopic);

// lookup an existing queue

                        javax.jms.Queue myQueue = (javax.jms.Topic) ctx.lookup(“MyQueue”);

                        System.out.println(myQueue);

            }

}

2.  Try Tibco EMS

When using Tibco EMS, in order to let the codes run successfully, we need to retrieve myTopic and myQueue objects:

1) There must be a Tibco JMS server running on localhost: 7222.

2) A topic named MyTopic and a queue named MyQueue must already be defined.

No other configuration files needed.

3.  Try ActiveMQ

When you try ActiveMQ (uncomment line 5 and 6, and comment line 9 and 10), things are little different:

1) You don’t need to have MyTopic and MyQueue already exists on ActiveMQ server.

2) You even needn’t have a server running at localhost: 61616.

3) Put a jndi.properties file on your class path, in which you have already predefined the wanted queues and topics:

java.naming.factory.initial = org.apache.activemq.jndi.ActiveMQInitialContextFactory

java.naming.provider.url = tcp://0.0.0.0:61616

# register some queues in JNDI using the form

# queue.[jndiName] = [physicalName]

queue.MyQueue = example.MyQueue

# register some topics in JNDI using the form

# topic.[jndiName] = [physicalName]

topic.MyTopic = example.MyTopic

Or use a little different syntax when you invoke lookUp in your java codes: use dynamicTopics/MyTopic instead of MyTopic, and use dynamicQueues/MyQueue instead of MyQueue.

4.  Conclusion

I checked the documentation of these two products, also relevant sections in the book ActionMQ in action, and figured out the differences about their JNDI capability:

1) Tibco EMS implements a server-side JNDI provider, you actually need to communicate to server to get your defined queues and topics.

2) ActiveMQ implements a client-side JNDI provider, no communication with server is needed.

When you get queue or topic object by passing a name to lookUp(), it doesn’t mean they already exist on server, or they will be created at that moment. ActiveMQ queues and topics are dynamically created when you actually use them, for example, when you actually send a message to a queue.

Suffice to say, the JNDI support is completely local and has nothing to do with server.