How-To Tutorials

article-image-geronimo-architecture-part-2

13 Nov 2009

10 min read

Geronimo Architecture: Part 2

13 Nov 2009

0
0
1841

article-image-geronimo-architecture-part-1

Packt

13 Nov 2009

8 min read

Geronimo Architecture: Part 1

Packt

13 Nov 2009

8 min read

Inversion of Control and dependency injection Inversion of Control (IoC) is a design pattern used in software engineering that facilitates the creation of loosely-coupled systems. In an IoC system, the flow of control is inverted, that is, the program is called by the framework—unlike in normal linear systems where the program calls the libraries. This allows us to circumvent the tight coupling that arises from the control being with the calling program. Dependency injection is a specific case of IoC where the framework provides an assembler or a configurator that provides the user program with the objects that it needs through injection. The user program declares dependencies on other services (provided by the framework or other user programs), and the assembler injects the dependencies into the user program wherever they are needed. It is important that you clearly understand the concept of dependency injection before we proceed further into the Geronimo architecture, as that is the core concept behind the functioning of the Geronimo kernel and how services are loosely coupled in it. To help you understand the concept more clearly, we will provide a simple example. Consider the following two classes: package packtsamples;public class RentCalculator{ private float rentRate; private TaxCalculator tCalc; public RentCalculator(float rate, float taxRate){ rentRate = rate; tCalc = new ServiceTaxCalculator(taxRate); } public void calculateRent(int noOfDays){ float totalRent = noOfDays * rentRate; float tax = tCalc.calculateTax(totalRent); totalRent = totalRent + tax; System.out.println("Rent is:"+totalRent); }}package packtsamples;public class ServiceTaxCalculator implements TaxCalculator{ private float taxRate; public ServiceTaxCalculator(float rate){ taxRate = rate; } public float calculateTax(float amount){ return (amount * taxRate/100); }}package packtsamples;public interface TaxCalculator{ public float calculateTax(float amount);}package packtsamples;public class Main { /** * @param args. args[0] = taxRate, args[1] = rentRate, args[2] =noOfDays */ public static void main(String[] args) { RentCalculator rc = new RentCalculator(Float.parseFloat(args[1]),Float.parseFloat(args[0])); rc.calculateRent(Integer.parseInt(args[2])); }} The RentCalculator class calculates the room rent including tax, given the rent rate, and the number of days. The TaxCalculator class calculates the tax on a particular amount, given the tax rate. As you can see from the code snippet given, the RentCalculator class is dependent on the TaxCalculator interface for calculating the tax. In the given sample, the ServiceTaxCalculator class is instantiated inside the RentCalculator class. This makes the two classes tightly coupled, so that we cannot use the RentCalculator with another TaxCalculator implementation. This problem can be solved through dependency injection. If we apply this concept to the previous classes, then the architecture will be slightly different. This is shown in the following code block:> package packtsamples.di;public class RentCalculator{ private float rentRate; private TaxCalculator tCalc; public RentCalculator(float rate, TaxCalculator tCalc){ rentRate = rate; this.tCalc = tCalc; } public void calculateRent(int noOfDays){ float totalRent = noOfDays * rentRate; float tax = tCalc.calculateTax(totalRent); totalRent = totalRent + tax; System.out.println("Rent is:" +totalRent); }}package packtsamples.di;public class ServiceTaxCalculator implements TaxCalculator{ private float taxRate; public ServiceTaxCalculator(float rate){ taxRate = rate; } public float calculateTax(float amount){ return (amount * taxRate/100); }}package packtsamples.di;public interface TaxCalculator{ public float calculateTax(float amount);} Notice the difference here from the previous implementation. The RentCalculator class has a TaxCalculator argument in its constructor. The RentCalculator then uses this TaxCalculator instance to calculate tax by calling the calculateTax method. You can pass in any implementation, and its calculateTax method will be called. In the following section, we will see how to write the class that will assemble this sample into a working program. package packtsamples.di;import java.lang.reflect.InvocationTargetException;public class Assembler { private TaxCalculator createTaxCalculator(String className, float taxRate){ TaxCalculator tc = null; try { Class cls = Class.forName(className); tc = (TaxCalculator)cls.getConstructors()[0] .newInstance(taxRate); } catch (ClassNotFoundException e) { e.printStackTrace(); } catch (IllegalArgumentException e) { e.printStackTrace(); } catch (SecurityException e) { e.printStackTrace(); } catch (InstantiationException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } catch (InvocationTargetException e) { e.printStackTrace(); } return tc; } private RentCalculator createRentCalculator(float rate, TaxCalculator tCalc){ return new RentCalculator(rate,tCalc); } private void assembleAndExecute(String className, float taxRate, float rentRate, int noOfDays){ TaxCalculator tc = createTaxCalculator(className, taxRate); createRentCalculator(rentRate, tc).calculateRent(noOfDays);} /** * * @param args args[0] = className, args[1] = taxRate args[2] = rentRate args[3] = noOfDays */ public static void main(String[] args){ new Assembler().assembleAndExecute(args[0], Float.parseFloat(args[1]), Float.parseFloat(args[2]), Integer.parseInt(args[3])); }} In the given sample code, you can see that there is a new class called the Assembler. The Assembler, in its main method, invokes the implementation class of TaxCalculator that we want RentCalculator to use. The Assembler then instantiates an instance of RentCalculator, injects the TaxCalculator instance of the type we specify into it, and calls the calculateRent method. Thus the two classes are not tightly coupled and the program control lies with the assembler, unlike in the previous case. Thus there is Inversion of Control happening here, as the framework (Assembler in this case) is controlling the execution of the program. This is a very trivial sample. We can write an assembler class that is more generic and is not even coupled to the interface as in the previous case. This is an example of dependency injection. An injection of this type is called constructor injection, where the assembler injects values through the constructor. You can also have other types of dependency injection, namely setter injection and field injection. In the former, the values are injected into the object by invoking the setter methods that are provided by the class, and in the latter, the values are injected into fields through reflection or some other method. The Apache Geronimo kernel uses both setter injection and constructor injection for resolving dependencies between the different modules or configurations that are deployed in it. The code for these examples is provided under di-sample in the samples. To build the sample, use the following command: mvn clean install To run the sample without dependency injection, use the following command: java –cp di-sample-1.0.jar packtsamples.Main <taxRate> <rentRate><noOfDays> To run the sample with dependency injection, use the following command: java –cp di-sample-1.0.jar packtsamples.Assembler packtsamples.di.ServiceTaxCalculator <taxRate> <rentRate> <noOfDays> GBeans A GBean is the basic unit in Apache Geronimo. It is a wrapper that is used to wrap or implement different services that are deployed in the kernel. GBeans are similar to MBeans from JMX. A GBean has attributes that store its state and references to other GBeans, and can also register dependencies on other GBeans. GBeans also have lifecycle callback methods and metadata. The Geronimo architects decided to invent the concept of GBeans instead of using MBeans in order to keep the Geronimo architecture independent from JMX. This ensured that they did not need to push in all of the functionality required for the IoC container (that forms Geronimo kernel) into the JMX implementation. Even though GBeans are built on top of MBeans, they can be moved to some other framework as well. A user who is writing a GBean has to follow certain conventions. A sample GBean is shown below: import org.apache.geronimo.gbean.GBeanInfo;import org.apache.geronimo.gbean.GBeanInfoBuilder;import org.apache.geronimo.gbean.GBeanLifecycle;public class TestGBean implements GBeanLifecycle{ private String name; public TestGBean(String name){ this.name = name; } public void doFail() { System.out.println("Failed............."); } public void doStart() throws Exception { System.out.println("Started............"+name); } public void doStop() throws Exception { System.out.println("Stopped............"+name); } public static final GBeanInfo GBEAN_INFO; static { GBeanInfoBuilder infoBuilder = GBeanInfoBuilder .createStatic(TestGBean .class, "TestGBean"); infoBuilder.setPriority(2); infoBuilder.addAttribute("name", String.class, true); infoBuilder.setConstructor(new String[]{"name"}); GBEAN_INFO = infoBuilder.getGBeanInfo(); } public static GBeanInfo getGBeanInfo() { return GBEAN_INFO; }} You will notice certain characteristics that this GBean has from the previous section. We will list these characteristics as follows: All GBeans should have a static getGBeanInfo method, which returns aGBeanInfo object that describes the attributes and references of GBean as well as the interfaces it can implement. All GBeans will have a static block where a GBeanInfoBuilder object is created and linked to that GBean. All of the metadata that is associated with this GBean is then added to the GBeanInfoBuilder object. The metadata includes descriptions of the attributes, references, interfaces, and constructors of GBean. We can add GBeans to configurations either programmatically, using methods exposed through the configuration manager and kernel, or by making an entry in the plan for the GBean, as follows: <gbean name="TestGBean" class="TestGBean"> <attribute name="name">Nitya</attribute></gbean> We need to specify the attribute values in the plan, and the kernel will inject those values into the GBean at runtime. There are three attributes for which we need not specify values. These are called the magic attributes, and the kernel will automatically inject these values when the GBeans are being started. These attributes are abstractName, kernel, and classLoader. As there is no way to specify the values of these attributes in the deployment plan (an XML file in which we provide Geronimo specific information while deploying a configuration), we need not specify them there. However, we should declare these attributes in the GBeanInfo and in the constructor. If the abstractName attribute is declared, then the Geronimo kernel will inject the abstractName of the GBean into it. If it is the kernel attribute, then a reference to the kernel that loaded this GBean is injected. If we declare classLoader, then the class loader for that configuration is injected.

0
0
1523

Packt

12 Nov 2009

11 min read

Geronimo Plugins

Packt

12 Nov 2009

11 min read

0
0
2381

article-image-short-tour-through-nav-2009-part-3

Packt

11 Nov 2009

17 min read

A Short Tour through NAV 2009: Part 3

Packt

11 Nov 2009

17 min read

An introduction to NAV development As part of our study of NAV development tools and techniques, we are going to do some exercises here and there. There's no better way to learn than to try out the tools in an environment where you can't break anything important. We're going to do development work for a simple system. As discussed earlier, we will access C/SIDE through the Tools Object Designer| menu option, as shown in the following screenshot: Our scenario for development exercises Our organization is a small, not-for-profit one. The name is ICAN, which stands for International Community And Neighbors. We collect materials, mostly food, from those who can afford to share and distribute it to those who have difficulty providing for themselves or their families. A large company has supplied us with a small computer network and a three-user Microsoft Dynamics NAV 2009 system. We need to track the donations which come in. They may be items, money, or some type of in-kind services. If they are items, we will need to inventory them. We also need to track donors, volunteers, and the people on our "help list" (our clients). A variety of reports and inquiries will be needed. As with any application, new requirements are likely to arise as time goes by. And, in this case, since the purpose of our scenario is to act as a laboratory for experimenting with NAV development tasks, new requirements will arise so that we can do additional experiments. Getting started with application design Our design for the ICAN application will start with the initial design of a Donor table, a Donor Card Page, a Donor List Page, and a Donor List Report. Along the way, we will review the basics of each of these NAV object types. Application tables Table objects are the foundation of every NAV application. Every project should start by designing the tables. Tables contain the definitions of the data structures, the data relationships within and between the tables, as well as many of the data constraints and validations. The coded logic in a table triggers not only provides the basic control for the insertion, modification, and deletion of records, but also embodies many of the business rules for an application. Such logic isn't just at the record level but also at the field level. When we embed a large part of the application data handling logic within the tables, it makes the application easier to develop, debug, support, modify, and upgrade. Designing a simple table Let's create a simple Donor table for our NAV Donor application. First, we will inspect existing definitions for tables containing name and address information. Basic inspection is done by clicking on the Tables button in the Object Designer, then highlighting the desired table and clicking the Design button. Good examples are the Customer table (table object 18) and the Vendor table (table object 23). We see some field name and definition patterns that we will generally copy on the basis of "consistency is good". One exception to the copying will be the Primary Key field. In the other tables, that field is No., but we will use Donor ID, just to make all our examples stand out from views of standard code. The Donor table will contain the following data fields: Field names Definitions Donor ID 20 character text (code) Name 50 character text Address 50 character text Address 2 50 character text City 30 character text State/Provinc 10 character text Post code 20 character text (code) Country/Region code 10 character text (code) In the preceding data field list, three of the fields are defined as Code fields, rather than Text fields. This is because these will be referenced by or will reference to other data tables. Using Code fields limits the contents to a subset of the ASCII character set, making it easier to constrain entries to a range of values. The Donor ID will be a unique identifier for our Donor record as it will also be referenced by other subordinate tables. The Post Code and Country/Region Code will reference other existing tables for validation. We choose the name, size, and data definition of these last two fields based on inspecting the equivalent field definitions in the Customer and Vendor tables. We will have to design and define any referenced validation tables before we can eventually complete the definition of the Donor table. But our goal at the moment is just to get started. Creating a simple table Open the Object Designer, click on Table (in the left column of buttons) and click on New (in the bottom row of buttons). Enter the first field name (Donor ID) in the Field Name column and then enter the data type in the Data Type column. For those data types where length is appropriate, enter the maximum length in the Length column (for example text fields require lengths, date or numeric fields do not). Enter Description data as desired; these are only for display here as internal documentation. As you can see in the following screenshot (and will have noticed already if you are following along in your system), when you enter a Text data type, the field length will default to 30 characters. This is simply an 'ease-of-use' default, which you should override as appropriate for your design. The 30 character Text default and 10 character Code default are used because this matches many standard application data fields of those data types. Field numbering The question often arises as to what field numbering scheme to use. Various systems follow a variety of standard practices, but in NAV, when you are creating a new table from scratch, it is a good idea to increment the Field No. by 10, as you can see in the preceding screenshot. The default increment for Field No. is 1. For a group of fields (such as an address block) where you are certain you will never add any intervening fields, you could leave the increment at 1, but there is no cost for using the larger increment. The numeric sequence of fields determines the default sequence in which data fields will display in a wide variety of situations, especially in the Classic Client. An example would be the order of the fields in any list presented to the user for setting up data filters in the Classic Client. This default sequence can only be changed by renumbering the fields. The compiler references each field by its Field No. not by its Field Name, so the renumbering of fields can be difficult once you have created other routines that reference back to these fields. At that point, it is generally better to simply add new fields where you can fit them without any renumbering. General rule: Once a design has started to mature, don't renumber data fields. In fact, it can be irritatingly painful to renumber fields at any point after a table has been defined and saved. In addition to the field numbers controlling the sequence of presentation of fields, the field numbers control bulk data transfer (those transfers that operate at the record level rather than explicitly field to field transfer—for example the TRANSFERFIELD instruction). In a record-level transfer, data is transferred from each field in the source record to the field of the same number in the target record. Obviously, it's a good idea to define an overall standard for field numbering as you start. Doing so makes it easier to plan your field numbering scheme for each table. Your design will be clearer for you and your user, if you are methodical about your design planning before you begin writing code (try to avoid the Ready-Fire-Aim school of system development). The increment of Field No. by 10 allows you to insert new fields in their logical sequence as the design matures. While it is not required to have the data fields appear in any particular order, it is frequently convenient for testing and often clarifies some of the user interactions. When you have completed this first table, your definition should look like the following screenshot: At this point, you can exit and save your Donor Table. The easiest way to do this is to simply press Esc until you are asked to save your changes. When you respond by clicking on Yes, you will be asked for the object number and name you wish to assign. In a normal development situation, you will plan ahead what Object Number and descriptive Object Name you want to use. In this case, we will use table Object No. 50000 and name it Donor. We are using 50000 as our Table Number just because it is the first (lowest) number available to us for a custom table through our Table Designer granule license. Note that NAV likes to compile any object as it is saved, so the Compiled option is automatically checked. A compiled object is one that can be executed. If the object we were working on was not ready to be compiled without error, we could unselect the Compiled option in the Save As window, as shown in the preceding screenshot. Be careful, as uncompiled objects will not be considered by C/SIDE when changes are made to other objects. Until you have compiled an object, it is a "work in progress", not an operable routine. There is a Compiled flag on every object that gives its compilation status. Even when you have compiled an object, you have not confirmed that all is well. You may have made changes that affect other objects which reference the modified object. As a matter of good work habit, recompile all objects before you end work for the day. Pages/Forms Pages are for the Role Tailored Client. Forms are for the Classic Client. If you are in the challenging position of maintaining a dual personality system (that is, running both clients), you will be forced to maintain equivalent versions of both Pages and Forms. We aren't going to address that situation in depth in this article as we are not going to cover the design and development of Forms in detail. In this article, we will focus on Pages and cover Forms just enough so that you can create a few to use as maintenance and debugging tools. Pages fulfill several basic purposes. They provide views of data or processes designed for on-screen display only. They provide key points of user data entry into the system. They also act as containers for action items (menu options). The first page with which a user will come in contact is a Role Center Page. The Role Center Page provides the user with a view of work tasks to be done. The Role Center Page should be tailored to the job duties of each user, so there will be a variety of Role Center Page formats for any firm. There are several basic types of display/entry pages in NAV: List pages Card pages Document pages Journal/Worksheet pages There are also page parts (they look and program like a page, but don't stand alone) as well as user interfaces that appear as pages, but are not Page objects. The latter user interfaces are generated by various dialog functions. List pages List pages display a simple list of any number of records in a single table. The Customer List page in the following screenshot shows a subset of the data for each customer displayed. The Master record list shows fields intended to make it easy to find a specific entry. List pages/forms often do not allow entry or editing of the data. Journal/Worksheet pages look like List pages, but are intended for data entry. Card pages Card pages display one record at a time. These are generally used for the entry or display of individual table records. Examples of frequently accessed card pages include Customer Card for customer data, Item Card for inventory items, and G/L Account Card for general ledger accounts. Card pages often have FastTabs (multiple pages with each tab focusing on a different set of related customer data). FastTabs can be expanded or collapsed dynamically, allowing the specific data visible at any time to be controlled by the user. Card pages for Master records display all the required data entry fields. Typically, they also display summary data about related activity so that the Card page can be used as the primary inquiry point for Master records. The following screenshot is a sample of a standard Customer Card: Document pages Another page style within NAV consists of what looks like a Card page plus a List page. An example is the Sales Order page as shown in the following screenshot. In this example, the upper portion of the page is in the style of a Card page with several tabs showing Sales Order data fields that have a single occurrence on the page (in other words, do not occur in a repeating column). The lower portion of the Document page is in the style of a List page showing a list of all the line items on the Sales Order (all fields are in repeating columns). Line items may include product to be shipped, special charges, comments, and other pertinent order details. The information to the right of the data entry is related data and computations that have been retrieved and formatted. On top of the page, the information is for the Ordering customer and the bottom right contains information for the item on the selected line. Journal/Worksheet pages Journal and Worksheet pages look very much like List pages. They display a list of records in the body of the page. Many have a section at the bottom that shows details about the selected line and/or totals for the displayed data. These pages may also include a Filter pane and perhaps a FactBox. The biggest difference between Journal/Worksheet pages and basic List pages is that Journal and Worksheet pages are designed to be used for data entry. An example of a Worksheet page, the Requisition Worksheet in Purchasing, is shown in the following screenshot. This Worksheet assists the user in determining and defining what purchases should be made. Standard elements of pages A page consists of Page properties and triggers, Controls, Control properties and triggers. Data controls generally are either labels displaying constant text or graphics, or containers that display data or other controls. Controls can also be elements such as buttons, action items, and page parts. While there are a few instances where you must include C/AL code within page or page control triggers, in general it is good practice to minimize the amount of code embedded within pages. Most of the time, any data-related C/AL code can (and should) be located within the table object rather than the page object. Creating a Card page Let us try creating a Card page and a List page for the table we created earlier. The NAV IDE contains object generation tools (Wizards) to help you create relatively fully formed Classic Client forms and reports. Creating pages and reports for the Role Tailored Client is less about Wizards and more about actually using the Designer tools, but the Wizards are still very useful. Open the Object Designer, click on Page and then click on New. The Page Wizard's screen will appear. Enter the name (Donor) or number (50000) of the Table with which the page is to be associated (bound). Choose the option Create a page using a wizard:. Choose Card as shown in the following screenshot. Click on OK. Next, you will encounter the following Card Page Wizard screen: As this is our first Page creation effort, we will keep it simple. We will accept the single suggested FastTab of General and click on Next to proceed. That will take us to the following screen. Now it's time to add all the data fields for our Donor table to the page. Click on the button shown in the following image. That will move all of the Available Fields to the Field Order window. Now click on the Finish button. The Page wizard will close and you will be looking at the Page Designer form showing the generated page code, as shown in the following screenshot. Place your cursor on the first blank line at the bottom of the list of control definitions. Right-click and select Properties to open the Page-Properties screen as shown below (you could also press Shift + F4 or click on the Properties icon at the top of the screen). Type the page name to be displayed "Donor Card" into the Caption field, it will default into the MLCaption field too, as follows: Escape from that screen, and Escape from the Page Designer screen. A Save Changes form will be displayed, just like the one we saw when we finished defining our Donor table. We have the same task now as we did then, to assign an ID (object number) and Name. Let's make this Page number 50000 and call it Donor Card. Leave the Compiled checkbox checked and click on OK so that the Page will be compiled (and error checked). Assuming you haven't received any error messages, you have now created your first NAV 2009 page object. Congratulations! If you are doing your work with the original release of NAV 2009, you have to test a new card page by running it from the system Run option. From the Start menu, select Run. In the command box, enter the following: Dynamicsnav:////runpage?page=50000 If you are using NAV 2009 SP1 or later, you can test your page by simply highlighting it and clicking on the Run button at the bottom of the Object Designer screen (the Run button is programmed to automatically submit that long command to the system). This will invoke the Role Tailored Client, open it up, and call up your new page 50000. You should see a screen that looks like this. Experiment a little. Expand the card page to full screen. Enter some Donor data for two or three donors (hint: click on the Actions icon at the top of the page and choose the New option). You might want to open the page with the Page Designer using the Design button, add one of the data fields so it will appear a second time on the card. This time, change the Caption field for that data item. Save and compile. Run a test. Before you quit experimenting, go back and remove any extras that you had added, so that later your Donor Card will be what we created initially. You could create a second copy of the page so that you could experiment, then discard it later. First, open Page 50000 in Design mode. Then click on File Save As| and save the page object as Page number 50090 with a different name such as Test Donor Card. Compile it, then make whatever changes you want, deleting the experimental page when you are done experimenting. When you begin testing, you will find that a lot of features have been created automatically as part of the Card page, but you are still very limited in what you can do. For example, without a properly set up List Page, it's harder to move around in your table and quickly find different Donors, especially if there are more than just a few records in the table. This difficulty would be even more significant for your users. That's why List pages are the primary data navigation interface in the application system. So let's create a List page for our Donor table.

0
0
1563

How-To Tutorials

article-image-short-tour-through-nav-2009-part-2

Packt

11 Nov 2009

8 min read

A Short Tour through NAV 2009: Part 2

Packt

11 Nov 2009

8 min read

NAV 2009: A set of building blocks and development tools If you look at NAV 2009 from the point of view of a developer, you may see it as a set of customizable off-the-shelf program objects (the building blocks) plus the IDE which allows you to modify those objects and create new ones (the C/SIDE development tools). The NAV 2009 system is an object-based system, consisting of several thousand application objects, the building blocks, made up of the eight different object types available in NAV. NAV does not have all of the features of an object-oriented system. A full-featured object-oriented system would allow the definition and creation of new object types, while NAV only allows for the creation and modification of the predefined object types. NAV object types Let's start with some basic definitions of the object types that are part of NAV: Table: Tables are the definers and containers of data. Form: Forms are the screen display constructs for the Classic Client user interface. Page: Pages are the screen display constructs for the Role Tailored Client user interface. Pages are designed and rendered (displayed) using technology that is new to NAV 2009. Report: Reports allow the display of data to the user in "hardcopy" format, either onscreen (preview mode) or via a printer device. Report objects can also update data in processes with or without accompanying data display output. Dataport: Dataports allow the importing and exporting of data from/to external files in the Classic Client. XMLport: XMLports are similar to Dataports. In the Classic Client, XMLports are specific only to XML files and XML formatted data. In the Role Tailored Client, XMLports handle the tasks of both XMLports and Dataports. Codeunit: Codeunits are containers for code, always structured in code segments called functions. MenuSuite: MenuSuites contain menus which refer in turn to other types of objects. MenuSuites are structured differently from other objects, especially since they cannot contain any code or logic. In the Role Tailored Client, MenuSuites are translated into Navigation Pane menu entries. The C/SIDE Integrated Development Environment NAV includes a full set of software development tools. All NAV development tools are accessed through the C/SIDE Integrated Development Environment. This environment and its full complement of tools are generally just referred to as C/SIDE. C/SIDE includes the C/AL compiler. All NAV programming uses C/AL. No NAV development can be done without using C/SIDE. The C/SIDE Integrated Development Environment is referred to as the Object Designer within NAV. It is accessed through the Tools Object Designer menu |option as shown in the following screenshot: The language in which NAV is coded is C/AL. A sample of some C/AL code is shown as follows. C/AL syntax has considerable similarity to Pascal. As with any programming language, readability is enhanced by careful programmer attention to structure, logical variable naming, process flow consistent with that of the code in the base product and good documentation both inside and outside of the code. Insert code1 A large portion of the NAV system is defined by tabular entries, properties, and references. This doesn't reduce the requirement for the developer to understand the code, but it does allow some very significant applications development work to be done on a more of a point-and-choose or fill-in-the-blank approach than the traditional "grind it out" approach to coding. NAV gives developers the ability to focus on design rather than code. Much of the time, the effort required to create a new NAV application or modification will be heavily weighted on the side of design time, rather than technical development time. This long term goal for systems development tools has always been true for NAV. As the tools mature, NAV development continues to be more and more heavily weighted to design time rather than coding time. Object Designer tool icons The following screenshot shows a list of Object Designer tool icons. These Object Designer icons are shown isolated in the screenshot and then described briefly in the following table. Some of these icons apply to actions that are only for objects which run in the Classic Client, some are for objects for both clients. Additional information is available in the C/SIDE Help files and the Microsoft NAV documentation. The following table lists the specific development tools used for each object type. Also, as shown in this table, some objects are limited to being used in the Classic Client, some are limited to being used in the RTC environment, some are used in both, and some are interpreted differently depending on the environment in which they are invoked. Object Type Design Tool User Interface Comments Table Table Designer Classic and RTC Form Form Designer Classic Page Page Designer RTC Report Report Designer Classic (and RTC) If a report is run from the RTC but doesn't have an RTC compatible layout, NAV will run it under a temporary instance of the Classic Client Report Designer (data definition) + Visual Studio (user interface) RTC Dataport Dataport Designer Classic XMLPort XMLport Designer Classic and RTC For the RTC, Dataport functionality is handled through appropriately defined XMLports Codeunit IDE code editor for the C/AL language Classic and RTC MenuSuite Navigation Pane Designer Classic and RTC Much of the navigation in the RTC is done via Role Center pages rather than menus NAV object and system elements Let's take a look at the following: Database: NAV has two physical database options. One is the C/SIDE Database Server; the other is the Microsoft SQL Server. The C/SIDE Database Server, formerly known as the "Native" database, only supports the two-tier client. The NAV 2009 three-tier functionality is only compatible with a SQL Server implementation. You won't be surprised to know that one or two product versions in the future, the only database option will be SQL Server. At the basic application or code design levels, you don't care which database is being used. For sophisticated or high data volume applications you care a great deal about the underlying database strengths, weaknesses and features. Properties: These are the attributes of the element (for example object, data field, or control) that define some aspect of its behavior or use. For example, attributes such as display length, font type or size, and if the elements are either editable or viewable. Fields: These are the individual data items, defined either in a table or in the working storage of an object. Records: These are groups of fields (data items) that are handled as a unit in most Input/Output operations. The table data consists of rows of records with columns consisting of fields. Controls: These are containers for constants and data. A control corresponds to a User Interface element on a form/page or a report. The visible displays in reports and forms consist primarily of controls. Triggers: The generic definition is a mechanism that initiates (fires) an action when an event occurs and is communicated to the application object. A trigger is either empty or contains code that is executed when the associated event fires the trigger. Each object type has its own set of predefined triggers. The event trigger name begins with the word "On" such as OnInsert, OnOpenPage, and OnNextRecord. NAV triggers have some similarities to those in SQL, but they are not the same. NAV triggers are locations within the various objects where a developer can place comments or C/AL code. When you look at the C/AL code of an object in its Designer, the following have a physical resemblance to the NAV event based triggers: Documentation which can contain comments only, no executable code. Every object type except MenuSuite has a single Documentation section at the beginning. Functions which can be defined by the developer. They represent callable routines that can be accessed from other C/AL code either inside or outside the object where the called function resides. Many functions are provided as part of the standard product. As a developer, you may add your own custom functions as needed. Object numbers and field numbers: The object numbers from 1 (one) to 50,000 and in the 99,000,000 (99 million) range are reserved for use by NAV as part of the base product. Objects in this number range can be modified or deleted, but not created with a developer's license. Field numbers are often assigned in ranges matching the related object numbers (that is starting with 1 for fields relating to objects numbered 1 to 50,000, starting with 99,000,000 for fields in objects in the 99,000,000 and up number range). Object and field numbers from 50,001 to 99,999 are generally available to the rest of us for assignment as part of customizations developed in the field using a normal development license. But object numbers from 90,000 to 99,999 should not be used for permanent objects as those numbers are often used in training materials. Microsoft allocates other ranges of object and field numbers to Independent Software Vendor (ISV) developers for their add-on enhancements. Some of these (in the 14,000,000 range in North America, other ranges for other geographic regions) can be accessed, modified, or deleted, but not created using a normal development license. Others (such as in the 37,000,000 range) can be executed, but not viewed or modified with a typical development license. The following table summarizes the content as: Object Number range Usage 1 - 9,999 Base-application objects 10,000 - 49,999 Country-specific objects 50,000 - 99,999 Customer-specific objects 100,000 - 98,999,999 Partner-created objects Above 98,999,999 Microsoft territory

0
0
1396

How-To Tutorials

article-image-apache-continuum-ensuring-health-your-source-code-part-1

Packt

10 Nov 2009

14 min read

Apache Continuum: Ensuring the Health of your Source Code (Part 1)

Packt

10 Nov 2009

14 min read

0
0
1872

article-image-developing-application-symfony-13-part-1

Packt

10 Nov 2009

5 min read

Developing an Application in Symfony 1.3 (Part 1)

Packt

10 Nov 2009

5 min read

The milkshake shop Our application will be designed for a fictitious milkshake shop. The functional requirements for our shop are: Display of the menu, job vacancies, and locations; these details will be updated from the back office Sign up to a newsletter, where users can submit their details Search facility for the menu Secure backend for staff to update the site The site must be responsive Option for the users to view our vacancies in three languages Creating the skeleton folder structure Symfony has many ways in which it can help the developer create applications with less efforts—one way is by using the Symfony tasks available on the Command Line Interface (CLI). These Symfony tasks do the following: Generate the folder structure for your project, modules, applications, and tasks Clear the generated cache and rotate log files Create controllers to enable and disable an application and set permissions Interact with the ORM layer to build models and forms Interact with SQL to insert data into the database Generate initial tests and execute them Search for text in your templates that need i18N dictionaries and create them If you'd like to see all the tasks that are available with Symfony, just type the following on your command line:symfony Let's begin with using one of the Symfony tasks to generate the file structure for our project. Our project will reside in the milkshake folder. In your terminal window, change your folder path to the path that will hold your project and create this milkshake folder. My folder will reside in workspace folder. Therefore, I would type this: $mkdir ~/workspace/milkshake && cd ~/workspace/milkshake Now that I have the project folder and have changed the path to within the milkshake folder, let's use a Symfony task to generate the project file structure. In your terminal window, type the following: $/home/timmy/workspace/milkshake>symfony generate:project -orm=Propel milkshake We can generate our project we can also specify which ORM we would like to use. Our application is going to use the Propel ORM, but you can also opt for Doctrine ORM. By default, Doctrine ORM is enabled. After pressing the Enter key, the task goes into action. Now you will see output like the one in the following screenshot on your terminal window. This screenshot shows the folder structure being created: Let's have a look at the top-level folders that have been created in our project folder: Folders Description apps This folder contains our frontend application and any other applications that we will create batch If there are any batch scripts, they are placed here cache This folder is the location for cached files and/or scaffolded modules config This folder holds all the main configuration files and the database schema definitions data This folder holds data files such as test or fixture data doc All our documentation should be stored in this folder; this includes briefs, PhpDoc for API, Entity Relationship Diagrams, and so on lib Our models and classes are located in this folder so that all applications can access them log This folder holds the development controllers log files and our Apache log plugins All installed plugins are located in this folder test All unit and functional tests should be placed in this folder; Symfony will create and place stubs in this folder when we create our modules web This is the web root folder that contains all web resources such as images, CSS, JavaScript, and so on There are three folders that must be writable by the web server. These are the cache, log, and web/uploads/. If these are not writable to your web server, then the server itself will either produce warnings at startup or fail to start. The files permissions are usually set during the generation process, but sometimes this can fail. You can use the following task to set the permissions:$/home/timmy/workspace/milkshake>symfony project:permissions With the initial project skeleton built, next we must create an application. Symfony defines an application as operations that are grouped logically and that can run independent of one another. For example, many sites have a frontend and back office/admin area. The admin area is where a user logs in and updates areas on the frontend. Of course, our application will also provide this functionality. We will call these areas frontend and backend. Our first application is going to be the frontend. Again, let's use a Symfony task to generate the frontend application folder structure. Enter the following task in your terminal window: $/home/timmy/workspace/milkshake>symfony generate:app frontend Again, after executing this task, you will see the following in your terminal window: Let's have a look at the top-level folders that have just been created in the apps folder: Directory Description config This folder will have all configuration files for our application i18N This folder will contain all Internationalization files lib This folder will hold all application-specific classes modules All our modules will be built in this folder templates The default layout template is created in this folder, and any other global templates that will be created will also be placed in this folder These steps will generate our project and frontend application folder structure, and we can now view our project in a web browser. Open your web browser and go to http://milkshake/frontend_dev.php and you will see the following default Symfony page: Now we can see the default project page along with the instructions on what to do next. The frontend_dev.php file is our index file while developing the frontend application, and adheres to the naming convention of <application>_<environment>.php. This controller is the development controller and is rather helpful while developing. Before we continue though, I urge you to also have a look at the web debug toolbar.

0
0
3081

How-To Tutorials

article-image-search-engine-optimization-using-sitemaps-drupal-6

Packt

10 Nov 2009

8 min read

Search Engine Optimization using Sitemaps in Drupal 6

Packt

10 Nov 2009

8 min read

Let's get started. As smart as the Google spider is, it's possible for them to miss pages on your site. Maybe you've got an orphaned page that isn't in your navigation anymore. Or, perhaps you have moved a link to a piece of content so that it's not easily accessible. It's also possible that your site is so big that Google just can't crawl it all without completely pulling all your server's resources—not pretty! The solution is a sitemap. In the early 2000s, Google started supporting XML sitemaps. Soon after Yahoo came out with their own standard and other search engines started to follow suit. Fortunately, in 2006, Google, Yahoo, Microsoft, and a handful of smaller players all got together and decided to support the same sitemap specification. That made it much easier for site owners to make sure every page of their web site is crawled and added to the search engine index. They published their specification at http://sitemaps.org. Shortly thereafter, the Drupal community stepped up and created a module called (surprise!) the XML sitemap module. This module automatically generates an XML sitemap containing every node and taxonomy on your Drupal site. Actually, it was written by Matthew Loar as part of the Google Summer of Code. The Drupal 6 version of the module was developed by Kiam LaLuno. Finally, in mid-2009, Dave Reid began working on a version 2.0 of the module to address performance, scalability, and reliability issues. Thanks, guys! According to www.sitemaps.org: Sitemaps are an easy way for Webmasters to inform search engines about pages on their sites that are available for crawling. In its simplest form, a Sitemap is an XML file that lists URLs for a site along with additional metadata about each URL (when it was last updated, how often it usually changes, and how important it is, relative to other URLs in the site) so that search engines can more intelligently crawl the site. Web crawlers usually discover pages from links within the site and from other sites. Sitemaps supplement this data to allow crawlers that support Sitemaps to pick up all URLs in the Sitemap and learn about those URLs using the associated metadata. Using a sitemap does not guarantee that every page will be included in the search engines. Rather, it helps the search engine crawlers find more of your pages. In my experience, submitting an XML Sitemap to Google will greatly increase the number of pages when you do a site: search. The keyword site: searches show you how many pages of your site are included in the search engine index, as shown in the following screenshot: Setting up the XML Sitemap module The XML Sitemap module creates a sitemap that conforms to the sitemap.org specification. Which XML Sitemap module should you use? There are two versions of the XML Sitemap module for Drupal 6. The 1.x version is, as of this writing, considered the stable release and should be used for production sites. However, if you have a site with more than about 2000 nodes, you should probably consider using the 2.x version. From www.drupal.org: 'The 6.x-2.x branch is a complete refactoring with considerations for performance, scalability, and reliability. Once the 6.x-2.x branch is tested and upgradeable, the 6.x-1.x branch will no longer be supported'. What this means is that in the next few months (quite possibly by the time you're reading this) everyone should be using the 2.x version of this module. That's the beauty of open source software—there are always improvements coming that make your Drupal site better Search Engine Optimized. Carry out the following steps to set up the XML Sitemap module: Download the XML Sitemap module and install it just like a normal Drupal module. When you go to turn on the module, you'll be presented with a list that looks similar to the following screenshot: Now that you have the XML sitemap module properly installed and configured, you can start defining the priority of the content on your site—by default, the priority is .5. However, there are times when you may want Google to visit some content more often and other times when you may not want your content in the sitemap at all (like the comment or contact us submission forms). Each node now has an XML sitemap section that looks like the following screenshot: Before you turn on any included modules, consider what pieces of content on your site you want to show up in the search engines and only turn on the modules you need. The XML sitemap module is required. Turn it on. XML sitemap custom allows you to add your own customized links to the sitemap. Turn it on. XML sitemap engines will automatically submit your sitemap to the search engines each time it changes. This is not necessary and there are better ways to submit your sitemap. However, it does a nice job of helping you verify your site with each search engine. Turn it on. XML sitemap menu adds your menu items to the sitemap. This is probably a good idea. Turn it on. XML sitemap node adds all your nodes. That's usually the bulk of your content so this is a must-have. Turn it on. XML sitemap taxonomy adds all your taxonomy term pages to the sitemap. Generally a good idea but some might not want this listed. Term pages are good category pages so I recommend it. Turn it on. Don't forget to click Save configuration. Go to http://www.yourDrupalsite.com/admin/settings/xmlsitemap or go to your admin screen and click on Administer | Site Configuration | XML sitemap link. You'll be able to see the XML sitemap, as shown in the following screenshot: Click on Settings and you'll see a few options, as shown in the following screenshot: Minimum sitemap lifetime: It determines that minimum amount of time that the module will wait before renewing the sitemap. Use this feature if you have an enormous sitemap that is taking too many server resources. Most sites should leave this set on No minimum. Include a stylesheet in the: The sitemaps will generate a simple css file to include with the sitemap that is generated. It's not necessary for the search engines but very helpful for troubleshooting or if any humans are going to view the sitemap. Leave it checked. Generate sitemaps for the following languages: In the future, this option will allow you to actually specify sitemaps for different languages. This is very important for international sites who want to show up in localized search engines. For now, English is the only option and should remain checked. Click the Advanced settings drop-down and you'll see several additional options. Number of links in each sitemap page allows you to specify how many links to pages on your web site will be in each sitemap. Leave it on Automatic unless you are having trouble with the search engines accepting the sitemap. Maximum number of sitemap links to process at once sets the number of additional links that the module will add to your sitemap each time the cron runs. This highlights one of the biggest differences between the new XML sitemap and the old one. The new sitemap only processes new nodes and updates the existing sitemap instead of reprocessing every time the sitemap is accessed. Leave this setting alone unless you notice that cron is timing out. Sitemap cache directory allows you to set where the sitemap data will be stored. This is data that is not shown to the search engines or users; it's only used by the module. Base URL is the base URL of your site and generally should be left as it is. Click on the Front page drop-down and set these options: Front page priority: 1.0 is the highest setting you can give a page in the XML sitemap. On most web sites, the front page is the single most important part of your site so, this setting should probably be left at 1.0. Front page change frequency: Tells the search engines how often they should revisit your front page. Adjust this setting to reflect how often the front page of your site changes. What is priority and how does it work? Priority is an often-misunderstood part of a sitemap. For instance, the priority is only used to compare pages of your own site and you cannot increase your ranking in the Search Engine Results Page (SERPS) by increasing the priority of your pages. However, it does help let the search engines know which pages of your site you feel are more important. They could use this information to select between two different pages on your site when deciding which page to show to a search engine user.

0
0
1775

How-To Tutorials

article-image-short-tour-through-nav-2009-part-1

Packt

10 Nov 2009

6 min read

A Short Tour through NAV 2009: Part 1

Packt

10 Nov 2009

6 min read

A product as complex and flexible as NAV can be considered from several points of view. One can study the NAV application software package as a set of application functions designed to help a business manage information about operations and finances. One can also look at NAV as a stack of building blocks from which to extend or build applications—and the tools with which to do the construction. In NAV 2009, which has two quite different user interface options available, one must consider how the user interface affects both the application design and the presentation to the user. This requirement overlaps both the application viewpoint and the construction viewpoint. You should know the different object types that make up a NAV system and the purposes of each. You should also have at least a basic idea of the tools that are available to you, in order to enhance (small changes) or extend (big changes) an NAV system. In the case of NAV, the Integrated Development Environment (IDE) includes essentially all of the tools needed for NAV application development. Prior versions of NAV were two-tier systems. One of the tiers was the database server, the other tier was the client. As the traditional two-tier NAV Client (now referred to as the Classic Client) is still an integral part of the system, we will cover the aspects of where it must be used for development and support. All development and much of the system administration uses the Classic Client. So, even though our focus is on developing for the Role Tailored Client (aka "the RTC"), many of the images in this article will be of Classic Client displays. In brief, the RTC is for users, and as a developer, you will generally use the Classic Client for your work. NAV 2009: An ERP system If you look at NAV 2009 from the point of view of a firm using NAV to help run its business, you will see it as an integrated set of business applications software. Microsoft Dynamics NAV is generally characterized as an ERP System. ERP stands for Enterprise Resource Planning. An ERP system is a set of integrated application software components designed to track and coordinate a wide variety of business activities, especially those involving products, orders, production and finances. An ERP system will typically include the following: Basic accounting functions (for example, general ledger, accounts payable, accounts receivable) Order processing and inventory (for example, sales orders, purchase orders, shipping, inventory, receiving) Relationship management (for example, vendors, customers, prospects, employees, contractors, and so on) Planning (for example MRP, sales forecasting, production forecasting) Other critical business areas (for example, manufacturing, warehouse management, fixed assets) The integration of an ERP system is supported by a common database, by an "enter once, use everywhere" data philosophy, by a modular software design, and with data extraction and analysis tools. The following image is a view of an ERP system from the highest level: The design of Microsoft Dynamics NAV addresses all the points in the above description and more. The NAV ERP system includes integrated modules covering the breadth of business functions for a wide range of business types. These modules share a common database and, where appropriate, share common data. In the NAV system, there is a considerable overlap of components across application areas, with individual functions showing up in multiple different "modules". For example, in NAV, Inventory is identified as part of Financial management, but it is also, obviously, an integral part of Manufacturing, Supply Chain, and others. The particular grouping of individual functions into modules that follows is based on Microsoft marketing materials. Some of these assignments are a bit arbitrary. What's important is for you to obtain a reasonable understanding of the overall set of application components that make up the NAV ERP system. In several of the following groupings, menu screenshots are included as examples. These are from the Role Tailored Client Departments menu screen. Financial Management Financial Management is the foundation of any ERP system. No matter what the business is, the money must be kept flowing, and the flow of money must be tracked. The tools which help to manage the capital resources of the business are included in NAV's Financial Management module. These include all or part of the following application functions: General Ledger—managing the overall finances of the firm Accounts receivable—tracking the incoming revenue Accounts payable—tracking the outgoing funds Analytical accounting—analyzing the various flows of funds Cash management and banking—managing the inventory of money Inventory and fixed assets—managing the inventories of goods and equipment Multi-Currency and Multi-Language—supporting international business activities Manufacturing NAV Manufacturing is general purpose enough to be appropriate for Make to Stock (MTS), Make to Order (MTO), and variations such as Assemble to Order, and so on. While off-the-shelf NAV is not particularly suitable for most process manufacturing and high-volume assembly line operations, there are third party add-on and add-in enhancements available for these. As with most of the NAV application functions, manufacturing can be installed in parts or as a whole, and can be used in a simplistic fashion or in a more sophisticated manner. NAV Manufacturing includes the following functions Product design (BOMs and Routings)—managing the structure of product components and the flow of manufacturing processes Capacity and supply requirements planning—tracking the intangible and tangible manufacturing resources Production scheduling (infinite and finite),execution, and tracking—tracking the planned use manufacturing resources, both on an unconstrained and constrained basis Supply Chain Management (SCM) Obviously, some of the functions categorized as part of NAV Supply Chain Management (for example sales, purchasing, and so on) are actively used in almost every NAV implementation. As a whole, these constitute the base components of a system appropriate for a distribution operation. The Supply Chain applications in NAV include parts of the following applications: Sales order processing and pricing—supporting the heart of every business—entering, pricing, and processing sales orders Purchasing (including Requisitions)—planning, entering, pricing, and processing purchase orders Inventory management—managing inventories of goods and materials Warehouse management including receiving and shipping—managing the receipt, storage, retrieval, and shipment of material and goods in warehouses

0
0
1418

How-To Tutorials

article-image-keyword-research-search-engine-optimization-drupal-6

Packt

10 Nov 2009

11 min read

Keyword Research for Search Engine Optimization in Drupal 6

Packt

10 Nov 2009

11 min read

SEO is necessary—you've got to do it if you want to rank well for keywords. Simple in concept, keywords are actually very complicated things. They bring order to chaos, define markets, and reveal intent. Keyword data simultaneously tells you how many people are looking for your product or service and what those people will do once they find you. The results of a keyword search can tell you who the top people are in an industry and inform you of upcoming trends in the market. Keywords are the most visible focal point of free market competition between business interests. Search engine optimization is a popularity contest for keywords and this is a popularity contest you want to win. The most critical part of an SEO project is finding the right keywords. You will spend months working on your web site, getting links, and telling the world that your site is the authority on that keyword. It's critical that when you finally arrive, your customers are there to embrace you. If you pick the wrong keywords, you'll spend months working only to find that there is nobody who wants to buy your product. Ouch! An extra few hours researching your keywords in the beginning will help you avoid this fate. What a keyword is Keywords are many things to many people. For the purpose of this SEO campaign, there are really only two things about keywords that we need to understand to get the job done. Keywords aggregate searchers into organized groups and a keyword defines a market. Keywords are single words that a search engine user types into the search box to try to find what they're looking for. Key phrases are the same as keywords except for the fact that they consist of two or more words. For the sake of simplicity, throughout this article let's use keywords to mean both, keywords and key phrases. Keywords aggregate searchers into organized groups Millions of random people visit Google every day. When they arrive, they are amorphous—a huddled mass yearning for enlightenment with nothing more than a blank Google search form to guide them. As each person types keywords into Google and clicks the Search button, this random mass of people becomes extraordinarily organized. Each keyword identifies exactly what that person is looking for and allows Google to show them results that would satisfy their query. Much like a labor union, the more searchers there are looking for a particular phrase, the more clout they have with the businesses who want to sell to them. However, instead of more pay and better health benefits, you get better search results. If there are a thousand people per month looking for keyword A and a hundred people per month looking for keyword B, then chances are good that there are more competitors focused on keyword A. More competition means better optimization is required to show up at the top. Better optimization requires more content, closer attention to meeting the needs of the group, and more interesting web sites. A keyword defines a market This organization of searchers is what gives Google such power. In a very real way, Google creates billions of tiny markets every day. There is a buyer (the searcher) looking for a product, the seller (the web site owners) selling what they've got, and the middleman (Google) organizing everything and facilitating the transaction. The transaction takes place when the searcher clicks on the result of a keyword search and is whisked off to the seller's web site. However, it doesn't always go smoothly. In fact, very high percentages of the time the searcher doesn't find what they're looking for so they hit the back button and try again. They may try a different result on the same page or type in a different keyword and do the entire search again. Each time you have an opportunity to convince them that yours is the right site with the best information and most promising solution to their questions. It is in your best interest to provide a web site that quickly engages the searchers, pulls them in, and keeps the dialogue going. Why keyword research is important As a Drupal site owner, you have the opportunity to position yourself as the best site available for the keywords people are searching for. Know thy customerThere are hundreds of good marketing books out there to help you better understand your audience. All that good information applies to SEO as well. The better you know your audience, the better you can guess what keywords they are typing in Google to find companies like yours. You're an expert in your field, so of course you know many of the keywords that people use to find your products and services. But, are you sure you know them all? A few years ago Tom, a friend of mine, hired me to do SEO for his high-end landscaping firm. His company designs and installs yards, trees, retaining walls, and so on, outside million dollar homes in the hill country near Austin, Texas. We sat down in an early morning meeting and he said, "Ben, the right keyword is landscaping. I know it so there's no reason to do all this research. Don't waste your time and my money. Just do landscaping and that's that". Being the thorough person that I am, I did the keyword research anyway. Guess what I found? The number one phrase in his business was landscaping. However, a very close second was landscaper. And, while landscaping had dozens of competitors—some of them were very well entrenched—there were only a handful of competitors showing up for landscaper. The next day, I called Tom and told him what I found. "You know what?" he said, "Now that you mention it, many of our customers do refer to us as landscapers—'I need a landscaper. Call a landscaper' ". So, we started his campaign targeting the keyword landscaper. Because there was so little competition, he ranked in the top five in a matter of weeks and was number one in Google within two months. He was dominating half the search traffic within two months! The leads were rolling in so we switched to the keyword landscaping. It took longer—about three months—for him to break into the top ten. By that time, he had so many inquiries, he hardly even noticed. The lesson here is three-fold: You may know some of the keywords, however, that doesn't mean you know them all. Just because you think of yourself in one particular way doesn't mean your customers do. By taking the time to do keyword research, you will reveal opportunities in your market that you didn't know existed. What your keyword goal is Before you start looking at keywords, you need to fix your goal firmly in your mind. There are basically two major reasons to do SEO. Goal 1: Brand awareness This may come as a surprise but there are people out there who don't know that you exist. SEO is a powerful and inexpensive way to get your name out there and build some credibility with your target customers. There are three major types of brand awareness: Company brand awareness Company brand awareness works on getting the name of your company into the market. If you want to build credibility for Big Computers Unlimited as a whole, then you probably want a campaign focused on getting your company listed where other top producers of PCs are listed. PC, computer, or fast computer all might be good terms. Product brand awareness Product brand awareness focuses on building general market knowledge of one product or line of products that your company produces. If you work for Big Computers Unlimited and you want to sell more Intergalactic Gamer brand computers at retail stores throughout the country, then you probably want to build a campaign around keywords like Gaming PC or even high-end PC. Credibility A 2004 survey by iProspect found that two out of three search engine users believed that the highest search results in Google were the top brands for their industry; there is little reason to believe this perception has changed. That means that just by being at the top of Google will gain you a certain level of trust among search engine users. If Big Computers Unlimited can rank in the top three for Gaming PCs, they'll develop a lot of creed among gamers. Goal 2: Conversions Conversions are a fancy way of saying that the visitor did what you wanted them to do. There are three typical types of conversions: Transactional A transaction is just what it sounds like. Someone puts in a credit card and buys your product. This is typical of most product-focused web sites but isn't limited to this narrow category. Your web site may sell registrations to online training, subscriptions to magazines, or even credit monitoring. The bottom line is that it can be purchased on the site. You need to focus your keyword research on terms that will bring buyers who are ready to purchase right now. Words like buy, price, merchant, store, and shop indicate a desire for immediate purchase. Give them the transactional information they need like price, color choices, size, quantity discounts, return policy, and delivery options. With this information and a great checkout experience you'll have them buying from you in no time. UbercartUbercart is simply the best shopping cart solution for Drupal. If you're a transactional web site and you need an e-commerce solution, start here: http://www.ubercart.org/. Lead Generation If you're in an industry with a long sales cycle like real estate, legal services, or medical, then you're probably interested in generating leads rather than online transactions. If you sell a service or product that requires direct contact with your customer, like consulting or personal training, then you probably want leads too. Lead generation means that instead of buying from your web site, you're interested in someone expressing an interest in doing business with you so that you can follow up with them later. You let them express interest by filling out a contact form, emailing you, or even picking up the phone and calling you. You need to focus your keyword research on terms that will bring people who are perhaps a little earlier in the buying process. Words like review, compare, best, information, and generic names of your product indicate a user is researching but not quite ready to buy. You'll need to provide a lot of information on your web site to inform them and shape their thinking about your product. Page impression (or ad impression) Some web sites make money when visitors view an ad. To these sites, a conversion may simply be someone clicking on one or more pages so that they'll see one more ads. You need to focus your keyword research on terms that will bring people seeking information or news to your web site. Keyword research tools There are many tools to help you find the right keywords. It's not important that you use them all but you should try a few of them just so you can see what's out there. Here are my favorites in order of preference: Your own web site The most important keyword research tool at your disposal is your own web site, http://www.yourDrupalsite.com/. If you already have some traffic, chances are that they're coming from somewhere. With analytics installed, you should be able to find out what they're searching on with just a few clicks. If you have Google Analytics installed then you can easily see this data by logging in to its admin section and then going to Traffic Sources | Search Engines | Google. This information can be invaluable if you cross-reference it with your current positions in the search engines. Say, for example, that you're getting 100 searchers a month on a term that you're on page 2 of Google. That's a good indicator that people are searching hard to find a company like yours and that may be a very good term to focus on with your search engine campaign. If you're getting that much traffic on page 2, imagine if you were in the top three on page 1. Drupal has a built-in search engine—another great tool to see what the people are searching for, after they've already visited your site. There's an insanely useful module for that, called Top Searches (http://drupal.org/project/top_searches) that does a better job that Drupal's built-in list. This module was developed by the founder of Linnovate, Zohar Stolar. Thanks, Zohar!

0
0
1499

How-To Tutorials

article-image-developing-application-symfony-13-part-2

Packt

10 Nov 2009

7 min read

Developing an Application in Symfony 1.3 (Part 2)

Packt

10 Nov 2009

7 min read

0
0
1440

How-To Tutorials

article-image-creating-and-using-templates-cacti-08

Packt

10 Nov 2009

3 min read

Creating and Using Templates with Cacti 0.8

Packt

10 Nov 2009

3 min read

For example, let's say we have a network of four Linux servers, two Unix servers, and one Cisco router. Here, if we use a template, we will need to make only three different templates: one for the Linux servers, one for the Unix servers, and one for the Cisco router. You may ask why we have to make a template for the Cisco router? We will make it so that we can use it later. Cacti templates can be imported and exported via the Console under Import/Export. You can only import templates that have been created on a system that is at the same, or an earlier, version of Cacti. At the end of this article, there is a list of third-party templates that can be imported. Types of Cacti templates Cacti templates are broken into two areas: Graph templates Host templates In the above figure, under the Templates section, you will see the three types of templates that come with the Cacti basic installation. If you click on one of those links, you will get the complete list of templates for that type. Graph templates Graphs are used to visualize the data you have collected. A graph template provides a skeleton for an actual graph. When you have more then one system/device, a graph template will save you lots of time and also reduce the possibility of error. Any parameters defined within a graph template are copied to all the graphs that are created using this template. Creating a graph template Now, we are going to create a new graph template. Under the Templates heading, click on Graph Templates. A list of the already available graph templates will be shown. Click on the Add link in the top right corner. You will get a screen like this: Here, you have to give the values that will be used in future to create the graph. If you have checked Use Per-Graph Value (Ignore this Value), then every time while using this graph template to create a graph, you have to give an input for this option. It's always best to enable this option for title field. After filling all these fields, click on the Create button. The graph template will be created. Now, we need to add a Graph Template Item and Graph Item Inputs to complete this graph template. Graph Template Item Graph template items are the various items that will be shown on the graph. To add a graph template item, click on Add on the right side of the Graph Template Items box. You will get this page. The following are the fields that can be filled in: When creating a graph item, you must always start with an AREA item before using STACK; otherwise, your graph will not render. Graph Item Inputs The second box is Graph Item Inputs. Graph item inputs are the input source through which the data will be collected. To add a new graph item input, click on the Add link on the right side of the Graph Item Inputs box. Below are the various fields that have to be filled out for a graph input item: After completing all these fields, click on the Create button. Do this again to add more graph item inputs to this graph template.

0
0
8822

article-image-apache-continuum-ensuring-health-your-source-code-part-2

Packt

10 Nov 2009

10 min read

Apache Continuum: Ensuring the Health of your Source Code (Part 2)

Packt

10 Nov 2009

10 min read

The build definition As we have seen in the Continuum build life cycle overview earlier, Continuum uses build definitions for building the projects. We can think of build definitions as instructions for Continuum on how to build the project. There are two levels of build definition: project group level and project level. Project group build definition Let's go back to the Project Group Summary page of our centrepoint application and click on the Build Definitions tab. Continuum configures a default build definition for each project group created. The content of the build definition depends on the type of the project. For Maven 2 projects, goals such as clean install and clean deploy need to be defined while Ant and shell projects do not require this. Instead, they configure their respective command-line goals. As we can see from the Project Group Build Definition of our Centrepoint project group below, the goals to be executed for the build can be configured as well as the schedule of its execution. The default Project Group Build Definition has clean install as its goals. Having install as a goal means that the project's artifacts will only be available locally (in the local Maven repository) to where our Continuum instance is running. Consumers of the project (for example, the project's Quality Assurance team) will not necessarily have permission to access the machine itself and it is out of the question to obtain the latest build from the local repository. Instead, the right way to do is to set up a deployment repository for snapshot artifacts, configure Continuum to build the project, and deploy the built artifacts to the snapshot repository, so that there is a new build each day that can be consumed by the QA team for testing. ...<distributionManagement> <repository> <id>releases</id> <name>Archiva Managed Releases Repository</name> <url>http://localhost:8081/archiva/repository/releases</url> <layout>default</layout> </repository> <snapshotRepository> <id>snapshots</id> <name>Archiva Managed Snapshots Repository</name> <url>http://localhost:8081/archiva/repository/snapshots</url> <uniqueVersion>true</uniqueVersion> <layout>default</layout> </snapshotRepository></distributionManagement>... We don't need to configure anything else in our settings.xml and security-settings.xml. Now let's create a new build definition for our Centrepoint project group. Click the Add button on the group build definitions page, then fill in the Build Definition as follows: The POM filename is the actual filename of our project's pom.xml that will be used for the build. The Goals are the goals we want to execute when using this build definition. As we want our artifacts to be available to the snapshots repository, we will set clean deploy as our goals. The Arguments specify the additional arguments that will be used when building the project. In our case, these are Maven 2 arguments, as our project is a Maven 2 project. If you had wanted to do a fresh checkout instead of just updating from the source repository during the build, you would tick the Build Fresh checkbox. One behavior of Continuum to take note of is that if there were no changes to the SCM in the last build; Continuum would no longer build the project. This sometimes causes people to panic and think their CI is broken, but it is actually not. When you think about it, it makes sense that this is the default behavior. There were no changes in the code, so why build it? To countermand this behavior, you would tick the Always Build checkbox in the build definition. This would tell Continuum to always build the project whether there were any changes in the SCM or not. The Is it default? field signifies that the build definition is the default one that will be used when the project build is explicitly triggered (forced build) from the Project Group Summary and Project Summary pages. This field can only be edited if there are multiple build definitions defined for the project. We will discuss schedules next, but for now we will just use the DEFAULT_SCHEDULE. The same goes for Build Environment. We will cover this at the end of this article. For now, we will leave as it is. As for the last two fields, they simply specify the type of project the build definition is for and the description of the build definition respectively. Click Save and our build definition is created. Now for each project group, we can define multiple build definitions and attach it to a schedule. A schedule is just a plain old schedule of when a build will be triggered or executed. The diagram below, which Wendy Smoak created for Continuum effectively shows how the project group, build definitions, schedules, build queues, and notifiers (which we will discuss later on) work together. Going back to the schedules, a default schedule running every hour is already pre-defined in Continuum and that is where the default build definition is attached. We will create a schedule for our project's nightly builds where we will attach the build definition that we created so that there is a fresh snapshot each day which the QA team can test for all the changes or fixes in the code from the previous day. From the Schedules tab on the left you can add a new schedule. Fill in the form as follows: The important field to take note of in the Schedule is the Cron Expression. A Cron Expression is a representation of a time or times at certain intervals. This is used typically to fire or trigger a schedule to do or execute something. From the Cron Expression we have specified above, we are configuring our schedule to build each night at 12 midnight. The other field to take note of is the Build Queue. This simply defines where the project(s) attached to this schedule will be queued. If no build queue were set, Continuum would use the DEFAULT_BUILD_QUEUE. Save the schedule that we created. Go back to Centrepoint's Build Definitions tab, edit the Project Group Build Definition we created earlier and attach it to our NIGHTLY_BUILDS schedule. When setting a schedule, sometimes an hour is too long to wait. If a problem occurs it may be drowned out by other changes, or the developer may have switched context. Builds should be kept short and scheduled frequently. Long-running tasks, such as performance and functional tests, and nightly builds can be run on separate schedules. To demonstrate how build definitions are used, click the build icon (third column from the right) of our snapshot deployment build definition. After the projects in the group have finished building, go back to the Project Group Summary page and click on the build number link (fifth column from the left) of one of the projects. Clicking on the build number leads us to the build result of that specific build including the build definition used and the build output. We will cover build results in the succeeding sections. You can also check the snapshots repository at http://localhost:8081/archiva/repository/snapshots to see that the projects were deployed. Project build definition A project level build definition is essentially the same as a project group build definition—it could be tied to a schedule and everything. The only difference is that it's on a per project level. Therefore, when only that project was triggered to be built, continuum would use the default project level build definition. The notifiers We mentioned earlier in the article that one of the benefits of using a CI server is that when the build breaks, the project members would immediately know of it. This is where notifiers come in. Notifiers are a configuration in the CI, which send out notifications to the project members regarding the status of the build. Different types of notifiers In Continuum, there are five types of notifiers that can be configured. These are the: Mail notifier: The mail notifier sends out an email to a specific address regarding the status of the build. For the mail notifier to work, it's good to keep in mind to set up a mail server first. Remember, we did this whilst installing prerequisites at the beginning of the article. IRC notifier: This notifier sends out a message to a specific IRC channel alerting the channel of the project's build condition. Jabber notifier: This notifier sends out a message to a specific Jabber account. MSN notifier: This notifier sends out a message to a specific MSN account. Wagon notifier: This notifier deploys the build results to a specific URL (for example, to the project's site) using Wagon. These notifiers can be configured to notify the project team on certain conditions of the build. They can be set up to Send on Success, Send on Failure, Send on Error, and/or Send on Warning as seen in the following screenshot: They are self-descriptive, but we will give each one a quick run through: Send on Success: Send out a notification if the build was successful. Send on Failure: "Code red! Code red! Code RED!!!". Need we say more? Okay, just to elaborate... a notification will be sent out when the build fails. By fail, we mean that a problem was encountered during build execution. This can be a compile failure, a test failure, or simply a dependency not being found. Send on Error: A notification will be sent out when there was an error outside of the build execution. A good example of this is when the source repository goes offline and Continuum cannot update its working copy. Send on Warning: A notification will be sent out if the build was not a successful build, a failed build, or an erroneous build. A notification is sent only when a project's state is modified. For example, if the previous state of all the projects in the group is SUCCESS and on the next build, all the projects in the entire group were built successfully again, no notification will be sent. However, if the second build of one of the projects failed (state is FAILURE), a notification will be sent specific to that project. The Send a mail to latest committers field for the Mail Notifier tells Continuum to send a notification mail to those developers who committed changes to the source repository as part of the last build. The Mail Recipient Address does not have any effect on the Send a mail to latest committers as the email addresses where the notification mail will be sent are retrieved from the list of project developers. Like build definitions, notifiers can also be configured at the project group level and/or at the project level. Notifiers are cumulative, which means notifiers configured at the group level always takes effect whether or not there are notifiers configured at the project level. This is similar to the co Now, let's create a group mail notifier for our centrepoint application. In our exercise, we will use our own valid email address for the mail notifier. We want to know everything that is happening to our project build so we tick all the checkboxes except for Send a mail to latest committers (we don't have usernames in our SVN repository so we don't have any use for this). Let's build our project by pressing the Build All Projects button on the Project Group Summary page. We should get a successful build and the build states of all the projects in the group should show the SUCCESS icon. However, no notification mail was sent. This is because there were not any changes in the build state nor were there any changes in SVN.

0
0
2362

article-image-useful-maven-plugins-part-1

Packt

09 Nov 2009

13 min read

Useful Maven Plugins: Part 1

Packt

09 Nov 2009

13 min read

0
0
6649

article-image-including-charts-and-graphics-pentaho-reports-part-1

Packt

09 Nov 2009

8 min read

Including Charts and Graphics in Pentaho Reports (Part 1)

Packt

09 Nov 2009

8 min read

0
0
5208

Geronimo Architecture: Part 2

Geronimo Architecture: Part 1

Geronimo Plugins

A Short Tour through NAV 2009: Part 3

A Short Tour through NAV 2009: Part 2

Apache Continuum: Ensuring the Health of your Source Code (Part 1)

Developing an Application in Symfony 1.3 (Part 1)

Search Engine Optimization using Sitemaps in Drupal 6

A Short Tour through NAV 2009: Part 1

Keyword Research for Search Engine Optimization in Drupal 6

Trending Topics

Developing an Application in Symfony 1.3 (Part 2)

Creating and Using Templates with Cacti 0.8

Apache Continuum: Ensuring the Health of your Source Code (Part 2)

Useful Maven Plugins: Part 1

Including Charts and Graphics in Pentaho Reports (Part 1)

Create a Free Account To Continue Reading

Sign in to activate your 7-day free access