Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Events
Videos
Audiobooks
Packt Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds

How-To Tutorials

7018 Articles
article-image-working-templates-apache-roller-40
Packt
28 Dec 2009
5 min read
Save for later

Working with Templates in Apache Roller 4.0

Packt
28 Dec 2009
5 min read
Your first template In essence, a theme is a set of templates, and a template is composed of HTML and Velocity code. You can make your own templates to access your weblog's data and show this to your visitors in any way you want. Creating and editing templates In Apache Roller, you can create, edit, or delete templates via the Frontpage: Templates page. Let's see how to use this wonderful tool to create and edit your own templates! Time for action – creating your first template In this exercise, you'll learn to create and edit your first custom template via Roller's admin interface: Open your web browser, log into Roller, and go to the Templates page, under the Design tab: On the Add a new template panel, type mytemplate in the Name field, leave the default custom value in the Action field, and click on the Add button: The mytemplate template you've just created will show up in the templates list: Now click on the mytemplate link under the Name field, to open the mytemplate file for editing: Leave the mytemplate value for the Name field, type mytemplate in the Link field, and type My First Template in Apache Roller! in the Description field: Then replace the <html><body></body></html> line with the following HTML code: <html><body>Welcome to my blog, <b>$model.weblog.name</b> </br>This is my first template </br>My weblog's absolute URL is: <b>$url.absoluteSite</b> </br></body></html> This is shown in the following screenshot: Scroll down the page and click on the Save button to apply the changes to your new template. Roller will show the Template updated successfully message inside a green box to confirm that your changes were saved: Now click on the [launch] link under the Link field to open a new tab in your web browser and see your template in action: You can close this tab now, but leave the Frontpage: Templates window open for the next exercise. What just happened? Now you know how to create your own templates! Although the previous example is very simple, you can use it as a starting point to create very complex templates. As I said before, templates are composed of HTML and Velocity code. The template we wrote in the previous exercise uses a few basic HTML elements, or tags: HTML Tag Definition Tip <html> , </html> Defines the start/end of an HTML document. You must write this tags at the beginning/end of each Roller template. <body>, </body> Defines the start/end of an HTML document's body. All the code you will write for your templates must go between the <body> and </body> tags. <b>, </b> Shows text in bold. Example: <b>Hello</b> shows up as Hello </br> Indicates a line break. Example: Hello</br>World shows up as Hello World Also, there are some elements from the Velocity Template Language, along with an example from the previous exercise:   Velocity Element Definition Example $model.weblog.name Shows the name of your weblog. <b>$model.weblog.name</b> shows up as Ibacsoft's Weblog $url.absoluteSite Shows the absolute URL of your weblog <b>$url.absoluteSite</b> shows up as http://alromero.no-ip.org/roller   These are just some of the basic HTML tags and Velocity elements you'll learn to use for your templates. In the following sections, we'll see some more, along with elements from the Velocity Template Language. The Velocity template language All templates in Roller use HTML tags, along with Velocity code. In the next subsections, you'll learn about some of the most widely used Velocity elements in your Roller templates. Using Velocity macros in your Roller weblog A macro in Velocity is a set of instructions that generate HTML code based on data from your weblog. They are very helpful when you need to do the same task more than once. In the following exercise, you'll learn to use some macros included in Roller in order to show your weblog data to your visitors. Time for action – showing your weblog's blogroll and most recent entries Now you will use the Velocity Template Language to show your weblog's bookmarks (blogroll) in your custom template, along with the most recent entries: Go to your custom template editing page, and type the following code just above the </body></html> line: </br>These are my favorite Web sites: </br>#set($rootFolder = $model.weblog.getBookmarkFolder("/"))#showBookmarkLinksList($rootFolder false false)
Read more
  • 0
  • 0
  • 3222

article-image-how-focus-business-results
Packt
28 Dec 2009
7 min read
Save for later

How to Focus on Business Results

Packt
28 Dec 2009
7 min read
Begin with the end in mind. – Stephen Covey Too often, in packaged software implementations, we readily equate software features with business results. We declare success when software goes into production. We assume (or hope) that the packaged software will drive the desired business results. What we sometimes fail to realize is that software is only one component of a holistic solution that drives business results. Another slippery slope we deal with during the implementation is the division of labor in order to accomplish project activities. We divide work based upon specialization. This leads to project members having ownership for a piece of the work and limits the project team's ability to validate that the desired business results are achieved. This division of work will also result in additional effort required to organize, direct, and control the work. The implementation of packaged software is only part of the greater effort of creating a new business solution—an alignment of people, business processes, and technology to support and drive business results. Challenging today's mindset Before we can address the limitations of the traditional approach, we must first challenge our current thinking in regard to how we define project objectives, success measures, and scope. We focus only on what we measure How can one determine whether the project is focused on business results? I believe that what we measure is a good indicator of what we focus on. Consider the following measurement examples: Number of lines of code Project budget Project schedule Number of test defects Customer satisfaction How do these metrics relate to achieving desired business results? I am not inferring that theses metrics are wrong, but what I am saying is that performance-related metrics focused on project execution should not be the only metrics that we utilize. Project scope fixates on software features Too often, I have observed packaged software implementations only focus on a subset of a business process, based upon the software features implemented. If you have a project that interacts with a business process then the implementation project needs to examine the entire business process to ensure that the desired business results are achieved. Otherwise, you assume that the upstream and downstream business activities will behave as they did before the packaged software implementation. What is more important to a business—installed software or reliable business results? I am persuaded to conclude that reliable business results are the focus of our customers. Now, let's spend a little time to address the main drivers for business results. Focus on key drivers for business results Let's briefly take a look at the key drivers for business results. What is important to note here is that the implementation of a business solution not only considers packaged software but also the business processes and people that can have a greater impact on business results. Technology is a great enabler that can play a role in generating business value. However, technology is not always the right approach to address problems inherent in a business model. Automation of a non-value-added business practice is not generating business value for the customer. "Making decisions and implementing them is where business value is created in an organization." Technology on its own does not have the capacity to consider a diverse range of issues and then act. Knowledge is an attribute of people—not software. Technology can store information, business rules, and other data that can facilitate the decision making process. From a knowledge management perspective, information only generates value for customers when information is applied and a decision is reached. "All of the work that goes into development is not adding value until the software is in the hands of the customer." It is people, not technology, that still make the business decisions that drive results. Challenge to packaged software providers, and implementation partnersWhat are the strategic and tactical business decisions that your packaged software can support the customers in making? Leading packaged software providers and implementation partners should be able to provide this information up front to their customers. If the packaged software providers and/or implementation partners cannot provide these decision points then it begs the question of how well the provider/partner understands the underlying business model. If the software provider does not have a competent understanding of the underlying business model then the chances are that there will be significant gaps between the packaged software and your existing business model. Gaps always result in costing the customer money—either as software customizations or business process changes within your organization. What results generate business value? Early in my consulting career, I was native enough to assume that all business results generated by the customer's existing business model added value. I did not question the requirements defined in the customer's RFPs (Request for Proposals) and quickly proceeded to perform a ft/gap analysis. What I have learned from experience is that there are customer requirements that support non-value-added business activities and results. What I come to understand is that customer required can be based upon both needs and wants. The traditional approach to requirements gathering and selection is reactive and full of non-value-added effort. The first step is to gather all requirements—regardless of whether a requirement generates real business value. The second step is to categorize and prioritize both the value-add and non-value-add business requirements. The third step is to perform an analysis on whether the packaged software can support the requirement. The final step is to conduct a formal ft/gap session to share the results of the first three steps and determine which requirements will be selected. There are three fundamental challenges with this approach: Wasted effort is spent gathering requirements that support no business value. It is easier to lose focus from the critical requirements that add significant business value. It increases the probability of missing value-added requirements due to a broader approach of capturing business needs and wants. It sets the stage for stressful ft/gap sessions with various stakeholders fighting for their requirements to be selected. A better approach is to minimize or eliminate non-value-added requirements from being captured up-front. Challenging requirements can be adversarial for IT and implementation partners. It is almost impossible if one does not have a competent understanding of the business model. A practical approach that has worked well for me is to begin with identifying the desirable business results, and then drilling back to the business activities and the corresponding requirements that directly support the result. We will use the above illustration to reinforce some concepts. First and foremost  is that the customer's existing business model will have both value-added and non-value-added business activities that will drive business results. Also, consider that the existing model may have both desirable and undesirable business results. Performing this type of analysis will take two iterations: The first iteration defines all of the business activities and associates these activities with the business results that they support. The second iteration focuses on all of the business results and categorizes as value-added or non-value-added. This activity is then performed for the associated business activities. By conducting this analysis the implementation team can lay the foundation to identify the business requirements that directly support desired business results.
Read more
  • 0
  • 0
  • 2272

article-image-introduction-kohana-php-framework
Packt
28 Dec 2009
6 min read
Save for later

Introduction to Kohana PHP Framework

Packt
28 Dec 2009
6 min read
Overview Kohana PHP Framework is an open source PHP software development framework that helps php developers to build web applications faster, and also, more effectively by providing them with a set of built-in objects/classes. It also enforces highly organized coding standards. The Kohana PHP Framework is just like Ruby on Rails; it implements the well known software engineering design pattern—Model View Controller(MVC). The Model View Controller software design pattern guides engineers to design their software codes into three separate parts which includes: Models: The objects that manipulate data sources and data stores. Views: The html and css files with inline php codes that present the user interface and controls to the application users. Controllers: Objects in charge of the business logic, displaying the page(views), and routing the click actions from the views to the model and back to the views. Kohana was originally based upon the well documented codeigniter php framework, but it stands out due to its strict use of OOP best practices and standards. Kohana PHP is officially defined by its creators to be a PHP 5 framework that uses the model view controller architectural pattern. It aims to be secure, lightweight, and easy to use. Why use Kohana PHP framework? PHP is a very easy to use programming language, that's the reason why its loved by the web development community. It's easy to use nature and learning curve has attracted a lot of users. But PHP has one downside. Most experienced developers don’t love coding php due to its little Object orientation, and its often nasty codes. With Kohana PHP, any php developer from beginner to expert will all get to write standard codes which we see in the Java World, or the .NET world. Kohana bridges the gap between amateur web developers and designers who love php because its easy, and the experienced web developers who go fully into Object Oriented codes and nothing less. Kohana enforces true software engineering and brings it closer to the php world which has little or no standards. So the major reason why you should use Kohana PHP Framework for your php work is to ensure that your codes are of standards, and you follow the best practices which go a long way to help teams of developers from beginners to experts to easily work together with the PHP programming language. Kohana PHP Framework solves the problem of beginners, and intermediate developers who have nasty codes and are killing the overall work of the team. With the well documented and standard practices of Kohana, a developer in India can write the code and a developer in Africa can optimise the code without asking a lot of questions, because everything will clearly be a model, view or a controller, and it will be easy to understand what it was meant for exactly. Key features of Kohana PHP framework Kohana PHP has some very good features that makes it stand out from all other PHP frameworks. The features include:  Fully Object Oriented: Object oriented programming is an industry standard since the introduction of C++. Many developers working with Java programming languages are comfortable with Object and classes, and they prefer the order it brings to programming. Kohana PHP being fully Object oriented, it automatically brings this order and industry standard programming to PHP; with this, you wont get developers saying you are just a php developer because Kohana PHP is a standard software programming platform for enterprise and web applications. In built templating: Kohana PHP like most other standard web frameworks has a very easy to use template engine. You get a simple html file, covert it into a kohana template by renaming it to template.php, fit in two php variables— $title and $content, to signify where the title of the page and where the content will be displayed. That’s all you need to have a kohana php template. In built Internationalization: Kohana PHP strongly supports internationalization and good documentation. With Kohana, all you need to do is create the various language files and use an internationalization object to reference the files depending on the language from page to page. Switching the language, automatically switches the language file referenced. Robust ORM Engine: ORM stands for Object Relational Mapping. It’s a programming concept in which your codes directly manipulate the database tables as objects, while the SQL gets generated for you behind the scenes. The ORM in Kohana is easy due to its use of convention over configuration. Its the best ORM I have seen in the php world and its 100% stable. To make use of the ORM, you simply extend the ORM class in your model and that model will be able to manipulate your database without any SQL code. MVC: the framework is based on MVC, and this helps to bring about a lot of order, eases code maintenance and team work. I can get any Kohana PHP application, and easily understand what every code does because it must flow from a controller to a view or to a model then to a view. And that’s all about it. Clean and Search Engine Friendly URLs: Kohana PHP framework has a good implementation of controllers where every url call or reference in a kohana based site refers to a controller and its function, as in site/controller/function/parammeters. For example, calling a blog controller to show a post with ID 1 will be as simple as your-site.com/index.php/blog/showPost/1 where index.php is the front controller, blog is a controller object and show post a blog->showPost function that takes a parameter which is the post ID. Libraries and helpers and third party classes: With kohana php, you have a set of libraries and helpers for almost everything you need as a web developer. For instance, sending out an email is as easy as calling email::send() function. There are more helpers and libraries, getting to read about them on the Kohana php website will make you feel like your life as a developer has been taken away and you are just a secretary. Also with Kohana PHP, you can get any available php class from the internet and use it in the kohana framework by simple dropping the file in a folder in your kohana site known as vendor, and then, instantiating the class in your codes. That’s all! It sounds too good to be true but thats all you need to use that PEAR object or that zend class or that php class you have been using for years with kohana framework on your next project.
Read more
  • 0
  • 0
  • 15104

article-image-learn-baking-blender
Packt
28 Dec 2009
3 min read
Save for later

Learn Baking in Blender

Packt
28 Dec 2009
3 min read
Getting Started Baking in Blender allows you to transfer different aspects of your rendered scene/model to a 2D planar projection, or UV map. This is primarily used for creating Normal Maps but can also be a very helpful aide in texturing, render time optimization, etc. Before we dive into the specifics, let me give you a quick crash course in baking. In order to bake out the necessary maps, the three requirements are that you have at least one mesh, that the UVs of that mesh have been unwrapped and that you have applied an image to the UVs of that mesh. Beyond this, it all depends on what you are doing. To bake out an object: Select all vertices of the default cube (or any object of your choice) in Edit Mode, press U > Unwrap (smart projections) > OK Switch your viewport to the UV/Image Editor, select all UVs with A, add a new image by going to Image > New > OK Under the Render properties, in the Bake panel click Bake. If all is correct, you should now see the results of the Full Render bake in the UV/Image Editor. You should see something like this: With the default Blender settings, you will get this result. As you can see Blender is baking out all of the lighting details of our default cube and saving it to the UV mapped image. These few steps are all it takes for most baking purposes. This is the basics of baking. Of course we did not yet bother to adjust anything or to select the method of baking needed, and so the results are quite useless. However, if you were to adjust the lighting to fit a specific purpose, as demonstrated further in this tutorial, you would see very different results. Let us now examine each of the different kinds of bakes and how to use them. Full Render Baking the Full Render enables you to bake out everything you see at render time, this includes lighting, materials, textures, and ambient occlusion. When used correctly this can be very helpful for transferring procedural materials to a 2D color map or for baking in the lighting details of textures to be used in ultra lowpoly games that do not offer dynamic lighting. Here is an example of procedural materials that have been baked out to our cube using the default lighting setup: Here is the same cube and same material with a basic 3-point lighting setup: Ambient Occlusion This baking method is very useful as an aide in the texturing process. When texturing, particularly for lowpoly models, creating realistic shading from light can be quite difficult. Using Ambient Occlusion baking can ease this process by giving you a plane, shaded map of your object in 2D. This is best demonstrated with an image as seen below: Here is our same cube and same material with ambient occlusion: As you can see it is plain grey, this is due to our cube having no variation in the surface and thus nothing to affect the lightness and shadows. Here is a modified cube with surface variation:   Due to the modified surface I have also re-unwrapped the UVs using Smart Projections.
Read more
  • 0
  • 0
  • 4504

article-image-creating-roller-theme-scratch-using-apache-roller-40
Packt
28 Dec 2009
6 min read
Save for later

Creating a Roller theme from scratch using Apache Roller 4.0

Packt
28 Dec 2009
6 min read
Creating a Roller theme from scratch Now things are going to get a little rough; just kidding! In Apache Roller, it's very easy to create your own themes, and in this section I'm going to show you how. For the following exercises, you'll need to download http://www.packtpub.com/files/code/9508_Code.zip. Extract the chapter07.zip file's contents into a directory in your hard disk. For example, I used Ubuntu Linux in the exercises, created a chapter07 directory inside my Desktop directory, and copied the mytheme directory inside Desktop/chapter07. All the steps in the exercises are based on these assumptions. Creating a directory for your theme Every Roller theme has a directory and some required files such as weblog.vm, _day.vm, and theme.xml. The next exercise will show you how to create a directory for your new theme inside Roller's themes directory, and how to copy these required files from the support files. Time for action – creating a directory for your theme Now, I'll show you all the necessary steps to create your new theme directory inside Roller's themes directory in a Linux Ubuntu system, and then copy all the required files. If you're using Windows or any other flavor of Linux, the procedure is very similar: Go to your Roller themes directory and create a directory named mytheme: Open a terminal window, go to the themes subdirectory inside Desktop/chapter07, and type sudo cp * /usr/local/tomcat/webapps/roller/ themes/mytheme to copy all the mytheme files to your Roller installation: In the end, your mytheme directory will have four files, as shown in the following screenshot: Now restart Tomcat and wait until it's running again. Then open your web browser, log into Roller, and go to the Design tab to see the Weblog Theme page: Click on the Shared Theme option and select My First Roller Theme from the drop-down listbox: Click on the Update Theme button to change your current Roller theme, and then click on the See how your blog will look with this theme link: Roller will open a new web browser tab to show you a preview of the new theme you selected: Close the preview tab and leave the Front Page: Weblog Theme page open for the next exercise. What just happened? As you can see from the previous exercise, the mytheme theme has a very basic functionality. That's because the CSS stylesheet (mystylesheet.css) is empty, so I'm going to show you how to add styles to your headings, links, and all the other elements displayed in your weblog. However, first we need to see a quick introduction to the four files that every Roller theme must have in order to run without any trouble: File Definition Tip weblog.vm Describes the main page of your weblog In this file you set the structure for your weblog, using macros and elements from Roller and the Velocity template language. _day.vm Describes how to display one day's worth of entries in your weblog Here you can configure how to display each entry's title, content and comments, for example. You can set the font's color and size of each element, based on the CSS stylesheet definitions. mystylesheet.css Stylesheet override file that defines the CSS style code used by your weblog Here you define all your weblog's styles, like size and color for headings and fonts used in your posts. theme.xml Theme definition file that describes each file used in your weblog You need to include some basic data about your theme, the stylesheet file, the weblog and _day templates, and every other file and/or resource used in your weblog. In the next exercises, you'll learn how to edit these files to change your weblog's visual appearance and suit your needs. The stylesheet override file The first thing we need to do in order to change your new theme's visual appearance is edit the stylesheet override file: mystylesheet.css. We can do this in two ways: Edit the file directly from the mytheme directory inside Roller's themes directory, or use Roller's Custom Theme feature. If we use the first option, we'll need to restart Tomcat every time we make a modification to mystylesheet.css. On the other hand, if we choose the second option, we can edit the stylesheet inside Roller's admin interface and see how our changes affect our weblog's visual appearance immediately, so I'm going to show you how to use the second option. Time for action – editing the stylesheet override file It's very easy to edit the stylesheet override file for your custom theme inside Roller, and the next exercise will show you how to do it: Go to the Front Page: Weblog Theme tab in your web browser, select the Custom Theme option, click on the I want to copy the templates from an existing theme into my weblog checkbox, and click on the Update Theme button: Roller will show you the following success message: Now click on the Templates link to see a list of the templates you currently have in your custom space: Looking at the template list in the previous screenshot, there are some templates from the other custom theme which we need to remove. Click on the Remove link of the custom.css, mytemplate, and _css templates to delete them from your custom space, as we won't need them, and they don't belong to mytheme. After removing all the unneeded files, there should be only two templates inyour list: Now click on the Stylesheet link to see and start editing your mystylesheet.css file's code: As you can see, your custom stylesheet is empty. If you click on the Front Page link in Roller's menu bar, you'll see your weblog's current front page: Now click on your web browser's Back button to return to the stylesheet editing page, and add the following code to your custom stylesheet: div.dayTitle {color:brown;font-weight:bold;font-size:90%;text-transform:uppercase;border-bottom:1px dotted #666;}.entryTitle {font-weight: bold;} Your stylesheet should now contain the line beginning with /*, along with the code you've just entered: Click on the Save button to apply the changes to your stylesheet, and then select the Front Page link to see how the code you entered affects your weblog's visual appearance: If you compare the previous screenshot with the one from step 7, you'll see that the code you entered into the override stylesheet changed the way your weblog displays the day and entry titles. Now click on the Back button of your web browser to return to the stylesheet editing page, and add the following lines of code above the lines you entered in step 8: a {text-decoration: none;}a:link {color: blue;font-weight: medium;}a:visited {color: purple;font-weight: medium;}a:hover {text-decoration: underline overline;}body {font-family:"Lucida Grande", lucida, Geneva, Arial,sans-serif;background:#FFFFCC;} Your stylesheet should now look like this: Click on the Save button and then select the Front Page link to see your weblog's front page: Click on the Back button to return to your stylesheet editing page.
Read more
  • 0
  • 0
  • 2005

article-image-backbase-4-ria-development-hello-backbase-four-variations
Packt
28 Dec 2009
11 min read
Save for later

Backbase 4 RIA Development: Hello Backbase in four variations

Packt
28 Dec 2009
11 min read
The Backbase page skeleton There is one more thing we would like to take care of before we really start. It will save a lot of useless book space if we can explain what a typical starter page for the Backbase framework looks like and then forget about it. Of course, the examples that are supplied with this book are all ready to execute and therefore this source code will repeat the skeleton page code where required. For any Backbase enabled page, you need an HTML file, usually named index.html, which looks like this: <!-- --><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html > <head> <meta http-equiv="Content-Type" content="text/xhtml; charset=UTF-8" /> <title>The Title of your Application</title> <script type="text/javascript" src="../../backbase/4_3_1/engine/boot.js" > </script> </head> <body> <script type="application/backbase+xml"> <xi:include href="../../backbase/4_4_1/bindings/config.xml"> </xi:include> <!-- YOUR APPLICATION CODE GOES HERE --> </script> </body></html> The version number of the Backbase Client Framework release is specified in the [version] folder name (for example, 4_4_1). If your version of the Backbase Client Framework is different from the one shown here, you must adapt the code samples accordingly. There are some interesting points: If you are including third-party libraries or your own JavaScript libraries, you should include them in the head section of the HTML document, as usual. At the place where it says: <!-- YOUR APPLICATION CODE GOES HERE -->, you can put your application code. We will call this a Backbase area. The code that you can put here can be ordinary XHTML, widgets that are provided by Backbase, or widgets that you have built yourself. The <!-- YOUR APPLICATION CODE GOES HERE --> part is contained within script tags with type="application/backbase+xml". The type attribute signals the Client Runtime that it should process the contents. The xml part of the type attribute says that the contents should be proper XML. There can be multiple Backbase area's areas. In fact, there can be as many areas as you like. This is convenient if you are converting an older web application to a Backbase application or when you have large chunks of conventional HTML in your application. As the Backbase framework takes some overhead to process this HTML, there is a performance advantage to put code that does not require processing by the Client Runtime outside a Backbase area. The code in a Backbase must adhere to XHTML standards and most importantly, all tags must be properly closed. This can be a source of errors if you are converting an older application where for example <input> and <img> tags are often not closed. Another XHTML violation to watch out for is that attribute values in tags must be enclosed in quotes and all attributes specified must have a value. For example, you should code selected="selected" instead of just selected in a select box. The Backbase JavaScript engine in boot.js is loaded in the header of the HTML page. It is very important to make sure that you have a proper path specification here. Many times, when you set up a new application, you get an empty page at your first try to see your application. The cause is almost always that your path specification is wrong. If this happens to you, it is convenient to use a tool like Firebug to see what the server returns and why it cannot find the Backbase libraries. To use the Backbase widgets, you must include the configuration files, also called implementation bindings for the tags: <xi:include href="../../backbase/4_4_1/bindings/config.xml"></xi:include> The config.xml file contains an additional include for the specific skin you want to use. The default is the chameleon skin . As an alternative, you can use the system skin. Similar to the earlier point, your path specification must be correct; otherwise your page will most likely stay empty. The inclusion of the configuration files is done with the statement: xi:include. We make use here of XInclude, or XML Inclusions, which is a W3C standard for merging XML files. This facility makes it possible to code your web pages in a more modular way by dividing your code in smaller chunks, which can be combined at runtime. See http://www.w3.org/TR/xinclude/ for details. Backbase has implemented the XInclude standard in its framework according to the standard and you see it used here to include the configuration files. We will see more of it later in this article. The HTML tag contains two namespace declarations— target="_blank">>From now on, we will usually take for granted that you know how to surround our example code with the right skeleton code. "Hello Backbase" in four variations In the previous section,we showed what a Backbase starter page looks like. So finally, we can show real Backbase code. It is time to say "Hello Backbase!" We will do so by showing typical "Hello World" examples as follows: The first example shows a simple alert when you click on the Click me text. It serves to make sure that we have the right setup for our applications. The second and third examples are a bit more interesting: a balloon from the Backbase Tag Library is shown, with the text that you typed in an input field. The difference between the two is the use of JavaScript or the XML Execution Language, as you will see. The fourth example is an AJAX example. It involves communication with a server, which echoes the text typed in, together with a timestamp. The response is added to earlier responses without refreshing the page. Directly Download the example code for the article. The downloadable files contain instructions on how to use them. We assume that you have a web development environment set up now and that you have put the Backbase libraries at the right place. We will take a follow-along approach for explaining the "Hello World!" examples, but of course you can also just execute the ready-to-run downloaded source code instead of typing the code yourself. Start with creating a new folder named bookApps, or whatever name you like better. Next, create a subfolder of the bookApps folder named helloWorld. Verifying the installation of the Backbase framework Create an HTML file named hello1.html and put this file in the helloWorld folder. Copy the skeleton file that we saw in the previous section into hello1.html. Remember the following: In this file, we made sure that the Backbase Framework Client Runtime will be loaded because of the <script> tag in the head section of the HTML document. The <script> tag in the body section of the HTML document has a type declaration, application/backbase+xml, which tells the client runtime to process whatever is contained within the tag. The first thing that the client runtime is asked to process is the inclusion of the config.xml file, which contains the bindings that define the UI widgets. The position where <!-- YOUR APPLICATION CODE GOES HERE --> is placed tells the runtime that it should process whatever we replace this with. Namespace declarations are needed for all the namespaces used, in the tag where they are used, or a parent tag within the document. Replace <!-- YOUR APPLICATION CODE GOES HERE --> with the following content: <div> <e:handler event="click" type="text/javascript"> alert('Backbase says hello!'); </e:handler> Click me </div> To see your first "Hello" example in action, you can either double-click on hello1.html in the Windows explorer (if you are running Windows), or, if you have started your local server, you can open a browser and type something like this in the address bar: http://localhost/bookApps/helloWorld/hello1.html. After clicking on the Click me text, you should see a result that is similar to what is shown in the following picture: What if you do not see anything? The most common problem that could be the cause is that the path to boot.js or config.xml is not correct. If you are running with a server, check that it is running properly, and that it can find your hello1.html. When all is well: Congratulations! The Backbase Client Framework is running successfully. Let us look at the code: The interesting part of the code is the event handler for the div element that contains the Click me text. The e:handler tag is part of the XML Execution Language (XEL), a custom markup language that is provided with the Backbase Client Framework, and that can be used as a replacement for JavaScript in many cases. The namespace that we need for using XEL is declared in the e:handler tag itself; it could also have been declared in the <div> or <html> tags. Between the start and end e:handler tags, you can code either JavaScript, as in this example, or XEL, as we will see in the next "Hello World!" example. You could have coded the example also as "Hello World" without the Backbase event handler: <div onclick="alert('Backbase says hello!');"> Click me! </div>. At first sight, this is shorter, so why would we need Backbase for this? Well, usually, you need more in the event handler than just a short alert. In such case, you have two choices: either clutter your page with hard to read JavaScript or create a JavaScript function that you put in the head section. Before you know it, you will have many of these functions, which become hard to maintain and organize. In the case of the XEL event handler, you can write well-formatted and well-structured JavaScript code that stays local to the widget where you put the event handler. Of course, you can define more global functionality as well and you will see examples of this also. XML namespaces! In this first example, you saw again a new XML namespace, this time for XEL. We already saw the XHTML and the XInclude namespace declaration in the page skeleton; in the next section you will see the Backbase Tag Library, the Commands, and the Forms namespace. Yes, that is a lot of namespaces. We promise that you will find out how useful these are and that you will get used to it. This was a very simple example that made sure the Backbase framework is working right. In the next three examples, we will expand your knowledge by demonstrating a personalized "Hello World", using a tag from the Backbase Tag Library. The last "Hello World" example will demonstrate the AJAX functionality of the Backbase Client Framework by showing a form with one input field, which, when submitted, causes a response to be displayed somewhere in the page without a page refresh. "Hello World" using a Backbase balloon This section contains a pair of examples showing how to create a BTL balloon that is filled with custom text. The balloon widget displays an image similar to that of a dialogue box in a comic book. The balloon can contain text, images, or other widgets. The user can click on the x icon in the balloon to close it or the balloon can be displayed for a limited amount of time. The balloon is positioned in relationship to its parent widget. The balloon widget is similar to a toolTip because they represent information that becomes available only after an action is performed. Most often, these widgets are used to present contextual information about a widget in your application. This is not the easiest example for showing a Backbase GUI widget from the Backbase Tag Library. However, we have chosen it because we wanted to show an example that illustrates the power of using pre-built widgets. The example is done twice, to show that BTL can be coded in two ways, either by using an event handler with JavaScript content, or by using no JavaScript at all. The second version of the example shows the Backbase-specific XML Execution Language (XEL) and Backbase Commands instead of JavaScript. Any combination of these two styles is also possible. Below is a picture of what the result of trying the example will look like: The user will type a name, and after clicking OK, the balloon will appear. The user can click on the x to close it. Otherwise, it will disappear automatically after a while.
Read more
  • 0
  • 0
  • 6362
Unlock access to the largest independent learning library in Tech for FREE!
Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.
Renews at €18.99/month. Cancel anytime
article-image-velocity-model-and-data-objects-apache-roller
Packt
28 Dec 2009
2 min read
Save for later

Velocity Model and Data Objects in Apache Roller

Packt
28 Dec 2009
2 min read
Velocity model and data objects in Apache Roller There are several standard model and data objects you can use in Apache Roller to access your weblog's data. Some of the most widely used are $config, $model, $url, $utils, $weblog, $weblogCategory, and $weblogPage. In the following exercise, you'll get to work with the $config object. The $config object This model is used to access Roller's site-wide configuration parameters, such as the e-mail address of Roller's administrator, the name of the Roller site, and so on. Time for action – properties of the $config model object The following exercise will show you how to use some properties of the $config model object inside your custom template: Go to your custom template editing page, and replace the six lines of code below the <body><html> line with the following lines: Welcome to my blog, <b>$model.weblog.name</b> --> <i>$config.siteDescription</i> </br>I'm using Apache Roller Version <b>$config.rollerVersion</b> </br>You can e-mail me at <b>$config.siteEmail</b> if you run into anyproblems in this site. </br>This is my first template </br>My weblog's absolute URL is: <b>$url.absoluteSite</b> </br></br> The entire code of your template should look like the following screenshot (the code you have to change is highlighted): Save your changes and click on your template's [launch] link to open a new tab in your web browser and see the results: Close the results tab if you like, but leave the Frontpage: Templates window open for the next exercise. What just happened? The following table summarizes the $config object properties you learned to use in the previous exercise, along with their value: Property Definition Value $config.siteDescription Shows your site's description. My First Installation of Apache Roller $config.rollerVersion Shows the Apache Roller version used. 4.0.1 $config.siteEmail Shows the site administrator's email. alromeromx@gmail.com You can find all $config parameters under Roller's Server Admin tab: The $model, $category, and $entry objects These objects are used to access all the data for a specific weblog: weblog entries, categories, comments, among others.
Read more
  • 0
  • 0
  • 1743

article-image-ajax-chat-implementation-part-1
Packt
28 Dec 2009
4 min read
Save for later

AJAX Chat Implementation: Part 1

Packt
28 Dec 2009
4 min read
Lets get started. We'll keep the application simple, modular, and extensible. We won't implement a login module, support for chat rooms, the online users list, and so on. By keeping it simple we'll focus on what the goal of this article is: posting and retrieving messages without causing any page reloads. We'll also let the user pick a color for her or his messages, because this involves an AJAX mechanism that is another good exercise. The chat application can be tested online at http://ajaxphp.packtpub.com, and should look like Figure 8-1: Figure 8-1: Online chat application built with AJAX and jQuery Using jQuery as a framework will simplify things: we won't need to worry about constructing XmlHttpRequest by ourselves and implementing design patterns and best practices. Technically, the application is split into two smaller applications that build the final solution: The chat application: Here we use a MySql database and AJAX to store and retrieve the users' messages and pass them between the client and the server. The code for choosing a text color: Here we use AJAX to call the PHP script that can tell us which text color was chosen by the user from the color palette. We use an image containing the entire spectrum of colors and allow the user choose any color for the text he or she writes. When the user clicks on the palette, the mouse coordinates are sent to the server, which obtain the color code, store it in the user's DB entry, and set the user's test to that color. The chat application Here we use a MySql database and AJAX to store and retrieve the users' messages and pass them between the client and the server. The chat window contacts the server periodically to send and retrieve the newest posted messages from the server to each user. Our DB will also hold username and text color information used in the application. Implementing this functionality involves creating the files and structures shown in the following figure: Figure 8-2: The components of the AJAX Chat application The application functions following our usual coding pattern as follows: The user interface is generated by index.html, which displays the chat box and the color picker. This file loads the other client-side files, which in our case are chat.js (our JavaScript chat class), jQuery-1.3.2.js (the jQuery framework), chat.css, and palette.png (the color picker image). On the server side, the main player is chat.php, which is designed to take requests from the client. In our case, client-server communication will happen between chat.js (on the client) and chat.php (on the server). The chat.php script uses three other files—config.php, error_handler.php and chat.class.php; we'll pay special attention to the latter, which is more complex and more interesting than the others. The other server-side file that listens to client requests is color.php, which is called whenever the user clicks the color palette image. When that happens, the client script calls color.php, tells it the location the user clicked on the palette, and color.php replies by telling the color at that location. You'll also need to create a new data table named chat (refer to the following figure), which holds the chat messages exchanged by the chatters. The files to which we're paying a little attention before starting to code are chat.js and chat.class.php. The chat.class.php file contains a server-side class named Chat which includes all the server-side functionality required to manipulate chat messages, as you can see in its diagram in Figure 8-3. This class contains methods for adding, deleting, and retrieving chat messages to and from the chat database table. Figure 8-3: Server-side Chat class Then we have the Chat class in the chat.js file. This is a JavaScript class that contains the client-side functionality required for our chatting application, which include functions for retrieving the list of messages from the server, sending new messages, deleting messages, displaying error messages, and so on. Most of the features are backed up by the server-side components, which are called to perform the necessary work. Figure 8-4: Client-side Chat class
Read more
  • 0
  • 0
  • 4782

article-image-venturing-beyond-basics-ms-office-live-small-business
Packt
28 Dec 2009
14 min read
Save for later

Venturing Beyond the Basics in MS Office Live Small Business

Packt
28 Dec 2009
14 min read
In this article we will discuss why Office Live Small Business is the perfect site-building tool for you if you don't know (or don't want to learn) HTML, the language of web pages. And you'll certainly agree that it does a pretty decent job of it. But afer your site is functionally complete, it's only natural that you'd want to tweak little things here and there; move the text on some page a wee bit to the left, for example, or move a picture up by a pixel or two, so as to align it with the neighboring text. The trouble, though, is that Office Live Small Business doesn't allow such tweaks. You can't touch the HTML that it generates. But what if you're not very happy with this state of affairs? Don't worry! Office Live Small Business has it covered. It has two advanced features that give you a fine-grained control over the look and feel of your web pages as follows: Page Editor's HTML modules in which you can write your own HTML markup Off-the-shelf Solutions, which render customized web pages within Office Live Small Business's framework In this article, you'll explore both these advanced options. Let's get started then. About HTML modules An HTML module is a little editor that you can plop on to your page in the Page Editor, just like any other module. It holds HTML markup. With an HTML module, you can construct a web page with raw HTML markup just as the pros do. If you're conversant with HTML, the idea of having a fine-grained control over your HTML is likely to pump you up. And yet, I don't recommend using HTML modules. You read that right: I don't recommend using HTML modules. Why? Because Office Live  Small Business stores the markup in HTML modules separate from the page. When a person requests your page from his/her browser, Office Live Small Business fetches the separately-stored markup and embeds it into the rest of the page dynamically. The problem is that it does the embedding using something called frames, which happen to be little windows on a web page that display content that doesn't actually reside on that page. Why is this problematic? Because search engines can't index the content that doesn't physically reside on your web page. Therefore, people can't find it using search engines. Frankly, I don't see a point in building a site that people can't fnd. So, I strongly discourage you to build your entire site with HTML modules. Another reason to avoid HTML modules is that they load the content dynamically using JavaScript. This can be an excruciatingly slow process that can delay the loading of a page  in a user's browser. In fact, such dynamically loaded pages often tend to time out. Having said that, there are situations where they can come in handy. You may not care, for example, whether search engines index a certain page on your site, but you'd like to have great control over how that page looks. Or you may want to embed a YouTube video on your page, which search engines don't index any way. It's a good idea, therefore, to learn how to use the HTML module and that's what you'll do in this section. The first step, of course, is to add an HTML module to one of your pages. Let's use a Test page as a guinea pig. Time for action – adding an HTML module to your page Bring up the Test page in Page Editor. Place the cursor where you want to add the module. Click the Module button in the Insert group on the Page Editor's ribbon. Select HTML from the Modules menu that drops down. The HTML dialog pops up, as shown: The dialog contains a mini-editor where you can type your HTML markup. The Images and Hyperlink buttons just above the editor box help you add markup for embedding pictures and hyperlinks. As this is just a Test page, I'll type some simple HTML to show you how the module really works. I suggest that you do the same. Type the following markup in the mini-editor: <strong>Welcome to my web site.</strong> Click OK. The HTML dialog closes and you return to Page Editor, which renders the HTML you just typed as any browser would. Preview your website. The page should now look like this: Close the preview window and return to Page Editor. Editing your markup is equally easy. Right-click on the HTML module in Page Editor. A pop-up menu appears, as shown in the next image: Choose Properties…. The HTML dialog opens again with your markup in it. Change the markup to: <strong>Welcome</strong> to my web site. You'll be working with the HTML module a few more times in this article. From now on, I'll just say "Open the HTML module's HTML dialog" when I want you to edit a module's markup. Click OK. The HTML dialog closes and you return to Page Editor. Preview your website. The page should now display only the word Welcome in bold letters. Close the preview window and return to Page Editor. What just happened? You added an HTML module to a web page and typed some basic HTML in it. Before this exercise, you simply typed text on to your web pages as you would in a word processor, and Office Live Small Business took care of converting it to HTML. With an HTML module, you're writing your own HTML. Naturally, you'll have a more fine-grained control over how you want it to appear. But to make use of this newfound power, you must know HTML. So, let me give you a brief tutorial on it. There are several hundred excellent HTML tutorials on the Web (not to mention several thousand lousy ones). If you take into account the hundreds of books on the subject, you'd think that everything that needs to be said about HTML has, perhaps, already been said. Many times over, at that. Yet, I have good reason to write this brief tutorial: writing HTML for Office Live Small Business web pages is an entirely different beast. Why? Because: You don't write an entire HTML document with Office Live Small Business's design tools. All you do is write little chunks of HTML in HTML modules placed strategically on your web pages. Office Live Small Business's Page Editor combines the basic framework of your web page with these chunks of HTML and presents a finished web page to your browser. An HTML module doesn't store the HTML you type verbatim. It encodes what you type and lets the browser handle the decoding. Therefore, the page may not look exactly as you intend it to, after the browser renders it. The page on which you drop an HTML module already has a Cascaded Style Sheet (CSS) associated with it. You may be able to take advantage of the fact and minimize manual formatting. Therefore, you don't have to be an HTML guru to use Office Live Small Business's HTML module. All you need to know is a small subset of HTML that leverages the web page's features. This tutorial introduces that subset. It won't make you a fully-fledged web designer, but it will arm you with enough knowledge to impress unsuspecting folks at cocktail parties. HTML 101 Contrary to what many people believe, HTML is not a programming language. It's a markup language. Unlike programming languages, it doesn't contain step-by-step instructions that tell a computer what to do. Instead, it contains instructions that tell a browser how to format and decorate web page content. The instructions are written as Tags. Tags are keywords that reside within a pair of angular brackets (< and >). Typically, you enclose some content between a pair of tags. For example, the <strong> and </strong> in the markup you just tried out is tag pair. The pair consists of an opening tag and a closing tag. The difference between an opening tag and the corresponding closing tag is usually a forward slash (/). So, <strong> is the opening tag and </strong> is the corresponding closing tag. If you want to make some text bold, you enclose it between <strong> and </strong> tags like this: This is some text. <strong>This sentence is bold.</strong> This one isn't. And the browser displays it like this: Most HTML tags are paired like the <strong> tag. But some are not. An example is the  <br /> tag. It adds a line break to your text like this: This is some text. <br /> This is some more text but it's on the next line. And the browser displays it like this: The character < opens the tag and the character sequence /> closes it. Such tags that close themselves without corresponding closing tags are called self-closing tags. It's not mandatory to close the self-closing tags. So, if you write <br> instead of <br />, your page will work just fine. But I recommend closing all tags. I'll do so in this tutorial and so will you. Notice, by the way, that simply typing the second line of text on a new line in the editor doesn't make the text appear on the next line (go ahead, try it!). It's the <br /> tag that actually does the trick and displays the subsequent text on the next line, although you typed it as a single line in the editor. In other words, the tags determine the appearance of your web page, not how you type the text in the editor. HTML is not case sensitve. So, you can write a <br /> tag as <BR />, <Br />, or even  <bR />, if you insist, and your page won't look any different. But, I strongly advise against it. As a matter of convention, I recommend sticking to lowercase letters, as I've done throughout this tutorial. That's just about all the dirt that you really need to know on HTML. There's more,  of course, but as this is not a complete HTML tutorial, we'll look into the finer details  on a need-to-know basis. So, let's proceed to some useful HTML tags. Working with paragraphs Most writing is structured as a collection of paragraphs. While writing HTML, you must enclose the text in a paragraph between the <p> and </p> tag pair like this: <p>This is the first paragraph. It has this filler text to make it rather long so that it looks like a real paragraph.</p><p>Here is the second paragraph.</p> And the browser renders it like this: As you can see, there's no space between the paragraphs in the markup. But the <p></p> tag pair automatically introduces breaks that makes the text look like paragraphs in the browser. Because of a bug in the HTML module, it doesn't seem to treat <p> and </p> tags correctly. As a result, you don't see intended paragraph breaks in the browser. In the picture above, I sneaked in our old friend, the <br /> tag, between the two paragraphs as in <p>...</p> <br /> <p>...</p>.You may have to resort to this workaround as well. But remember that if Microsoft fixes the bug, you'll get an extra line-break on your page.Also, remember that you can add text to an HTML module without the paragraph tag pair; you can use <br /> tags instead, for example, where you want a break in text. However, I recommend that you enclose all of your text in paragraph tags. If you don't, Office Live Small Business's stylesheets may hijack the formatting of your text. Not enclosing text in paragraphs is one of the main reasons why text on so many web pages is misaligned and displayed in the wrong font. Working with horizontal rules You can draw a horizontal line across your web page simply by clicking the Horizontal line button on Page Editor's ribbon. To draw a similar line while working with the HTML module, you'll need—you guessed it—a tag! Web designers call a horizontal line a horizontal rule and so the corresponding tag is the <hr /> tag, like the <br /> tag, the <hr /> tag. Simply type <hr /> wherever you want a horizontal line  to appear. If you want it to appear between the two paragraphs in the previous example, your markup will look like this: <p>This is the first paragraph. It has this filler text to make it rather long so that it looks like a real paragraph.</p><hr /><p>Here is the second paragraph.</p> And your page will appear in the browser like this: Working with headings Headings are an important part of the text. Books, for example, use headings with varying importance. The more important a heading, the bigger its font size is. This scheme makes  it easy for readers to quickly grasp the scope of topics and sub-topics within the text. HTML uses a similar scheme. There are six levels of heading tag pairs in HTML that you can put around heading text like this: <h1>Heading 1</h1><h2>Heading 2</h2><h3>Heading 3</h3><h4>Heading 4</h4><h5>Heading 5</h5><h6>Heading 6</h6> Text included between beginning and ending tags at each level looks like this: As you can see, <h1> has the largest font size. Naturally, it's used for the most important heading on a web page. As the number inside the tag increases, its font size decreases.  So, among headings, <h6> has the smallest font size. What if you need more than six levels of headings? Well, you shouldn't; a six level deep topic hierarchy is deep enough for most people to keep track of. If you have seven or more levels, you should seriously consider rewritng your text. Generally, it's a good idea to start a page with the <h1> tag. It identifies the most important heading on the page, and it is used by search engines to take an educated guess at what  the page is all about. So, a good convention to follow is to have only one <h1> tag on every web page. But, you're better off flouting this convention when working with Office Live Small Business. Why? Because you don't write entire web pages in HTML modules; you just write individual chunks of HTML. Office Live Small Business automatically adds a <h1></h1> tag pair  to your web pages and places the title of your site between them. Similarly, it uses the <h2></h2> tag pair for your site's tag line. So, you're better off starting with a <h3> tag in every HTML module on a web page. That way, you won't drive Google's spider nuts by forcing it to wrestle with 23 <h1> tags on a single web page. When you need a sub-heading on the page, you should use the next tag downin the hierarchy; in our example, <h4>. Avoid the temptaton to skip levels. Don't jump from <h3> to <h6>, for example. And it's a good idea to use these heading tags. Don't just write plain text with large fonts instead.
Read more
  • 0
  • 0
  • 1541

article-image-ajax-chat-implementation-part-2
Packt
28 Dec 2009
9 min read
Save for later

AJAX Chat Implementation: Part 2

Packt
28 Dec 2009
9 min read
Create a new file named index.html, and add this code to it: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xml_lang="en" lang="en"> <head> <title>AJAX Chat</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <link href="chat.css" rel="stylesheet" type="text/css" /> <script type="text/javascript" src="jQuery-1.3.2.js" ></script> <script type="text/javascript" src="chat.js" ></script> </head> <body> <noscript> Your browser does not support JavaScript!! </noscript> <table id="content"> <tr> <td> <div id="scroll"> </div> </td> <td id="colorpicker"> <img src="palette.png" id="palette" alt="Color Palette" border="1"/> <br /> <input id="color" type="hidden" readonly="true" value="#000000" /> <span id="sampleText"> (text will look like this) </span> </td> </tr> </table> <div> <input type="text" id="userName" maxlength="10" size="10"/> <input type="text" id="messageBox" maxlength="2000" size="50" /> <input type="button" value="Send" id="send" /> <input type="button" value="Delete All" id="delete" /> </div> </body> </html> Let's deal with appearances now, creating chat.css and adding the following code to it: body { font-family: Tahoma, Helvetica, sans-serif; margin: 1px; font-size: 12px; text-align: left } #content { border: DarkGreen 1px solid; margin-bottom: 10px } input { border: #999 1px solid; font-size: 10px } #scroll { position: relative; width: 340px; height: 270px; overflow: auto } .item { margin-bottom: 6px } #colorpicker { text-align:center } It's time for another test. We still don't have the color picker in place, but other than that, we have the whole client-server chat mechanism in place. Load index.html at http://localhost/ajax/chat/index.html from multiple browsers and/or computers, and ensure everything works as planned. Figure 8-7: Screenshot of index.html Copy palette.png from the code download to your ajax/chat folder. Create a file named color.php and add the following code to it. This is actually the only step left to make the color picker work as expected. <?php // the name of the image file $imgfile='palette.png'; // load the image file $img=imagecreatefrompng($imgfile); // obtain the coordinates of the point clicked by the user $offsetx=$_GET['offsetx']; $offsety=$_GET['offsety']; // get the clicked color $rgb = ImageColorAt($img, $offsetx, $offsety); $r = ($rgb >> 16) & 0xFF; $g = ($rgb >> 8) & 0xFF; $b = $rgb & 0xFF; // return the color code echo json_encode(array("color" => sprintf('#%02s%02s%02s', dechex($r), dechex($g), dechex($b)))); ?> Make another test to ensure the color picker works and that your users can finally chat in color. What just happened? First, make sure the application works well. Load http://localhost/ajax/chat/index.html with a web browser, and you should get a page that looks like the one in Figure 8-1. If you analyze the code for a bit, the details will become clear. Everything starts with index.html. The only part that is really interesting in index.html is a scrolling region implemented in DHTML. (A little piece of information regarding scrolling can be found at http://www.dyn-web.com/code/scroll/.) The scrolling area allows our users to scroll up and down the history of the chat and ensures that any new messages that might flow out of the area are still viewed. In our example, the scroll element and its inner layers do the trick. The scroll element is the outermost layer; it has a fixed width and height; and its most useful property, overflow, determines how any content that falls (or overflows) outside of its boundaries is displayed. Generally, the content of a block box is confined to the content edges of the box. In CSS, the overflow property has four possible values that specify what should happen when an element overflows its area: visible, hidden, scroll, and auto. (For more details, please see the specification of overflow, at http://www.w3.org/TR/REC-CSS2/visufx.html.)   As you can see, the HTML file is very clean. It contains only the declarations of the HTML elements that make up the user interface. There are no event handlers and there is no JavaScript code inside the HTML file—we have a clean separation between the user interface and the programming. In our client-side JavaScript code, in the chat.js file, the action starts with the ready event, which is defined in jQuery (reference: http://docs.jQuery.com/Events/ready) as a replacement for window.onload. In other words, your ready() function, which you can see in the following code snippet, is called automatically after the HTML page has been loaded by the browser, and the page elements can be safely used and manipulated by your JavaScript code: $(document).ready(function() { } Inside this function, we do several operations involving events related to the user interface. Let's analyze each step! We want to be sure that a username always appears, that is, it should never be left empty. To do this, we can create a function that checks for this and bind it to the blur event of the textbox. // function that ensures that the username is never empty and //if so a random name is generated $('#userName').blur( function(e) { // ensures our user has a default random name when the form loads if (this.value == "") this.value = "Guest" + Math.floor(Math.random() * 1000); } ); If the username is empty, we simply generate a random username suffixing Guest with a randomly generated number. When the page first loads, no username has been set and we trigger the blur event on userName. // populate the username field with // the default value $('#userName').triggerHandler('blur'); The success() function starts by checking if the JSON response contains an errno field, which would mean that an error has happened on the server side. If an error occurred the displayPHPError() function is called passing in the error in JSON format. // function that displays a PHP error message function displayPHPError(error) { displayError ("Error number :" + error.errno + "rn" + "Text :"+ error.text + "rn" + "Location :" + error.location + "rn" + "Line :" + error.line + + "rn"); } The displayPHPError() will retrieve the information from the error and call in turn the displayError() function. The displayError() function shows the error message or a generic alert depending on whether the debugging flag is set or not. // function that displays an error message function displayError(message) { // display error message, with more technical details if debugMode is true alert("Error accessing the server! " + (debugMode ? message : "")); } Next, in our ready event, we set the default color for the sample text to black: // set the default color to black $('#sampleText').css('color', 'black'); Moving on, we hook on to the click event of the Send button. The following code is very simple, as the entire logic behind sending a message is encapsulated in sendMessage(): $('#send').click( function(e) { sendMessage(); } ); Moreover, here we hook on to the click event of the Delete all button in a similar way as the Send button. $('#delete').click( function(e) { deleteMessages(); } ); For the messageBox textbox, where we input messages, we disable autocomplete and we capture the Enter key and invoke the logic for sending a message: // set autocomplete off $('#messageBox').attr('autocomplete', 'off'); // handle the enter key event $('#messageBox').keydown( function(e) { if (e.keyCode == 13) { sendMessage(); } } ); Finally, when the page loads, we want to have the messages that have already been posted and we call retrieveNewMessages() function. Now that we have seen what happens when the page loads, it's time to analyze the logic behind sending and receiving new messages. Because everything starts when the page loads and the existing messages are retrieved, we will start with retrieveNewMessages() function. The function simply makes an AJAX request to the server indicating the retrieval of the latest messages. function retrieveNewMessages() { $.ajax({ url: chatURL, type: 'POST', data: $.param({ mode: 'RetrieveNew', id: lastMessageID }), dataType: 'json', error: function(xhr, textStatus, errorThrown) { displayError(textStatus); }, success: function(data, textStatus) { if(data.errno != null) displayPHPError(data); else readMessages(data); // restart sequence setTimeout("retrieveNewMessages();", updateInterval); } }); } The request contains as parameters the mode indicating the retrieval of new messages and the ID of the last retrieved message: data: $.param({ mode: 'RetrieveNew', id: lastMessageID }), On success, we simply read the retrieved messages and we schedule a new automatic retrieval after a specific period of time: success: function(data, textStatus) { if(data.errno != null) displayPHPError(data); else readMessages(data); // restart sequence setTimeout("retrieveNewMessages();", updateInterval); } Reading messages is the most complicated function as it involves several steps. It starts by checking whether the database has been cleared of messages and, if so, it empties the list of messages and resets the ID of the last retrieved message. function readMessages(data, textStatus) { // retrieve the flag that says if the chat window has been cleared or not clearChat = data.clear; // if the flag is set to true, we need to clear the chat window if (clearChat == 'true') { // clear chat window and reset the id $('#scroll')[0].innerHTML = ""; lastMessageID = -1; } Before retrieving the new messages, we need to check and see if the received messages have not been already processed. If not, we simply store the ID of the last received message in order to know what messages to ask for during the next requests: if (data.messages.length > 0) { // check to see if the first message // has been already received and if so // ignore the rest of the messages if(lastMessageID > data.messages[0].id) return; // the ID of the last received message is stored locally lastMessageID = data.messages[data.messages.length - 1].id; }
Read more
  • 0
  • 0
  • 5857
article-image-backbase-tag-library
Packt
28 Dec 2009
4 min read
Save for later

Backbase Tag Library

Packt
28 Dec 2009
4 min read
The focus of this article is the Backbase Tag Library (BTL). BTL concerns itself with the visible aspect of a web application user interface. For its dynamic behavior, we need JavaScript, or the XML Execution Language and Command Functions tag libraries. When you are developing a user interface, you will find that you are solving the same problems over and over again: Create a layout Show a menu of options Have tabs to structure the space on a page Provide pop ups and tool tips Do form validation These are just a few examples from a long list. The BTL is a set of UI widgets that can be used out of the box, which are extensible, and should appear the same in all browsers. By using these, you should be able to develop your website faster with a more robust result. Backbase Tag Library widget overview There are eight categories of BTL widgets for every aspect of layout and user interaction. If that is not enough, you can extend the BTL widgets to add new behavior or new looks and you can also develop your own widgets. The following schema shows an overview of the widgets that are available: There is also a ninth category of BTL elements. They are special because they can appear as attributes on other tags to specify extra behaviors that can be applied to any UI element. An example of such a behavior is drag-and-drop. If you are using the Backbase Explorer to find examples for the BTL widgets (http://demo.backbase.com/explorer/), the schema shown above may be a handy reference to find widgets you are looking for. We always use the b prefix when referring to BTL widgets, although you can use whatever (nonconflicting) prefix you want. The BTL abstract elements If you are interested mainly in learning what BTL widgets look like, then the subject of this section about abstract elements maybe a little too abstract. Feel free to skip it, but before you do, take a look at the picture of the inheritance relationships between abstract elements. The picture shows the attributes that are available on many BTL elements. Most of these attributes will be familiar to you and remind you of a not so distant past when you were still coding HTML instead of XHTML. While coding XHTML instead of HTML, you should use class and style instead of more specific attributes like width or margin. However, while using BTL, you must partly unlearn this for the BTL elements because using class or style could upset the styling that is done for the BTL elements, to make them look as they do. Abstract element inheritance structure The BTL markup language was developed using the Backbase Tag Definition Language. This means that BTL widgets are objects that can inherit properties from other TDL objects. It also means that you are able to extend the BTL objects into customized objects suitable for your application. The BTL objects that we are looking at in this article, the layout objects, inherit from more basic, abstract objects. It is useful to look at some of these abstract elements because their attributes can be used by inheritance on the layout objects. The BTL elements we will be looking at are element, containerElement, dimensionElement, postionElement, and visualElement. All layout BTL elements inherit from these. Here is a diagram of the inheritance structure: For those of you who are not so familiar with object-oriented models: the picture says that element is the object from which all others inherit. Therefore, for all BTL widgets, you can use the id and xml:base attributes, because these are defined on the element element. The Backbase Tag Definition Language supports multiple inheritance. Therefore, a cardStack element can use the attributes of both dimensionElement and positionElement, and by looking further up in the tree, also of visualElement and element. The relationship between card and cardStack says that a cardStack can contain zero or more card elements. The picture does not describe the methods available. The only public methods that are interesting, belong to cardStack, which has the next and previous methods. Now, let's look at some of the BTL elements in detail:
Read more
  • 0
  • 0
  • 1715

article-image-dialog-jquery-user-interface-17
Packt
24 Dec 2009
4 min read
Save for later

The Dialog in jQuery User Interface 1.7

Packt
24 Dec 2009
4 min read
Traditionally, the way to display a brief message or ask a visitor a question would've been to use one of JavaScript's native dialog boxes (such as alert or confirm) or to open a new web page with a predefined size, styled to look like a dialog box. Unfortunately, as I'm sure you're aware, neither of these methods is particularly flexible to us as developers, or particularly engaging for our visitors. For each problem they solve, several new problems are usually introduced. The dialog widget lets us display a message, supplemental content (such as images or text), or even interactive content (like forms). It's also easy to add buttons, such as simple ok and cancel buttons to the dialog and define callback functions for them in order to react to their being clicked. The following screenshot shows a dialog widget and the different elements that it is made of: A basic dialog A dialog has a lot of default behavior built-in, but few methods are needed to control it programmatically, making this an easy to use widget that is also highly configurable and powerful. Generating the widget is simple and requires a minimal underlying markup structure. The following page contains the minimum markup that's required to implement the dialog widget: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="en"> <head> <link rel="stylesheet" type="text/css" href="development-bundle/ themes/smoothness/ui.all.css"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>jQuery UI Dialog Example 1</title> </head> <body> <div id="myDialog" title="This is the title!">Lorem ipsum dolor sit amet,  consectetuer adipiscing elit.Aenean sollicitudin. Sed interdum pulvinar justo.  Nam iaculis volutpat ligula. Integer vitae felis quis diam laoreet ullamcorper.  Etiam tincidunt est vitae est.</div> <script type="text/javascript" src="development-bundle/jquery-1.3.2.js"></script> <script type="text/javascript" src="development-bundle/ui/ui.core.js"></script> <script type="text/javascript" src="development-bundle/ui/ui.dialog.js"></script> <script type="text/javascript"> $(function(){ $("#myDialog").dialog(); }); </script> </body> </html> Save this file as dialog1.html in the jqueryui project folder. To use the dialog, the following dependencies are required: ui.all.css jquery-1.3.2.js ui.core.js ui.dialog.js The dialog widget is initialized in the same way as the other widgets we have already looked at—by calling the widget's plugin method. When you run this page in your browser, you should see the default dialog widget as shown in the screenshot at the start of this article. As with the previous widgets we've covered, a variety of class names from the CSS framework are added to different elements within the widget to give them the appropriate styling for their respective elements, and any additional elements that are required are created on the fly. The following screenshot show these classes and the structure of the widget as interpreted by Firebug:   The dialog in the first example is fixed both in size and position, and will remain in the center of the viewport until it is closed. We can make the widget draggable, or resizable, or both easily. All we need to do is include the draggable and resizable component's source files with the other < script> resources at the end of the < body>.   It's not important that the draggable and resizable files are included in the page before the dialog's source file, they can come before or after and the widget will still inherit these behaviors. Any styling that is required, such as the resize indicator that appears in the bottom-left of the dialog, will be picked up automatically from the master CSS file.   Add the following two < script> elements directly before the closing < /body> tag in dialog1.html:   <script type="text/javascript" src="development-bundle/ui/ui.draggable.js"></script> <script type="text/javascript" src="development-bundle/ui/ui.resizable.js"></script>   Save this as dialog2.html and view it in a browser. The dialog should now be draggable and can be moved to any part of the viewport, but will not cause it to scroll if the widget is moved to an edge. The dialog should also be resizable—by clicking and holding the resize indicator the widget can be made bigger or smaller. If the dialog is made bigger than the viewport then it will cause the window to scroll.  
Read more
  • 0
  • 0
  • 1791

article-image-adding-flash-your-wordpress-theme
Packt
24 Dec 2009
11 min read
Save for later

Adding Flash to your WordPress Theme

Packt
24 Dec 2009
11 min read
Adobe Flash—it's come quite a long way since my first experience with it as a Macromedia product (version 2 in 1997). Yet still, it does not adhere to W3C standards, requires a plugin to view, and above all, is a pretty pricey proprietary product. So why is everyone so hot on using it? Love it or hate it, Flash is here to stay. It does have a few advantages that we'll take a quick look at. The Flash player plugin does boast the highest saturation rate around (way above other media player plugins) and it now readily accommodates audio and video, as video sites such as You Tube take advantage of it. It's pretty easy to add and upgrade for all major browsers. The price may seem prohibitive at first, but after the initial purchase, additional upgrades are reasonably priced. Plus, many third-party software companies offer very cheap authoring tools that allow you to create animations and author content using the Flash player format. (In most cases, no one needs to know you're using the $50 version of Swish and not the $800 Flash CS3 to create your content.) Above all, it can do so much more than just playing video and audio (like most plugins). You can create seriously rich and interactive content, even entire applications with it, and the best part is, no matter what you create with it, it is going to look and work exactly the same on all browsers and platforms. These are just a few of the reasons why so many developers chose to build content and applications for the Flash player. Oh, and did I mention you can easily make awesome, visually slick, audio-filled stuff with it? Yeah, that's why your client wants you to put it in their site. Flash in your theme A commonly requested use of Flash is usually in the form of a snazzy header within the theme of the site, the idea being that various relevant and/or random photographs or designs load into the header with some supercool animation (and possibly audio) every time a page loads or a section changes. I'm going to assume if you're using anything that requires the Flash player, you're pretty comfortable with generating content for it. So, we're not going to focus on any Flash timeline tricks or ActionScripting. We'll simply cover getting your Flash content into your WordPress theme. For the most part, you can simply take the HTML object embed code that Flash (or other third-party tools) will generate for you and paste it into the header area of your WordPress index.php or header.php template file. Handling users without Flash, older versions of Flash, and IE6 users While the previous method is extremely clean and simple, it doesn't help all of your site's users in dealing with Flash. What about users who don't have Flash installed or have an older version that won't support your content? What about IE users who have the Active X restrain? You'll want your site and theme to gracefully handle users who do not have Flash (if you've used the overlay method, they'll simply see the CSS background image and probably not know anything is wrong!) or an older version of Flash that doesn't support the content you wish to display. This method lets you add in a line of text or a static image as an alternative, so people who don't have the plugin/correct version installed are either served up alternative content and they're none-the-wiser, or served up content that nicely explains that they need the plugin and directs them towards getting it. Most importantly, this method also nicely handles IE's ActiveX restrictions. Is the ActiveX restriction still around? In 2006, the IE browser upped its security, so users had to validate content that shows up in the Flash player (or any player) via Microsoft's ActiveX controls). Your Flash content starts to play, but there's a "grey outline" around the player area which may or may not mess up your design. If your content is interactive, then people will need to click to activate it. This is annoying, but the main workaround involved "injecting" controls and players via JavaScript. Essentially, you need to include your Flash content via a JavaScript include file. As of April 2008, this restriction was reverted, but only if your user has updated their browser; chances are, if they intent on still using IE6 or 7, they haven't done this update. Regardless of whether you are concerned about ActiveX restrictions, using JavaScript to help you instantiate your Flash will greatly add to the ease of embedding content. It will also make sure that users of all versions or who need to install Flash are handled either by directing them to the proper Flash installation and/or letting them see an alternative version of the content. swfObject For a while, I used this standard swfObject method that was detailed in this great SitePoint article: http://www.sitepoint.com/article/activex-activationissue-ie. A similar, robust version of this JavaScript is located on Google Code's AJAX API http://code.google.com/p/swfobject/wiki/hosted_library. You can download the script (it's very small) or you can link directly to the swfObject AJAX API URL: <script type="text/javascript"src="http://ajax.googleapis.com/ajax/libs/swfobject/2.2/swfobject.js"></script> Downloaded or linked to the Google Code CDN, be sure to place this below your wp_head or any wp_enqueue_script calls in your < head > tags in your header.php template file or other head template file. Adding a SWF to the template using swfObject If you'd like to use the swfObject.js file and method, you can read the full documentation here: http://code.google.com/p/swfobject/wiki/documentation. But essentially, we're going to use the dynamic publishing option to include our SWF file. Using the SWF file included in this book's code packet, create a new directory in your theme called flash and place the SWF file in it. Then, create a div with alternative content and a script tag that includes the following JavaScript: <script type="text/javascript">swfobject.embedSWF("myContent.swf", "myContent", "300", "120","9.0.0");</script>...<div id="myContent"><p>Alternative content</p></div>... Add this ID rule to your stylesheet (I placed it just below my other header and intHeader ID rules): #flashHold{float: right;margin-top: 12px;margin-right: 47px;} As long as you take care to make sure the div is positioned correctly, the object embed code has the correct height and width of your Flash file, and you're not accidentally overwriting any parts of the theme that contain WordPress template tags or other valuable PHP code, you're good to go. What's the Satay method?It's a cleaner way to embed your Flash movies while still supporting web standards. Drew McLellan discusses its development in detail in this article: http://www.alistapart.com/articles/flashsatay. This method was fine on its own until IE6 decided to include its ActiveX security restriction. Nowadays, a modified embed method called the "nested-objects method": http://www.alistapart.com/articles/flashembedcagematch/ is used with the swfObject JavaScript we just covered. Good developer's tip:Even if you loathe IE (as lots of us as developers tend to), it is an "industry standard" browser and you have to work with it. I've found the Microsoft's IE blog ( http://blogs.msdn.com/ie/) extremely useful in keeping tabs on IE so that I can better develop CSS-based templates for it. While you're at it, go ahead and subscribe to the RSS feeds for Firefox ( http://developer.mozilla.org/devnews/), Safari ( http://developer.apple.com/internet/safari/), and your other favorite browsers. You'll be surprised at the insight you can glean, which can be extremely handy if you ever need to debug CSS or JavaScripts for one of those browsers. jQuery Flash plugin In the past year, as I've found myself making more and more use of jQuery, I've discovered and really liked Luke Lutman's jQuery Flash plugin. There is no CDN for this and it's not bundled with WordPress, so you'll need to download it and add it to your theme's js directory: ( http://jquery.lukelutman.com/plugins/flash/). Embedding Flash files using the jQuery Flash plugin As we're leveraging jQuery already, I find Luke's Flash plugin a little easier to deal with. Load the script under the wp_head. Place a div of alternative content; just the div of alternative content and nothing else! Write the jQuery script that will replace that content or show your alternative content for old/no Flash players. Code goes here. I think you see why I liked this so much more. Passing Flash a WordPress variable So now you've popped a nice Flash header into your theme. Here's a quick trick to make it all the more impressive. If you'd like to keep track of what page, post, or category your WordPress user has clicked on and display a relevant image or animation in the header, you can pass your Flash SWF file a variable from WordPress using PHP. I've made a small and simple Flash movie that will fit right over the top-right of my internal page's header. I'd like my Flash header to display some extra text when the viewer selects a different "column" (a.k.a. category). In this case, the animation will play and display OpenSource Magazine: On The New Web underneath the open source logo when the user selects the On The New Web category. More fun with CSSIf you look at the final theme package available from this title's URL on the Packt Publishing site, I've included the original ooflash-sample. FLA file. You'll notice the FLA has a standard white background. If you look at my header.php file, you'll notice that I've set my wmode parameter to transparent. This way, my animation is working with my CSS background. Rather than beef up my SWF's file size with another open source logo, I simply animate over it! Even if my animation "hangs" or never loads, the user's perception and experience of the page is not hampered. You can also use this trick as a "cheater's preloader". In your stylesheet, assign the div that holds your Flash object embed tags, a background image of an animated preloading GIF or some other image that indicates the user should expect something to load. The user will see this background image until your Flash file starts to play and covers it up. My favorite site to get and create custom loading GIFs is http://www.ajaxload.info/.   In your Flash authoring program, set up a series of animations or images that will load or play based on a variable set in the root timeline called catName. You'll pass this variable to your ActionScript. In my FLA example, if the catName variable does not equal On The New Web, then the main animation will play, but if the variable returns On The New Web, then the visibility of the movie clip containing the words OpenSource Magazine: On The New Web will be set to "true". Now, let's get our PHP variable into our SWF file. In your object embed code where your swfs are called, be sure to add the following code: If you plan on using the Satay embed method, your object embed will look like this: ...<script type="text/javascript">var flashvars = {catName: "<?echo single_cat_title('');?>"};swfobject.embedSWF("<?php bloginfo('template_directory');?>/flash/ooflash-sample.swf", "flashHold", "338", "150","8.0.0","expressInstall.swf", flashvars);</script>... If you'd like to use jQuery Flash, your jQuery will look like this: ...<script type="text/javascript">jQuery(document).ready(function(){jQuery('#flashHold').flash({src: '<?php bloginfo('template_directory');?>/flash/ooflash-sample.swf',width: 338,height: 150,flashvars: { catName: '<?echo single_cat_title('');?>' }},{ version: 8 });});</script>... Be sure to place the full path to your SWF file in the src and value parameters for the embed tags or jQuery src. Store your Flash file inside your themes directory and link to it directly, that is, src="/mythemename/flas'); template tag. This will ensure that your SWF file loads properly. Using this method every time someone loads a page or clicks on a link on your site that is within the On The New Web category, PHP will render the template tag as myswfname.swf?catName=On The New Web, or whatever the $single_cat_title(""); for that page is. So your Flash file's ActionScript is going to look for a variable called catName in the_root or _level0, and based on that value, do whatever you told it to do—call a function, go to a frame and animate; you can even name it. For extra credit, you can play around with the other template tag variables such as the_author_meta or the_date(), for example, and load up special animations, images, or call functions based on them.
Read more
  • 0
  • 2
  • 8468
article-image-seam-conversation-management-using-jboss-seam-components-part-2
Packt
24 Dec 2009
4 min read
Save for later

Seam Conversation Management using JBoss Seam Components: Part 2

Packt
24 Dec 2009
4 min read
The introductory page of the order process The first view in our page flow is an introductory page that simply navigates to the first step in our ordering process. Notice that we use the Seam tag to render a hyperlink that includes the conversation ID as a query string parameter. This is called conversation propagation. Seam conversation propagation using hyperlinks Seam automatically propagates the conversation during JSF form submissions using the HTTP POST method. For any GET requests (for instance, clicking on a hyperlink), we are responsible for including the current conversation ID as a request parameter to ensure that the request is handled properly. Seam provides a hyperlink control rendered by the tag that automatically includes the current conversation ID on the query string. We can also include the conversation ID as a query string parameter by nesting the Seam tag inside the standard JSF tag. Conversation ID propagation is automatic when a JSF form is submitted using POST. The markup for the introductory screen in our order process is as follows: <h1>Product Order Form</h1> <a4j:form> <rich:panel> <f:facet name="header"> <h:outputText value="Welcome to our Store" /> </f:facet> <p>Welcome to our store. Our step-by-step forms will guide you through the ordering process.</p> <s:link view="/order/step1.jsf" value="Place an order" /> </rich:panel> </a4j:form> } The following screenshot shows the introductory screen of our ordering process. Notice in the status bar of the browser window that the URL generated by the Seam JSF hyperlink control contains a query string parameter named cid with a value of one. As long as we pass this parameter from page to page, all the requests will be handled as a part of the same conversation. The conversation ID is automatically  submitted during JSF postback requests. When a new conversation is started, Seam will increment the conversation ID automatically. The customer registration screen (Step 1) The first screen, our page flow, requires the user to provide customer information before placing an order. This view is basically identical to the example used in the Seam validation section of this article. Therefore, much of the JSF markup has been removed for simplification purposes. Notice that the action has been hardcoded in the <a4j:commandButton> tag and corresponds to a navigation rule declaration in faces-config.xml. No additional work is required for the Seam conversation ID to be propagated to the server when the form is submitted; this happens automatically. <h1>Step 1. Customer Registration</h1> <a4j:form id="customerForm" styleClass="customer-form"> ... <a4j:commandButton value="Next Step" action="next" reRender="customerForm" /> ... </a4j:form> The following screenshot shows the customer registration step in the online ordering page flow of our application. The shipping information screen (Step 2) The following screen requires the user to select a product and a shipping destination before clicking on the Next Step button. Once again, Seam conversation propagation happens automatically when the form is submitted. The order details confirmation screen (Step 3) The next screen requires the user to confirm the order details before submitting the order for processing. Once again, the JSF markup has been omitted for brevity. Notice that the command button invokes the submitOrder backing bean method to submit the order. As noted earlier, this method is annotated with the Seam framework @End annotation, indicating that the long-running conversation ends after the method is invoked. When the method returns, Seam demotes the long-running conversation to a temporary conversation and destroys it after the view is rendered. Any references to conversation-scoped beans are released when the Seam conversation is destroyed, efficiently freeing up server resources in a more fine-grained way than by invalidating the session. <h:form> ... <a4j:commandButton action="#{orderBean.submitOrder}" value="Submit Order" /> ... </h:form> The following screenshot shows the order details confirmation screen.
Read more
  • 0
  • 0
  • 2145

article-image-data-modeling-naming-standards-ibm-infosphere-data-architect
Packt
24 Dec 2009
4 min read
Save for later

Data Modeling Naming Standards with IBM InfoSphere Data Architect

Packt
24 Dec 2009
4 min read
The Prime-Class-Modifier Words Pattern Prime words represent key business entities. In an insurance business, examples of prime word are policy and coverage. A class word is a category that qualifies a prime word; for example, in policy code name, code is a class word. policy code can further be qualified by a modifier word; for instance, previous policy code where previous is the modifier word. You can define your own naming pattern different from the above modifier prime class pattern for a specific modeling object, including the separator between words and if modifier word or class word in the pattern is optional. You can have, for instance, modifier?_prime_modifer?_class_modifier? pattern for attribute naming in a logical data model. The ? characters indicate the words are optional and the separators are _. An example name with that pattern is permanent employee last name, assuming we have defined in our standard that permanent as a modifier word, employee as a prime word, last a modifier word, and name as a class word. Note that we don’t have the last optional modifier word in this example. In a different business (not insurance), code might well be a prime word and policy might not be a prime word; hence the need to define your own specific list of prime, class and modifier words and naming patterns for their application, and that is what you build in glossary model. Building Glossary Model The InfoSphere Data Architect (IDA) allows you to build a glossary model from blank or from pre-defined enterprise model. Creating glossary model and selecting its template, blank or pre-built enterprise template The enterprise glossary model gives you a head start with its collection of words relevant across various business types, most of which would probably be applicable to your business too. You can customize the glossary: change or delete the existing words, or add new ones. Selecting an existing word or words in the list and then clicking the cross icon will delete the selected words   Clicking the plus icon allows you to add a new word into the glossary   When you add a new word, in addition to the name, you specify its Abbreviation, Alternate name, and most importantly its type (CLASS, PRIME) and if it is a Modifier word. When the glossary is applied for transforming a logical to physical model, the abbreviation is applied to the physical modeling object. Customizing a word being added   Selecting the type of a word   Before we can apply the words to naming our data model objects, we need to define the naming pattern. You can define the naming pattern for logical and physical modeling objects. The sequence of the word types in the pattern from top to bottom is left to right when you apply them in the names. You can also choose the separator for your naming pattern: space or title case for the logical model, and any character for the physical model (most preferred choice would be non alpha numeric character that is not used in any of the words in the glossary). Defining pattern for logical model objects (entity and attribute)   Defining pattern for physical model objects (table and column)   Specifying separator for logical model   Specifying separator for physical model You then choose the glossary model that you want to apply to your data models. Glossary Model.ndm in the packtpub directory is applied   When you have finished building your glossary model and defining naming pattern, you can then apply them for naming your modeling objects. (You can further adjust the words in the glossary them when such a need arises)
Read more
  • 0
  • 0
  • 7912
Modal Close icon
Modal Close icon