How-To Tutorials

article-image-movable-type-5-introduction

18 Jan 2010

4 min read

Movable Type 5: An Introduction

18 Jan 2010

I’ve been a longtime user of MT, since version 3.2, and have followed its evolution closely from the inside out. When the beta-test and release-candidate versions of MT5 were released for public testing, I jumped on them and got my hands as dirty as I could, cloning my own MT4-driven site and testing it out in a separate MT5 instance (almost everything, plugins included, worked as-is). With each set of changes, I’ve also identified a couple of gotchas and potential problems that new users will want to keep an eye out for, and that any current MT user will want to be mindful of when they upgrade. Pages And Sites: Getting (Re)Organized The single biggest outward change to Movable Type is a reworking of how blogs are organized. Movable Type 4 introduced the ability to create and edit individual HTML pages in a folder hierarchy, each styled with the same templates used to create one’s blog. With MT5, this is paired with a new meta-organizational feature: the ability to create "websites" as an adjunct to one’s blog. A website contains a page hierarchy, but is kept as physically distinct as possible from a blog, so one site could contain a number of different blogs. This way, one could create a set of pages that changed very little—a corporate mission statement, an about-us page, personnel, etc.—and keep them entirely distinct, not just in the file hierarchy but in terms of permissions and editability. It’s another step towards making MT into a general content management system—or, at least, to add CMS-like features to the program to make it that much more powerful generally. One downside to this new behavior is that it throws first-timers and MT4 users for a bit of a loop. You can’t just create a blog—rather, you have to create a website (even if it’s just an empty one) and then create a blog under it. The blog and the website can share the same page hierarchy as long as nothing’s formally published in the website, or at least as long as no pages from one overwrite the other. Databases: MySQL All The Way Sometimes a new version of a product means features are dropped rather than added. Movable Type 5 is no exception, since it removes support for a number of database products. Oracle and Microsoft SQL Server are now only supported in the Enterprise edition of the product; some (SQLite and Postgres) have been relegated to plug-ins. Several things were behind this decision. First, MySQL has by and large been the database that people have used with Movable Type (and with blogging generally). It’s free, it’s been ported to most every platform of significance, and it’s already accumulated a large enough user base—both with Movable Type and other blogging programs—that consolidating on it as a standard would probably not inconvenience too many people. The second decision: convenience of support. It’s easier to support one commonly-used (and free) database system instead of several that are both free and commercial. If you’ve been using SQLite or PostgreSQL as your database, MovableType.org has some migration instructions for moving to MySQL. The short version: create a backup of your site/blog through MT itself, make a new installation of MT 5 on a MySQL instance, and restore the blog in MT. I’ve jumped through these exact hoops myself, so a word of caution. If you’re dealing with a really big blog (more than, say, 10MB) and you’re hosting the blog on a remote server, your best bet is to send the backup file to someone at the host and have them perform it for you locally. Part of the reason the MT full-system backup process is a bit clunky is because it is typically done through the progam’s web interface; it’s not something that can be done through a command line. (There is a third-party command-line backup solution for MT—but it’s been written for MT4, so there’s no guarantee it works with MT5, and it hasn’t been updated since 2008.)

0
1
1889

article-image-securely-encrypt-removable-media-ubuntu

Packt

18 Jan 2010

3 min read

Securely Encrypt Removable Media with Ubuntu

Packt

18 Jan 2010

3 min read

The other day my Dad mentioned that "any true geek always carries a USB drive with him". I proved my geek-hood by producing the 2G titanium thumb drive from around my neck. I then did him one further by telling him that the drive was encrypted with AES 256 bit encryption. I don't know whether or not he was impressed, but I sure proved that I am a true geek. It was this experience that prompted me to share my instructions on how to securely encrypt any removable drive. Following the steps outlined in this tutorial will wipe all data from the device / partition that you present to the encryption utility. You cannot encrypt an existing system using this method and retain the data. Please ensure that you have backups of your data, or that your data is otherwise expendable. Step 1: The first step in this tutorial is installing the cryptsetup utility. This tool is part of the cryptsetup package, which is available in the default repositories. You can search for this using your favorite package management utility or install from the terminal using the command: sudo aptitude install cryptsetup Step 2: Once you have the required utility installed, we'll need to prepare the device for use. This step will alter the partition table on the device, potentially causing loss of data. Again, refer to the warning above. Identify the Device We need to know the /dev/ entry that the device is assigned in order to successfully partition and encrypt it. There are two methods outlined below which can aid you in determining the device name. In many cases the device may be listed as /dev/sdb1, /dev/sdc1, etc. The first method of identifying the device is using the fdisk utility. Simply listing all available partitions may help you determine the device. Hint: you can use the size of the device to help determine its device entry if needed. [cedwards@daphne ~]$ sudo fdisk -lDisk /dev/sda: 80.0 GB, 80026361856 bytes255 heads, 63 sectors/track, 9729 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytesDisk identifier: 0x000602ca Device Boot Start End Blocks Id System/dev/sda1 * 1 13 104422 83 Linux/dev/sda2 14 46 265072+ 82 Linux swap / Solaris/dev/sda3 47 1003 7687102+ 83 Linux/dev/sda4 1004 9729 70091595 83 LinuxDisk /dev/sdb: 1021 MB, 1021313024 bytes10 heads, 45 sectors/track, 4432 cylindersUnits = cylinders of 450 * 512 = 230400 bytesDisk identifier: 0x00000000 Device Boot Start End Blocks Id System/dev/sdb1 1 4432 997177+ 83 Linux In this example I have determined that my 1G USB drive is detected as /dev/sdb1. This will be the device entry that I will use moving forward. A second method that you can use to determine the device is the dmesg utility. The dmesg utility outputs kernel-level messages to the console. One little "trick" is to unplug and replug your removable disk, and then run dmesg. You should see output similar to: dmesg...usb-storage: device found at 7usb-storage: waiting for device to settle before scanningscsi 8:0:0:0: Direct-Access Kingston DataTraveler 2.0 1.00 PQ: 0 ANSI: 2sd 8:0:0:0: Attached scsi generic sg1 type 0usb-storage: device scan completesd 8:0:0:0: [sdb] 1994752 512-byte logical blocks: (1.02 GB/974 MiB)sd 8:0:0:0: [sdb] Write Protect is offsd 8:0:0:0: [sdb] Mode Sense: 23 00 00 00sd 8:0:0:0: [sdb] Assuming drive cache: write throughsd 8:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1sd 8:0:0:0: [sdb] Assuming drive cache: write throughsd 8:0:0:0: [sdb] Attached SCSI removable diskEXT4-fs (dm-0): mounted filesystem with ordered data mode Again, we can see from this information that the USB device was detected and assigned at sdb1.

0
0
3736

article-image-features-and-utilities-sql-developer-data-modeler

Packt

07 Jan 2010

8 min read

Features and utilities in SQL Developer Data Modeler

Packt

07 Jan 2010

8 min read

0
0
11527

article-image-working-events-mootools-part-2

Packt

07 Jan 2010

10 min read

Working with Events in MooTools: Part 2

Packt

07 Jan 2010

10 min read

Removing, Cloning, and Firing off Events Besides adding event listeners, other operations you may want to do are removing events from an element, cloning events from other elements, and firing off events for elements manually. We'll go through each one of these operations. Removing events from elements There are instances when you want to remove an event listener that you've added to an element. One reason would be that you only want to an element to be triggered once, and after that event has been triggered, you no longer want to trigger it again. To ensure it only fires once, you should remove the event once certain conditions have been met. Removing a single event from elements There are two methods available to you for removing events from elements. The first is removeEvent() which removes a single specified event. Time for action – removing an event Let's say you have some hyperlinks on a page, that when clicked, will alert the user that they have clicked a hyperlink, but you only wanted to do it once. To ensure that the warning message appears only once, we'll have to remove the event after it has been fired. This type of thing may be utilized for instructional tips: when the user sees an unfamiliar interface element, you can display a help tip for them, but only once - because you don't want the tip to keep showing up every single time they perform an action. First, let's put some links on a web page. <a href="#">Hyperlink 1</a> <a href="#">Hyperlink 2</a> Next, let's create a function object that we will call whenever a click event happens on any of the links on our page. When the function fires, it will open up an alert box with a message, and then it will remove the click event from all <a> elements on the web page. // Create an function objectvar warning = function() { alert('You have clicked a link. This is your only warning'); // After warning has executed, remove it $$('a').removeEvent('click', warning);}; Now we add a click event listener that will fire off the warning function object. // Add a click event listener which when triggered, executes the //warning function$$('a').addEvent('click', warning); Our script should look like the following window.addEvent('domready', function(){ // Create an function object that will be executed when a //click happens var warning = function() { alert('You have clicked a link. This is your only warning'); // After warning has executed, remove it from all <a> //elements on the web page $$('a').removeEvent('click', warning); }; // Add a click event listener which when triggered, executes the //warning function $$('a').addEvent('click', warning);}); Test in your web browser by clicking on any of the hyperlinks on the page. The first time you click, you'll see an alert dialog box with our message. The second (or third, forth, fifth… you get the picture) time you click on any hyperlink, the alert dialog box will no longer show up. Removing a type of event, or all events, from elements If you want to remove a type of event on an element (or set of elements), or if you want to remove all events regardless of its type from an element, you have to use the removeEvents method. To remove a type of event from an element, you pass the type of event you want to remove as a parameter of the removeEvents method. For example, if you wanted to remove all click events that were added using MooTools addEvent method from an element called myElement, you would do the following: $('myElement').removeEvents('click'); If instead, you wanted to remove all events that myElement has regardless of the type of event it has, then you would simply run removeEvents as follows: $('myElement').removeEvents(); Cloning events from another element What if you wanted to copy all event listeners from another element. This could be useful in situations where you clone an element using the clone MooTools element method. Cloning an element doesn't copy the event listeners attached to it, so you also have to run the cloneEvents method on the element being cloned if you wanted to also port the event listeners to the copy. To clone the events of an element, follow the format: // clone the elementvar original = $(‘originalElement’);var myClone = original.clone();// clone the events from the originalmyClone.cloneEvents(original); Firing off Events Sometimes you want to fire off events manually. This is helpful in many situations, such as manually firing off an event listener functions that is triggered by another event. For example, to fire off a click event on myElement without having the user actually clicking on myElement, you would do the following: $('myElement').fireEvent('click'); Time for action – firing off a click event Imagine that you have a hyperlink with a click event listener attached to it, that when triggered, alerts the user with a message. But you also want to fire off this alert message when the user presses the Ctrl key. Here's how you'd do this: First, let us place a hyperlink in an HTML document. We'll put it inside a <p> element and tell the users that clicking on the hyperlink or pressing the Ctrl key will open up an alert dialog box. <body> <p>Show a warning by clicking on this link: <a href="#">Click me</a>. Alternatively, you can show the warning by pressing the <strong>Ctrl</strong> key on your keyboard.</p></body> Next, let's add an event to <a> elements. We'll use the addEvent method to do this. // Add a click event$$('a').addEvent('click', function(){ alert('You either clicked a link or pressed the Ctrl key.');}); Now we have to add another event listener onto our HTML document that watches out for a keydown event. The function that the event listener executes will check if the key pressed is the Ctrl key by using the control Event method which returns a Boolean value of true if the Ctrl key is pressed. If the key that was pressed is the Ctrl key, we ask it to fire the click event function that we set in all our a elements by using the fireEvent method with click as its parameter. // Add a keydown event on our web pagewindow.addEvent('keydown', function(e){// If the keypress is the Ctrl key // manually fire off the click event if(e.control) { $$('a').fireEvent('click'); }}); All together, our MooTools script should look like this: window.addEvent('domready', function(){ // Add a click event $$('a').addEvent('click', function(){ alert('You either clicked a link or pressed the Ctrl key.'); }); // Add a keydown event on our web page window.addEvent('keydown', function(e){ // If the keypress is the Ctrl key // manually fire off the click event if(e.control) { $$('a').fireEvent('click'); } });}); Test your HTML document in the web browser. Click on the “Click me” link. It should show you the alert message we created. Press the Ctrl key as well. It should also open up the same alert message we created. The MooTools Event Object The MooTools Event object, which is part of the Native component, is what allows us to create and work with events. It's therefore worth it to take a bit of time to explore the Events object. Using Event Object Methods There are three Event methods: preventDefault, stopPropagation, stop. Preventing the default behavior Events usually has a default behavior; that is, it has a predefined reaction in the instance that the event is triggered. For example, clicking on a hyperlink will direct you to the URL that href property is assigned to. Clicking on a submit input field will submit the form to the value that the action property of the form element is assigned to. Perhaps you want to open the page in a new window, but instead of using the non-standard target property on an <a> element, you can use JavaScript to open the page in a new window. Or maybe you need to validate a form before submitting it. You will want to prevent the default behaviors of an event doing either one of these things. You can use the preventDefault method to do so. Time for action – preventing the default behavior of a hyperlink Imagine that you have a list of hyperlinks that go to popular sites. The thing is, you don't want your website visitors to ever get to see them (at least coming from your site). You can prevent the default behavior of your hyperlinks using the preventDefault method. Here is the HTML markup for a list of <a> elements that go to popular websites. Place it inside an HTML document. <h1>A list of links you can't go to.</h1><ul> <li><a href="http://www.google.com/">Google</a></li> <li><a href="http://www.yahoo.com/">Yahoo!</a></li> <li><a href="http://digg.com/">Digg</a></li> </ul> We will warn the user with an alert dialog box that tells them they can't access the links, even when they click on it. We'll fire this alert dialog box when a user clicks on it. Notice the e argument in the function? That is the event object that is passed into the function, allowing us to access events' methods and properties. $$('a').addEvent('click', function(e){alert('Sorry you can't go there. At least not from this page.'); }); Open your HTML document in a web browser and verify that the links still open their destination, since we haven't prevented the default yet. You will, however, see the alert dialog box we set up in step 2, showing you that, indeed, the click event listener function fires off. Now we will prevent the links from opening by using the preventDefault method. We'll just add the following line above the alert(); line: e.preventDefault(); Test the document again in your web browser. Clicking on any hyperlink opens the alert dialog box, but doesn't open the hyperlink. Preventing event bubbling Event bubbling occurs when you have an element inside another element. When an event is triggered from the child element, the same event is triggered for the parent element, with the child element taking precedence by being triggered first. You can prevent event bubbling using the stopPropagation method. Let's explore the concept of event bubbling and how to prevent it from occurring (if you want to), using the stopPropagation event method.

0
0
4045

How-To Tutorials

Packt

07 Jan 2010

8 min read

CXF architecture

Packt

07 Jan 2010

8 min read

The following figure shows the overall architecture: Bus Bus is the backbone of the CXF architecture. The CXF bus is comprised of a Spring-based configuration file, namely, cxf.xml which is loaded upon servlet initialization through SpringBusFactory. It defines a common context for all the endpoints. It wires all the runtime infrastructure components and provides a common application context. The SpringBusFactory scans and loads the relevant configuration files in the META-INF/cxf directory placed in the classpath and accordingly builds the application context. It builds the application context from the following files: META-INF/cxf/cxf.xml META-INF/cxf/cxf-extension.xml META-INF/cxf/cxf-property-editors.xml The XML file is part of the installation bundle's core CXF library JAR. Now, we know that CXF internally uses Spring for its configuration. The following XML fragment shows the bus definition in the cxf.xml file. <bean id="cxf" class="org.apache.cxf.bus.CXFBusImpl" /> The core bus component is CXFBusImpl . The class acts more as an interceptor provider for incoming and outgoing requests to a web service endpoint. These interceptors, once defined, are available to all the endpoints in that context. The cxf.xml file also defines other infrastructure components such as BindingFactoryManager, ConduitFactoryManager, and so on. These components are made available as bus extensions. One can access these infrastructure objects using the getExtension method. These infrastructure components are registered so as to get and update various service endpoint level parameters such as service binding, transport protocol, conduits, and so on. CXF bus architecture can be overridden, but one must apply caution when overriding the default bus behavior. Since the bus is the core component that loads the CXF runtime, many shared objects are also loaded as part of this runtime. You want to make sure that these objects are loaded when overriding the existing bus implementation. You can extend the default bus to include your own custom components or service objects such as factory managers. You can also add interceptors to the bus bean. These interceptors defined at the bus level are available to all the endpoints. The following code shows how to create a custom bus: SpringBeanFactory.createBus("mycxf.xml") SpringBeanFactory class is used to create a bus. You can complement or overwrite the bean definitions that the original cxf.xml file would use. For the CXF to load the mycxf.xml file, it has to be in the classpath or you can use a factory method to load the file. The following code illustrates the use of interceptors at the bus level: <bean id="cxf" class="org.apache.cxf.bus.spring.SpringBusImpl"> <property name="outInterceptors"> <list> <ref bean="myLoggingInterceptor"/> </list> </property></bean><bean id="myLogHandler" class="org.mycompany.com.cxf.logging. LoggingInterceptor"> ...</bean> The preceding bus definition adds the logging interceptor that will perform logging for all outgoing messages. Frontend CXF provides the concept of frontend modeling, which lets you create web services using different frontend APIs. The APIs let you create a web service using simple factory beans and JAX-WS implementation. It also lets you create dynamic web service clients. The primary frontend supported by CXF is JAX-WS. JAX-WS JAX-WS is a specification that establishes the semantics to develop, publish, and consume web services. JAX-WS simplifies web service development. It defines Java-based APIs that ease the development and deployment of web services. The specification supports WS-Basic Profile 1.1 that addresses web service interoperability. It effectively means a web service can be invoked or consumed by a client written in any language. JAX-WS also defines standards such as JAXB and SAAJ. CXF provides support for complete JAX-WS stack. JAXB provides data binding capabilities by providing a convenient way to map XML schema to a representation in Java code. The JAXB shields the conversion of XML schema messages in SOAP messages to Java code without the developers seeing XML and SOAP parsing. JAXB specification defines the binding between Java and XML Schema. SAAJ provides a standard way of dealing with XML attachments contained in a SOAP message. JAX-WS also speeds up web service development by providing a library of annotations to turn Plain Old Java classes into web services and specifies a detailed mapping from a service defined in WSDL to the Java classes that will implement that service. Any complex types defined in WSDL are mapped into Java classes following the mapping defined by the JAXB specification. As discussed earlier, two approaches for web service development exist: Code-First and Contract-First. With JAX-WS, you can perform web service development using one of the said approaches, depending on the nature of the application. With the Code-first approach, you start by developing a Java class and interface and annotating the same as a web service. The approach is particularly useful where Java implementations are already available and you need to expose implementations as services. You typically create a Service Endpoint Interface (SEI) that defines the service methods and the implementation class that implements the SEI methods. The consumer of a web service uses SEI to invoke the service functions. The SEI directly corresponds to a wsdl:portType element. The methods defined by SEI correspond to the wsdl:operation element. @WebServicepublic interface OrderProcess { String processOrder(Order order);} JAX-WS makes use of annotations to convert an SEI or a Java class to a web service. In the above example, the @WebService annotation defined above the interface declaration signifies an interface as a web service interface or Service Endpoint Interface. In the Contract-first approach, you start with the existing WSDL contract, and generate Java class to implement the service. The advantage is that you are sure about what to expose as a service since you define the appropriate WSDL Contract-first. Again the contract definitions can be made consistent with respect to data types so that it can be easily converted in Java objects without any portability issue. WSDL contains different elements that can be directly mapped to a Java class that implements the service. For example, the wsdl:portType element is directly mapped to SEI, type elements are mapped to Java class types through the use of Java Architecture of XML Binding (JAXB), and the wsdl:service element is mapped to a Java class that is used by a consumer to access the web service. The WSDL2Java tool can be used to generate a web service from WSDL. It has various options to generate SEI and the implementation web service class. As a developer, you need to provide the method implementation for the generated class. If the WSDL includes custom XML Schema types, then the same is converted into its equivalent Java class. Simple frontend Apart from JAX-WS frontend, CXF also supports what is known as 'simple frontend'. The simple frontend provides simple components or Java classes that use reflection to build and publish web services. It is simple because we do not use any annotation to create web services. In JAX-WS, we have to annotate a Java class to denote it as a web service and use tools to convert between a Java object and WSDL. The simple frontend uses factory components to create a service and the client. It does so by using Java reflection API. The following code shows a web service created using simple frontend: // Build and publish the serviceOrderProcessImpl orderProcessImpl = new OrderProcessImpl();ServerFactoryBean svrFactory = new ServerFactoryBean();svrFactory.setServiceClass(OrderProcess.class);svrFactory.setAddress("http://localhost:8080/OrderProcess");svrFactory.setServiceBean(orderProcessImpl);svrFactory.create(); Messaging and Interceptors One of the important elements of CXF architecture is the Interceptor components. Interceptors are components that intercept the messages exchanged or passed between web service clients and server components. In CXF, this is implemented through the concept of Interceptor chains. The concept of Interceptor chaining is the core functionality of CXF runtime. The interceptors act on the messages which are sent and received from the web service and are processed in chains. Each interceptor in a chain is configurable, and the user has the ability to control its execution. The core of the framework is the Interceptor interface. It defines two abstract methods—handleMessage and handleFault. Each of the methods takes the object of type Message as a parameter. A developer implements the handleMessage to process or act upon the message. The handleFault method is implemented to handle the error condition. Interceptors are usually processed in chains with every interceptor in the chain performing some processing on the message in sequence, and the chain moves forward. Whenever an error condition arises, a handleFault method is invoked on each interceptor, and the chain unwinds or moves backwards. Interceptors are often organized or grouped into phases. Interceptors providing common functionality can be grouped into one phase. Each phase performs specific message processing. Each phase is then added to the interceptor chain. The chain, therefore, is a list of ordered interceptor phases. The chain can be created for both inbound and outbound messages. A typical web service endpoint will have three interceptor chains: Inbound messages chain Outbound messages chain Error messages chain There are built-in interceptors such as logging, security, and so on, and the developers can also choose to create custom interceptors.

0
0
3166

How-To Tutorials

article-image-selecting-dom-elements-using-mootools-12-part-2

Packt

07 Jan 2010

7 min read

Selecting DOM Elements using MooTools 1.2: Part 2

Packt

07 Jan 2010

7 min read

Time for action – using pseudo-classes to zebra stripe a table Let's set up the markup for our HTML table - it'll have three columns and six rows listing my favorite movies in order. Pseudo-class example HTML table markup: <body><table width="100%" cellpadding="1" cellspacing="0">  <tr> <th>Rank</th> <th>Movie</th> <th>Genre</th> </tr> <tr> <td>1</td> <td>The Matrix</td> <td>Action</td> </tr> <tr> <td>2</td> <td>Die Hard</td> <td>Action</td> </tr> <tr> <td>3</td> <td>The Dark Knight</td> <td>Action</td> </tr> <tr> <td>4</td> <td>Friday</td> <td>Comedy</td> </tr> <tr> <td>5</td> <td>Love Actually</td> <td>Drama</td> </tr></table></body> Our HTML table should look like this: To color even rows with a light gray color, write this line of code (again, we use the .setStyle() method): $$('table tr:even').setStyle( 'background-color', '#ebebeb' ); Save your work. View your document in a web browser. You should see something like this: Now we're going to style the odd rows. This time, instead of .setStyle(), we're going to use the .setStyles() method so that we can supply more than one CSS property/CSS property value pair to be implemented. Here's the code to accomplish what we set out to do (which you can place right below the code in step 1): $$('table tr:odd').setStyles( { 'background-color' : '#252525', 'color' : '#ffffff'} ); Save your work and view your work in a web browser. Your HTML table that contains my favorite movies of all time should now looks like this: What just happened? We just learned one of the many ways where pseudo-class selectors are helpful. In this case, we took a regular HTML table and zebra striped it so that we have different styles at alternating rows. To zebra stripe our HTML table, we used the :even and :odd pseudo-class selectors to change the background color of even row with a light gray color (#ebebeb in hexadecimal) and all odd rows of our tables with a dark gray background (#252525) with a white foreground color (#ffffff). A couple of notes on the :odd and :even pseudo-class selectorsThe :odd and :even pseudo-classes aren't available in W3C specifications; although the concept of using them is the same, they are custom MooTools pseudo-class selectors.Secondly, the index of each one starts at 0. Because of this, using :even would select the first element (index 0) and third child elements because their index is actually 0 and 2, respectively. So they're kind of switched around in the conventional sense of odd and even. Other Pseudo-class selectors There are nine MooTools pseudo-class selectors as of version 1.2: Pseudo-class Selector Description :contains Matches elements that contain a particular text string. For example, matching all <div>'s with the text "I love MooTools" is $$('div:contains(I love MooTools)') :empty Matches elements that don't contain anything. For example, $$(div:empty) would match this: <div></div> :enabled Matches elements that are enabled. Usually used in <input> tags. :even Matches all child elements that have an even index. For example, if there are four paragraphs, using $$('p:even') would select the first and third paragraphs (remember that the index starts at 0). :first-child Matches the first child element (i.e. the child with an index of 0). For example, if there are four paragraphs in a <div> element, using $$('div p:first-child') would select the first paragraph inside the <div> element. :last-child Matches the last child element (i.e. the child with the highest index). For example, if there are four paragraphs in a <div> element, using $$('div p:last-child') will select the fourth paragraph inside the <div> element. :not Matches elements that do not match a particular selector. For example, matching all paragraphs that do not have the class .intro would be $$('p:not(.intro)'). :nth-child Matches the nth expression child element. You can use mathematical expressions. For example, $$('div:nth-child(3n+1)') would select the first div (3(0)+1 = index 0 position), 4th div (3(1)+1 = index 4 position)... 3(n)+1 index position. You can also use, as an argument: even, odd, first, and last as in div:nth-child(even) which is exactly like the :even pseudo-class selector. :odd Matches all child elements with an odd index. For example, If there are four paragraphs, using $$('p:odd') would select the second paragraph and fourth paragraph (index 1 position and index 3 position). :only-child Matches all elements that are the only children of the only child element. For example, $$(p:only-child) would match the paragraph <div><p>only child></p></div> but will not match these paragraphs <div>><p>not an only child></p>><p>not only child></p></div> because it has a sibling paragraph. Working with attribute selectors If you thought MooTools can't get any cooler with element selection - well, it gets much better. MooTools also implements CSS3's Attribute Selectors. An Attribute Selector allows you to select elements based on their CSS attributes, also commonly referred to as properties in MooTools. For example, an <input> tag's type is considered one of its attributes (or properties), so is its class <input type=”text” name=”query” value=”” /> In MooTools (as well as CSS3), the syntax for an attribute selector is as follows: element[attribute=attribute value] For example, if we wanted to select all <input> elements with a type of text, we would write: $$('input[type=text]'); Attribute selector operators Attribute selectors can match attribute values various ways using Attribute selector operators. The following table depicts a list and description of each attribute selector operator. Operator Description = Matches attribute value exactly and literally. For example, $$('a[class=myLinkClass]') will match all <a> elements with the class of myLinkClass. != Matches all elements with the attribute value that is not the value given. For example, $$('a[class!=myLinkClass]') will select all <a> elements that doesn't have the class of myLinkClass. ^= Matches all elements with attribute value that starts with the value given. For example, $$('img[src^=big]') will match all images with the src attribute value the begins with the word big, such as big-picture.png or biggiesmalls.jpg. $= Matches all elements with the attribute value that ends with the value given. For example, $$('img[src$=.jpg]') will select all images that end with .jpg - useful in selecting particular file extensions. Attribute Selector example: styling different types of links Often, you want to indicate to a user what a particular type of link is. For example, you may want to indicate to the user that a particular link goes to another website or that a link is a mailto: link that will open up their default email client. Perhaps, you want to highlight all links that point to a particular domain name like sixrevisions.com.

0
0
1596

How-To Tutorials

article-image-working-forms-dynamics-ax-part-1

Packt

07 Jan 2010

12 min read

Working with Forms in Dynamics AX: Part 1

Packt

07 Jan 2010

12 min read

Introduction Normally, forms are created using AOT by creating a form object and adding form controls like tabs, tab pages, grids, groups, data fields, images, and other. Form behavior is controlled by its properties or the code in its member methods. The behavior and layout of form controls are also controlled by their properties and the code in their member methods. Although it is very rare, forms can also be created dynamically from code. In this article, we will cover various aspects of using Dynamics AX forms. We start with building Dynamics AX dialogs, which actually are dynamic forms, and explain how to handle their events. The article will also show how to add dynamic controls to existing forms, how to build dynamic forms from scratch, how to make forms modal, and how to change the appearance of all application forms with a few lines of code. This article also discusses the usage of splitters, tree controls, creating checklists, saving last user selections, modifying application version, and other things. Creating Dialogs Dialogs are a way to present users with a simple input form. They are commonly used for small user tasks like filling in report values, running batch jobs, presenting only the most important fields to the user when creating a new record, etc. Dialogs are normally created from X++ code without storing actual layout in AOT. The application class Dialog is used to build dialogs. Other application classes like DialogField, DialogGroup , DialogTabPage, and so on, are used to create dialog controls. One of the common ways is to use dialogs within RunBase framework classes that need user input. In this example, we will see how to build a dialog from code using the RunBase framework class. The dialog will contain customer table fields shown in different groups and tabs for creating a new record. There will be two tab pages, General and Details. The first page will have Customer account and Name input controls. The second page will be divided into two groups, Setup and Payment, with relevant fields. The actual record will not be created, as it is out of scope of this example. However, for demonstration purposes, the information specified by the user will be displayed in the Infolog. How to do it... Open AOT, and create a new class CustCreate with the following code: class CustCreate extends RunBase{ DialogField fieldAccount; DialogField fieldName; DialogField fieldGroup; DialogField fieldCurrency; DialogField fieldPaymTermId; DialogField fieldPaymMode; CustAccount custAccount; CustName custName; CustGroupId custGroupId; CurrencyCode currencyCode; CustPaymTermId paymTermId; CustPaymMode paymMode;}public container pack(){ return connull();}public boolean unpack(container packedClass){ return true;}protected Object dialog(){ Dialog dialog; DialogTabPage tabGeneral; DialogTabPage tabDetails; DialogGroup groupCustomer; DialogGroup groupPayment; ; dialog = super(); dialog.caption("Customer information"); tabGeneral = dialog.addTabPage("General"); fieldAccount = dialog.addField( typeid(CustVendAC), "Customer account"); fieldName = dialog.addField(typeid(CustName)); tabDetails = dialog.addTabPage("Details"); groupCustomer = dialog.addGroup("Setup"); fieldGroup = dialog.addField(typeid(CustGroupId)); fieldCurrency = dialog.addField(typeid(CurrencyCode)); groupPayment = dialog.addGroup("Payment"); fieldPaymTermId = dialog.addField(typeid(CustPaymTermId)); fieldPaymMode = dialog.addField(typeid(CustPaymMode)); return dialog;}public boolean getFromDialog(){; custAccount = fieldAccount.value(); custName = fieldName.value(); custGroupId = fieldGroup.value(); currencyCode = fieldCurrency.value(); paymTermId = fieldPaymTermId.value(); paymMode = fieldPaymMode.value(); return true;}public void run(){; info("You have entered customer information:"); info(strfmt("Account: %1", custAccount)); info(strfmt("Name: %1", custName)); info(strfmt("Group: %1", custGroupId)); info(strfmt("Currency: %1", currencyCode)); info(strfmt("Terms of payment: %1", paymTermId)); info(strfmt("Method of payment: %1", paymMode));}static void main(Args _args){ CustCreate custCreate = new CustCreate(); ; if (custCreate.prompt()) { custCreate.run(); }} To test the dialog, run the class. The following form should appear with the General tab page open initially: When you click on the Details tab page, you will see the following screen: Enter some information into the fields, and click OK. The results are displayed in the Infolog: How it works... Firstly, we create a new class CustCreate. By extending it from RunBase, we utilize the standard approach of running such kinds of dialogs. RunBase will also automatically add the required buttons to the dialog. Then we declare class member variables, which will be used later. DialogField type variables are actual user input fields. The rest are used to store the values returned from user input. The pack() and unpack() methods are normally used to convert an object to a container, which is a format to store an object in the user cache (SysLastValue) or to transfer it between Server and Client tiers. RunBase requires those two methods to be present in all its subclasses. In this example, we are not using any of the pack()/unpack() features, but because those methods are mandatory, we return an empty container from pack() and true from unpack(). The layout of the actual dialog is constructed in the dialog() member method. Here, we define local variables for the dialog itself, tab pages, and groups. Those variables, as opposed to the dialog fields, do not store any value to be processed further. The super() of the RunBase framework creates the initial dialog object for us. The object is created using the Dialog application class. The class actually uses the Dynamics AX form as a base, automatically adds the relevant controls, including OK and Cancel buttons, and presents it to the user as a dialog. Additional dialog controls are added to the dialog by using the addField(), addGroup(), and addTabPage() methods . There are more methods to add different types of controls like addText(), addImage(), addMenuItemButton(), and others. All controls have to be added to the dialog object directly. Adding an input control to groups or tabs is done by calling addField() right after addGroup() or addTabPage(). In the example above, we add tab pages, groups, and fields in logical sequence, so every control appears in the right position. The method returns a prepared dialog object for further processing. Values from the dialog controls are assigned to variables by calling the value() member method of DialogField. If a dialog is used within the RunBase framework, as in this example, the best place to assign dialog control values to variables is the getFormDialog() member method. RunBase calls this method right after the user clicks OK. The main processing is done in run(). For demonstration purposes, this example contains only variable output to Infolog. In order to make this class runable, the static method main() has to be created. Here, we create a new CustCreate object, invoke user dialog by calling prompt(), and once the user finishes entering customer details by clicking OK, we call run() to process the data. Handling dialog events Sometimes, the user interface requires us to change the status of a field, depending on the status of another field. For example, if the user marks the Show filter checkbox, another field, Filter, appears or becomes enabled. In standard Dynamics AX forms, this can be done using input control event modified() . But sometimes such features are required on dialogs where handling events is not that straightforward. Very often, I find myself in a situation where existing dialogs need to be adjusted to support events. The easiest way of doing that is of course to build a form in AOT, which will replace the original dialog. But in cases when the existing dialog is complex enough, probably a more cost effective solution would be to implement dialog event handling. It is not as flexible as AOT forms, but in most cases it does the job. In this recipe, we will create a dialog very similar to the previous one, but instead of entering the customer number, we will be able to select it from the list. Once the customer is selected, the rest of the fields will be filled automatically by the system from the customer record. How to do it... In AOT, create a new class named CustSelect with the following code: class CustSelect extends RunBase{ DialogField fieldAccount; DialogField fieldName; DialogField fieldGroup; DialogField fieldCurrency; DialogField fieldPaymTermId; DialogField fieldPaymMode;}public container pack(){ return connull();}public boolean unpack(container packedClass){ return true;}protected Object dialog(){ Dialog dialog; DialogTabPage tabGeneral; DialogTabPage tabDetails; DialogGroup groupCustomer; DialogGroup groupPayment; ; dialog = super(); dialog.caption("Customer information"); dialog.allowUpdateOnSelectCtrl(true); tabGeneral = dialog.addTabPage("General"); fieldAccount = dialog.addField( typeid(CustAccount), "Customer account"); fieldName = dialog.addField(typeid(CustName)); fieldName.enabled(false); tabDetails = dialog.addTabPage("Details"); groupCustomer = dialog.addGroup("Setup"); fieldGroup = dialog.addField(typeid(CustGroupId)); fieldCurrency = dialog.addField(typeid(CurrencyCode)); fieldGroup.enabled(false); fieldCurrency.enabled(false); groupPayment = dialog.addGroup("Payment"); fieldPaymTermId = dialog.addField(typeid(CustPaymTermId)); fieldPaymMode = dialog.addField(typeid(CustPaymMode)); fieldPaymTermId.enabled(false); fieldPaymMode.enabled(false); return dialog;}public void dialogSelectCtrl(){ CustTable custTable; ; custTable = CustTable::find(fieldAccount.value()); fieldName.value(custTable.Name); fieldGroup.value(custTable.CustGroup); fieldCurrency.value(custTable.Currency); fieldPaymTermId.value(custTable.PaymTermId); fieldPaymMode.value(custTable.PaymMode);}static void main(Args _args){ CustSelect custSelect = new CustSelect(); ; if (CustSelect.prompt()) { CustSelect.run(); }} Run the class, select any customer from the list, and move the cursor to the next control. Notice how the rest of the fields were populated automatically with the customer information: When you click on Details tab page, you will see the details as in following screenshot: How it works... The new class CustSelect is a copy of CustCreate from the previous recipe with few changes. In its declaration, we leave all DialogField declarations. We remove all other variables apart from Customer account. The Customer account input control is the only editable field on the dialog, so we have to keep it for storing its value. The methods pack()/unpack() remain the same as we are not using any of their features. In the dialog() member method, we call allowUpdateOnSelect() with the argument true to enable input control event handling. We also disable all fields apart from Customer account by calling enable() with parameter false for every field. The member method dialogSelectCtrl() of the RunBase class is called every time the user modifies any input control in the dialog. It is the place where we have to add all the required code to ensure that, in our case, all controls are populated with the correct data from the customer record, once the Customer account is chosen. Static main() method ensures that we can run this class. There's more... Usage of dialogSelectCtrl() sometimes might appear a bit limited as this method is only invoked when the dialog control loses its focus. No other events can be controlled, and it can become messy if more controls needs to be processed. Actually, this method is called from the selectControl() of the form, which is used as a base for the dialog. As mentioned earlier, dialogs created using the Dialog class are actually forms, which are dynamically created during runtime. So in order to extend event handling functionality on dialogs, we should utilize form event handling features. The Dialog class does not provide direct access to form event handling functions, but we can easily access the form object within the dialog. Although we cannot create the usual event handling methods on runtime form controls, we can override this behavior. Let's modify the previous example to include more events. We will add an event on the second tab page, which is triggered once the page is activated. First, we have to override the dialogPostRun() method on the CustSelect class: public void dialogPostRun(DialogRunbase dialog){; dialog.formRun().controlMethodOverload(true); dialog.formRun().controlMethodOverloadObject(this); super(dialog);} Here, we enable event overriding on the form after it is fully created and is ready for displaying on the screen. We also pass the CustSelect object as argument for the controlMethodOverloadObject() to make sure that form "knows" where overridden events are located. Next, we have to create the method that overrides the tab page event: void TabPg_2_pageActivated(){; info('Tab page activated');} The method name consists of the control name and event name joined with an underscore. But before creating such methods, we first have to get the name of the runtime control. This is because the dialog form is created dynamically, and Dynamics AX defines control names automatically without allowing the user to choose them. In this example, I have temporary added the following code to the bottom of dialog(), which displayed the name of the Details tab page control when the class was executed: info(tabDetails.name()); Now, run the class again, and select the Details tab page. The message should be displayed in the Infolog. Creating dynamic menu buttons Normally, Dynamics AX forms are created in AOT by adding various controls to the form's design and do not change during runtime. But besides that, Dynamics AX allows developers to add controls dynamically during form runtime. Probably, you have already noticed that the Document handling form in the standard Dynamics AX application has a nice option to create a new record by clicking the New button and selecting the desired document type from the list. This feature does not add any new functionality to the application, but it provides an alternative way of quickly creating a new record and it makes the form more user-friendly. The content of this button is actually generated dynamically during the initialization of the form and may vary depending on the document handling setup. There might be other cases when such features can be used. For example, dynamic menu buttons could be used to display a list of statuses, which depends on the type of the selected record. In this recipe, we will explore the code behind this feature. As an example, we will modify the Ledger budget button on the Chart of accounts form to display a list of available budget models relevant only for the selected ledger account. That means the list is going to be generated dynamically and may be different for different accounts.

0
0
8339

How-To Tutorials

Packt

07 Jan 2010

11 min read

jBPM for Developers: Part 2

Packt

07 Jan 2010

11 min read

Process execution At this point, where our definitions are ready, we can create an execution of our defined processes. This can be achieved by creating a class where each instance represents one execution of our process definition—bringing our processes to life and guiding the company with their daily activities; letting us see how our processes are moving from one node to the next one. With this concept of execution, we will gain the power of interaction and influence the process execution by using the methods proposed by this class. We are going to add all of the methods that we need to represent the executional stage of the process, adding all the data and behavior needed to execute our process definitions. This process execution will only have a pointer to the current node in the process execution. This will let us query the process status when we want. An important question about this comes to our minds: why do we need to interact with our processes? Why doesn't the process flow until the end when we start it? And the answer to these important questions is: it depends. The important thing here is to notice that there will be two main types of nodes: One that runs without external interaction (we can say that is an automatic node). These type of nodes will represent automatic procedures that will run without external interactions. The second type of node is commonly named wait state or event wait. The activity that they represent needs to wait for a human or a system interaction to complete it. This means that the system or the human needs to create/fire an event when the activity is finished, in order to inform the process that it can continue to the next node. Wait states versus automatic nodes The difference between them is basically the activity nature. We need to recognize this nature in order to model our processes in the right way. As we have seen before, a "wait state" or an "event wait" situation could occur when we need to wait for some event to take place from the point of view of the process. These events are classified into two wide groups—Asynchronous System Interactions and Human tasks. Asynchronous System Interactions This means the situation when the process needs to interact with some other system, but the operation will be executed in some asynchronous way. For non-advanced developers, the word "asynchronous" could sound ambiguous or without meaning. In this context, we can say that an asynchronous execution will take place when two systems communicate with each other without blocking calls. This is not the common way of execution in our Java applications. When we call a method in Java, the current thread of execution will be blocked while the method code is executed inside the same thread. See the following example: The doBackup() method will block until the backup is finished. When this happens, the call stack will continue with the next line in the main class. This blocking call is commonly named as a synchronous call. On the other hand, we got the non-blocking calls, where the method is called but we (the application) are not going to wait for the execution to finish, the execution will continue to the next line in the main class without waiting. In order to achieve this behavior, we need to use another mechanism. One of the most common mechanisms used for this are messages. Let's see this concept in the following image: In this case, by using messages for asynchronous executions, the doBackup() method will be transformed into a message that will be taken by another thread (probably an external system) in charge of the real execution of the doBackup() code. The main class here will continue with the next line in the code. It's important for you to notice that the main thread can end before the external system finishes doing the backup. That's the expected behavior, because we are delegating the responsibility to execute the backup code in the external system. But wait a minute, how do we know if the doBackup() method execution finished successfully? In such cases, the main thread or any other thread should query the status of the backup to know whether it is ready or not. Human tasks Human tasks are also asynchronous, we can see exactly the same behavior that we saw before. However, in this case, the executing thread will be a human being and the message will be represented as a task in the person's task list. As we can see in this image, a task is created when the Main thread's execution reaches the doBackup() method. This task goes directly to the corresponding user in the task list. When the user has time or is able to do that task, he/she completes it. In this case, the "Do Backup" activity is a manual task that needs to be performed by a human being. In both the situations, we have the same asynchronous behavior, but the parties that interact change and this causes the need for different solutions. For system-to-system interaction, probably, we need to focus on the protocols that the systems use for communication. In human tasks, on the other hand, the main concern will probably be the user interface that handles the human interaction. How do we know if a node is a wait state node or an automatic node?First of all, by the name. If the node represents an activity that is done by humans, it will always wait. In system interactions, it is a little more difficult to deduce this by the name (but, if we see an automatic activity that we know takes a lot of time, that will probably be an asynchronous activity which will behave as a wait state). A common example could be a backup to tape, where the backup action is scheduled in an external system. If we are not sure about the activity nature we need to ask about the activity nature to our stakeholder. We need to understand these two behaviors in order to know how to implement each node's executional behavior, which will be related with the specific node functionality. Creating the execution concept in Java With this class, we will represent each execution of our process, which means that we could have a lot of instances at the same time running with the same definition. Inside the package called org.jbpm.examples.chapter02.simpleGOP.execution (provided at www.packtpub.com/files/code/5685_Code.zip), we will find the following class: public class Execution { private Definition definition; private Node currentNode; public Execution(Definition definition) { this.definition = definition; //Setting the first Node as the current Node this.currentNode = definition.getNodes().get(0); } public void start(){ // Here we start the flow leaving the currentNode. currentNode.leave(this); }... (Getters and Setters methods)} As we can see, this class contains a Definition and a Node, the idea here is to have a currentNode that represents the node inside the definition to which this execution is currently "pointing". We can say that the currentNode is a pointer to the current node inside a specific definition. The real magic occurs inside each node. Now each node has the responsibility of deciding whether it must continue the execution to the next node or not. In order to achieve this, we need to add some methods (enter(), execute(), leave()) that will define the internal executional behavior for each node. We do this in the Node class to be sure that all the subclasses of the Node class will inherit the generic way of execution. Of course, we can change this behavior by overwriting the enter(), execute(), and leave() methods. We can define the Node.java class (which is also found in the chapter02.simpleGOPExecution project in the code bundle) as follows: ...public void enter(Execution execution){ execution.setCurrentNode(this); System.out.println("Entering "+this.getName()); execute(execution);}public void execute(Execution execution){ System.out.println("Executing "+this.getName()); if(actions.size() > 0){ Collection<Action> actionsToExecute = actions.values(); Iterator<Action> it = actionsToExecute.iterator(); while(it.hasNext()){ it.next().execute(); } leave(execution); }else{ leave(execution); }}public void leave(Execution execution){ System.out.println("Leaving "+this.getName()); Collection<Transition> transitions = getLeavingTransitions().values(); Iterator<Transition> it = transitions.iterator(); if(it.hasNext()){ it.next().take(execution); }}... As you can see in the Node class, which is the most basic and generic implementation, three methods are defined to specify the executional behavior of one of these nodes in our processes. If you carefully look at these three methods, you will notice that they are chained, meaning that the enter() method will be the first to be called. And at the end, it will call the execute() method, which will call the leave() method depending on the situation. The idea behind these chained methods is to demarcate different phases inside the execution of the node. All of the subclasses of the Node class will inherit these methods, and with that the executional behavior. Also, all the subclasses could add other phases to demarcate a more complex lifecycle inside each node's execution. The next image shows how these phases are executed inside each node. As you can see in the image, the three methods are executed when the execution points to a specific node. Also, it is important to note that transitions also have the Take phase, which will be executed to jump from one node to the next. All these phases inside the nodes and in the transition will let us hook custom blocks of code to be executed. One example for what we could use these hooks for is auditing processes. We could add in the enter() method, that is the first method called in each node, a call to an audit system that takes the current timestamp and measures the time that the node uses until it finishes the execution when the leave() method is called. Another important thing to notice in the Node class is the code inside the execute() method. A new concept appears. The Action interface that we see in that loop, represents a pluggable way to include custom specific logic inside a node without changing the node class. This allows us to extend the node functionality without modifying the business process graph. This means that we can add a huge amount of technical details without increasing the complexity of the graph. For example, imagine that in our business process each time we change node, we need to store the data collected from each node in a database. In most of the cases, this requirement is purely technical, and the business users don't need to know about that. With these actions, we achieve exactly the above. We only need to create a class with the custom logic that implements the Action interface and then adds it to the node in which we want to execute the custom logic. The best way to understand how the execution works is by playing with the code. In the chapter02.simpleGOPExecution maven project, we have another test that shows us the behavior of the execution class. This test is called TestExecution and contains two basic tests to show how the execution works. If you don't know how to use maven, there is a quick start guide at the end of this article. You will need to read it in order to compile and run these tests. public void testSimpleProcessExecution(){ Definition definition = new Definition("myFirstProcess"); System.out.println("########################################"); System.out.println(" Executing PROCESS: "+definition.getName()+" "); System.out.println("########################################"); Node firstNode = new Node("First Node"); Node secondNode = new Node("Second Node"); Node thirdNode = new Node("Third Node"); firstNode.addTransition("to second node", secondNode); secondNode.addTransition("to third node", thirdNode); //Add an action in the second node. CustomAction implements Action secondNode.addAction(new CustomAction("First")); definition.addNode(firstNode); definition.addNode(secondNode); definition.addNode(thirdNode); //We can graph it if we want. //definition.graph(); Execution execution = new Execution (definition); execution.start(); //The execution leave the third node assertEquals("Third Node", execution.getCurrentNode().getName());} If you run this first test, it creates a process definition as in the definition tests, and then using the definition, it creates a new execution. This execution lets us interact with the process. As this is a simple implementation, we only have the start() method that starts the execution of our process, executing the logic inside each node. In this case, each node is responsible for continuing the execution to the next node. This means that there are no wait state nodes inside the example process. In case we have a wait state, our process will stop the execution in the first wait state. So, we need to interact with the process again in order to continue the execution. Feel free to debug this test to see how this works. Analyze the code and follow the execution step by step. Try to add new actions to the nodes and analyze how all of the classes in the project behave. When you get the idea, the framework internals will be easy to digest.

0
0
1950

article-image-introducing-sql-developer-data-modeler-part-2

Packt

07 Jan 2010

9 min read

Introducing SQL Developer Data Modeler: Part 2

Packt

07 Jan 2010

9 min read

Working with diagrams and their components You can waste away many hours laying out the elements on a diagram. Therefore, this aspect of modeling can be time consuming. However, a model serves as documentation and a communication device. Therefore, taking the time to make sure it is well annotated and clearly designed is important. Most of the controls for the models are on the context menu, allowing you to modify individual aspects of the diagram. The context menu changes depending on whether you have an object or line selected, or you're just clicking in the open space. You can also set general defaults using Tools | General Options | Diagram. In this section, we'll look at the various options available when working with the diagrams. Formatting the elements Before moving a relationship line, entity, or table, you can dramatically change the impact and readability of a large diagram just by changing the colors. This is readily demonstrated when importing from two or more schemas. Using the previous example where we imported from two schemas, open one of the subviews and select all of the tables. With the objects selected, invoke the Format Object dialog using the context menu: If this is the first time you are adjusting the colors, the dialog does not display any colors as you open it. The colors used in the diagram are the default settings. Deselect Use Default Color and click on the Background and Border Color items to select and set the new color. When you are done, click on OK and note the changes applied to the subview. Switch to the main relational model to review the impact there. The color applied to the subview is also applied to the main model as shown. This is very useful when illustrating how tables in different schemas relate to each other. For example, take the HR and OE sample schema, all of the tables related to human resources are maintained in the HR schema, while those related to the order entry system are maintained in the OE schema. You may well have applications designed around the HR schema and others tied to the OE schema, but some may involve both. In the following relational model, the OE tables are now colored green, so we're able to identify them, but we can also see where the schemas link. We can see that a CUSTOMER may deal with one EMPLOYEE and has many ORDERS: Selecting all of the tables in a modelSelect any table and click on Select Neighbors from the context menu. Select All Zones, to select all of the tables. Use this instead of Ctrl+A, which selects all tables and all lines. Changing the default format settings Instead of changing individual items or even a set of items, you can change the default color for each of the element types displayed on a diagram. The Tools | General Options | Diagram | Format provides the ability to control the color of each of the elements displayed such as tables, views, and entities: To edit any of the elements in the dialog, double-click on the object, or select the object and the edit icon. This allows you to adjust the color of the item and to format the font. You can use the font color to highlight mandatory, Unique, or Foreign Keys. Setting general diagram properties Use the same Tools | General Options | Diagram to set model properties,which include: Displaying the grid Controlling the background color of the diagram Controlling the Auto Route feature which is on by default Set display properties for certain items on each of the models, including the control of: The diagram notation for the logical model, which supports the Barker and Bachman notations The display of the relationship names for either the logical or relational models The flow names for process models For example, to display the relationship names on an Entity Relationship Diagram (as seen below), check the display property on the Tools | General Options | Model | Logical, and ensure that the Relation Cardinality properties for the relationships are also set. Creating subviews and displays Adding subviews and displays offers you alternative ways of laying out elements on a diagram and for working with subsets of items. You can create multiple subviews and displays for either logical or relational models, and remove them as easily, without impacting the main models. Adding subviews to your design You have already encountered a subview by importing from a number of schemas in the data dictionary. Subviews are not only a reflection of the different schemas in a design, but they can also represent any subset of elements in the design, allowing you to work with a smaller, more manageable set of elements. You can create a subview from the object browser by selecting: The SubViews node and using the New SubView context menu. In this case, you have a new empty diagram that you can populate by dragging tables or entities (depending on the subview in question) onto the page. Any of the model tabs and then selecting the Create SubView menu. This creates a new and empty subview. An element or elements on an existing model and using the Create SubView from selected context menu on the diagram. In this case, the new subview will contain the tables or entities you selected: The layout of the subview is not linked to the main model in any way. What is linked is how you format the items on the subview and any structural changes you make to the objects. You can continue to add new items to the subview by dragging them onto the surface from the object browser. When deleting items from the subview, you should choose whether the item is deleted: From the view (Delete View) From the complete design (Delete Object) Adding displays A display is an alternative view of a diagram, whether a main model or a subview, and is linked directly to that model. If you delete the model, the display is also deleted. Any items that you add or remove from displays are also automatically added or removed from the main model they are linked to. To create a new display, select the tab of any model and select Create Display from the context menu. The new display created is, initially, a replica of the model you selected in both layout and items available. All additional displays are listed at the bottom of the model. In the following example, the HR subview has two displays created, as highlighted at the bottom of the screenshot, the main HR display and the new Display_1. The Create Display context menu is also illustrated: Use the new display to change the layout of the model and to adjust the level of detail displayed on the diagram. A second display of the same model is useful when you want to show more or less detail on a model. You can, for example, create a display which only displays the entity or table names. Right-click in the space on a diagram and select View Details | Names Only. We'll discuss how to layout the diagram elements later. Creating a composite view If you create a number of subviews, create a new diagram showing the composite models of each of these on a single layout. This serves as a useful reminder of the number of subviews or models you have by having a thumbnail of the various layouts. Alternatively, you can add a composite view of one subview and place it on another. To create a composite view, select the model in the browser and drag it onto the diagram surface. You can drag any model onto any other diagram surface, except its own: Once you have the composite folder displayed on the diagram, display the composite model within that folder by selecting Composite View from the context menu. If the model you want to view has a selection of displays, then you can also select the display you want to see within that composite. The following screenshot shows the, subview, displaying the composite models of the HR subview, the main logical model, and both displays of the logical model: Controlling the layout When working with a large number of items in a model, it's important to keep the layout organized. A variety of tools to help with the process are explained in the following sections. Adjusting the level of detail displayed Change the amount of detail displayed in a table (or entity) using the View Details menu. It is invoked with a right-click on the white space of any diagram. The View Details menu has options for displaying: All Details Names Only Columns Datatype Keys Adjusting the width and height across the model If you have a large diagram and want to see how tables or entities relate to each other, you can create a more compact model using a display, without impacting the main model. This can be done by setting the details to display the name only and then resizing and repositioning the objects. In the following screenshot, we have set the model to display only the name of the tables. Create a more compact diagram by resizing one of the tables to a more fitting set of dimensions, select the rest, and then resize them all to the same width and height: Controlling alignment Once you have positioned the items, align them to complete the model. Use the Edit menu with the required items for top and left alignment as shown in the following screenshot: Resizing and alignmentThe first item you select is the one that drives the position for left or top alignment, and the item that controls the width and height of all subsequent items selected.

0
0
7108

article-image-selecting-dom-elements-using-mootools-12-part-1

Packt

07 Jan 2010

7 min read

Selecting DOM Elements using MooTools 1.2: Part 1

Packt

07 Jan 2010

7 min read

In order to successfully and effortlessly write unobtrusive JavaScript, we must have a way to point to the Document Object Model (DOM) elements that we want to manipulate. The DOM is a representation of objects in our HTML and a way to access and manipulate them. In traditional JavaScript, this involves a lot (like, seriously a lot) of code authoring, and in many instances, a lot of head-banging-against-wall-and-pulling-out-hair as you discover a browser quirk that you must solve. Let me save you some bumps, bruises, and hair by showing you how to select DOM elements the MooTools way. This article will cover how you can utilize MooTools to select/match simple (like, "All div elements") up to the most complex and specific elements (like, "All links that are children of a span that has a class of awesomeLink and points to http://superAwesomeSite.com MooTools and CSS selectors MooTools selects an element (or a set of elements) in the DOM using CSS selectors syntax. Just a quick refresher on CSS terminology, a CSS style rule consists of: selector { property: property value; } selector: indicates what elements will be affected by the style rule. property: the CSS property (also referred to as attribute). For example, color is a CSS property, so is font-style. You can have multiple property declarations in one style rule property value: the value you want assigned to the property. For example, bold is a possible CSS property value of the font-weight CSS property. For example, if you wanted to select a paragraph element with an ID of awesomeParagraph to give it a red color (in hexadecimal, this is #ff0), in CSS syntax you'd write: #awesomeParagraph { color: #ff0; } Also, if I wanted to increase its specificity and make sure that only paragraph elements that have an ID of awesomeParagraph is selected: p#awesomeParagraph { color: #ff0;} You'll be happy to know that this same syntax ports over to MooTools. What's more is that you'll be able to take advantage of all of CSS3's more complex selection syntax because even though CSS3 isn't supported by all browsers yet, MooTools supports them already. So you don't have to learn another syntax for writing selectors, you can use your existing knowledge of CSS - awesome, isn't it? Working with the $() and $$() functions The $() and $$() functions are the bread and butter of MooTools. When you're working with unobtrusive JavaScript, you need to specify which elements you want to operate on. The dollar and dollars functions help you do just that - they will allow you to specify what elements you want to work on. Notice, the dollar sign $ is shaped like an S, which we can interpret to mean 'select'. The $() dollar function The dollar function is used for getting an element by it's ID, which returns a single element that is extended with MooTools Element methods or null if nothing matches. Let's go back to awesomeParagraph in the earlier example. If I wanted to select awesomeParagraph, this is what I would write: $('awesomeParagraph’) By doing so, we can now operate on it by passing methods to the selection. For example, if you wanted to change its style to have a color of red. You can use the .setStyle() method which allows you to specify a CSS property and its matching property value, like so $('awesomeParagraph').setStyle('color', '#ff0'); The $$() dollars function The $$() function is the $() big brother (that's why it gets an extra dollar sign). The $$() function can do more robust and complex selections, can select a group, or groups of element’s and always returns an array object, with or without selected elements in it. Likewise, it can be interchanged with the dollar function. If we wanted to select awesomeParagraph using the dollars function, we would write: $$('#awesomeParagraph') Note that you have to use the pound sign (#) in this case as if you were using CSS selectors. When to use which If you need to select just one element that has an ID, you should use the $() function because it performs better in terms of speed than the $$() function. Use the $$() function to select multiple elements. In fact, when in doubt, use the$$() function because it can do what the $() function can do (and more). A note on single quotes (') versus double quotes ("")The example above would work even if we used double quotes such as $("awesomeParagraph") or $$("#awesomeParagraph") ") - but many MooTools developers prefer single quotes so they don’t have to escape characters as much (since the double quote is often used in HTML, you'll have to do "in order not to prematurely end your strings). It's highly recommended that you use single quotes - but hey, it's your life! Now, let's see these functions in action. Let's start with the HTML markup first. Put the following block of code in an HTML document: <body> <ul id="superList"> <li>List item</li> <li><a href="#">List item link</a></li> <li id="listItem">List item with an ID.</li> <li class="lastItem">Last list item.</li> </ul></body> What we have here is an unordered list. We'll use it to explore the dollar and dollars function. If you view this in your web browser, you should see something like this: Time for action – selecting an element with the dollar function Let's select the list item with an ID of listItem and then give it a red color using the .setStyle() MooTools method. Inside your window.addEvent('domready') method, use the following code: $('listItem').setStyle('color', 'red'); Save the HTML document and view it on your web browser. You should see the 3rd list item will be red. Now let's select the entire unordered list (it has an ID of superList), then give it a black border (in hexadecimal, this is #000000). Place the following code, right below the code the line we wrote in step 1: $('superList').setStyle('border', '1px solid #000000'); If you didn't close your HTML document, hit your browser's refresh. You should now see something like this: Time for action – selecting elements with the dollars function We'll be using the same HTML document, but this time, let's explore the dollars function. We're going to select the last list item (it has a class of lastItem). Using the .getFirst(), we select the first element from the array $$() returned. Then, we're going to use the .get() method to get its text. To show us what it is, we'll pass it to the alert() function. The code to write to accomplish this is: alert( $$('.lastItem').getFirst().get('text') ); Save the HTML document and view it in your web browser (or just hit your browser's refresh button if you still have the HTML document from the preview Time for action open). You should now see the following: Time for action – selecting multiple sets of elements with the dollars function What if we wanted to select multiple sets of elements and run the same method (or methods) on them? Let's do that now. Let's select the list item that has an <a> element inside it and the last list item (class="lastItem") and then animate them to the right by transitioning their margin-left CSS property using the .tween() method. Right below the line we wrote previously, place the following line: $$('li a, .lastItem').tween('margin-left', '50px'); View your work in your web browser. You should see the second and last list item move to the right by 50 pixels. What just happened? We just explored the dollar and dollars function to see how to select different elements and apply methods on them. You just learned to select: An element with an ID (#listItem and #superList) using the dollar $() function An element with a class (.lastItem) using the dollars $$() function Multiple elements by separating them with commas (li and .lastItem) You also saw how you can execute methods on your selected elements. In the example, we used the .setStyle(), .getFirst(), get(), and .tween() MooTools methods. Because DOM selection is imperative to writing MooTools code, before we go any further, let's talk about some important points to note about what we just did.

0
0
7823

How-To Tutorials

article-image-developing-web-service-cxf

Packt

07 Jan 2010

9 min read

Developing a Web Service with CXF

Packt

07 Jan 2010

9 min read

In this article we will basically study the sample Order Processing Application and discuss the following points: Developing a service Developing a client The Order Processing Application The objective of the Order Processing Application is to process a customer order. The order process functionality will generate the customer order, thereby making the order valid and approved. A typical scenario will be a customer making an order request to buy a particular item. The purchase department will receive the order request from the customer and prepare a formal purchase order. The purchase order will hold the details of the customer, the name of the item to be purchased, the quantity, and the price. Once the order is prepared, it will be sent to the Order Processing department for the necessary approval. If the order is valid and approved, then the department will generate the unique order ID and send it back to the Purchase department. The Purchase department will communicate the order ID back to the customer. For simplicity, we will look at the following use cases: Prepare an order Process the order The client application will prepare an order and send it to the server application through a business method call. The server application will contain a web service that will process the order and generate a unique order ID. The generation of the unique order ID will signify order approval. In real world applications a unique order ID is always accompanied by the date the order was approved. However, in this example we chose to keep it simple by only generating order ID. Developing a service Let's look specifically at how to create an Order Processing Web Service and then register it as a Spring bean using a JAX-WS frontend. The Sun-based JAX-WS specification can be found at the following URL: http://jcp.org/aboutJava/communityprocess/final/jsr224/index.html JAX-WS frontend offers two ways of developing a web service—Code-first and Contract-first. We will use the Code-first approach, that is, we will first create a Java class and convert this into a web service component. The first set of tasks will be to create server-side components. In web service terminology, Code-first is termed as the Bottoms Up approach, and Contract-first is referred to as the Top Down approach. To achieve this, we typically perform the following steps: Create a Service Endpoint Interface (SEI) and define a business method to be used with the web service. Create the implementation class and annotate it as a web service. Create beans.xml and define the service class as a Spring bean using a JAX-WS frontend. Creating a Service Endpoint Interface (SEI) Let's first create the SEI for our Order Processing Application. We will name our SEI OrderProcess. The following code illustrates the OrderProcess SEI: package demo.order; import javax.jws.WebService; @WebService public interface OrderProcess { @WebMethod String processOrder(Order order); } As you can see from the preceding code, we created a Service Endpoint Interface named OrderProcess. The SEI is just like any other Java interface. It defines an abstract business method processOrder. The method takes an Order bean as a parameter and returns an order ID String value. The goal of the processOrder method is to process the order placed by the customer and return the unique order ID. One significant thing to observe is the @WebService annotation. The annotation is placed right above the interface definition. It signifies that this interface is not an ordinary interface but a web service interface. This interface is known as Service Endpoint Interface and will have a business method exposed as a service method to be invoked by the client. The @WebService annotation is part of the JAX-WS annotation library. JAX-WS provides a library of annotations to turn Plain Old Java classes into web services and specifies detailed mapping from a service defined in WSDL to the Java classes that will implement that service. The javax.jws.WebService annotation also comes with attributes that completely define a web service. For the moment we will ignore these attributes and proceed with our development. The javax.jws.@WebMethod annotation is optional and is used for customizing the web service operation. The @WebMethod annotation provides the operation name and the action elements which are used to customize the name attribute of the operation and the SOAP action element in the WSDL document. The following code shows the Order class: package demo.order;import javax.xml.bind.annotation.XmlRootElement;@XmlRootElement(name = "Order")public class Order { private String customerID; private String itemID; private int qty; private double price; // Contructor public Order() { } public String getCustomerID() { return customerID; } public void setCustomerID(String customerID) { this.customerID = customerID; } public String getItemID() { return itemID; } public void setItemID(String itemID) { this.itemID = itemID; } public int getQty() { return qty; } public void setQty(int qty) { this.qty = qty; } public double getPrice() { return price; } public void setPrice(double price) { this.price = price; }} As you can see, we have added an @XmlRootElement annotation to the Order class. The @XmlRootElement is part of the Java Architecture for XML Binding (JAXB) annotation library. JAXB provides data binding capabilities by providing a convenient way to map XML schema to a representation in Java code. The JAXB shields the conversion of XML schema messages in SOAP messages to Java code without having the developers know about XML and SOAP parsing. CXF uses JAXB as the default data binding component. The @XmlRootElement annotations associated with Order class map the Order class to the XML root element. The attributes contained within the Order object by default are mapped to @XmlElement. The @XmlElement annotations are used to define elements within the XML. The @XmlRootElement and @XmlElement annotations allow you to customize the namespace and name of the XML element. If no customizations are provided, then the JAXB runtime by default would use the same name of attribute for the XML element. CXF handles this mapping of Java objects to XML. Developing a service implementation class We will now develop the implementation class that will realize our OrderProcess SEI. We will name this implementation class OrderProcessImpl. The following code illustrates the service implementation class OrderProcessImpl: @WebServicepublic class OrderProcessImpl implements OrderProcess { public String processOrder(Order order) { String orderID = validate(order); return orderID; }/** * Validates the order and returns the order ID**/ private String validate(Order order) { String custID = order.getCustomerID(); String itemID = order.getItemID(); int qty = order.getQty(); double price = order.getPrice(); if (custID != null && itemID != null && !custID.equals("") && !itemID.equals("") && qty > 0 && price > 0.0) { return "ORD1234"; } return null; }} As we can see from the preceding code, our implementation class OrderProcessImpl is pretty straightforward. It also has @WebService annotation defined above the class declaration. The class OrderProcessImpl implements OrderProcess SEI. The class implements the processOrder method. The processOrder method checks for the validity of the order by invoking the validate method. The validate method checks whether the Order bean has all the relevant properties valid and not null. It is recommended that developers explicitly implement OrderProcess SEI, though it may not be necessary. This can minimize coding errors by ensuring that the methods are implemented as defined. Next we will look at how to publish the OrderProcess JAX-WS web service using Spring configuration. Spring-based server bean What makes CXF the obvious choice as a web service framework is its use of Spring-based configuration files to publish web service endpoints. It is the use of such configuration files that makes the development of web service convenient and easy with CXF. Spring provides a lightweight container which works on the concept of Inversion of Control (IoC) or Dependency Injection (DI) architecture; it does so through the implementation of a configuration file that defines Java beans and its dependencies. By using Spring you can abstract and wire all the class dependencies in a single configuration file. The configuration file is often referred to as an Application Context or Bean Context file. We will create a server side Spring-based configuration file and name it as beans.xml. The following code illustrates the beans.xml configuration file: <beans xsi_schemaLocation="http://www.springframework.org/schema/beanshttp://www.springframework.org/schema/beans/spring-beans.xsdhttp://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd"> <import resource="classpath:META-INF/cxf/cxf.xml" /> <import resource="classpath:META-INF/cxf/cxf-extension- soap.xml" /> <import resource="classpath:META-INF/cxf/cxf-servlet.xml" /> <jaxws:endpoint id="orderProcess" implementor="demo.order.OrderProcessImpl" address="/OrderProcess" /></beans> Let's examine the previous code and understand what it really means. It first defines the necessary namespaces. It then defines a series of <import> statements. It imports cxf.xml, cxf-extension-soap.xml, and cxf-servlet.xml. These files are Springbased configuration files that define core components of CXF. They are used to kick start CXF runtime and load the necessary infrastructure objects such as WSDL manager, conduit manager, destination factory manager, and so on. The <jaxws:endpoint> element in the beans.xml file specifies the OrderProcess web service as a JAX-WS endpoint. The element is defined with the following three attributes: id—specifies a unique identifier for a bean. In this case, jaxws:endpoint is a bean, and the id name is orderProcess. implementor— specifies the actual web service implementation class. In this case, our implementor class is OrderProcessImpl. address— specifies the URL address where the endpoint is to be published. The URL address must to be relative to the web context. For our example, the endpoint will be published using the relative path /OrderProcess. The <jaxws:endpoint> element signifies that the CXF internally uses JAX-WS frontend to publish the web service. This element definition provides a short and convenient way to publish a web service. A developer need not have to write any Java class to publish a web service.

0
0
3329

How-To Tutorials

article-image-working-events-mootools-part-1

Packt

07 Jan 2010

9 min read

Working with Events in MooTools: Part 1

Packt

07 Jan 2010

9 min read

We have a lot of things to cover in this article, so hold on to your seats and enjoy the ride! What are Events, Exactly? Events are simply things that happen in our web pages. MooTools supports all HTML 4.01 event attributes like onclick and onmouseout, but the framework refers to them without the "on" prefix (click instead of onclick, mouseout instead of onmouseout). What's neat about MooTools is that it not only extends HTML 4.01 event attributes with a few of its own, but also ensures that methods and functions that deal with web page events work across all web browsers by providing us with a solid, built-in object called Events. Event is part of the Native component of MooTools, and is also referred to as the Event hash. You can read the official W3C specifications on events, in the HTML 4.01 Specification, section 18.2.3, under Intrinsic Events:http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.3 We'll go over all of the available event attributes in MooTools so you can learn what stuff we can listen to. There are several events that we can detect or "listen to". We can, for the sake of discussion, divide them into five groups: window events, form events, keyboard events, mouse events, and MooTools custom events. Window Events Window events refer to activities that occur in the background. There are only two window events. HTML Event attribute / MooTools event name What is it? onload / load This event occurs when the window and images on the page has fully loaded and/or when all of the iFrames in the page have loaded. It can be used for monitoring when the web page has fully loaded (such as when you want to know if all images have been downloaded). onunload / unload This even happens when a window or an iFrame is removed from the web page. It has limited use. Form events There are events that occur within Form elements (such as <input> elements), and we'll refer to these as form events. For example, the onfocus event is triggered when the user clicks on an input field (you'll see this in action in this article), effectively focusing on that particular input field. Some of these events apply event to non-form elements. HTML Event attribute / MooTools event name What is it? onblur / blur This event occurs when an element loses focus, either because the user has clicked out of it, or because the user used the Tab key to move away from it. This is helpful for monitoring the instant the user loses focus on a particular element. onchange / change This event happens when the element loses focus or when its original value has changed. This is helpful for knowing when the user starts typing in a input text field or textarea, or when a user selects a different option in a select drop-down element. onfocus / focus This event is the opposite, of the blur event: it is triggered when the user focuses on an element. This is useful for watching when the user highlights a form field or when they have navigated to it using the Tab key. onreset / reset This event only applies to form elements. This event is triggered when the form has been reset to its default values. onselect / select This event happens when the user highlights (selects) text in a text field. onsubmit / submit This event is only for form elements. This event occurs when the user submits a web form. Keyboard events There are events that happen when a user presses on a keyboard input device; let's call these keyboard events. For example, the onkeypress event is triggered when you press any key on your keyboard. HTML Event attribute / MooTools event name What is it? onkeydown / keydown This event occurs when the user holds down a keyboard key. onkeypress / keypress This event is triggered whenever the user presses a keyboard key. onkeyup /keyup This event happens when the user releases a key. Mouse events There are several HTML event properties that allow you to deal with activities related to the mouse. Clicking, moving, double-clicking, and hovering are all mouse events. HTML Event attribute / MooTools event name What is it? onclick / click This event occurs whenever the user uses the mouse button to click on an element. ondblclick / dblclick This even occurs whenever the user double-clicks on an element. onmousedown / mousedown This event occurs when the mouse button is held down. onmouseup / mouseup This even occurs when the mouse button is released. onmousemove / mousemove This event occurs when the mouse is moved. onmouseout / mouseout This event occurs when the mouse pointer is removed from the target element. onmouseover / mouseover This event occurs when the mouse pointer enters the target element. MooTools Custom Mouse Events MooTools supplies us with three custom events that extend the standard mouse events. MooTools event name What is it? mouseenter This event is triggered when the user's mouse pointer enters an element, but does not fire again when the mouse goes over a children element (unlike mouseover). This is useful for detecting the mouseover event once in nested element structures, such as <li><a>item</a></li>. If we were to use the mouseover event, it would be triggered twice, once for <li> and once again for <a>. mouseleave This event works similarly to mouseenter in that it is triggered only once when the mouse pointer exits the target element. Unlike the mouseout event, which will be triggered more than once for nested element structures. mousewheel This even is triggered when the scroller on a mouse is used (available in most modern mice input devices, usually situated in between the left and right mouse buttons). Adding Event Listeners We can attach event listeners to elements on a web page using the addEvent and addEvents method. By doing so, we're able to find out whenever that event happens, as well as execute a function to react to them. Adding event listeners is the basis for interactivity and is where JavaScript (and subsequently) MooTools has gained its popularity. Imagine being able to perform an operation whenever a user hovers over an image, or clicks on a link, or whenever the user submits a form -- the possibilities are endless. Adding a single event listener The addEvent method allows you to add one event listener to an element method and follows the format: $(yourelement).addEvent(event, function(){}) For example, in the following code block, we attach a click event listener for all <a> elements. When the user clicks on any hyperlink on our web page, it runs a function that opens up an alert dialog box that says You clicked on a hyperlink. $$('a').addEvent('click', function(){ alert('You clicked on a hyperlink');}); In a moment, we'll create a simple web form the highlights the input field that the user is focused on. Time for action – Highlighting focused fields of web forms Let's start with our web form's HTML. We'll use <input> and <textarea> tags that will hold our user's information as well as provide them a means to submit the web form (input type="button").We use the <label> tag to indicate to the user what information to put inside each form field. <form action="" method="get"> <p><label for="Name">Name: </label> <input name="Name" type="text"></p> <p><label for="Email">Email: </label> <input name="Email" type="text"></p> <p><label for="Comment">Comment: </label> <textarea name="Comment" cols="" rows=""></textarea></p> <p><input name="Submit" type="button" value="Submit"></p></form> With the above markup, this is how our form looks like: Our web form is a bit dull, so how about we spruce it up a bit with some CSS? Read the comments to gain insight on some of the more important CSS properties to take a note off. /* Center the fields using text-align:center */form { width:300px; border:1px solid #b1b8c2; background-color:#e3e9f2; text-align:center; padding:25px 0;}label { display:block; font:12px normal Verdana, Geneva, sans-serif;}/* Give the input and textarea fields a 1px border */input, textarea { width:250px; border:1px solid #5c616a;}textarea { height:100px;}p { text-align:left; display:block; width:250px; overflow:auto; padding:0; margin:5px 0;}/* We will give fields that are currently focused on the .focus class which will give them a distinct thicker border and background color compared to the other input fields */.focused { border:3px solid #b1b8c2; background-color: #e8e3e3;} With just a few styles, our simple web form has transformed to a more attractive form field. Let us move onto the JavaScript. We use the addEvent method to add an event listener for the form event, onfocus. When the user focuses on a particular field, we run a function that adds the .focus CSS class on that field we declared as a style rule in step 2. We'll also remove .focus class on other fields on the web page. window.addEvent('domready', function(){ var els = $$('input, textarea') els.addEvent('focus', function(){ els.removeClass('focused'); this.addClass('focused'); })}); Now, when you focus on a form field, it will be highlighted with a thick blue border and with a lighter blue background. Users who use the Tab key to navigate in between form fields will appreciate this feature since they'll clearly see which field is active. What just happened? In the previous example, we created a simple and interactive web form that highlights the current field the user has active. We did this by using the addEvent method, adding an event listener for the focus form event. When the user focuses on a particular input field, we ran a function that adds the .focusCSS class which highlights the focused field <input> or <textarea>with a thick blue border with a light blue background. By highlighting active fields in a web form, we have just improved our form's usability by providing visual feedback about which field the user is currently on.

0
0
2136

How-To Tutorials

Packt

07 Jan 2010

10 min read

jBPM for Developers: Part 1

Packt

07 Jan 2010

10 min read

In this article, the following key points will be covered: Common development process Decoupling processes from our applications Graph Oriented Programming Modeling nodes Modeling transitions Expanding our language Implementing our graph-oriented solution in Java Wait states versus automatic nodes Executing our processes Let's get started with the main cornerstone behind the framework. This article will give us the way to represent our business processes using the Java language and all the points that you need to cover in order to be able to represent real situations. Graph Oriented Programming We will start talking about the two main concepts behind the framework's internal implementation. The Graph Oriented Programming (GOP) approach is used to gain some features that we will want when we need to represent business processes inside our applications. Basically, graph oriented programming gives us the following features: Easy and intuitive graphical representation Multi-language support These are concepts that jBPM implementers have in mind when they start with the first version of the framework. We are going to take a quick look at that and formulate some code in order to try to implement our minimal solution with these features in mind. Starting with GOP as a bigger concept, you will see that the official documentation of jBPM mentions this topic as one of the most important concepts behind the framework. Here, we will reveal all of the advantages that this approach implementation will give us. Basically, by knowing GOP, we will gain complete knowledge about how processes are represented and how they are executed. Therefore, a common question here is, why do we need a new approach (GOP) for programming our processes when we have already learnt about the object-oriented programming paradigm? Common development process In order to answer the previous question, we will quickly analyze the situation here. To achieve this, we need to understand the nature of our processes. We will also analyze what kind of advantages developers gain when the business process information is decoupled from the rest of the application code. Let's clarify this point with a simple example. Imagine that we have to build an entire application that represents the stages in the "Recycling Things Co." example previously presented. The most common approach for a three-tier application and development process will be the following: This is a traditional approach where all the stages are iteratively repeated for each stage/module of the application. One thing that we can notice here, and which happens in real software projects, is that the business analyst's description will be lost in the design phase, because the business analyst doesn't fully understand the design class diagrams as these diagrams are focused on implementation patterns and details. If we are lucky and have a very good team of business analysts, they will understand the diagrams. However, there is no way that they could understand the code. So, in the best case, the business analyst description is lost in the code—this means that we cannot show our clients how the stages of their processes are implemented in real working code. That is why business analysts and clients (stakeholders) are blind. They need to trust that we (the developers) know what we are doing and that we understand 100 percent of the requirements that the business analysts collect. Also, it is important to notice that in most of the cases, the client validates the business analyst's work—if changes emerge in the implementation phase, sometimes these changes are not reflected in the business analyst's text and the client/stakeholders never realize that some implementation aspect of their software changes. Maybe they are not functional changes, but there are sometimes changes that affect the behavior of the software or the way users will interact with it. This uncertainty generated in the stakeholder causes some dependency and odd situations where the stakeholder thinks that if he/she cannot count on us (the developers and architects team) any longer, nobody will be able to understand our code (the code that we write). With this new approach, the client/stakeholders will be able to perceive, in a transparent way, the code that we write to represent each business situation. This allows them (the stakeholders) to ask for changes that will be easily introduced to reflect everyday business requirements. Let's be practical and recognize that, in most situations, if we have the application implemented in a three-tier architecture, we will have the following artifacts developed: Database model That includes logic tables to do calculations, UI tables to store UI customizations or users' data about their custom interfaces, domain entities (tables that represent the business entities, for example, Invoice, Customer, and so on), and history logs all together. Business logic If we are careful developers, here we are going to have all of the code related to a logical business processes method. In the case of the example, here we will have all the stages represented in some kind of state machine in the best cases. If we don't have a kind of state machine, we will have a lot of if and switch statements distributed in our code that will represent each stage in the process. For example, if we have the same application for all the branches of a company, this application will need to behave differently for the main office's employee than for the 'just finished' warehouse employee. This is because the tasks that they are doing are very different in nature. Imagine what would happen if we want to add some activity in the middle, probably the world would collapse! Developers will need to know in some depth how all the if and switch statements are distributed in the code in order to add/insert the new activity. I don't want to be one of these developers. User interfaces Once again, if we are lucky developers, the process stages will not be represented here, but probably many if and switch statements will be dispersed in our UI code that will decide what screen is shown to each of the users in each activity inside the process. So, for each button and each form, we need to ask if we are in a specific stage in the process with a specific user. Decoupling processes from our applications By decoupling the business process from these models, we introduce an extra layer (tier) with some extra artifacts, but this helps us to keep the application simple. This new paradigm proposed here includes the two Business Process Management (BPM) roles in all the development and execution stages of our processes (business analysts and developers). This is mainly achieved through the use of a common language that both sides understand. It lets us represent the current process that the business analysts see in the everyday work inside the company, and all of the technical details that these processes need, in order to run in a production environment. As we can see in the next image, both roles interact in the creation of these new artifacts. We don't have to forget about the clients/managers/stakeholders that can validate the processes every day as they are running them. Also, they can ask for changes to improve the performance and the current way used to achieve the business goal of the process. On comparing with the OOP paradigm, class diagrams here are commonly used to represent static data, but no executional behavior. These newly created artifacts (process definitions) can be easily represented in order to be validated by our clients/stakeholders. One of the main advantages of this approach is that we can get visibility about how the processes are executed and which activity they are in at any given moment of time. This requirement will force us to have a simple way to represent our business processes—in a graphicable way. We need to be able to see, all the time, how our production processes are running. Graph Oriented Programming on top of OOP Here, we will discuss the main points of the Graph Oriented Programming paradigm. With this analysis, we will implement some basic approach to understand how we use this paradigm on top of the Java language in the next section. In order to do that, we need to know the most important requisites that we have to fulfill in order to achieve the goal which integrates, maintains, and executes our business processes in real-world implementation: Easy and intuitive graphical representation: To let the business analysts and developers communicate smoothly and to fully understand what is happening in the real process. Must give us the possibility of seeing the processes' executions in real time: In order to know how our processes are going on to make more accurate business decisions. Could be easily extended to provide extra functionality to fulfill all of the business situations. Could be easily modified and adapted to everyday business (reality) changes. No more huge development projects for small changes and no more migrations. Implementing Graph Oriented Programming on top of the Java language (finally Java code!) With these requisites, presented in the previous section, in mind, we are able to implement a simple solution on top of the Java language that implements this new approach (called the Graph Oriented Programming paradigm). As the name of the paradigm says, we are going to work with graphs—directed graphs to be more precise. A graph can be defined as a set of nodes linked to each other as the following image shows us: If we are talking about directed graphs, we need to know that our nodes will be linked using directed transitions. These transitions will be directed, because they will define a source node and a destination node. This means that if we have a transition that has node A as the source node, and node B as the destination node, that transition will not be the same as the one that has node B as the source node, and node A as the destination node. Take a look at the following image: Like in the object-oriented programming paradigm, we need to have a language with specific set of words (for example, object) here. We will need words to represent our graphs, as we can represent objects in the object-oriented paradigm. Here we will try to expand the official documentation proposed by the jBPM team and guide the learning process of this important topic. We will see code in this section and I will ask you to try it at home, debug it, and play with this code until you feel confident about what is the internal behavior of this example. Let's get started first with the graph definition and with some of the rules that the graph needs to implement, in order to represent our business processes correctly. Up until now, we have had two concepts that will appear in our graph oriented programming language—Node and Transition. These two concepts need to be implemented in two separate classes, but with a close relationship. Let's see a class diagram about these two classes and make a short analysis about the attributes and methods proposed in this example.

0
0
1945

article-image-getting-started-sql-developer-part-2

Packt

07 Jan 2010

6 min read

Getting Started with SQL Developer: Part 2

Packt

07 Jan 2010

6 min read

A quick overview Let's start with a run-through of the product. By spending a little time dipping into a number of areas of the product, you can start laying down a map of how the pieces connect and provide a base that you can drill down into later. Sample schemas To follow the examples in the article, you need access to SYSTEM and the shipped sample schemas, HR, OE, SH, PM, and IX available in Oracle Database 9i, 10g, or 11g. Specifcally, this article uses the sample schemas shipped with Oracle Database 11g. There are two ways to install the sample schema. The first way is when you install the database. You can elect to have the sample schema installed at that point. Second, if you have not installed these, then you can locate the sample schema in the $ORACLE_HOME/demo/schema folder and follow the instructions on installing them using the Oracle online documentation. Not all of these schemas are available for Oracle Express Edition. In this article, we use SYSTEM to verify the HR schema is unlocked, and then we use the HR sample schema, which is available in Oracle Express Edition. Creating your first connection To complete this quick walk through, you need to know the username and password of the SYSTEM user. You also need to know the location of the database, whether this is the machine name or the IP address, and the database SID. To begin, start SQL Developer. The very first time you start SQL Developer, you'll be asked if you want to migrate from a previous version. Select No and allow the tool to start up. The first thing you need to do after you have started SQL Developer for the first time is to create your initial connections. Create a connection for SYSTEM: Select Connections, right-click and select New Connection. This invokes the New Database Connection dialog. You can edit and control all of the connection details using this dialog. Complete the details, as seen in the following screenshot, relevant to your environment. Click on Test to ensure you have the connection details correct and click on Connect. You are now connected as SYSTEM. Use this connection to verify your other users, by continuing as follows: Select the new connection you have created, expand the node, and scroll down to Other Users. Expand Other Users and find the user HR. Right-click and select Edit User. Verify that the account for HR is unlocked and the Password has not expired, that is, the properties Account is Locked and Password Expired are deselected. If either of these is selected, deselect them. You can change the password for HR at this point too. It's good practice to modify the passwords of the shipped sample schemas once you have unlocked them. Now you are really ready to begin! Once again, select Connections, right-click and select New Connection. Give the connection a name (for example, HR_11g. Provide the Username (HR) and a Password. If you are working on Oracle Database 11g, be aware that passwords are now case sensitive. Select the Save Password checkbox. This makes life easy while you are working with SQL Developer. Passwords are stored in an encrypted file. However, you should always be aware of saving passwords and possible security implications this may have. Use the Basic connection. This requires no more detail than the location of the database and the SID, details you have. Click on Test to test the connection. Click on Connect. Using basic commands in the SQL Worksheet As soon as you connect to a user, SQL Developer opens an SQL Worksheet. You may have started working with Oracle using the SQL*Plus command line, or even the GUI window. Either way, you'd start with a selection of SQL*Plus and SQL commands. Enter the following into the SQL Worksheet: DESC DEPARTMENTSSELECT * FROM DEPARTMENTS; Press the F5 key (or use the Run Script button). The output of both commands appears in the Script Output tab, which appears below the SQL Worksheet (as seen in the previous screenshot). Both commands are handled by a few simple clicks of the mouse in SQL Developer. Select and expand the HR_11g connection in the Connections navigator. Expand the Tables node and select DEPARTMENTS. The DEPARTMENTS tab now opens, displaying a list of the column names and details. These are the same details as given by the DESC (describe) SQL*Plus command that you entered in the SQL Worksheet. It also provides additional detail, such as the Primary Key and column comments. Select the Data tab and notice that you now see the output from your second command. These two tabs are included with a number of other tabs, each with additional details about the DEPARTMENTS table. You would need to write a number of SQL queries in order to get the additional detail from the data dictionary if you were working in SQL*Plus. Select the EMPLOYEES table. Notice that the new table, EMPLOYEES, immediately replaces the previous DEPARTMENTS table with its details. Select the Triggers tab, and select one of the triggers. The trigger and related trigger detail is displayed in a master-detail window: Browsing and updating data Return to the EMPLOYEES data by again selecting the Data tab. The data grid that is displayed provides a variety of options. To get started with the data grid, double-click on an item or field, such as the name of one of the employees, and change it. Tab out of the field and notice that the change is applied to the data grid and an asterisk (*) flags the record. Commit and Rollback buttons are available to send the change to the database, or to undo your action. Roll back the changes. Once again you get feedback, this time in the Data Editor log, as shown in the following screenshot: Running reports Select the Reports navigator and expand the Data Dictionary Reports node. Expand the Table node and review the available reports. Expand Constraints and select the Unique Constraints report. As you select the report, a dialog displays requesting the Connection name. Select the connection you created, HR_11g, and click on OK. An Enter Bind Values dialog now appears, requesting the table name as an input parameter. Click on Apply to accept the default, which in this case, means all tables: Run the same report for any user by selecting the Connections drop-down list on the right-hand side. Navigating around SQL Developer SQL Developer has a selection of windows, navigators, and tabs. On start-up, you are presented with the main navigator toolbars and menus: The two main navigators: Connections and Reports, are presented in a tabbed window. These and other navigators, such as the Versioning Navigator, are available through the main View menu. You can also open windows such as Snippets, Recent Objects, and Find DB Objects using the View menu. Any navigators that you open during a session, and that are still open when you close the product, are automatically opened when you restart the product.

0
0
2673

article-image-getting-started-sql-developer-part-1

Packt

07 Jan 2010

8 min read

Getting Started with SQL Developer: Part 1

Packt

07 Jan 2010

8 min read

Preparing your environment Preparing your environment depends on a few factors, including the platform you are working on and whether you have an early edition of SQL Developer previously installed. First, you need to locate the software, download, and install it. Finding and downloading the software SQL Developer is available through a variety of sources as both a standalone download and as part of the Oracle Database and Oracle JDeveloper installations. SQL Developer is a free product, and you can download it from the Oracle Technology Network, http://www.oracle.com/technology/products/database/sql_developer. Use this link to reach the download for the latest standalone production release. It also includes details of the release and is regularly updated with news of preview releases and new articles. While SQL Developer is free to download and use, you are required to read and agree to the license before you can proceed with the download. The product also falls under Oracle Support contracts, if you have a Support contract for the database, which means that you can log Oracle Support tickets. Downloading and installing the Java Development Kit SQL Developer requires the Java SE Development Kit (JDK); this includes the Java Runtime Environment (JRE) and other tools, which are used by SQL Developer utilities such as the PL/SL Debugger. For Microsoft Windows, you can download and install SQL Developer with the JDK already installed. This means you'll download and unzip the product and will be ready to start, as there are no extra steps required. For the other operating systems, you'll need to download the JDK and direct SQL Developer to the path yourself. Indeed, as many other products require a JDK to be installed, you may already have one on your system. In this case, just direct the product to use an existing JDK installation. For Microsoft Windows, ensure you download SQL Developer without the JDK to make use of an existing JDK installation. The SQL Developer download site offers a selection of download choices: Microsoft Windows (with or without the JDK) Linux (without the JDK) Mac OS X (without the JDK) In each case, make your selection and download the required file. The download sites for the JDK are as follows: For Microsoft Windows and Linux: http://java.sun.com/javase/downloads/index.jsp For Mac:http://developer.apple.com/java/download/ SQL Developer is shipped with the minimum JDK required. You can download and use the latest updates to the JDK. You should be aware that some updates to the JDK are not supported. This detail is posted on the SQL Developer Downloads page for each release. Starting from SQL Developer 2.1, JDK 1.6 is the minimum JDK supported. Once you have installed the JDK, you can start SQL Developer. Installing and starting SQL Developer SQL Developer does not use an installer. All you need to do is unzip the given file into an empty folder, locate, and run the executable. Do not unzip SQL Developer into an $Oracle_Home folder or an existing SQL Developer install. Unzipping the file creates an sqldeveloper folder, which includes a selection of sub-folders and fles, including the sqldeveloper.exe executable. If your download does not include the JDK, then you'll be prompted for the full path of the java.exe. Browse to the location of the fle and select it. The path should include the full path and executable (for example, C:Program FilesJavajdk1.6.0_13binjava.exe): Working with different platforms Whether you are accessing SQL Developer as part of the Oracle Database 11g installation or as a stand-alone install, there is a selection of executables available to you. These are either platform specifc or provide additional detail while running the product. Microsoft Windows The first executable you'll find is in the root folder sqldeveloper. This is the executable more generally used. If you navigate down to sqldeveloperbin, there are two additional executables, sqldeveloper.exe and sqldeveloperW.exe. The latter is the same as the executable in the root folder. Use either of these for running SQL Developer. The additional executable is often used for debugging purposes. Use sqldeveloperbinsqldeveloper.exe to invoke SQL Developer and a separate console window which displays additional Java messages. You can use these messages when encountering errors in the product and if you want to log an issue with Oracle Support. Oracle SQL DeveloperThree steps to getting started on Microsoft Windows:Download: Download the full file, with JDK, from the Oracle Technology Network websiteUnzip: Unzip the file to an empty directoryDouble-click: Double-click on the sqldevelopersqldeveloper.exe file Alternative platforms Microsoft Windows is the predominant platform used by SQL Developer users. There is a steadily growing audience for Linux and Max OS X. As neither of these platform downloads include the JDK, you need to first access, download, and install the JDK. On starting either Linux or the Mac OS, you'll be prompted for the full path of the JDK as described. Mac OS X Download the file specific to Mac OS X and unzip it to an empty folder. This creates an sqldeveloper folder, complete with files and sub-folders. Run the sqldeveloper.sh file. Linux Use the Linux rpm command to install SQL Developer. For example, your command might look like this: rpm -Uhv sqldeveloper-1.5.54.40-1.noarch.rpm In the same way that unzip creates an sqldeveloper folder, with sub-folders and files, the rpm, command creates an sqldeveloper folder, complete with files and sub-folders. Switch to this new folder and run the sqldeveloper.sh executable. Migrating settings from a previous release On the initial startup of any release of SQL Developer, you may be asked one or two questions. The first is the location of the Java executable of the JDK as discussed. If you have installed the full release with the JDK, this question is skipped. The second question is if you want to migrate any preferences from a previous release. Regardless of whether this is the first SQL Developer install on the machine or not, the frst time you invoke SQL Developer, you are offered the choice of migrating your settings. You can migrate settings of any release from SQL Developer 1.5 and above. By default, the utility looks for the latest previous installation of the software. If you want to migrate from a different installation, select the Show All Installations button (seen above). This displays a list of all SQL Developer installations that have the system folder in the Documents and Settings system folder (for example, C:Documents and Settings<your_user>Application DataSQL Developersystem1.5.1.54.40) and includes releases from SQL Developer 1.5 and above. For releases prior to SQL Developer 1.5, the system folder was created within the SQL Developer install (for example, D:SQLDeveloperBuilds1.2.11.2.1.3213sqldevelopersqldevelopersystem). Maintaining your environment Once you have SQL Developer installed, it is helpful to know about the environmental settings and some of the files that are created when you start the product. Knowing about the version you have installed is important if only to be able to identify this when asking questions on the forum, or when contacting Oracle Support. Verifying the current release To verify the SQL Developer release you have, select the Help | About menu once you start SQL Developer or JDeveloper. In the dialog invoked, select the Extensions tab and find the Oracle SQL Developer extension, as shown in the next screenshot. This will match the build number on the download site if you have the latest release. The screenshot shows a number of the extensions that make up SQL Developer. If your dialog does not show the Version or Status columns, you can select the column headers to resize the visible columns and bring the others into focus. Using Check for Updates SQL Developer offers a built-in patching and extensions utility, known as Check for Updates. Check for Updates is used to release: SQL Developer extensions General Oracle extensions Minor patches Third-party tools required by SQL Developer, such as the non-Oracle database drivers Third-party extensions You can control whether Check for Updates warns you about new updates using the Tools | Preferences menu. Select Extensions and then select Automatically Check for Updates. For SQL Developer extensions, if you already have SQL Developer installed and you're not secured by a firewall, you'll be alerted about new updates. You need not use the utility to get the updates, but you'll be aware of the latest release from the alert. For all other extensions, you need to start Check for Updates to see what's available. To do this, select Help | Check for Updates. In either situation, just follow the dialog to find the updates you require.

0
0
6645

Movable Type 5: An Introduction

Securely Encrypt Removable Media with Ubuntu

Features and utilities in SQL Developer Data Modeler

Working with Events in MooTools: Part 2

CXF architecture

Selecting DOM Elements using MooTools 1.2: Part 2

Working with Forms in Dynamics AX: Part 1

jBPM for Developers: Part 2

Introducing SQL Developer Data Modeler: Part 2

Selecting DOM Elements using MooTools 1.2: Part 1

Trending Topics

Developing a Web Service with CXF

Working with Events in MooTools: Part 1

jBPM for Developers: Part 1

Getting Started with SQL Developer: Part 2

Getting Started with SQL Developer: Part 1

Create a Free Account To Continue Reading

Sign in to activate your 7-day free access