creating a form template
advertisement
KINETIC REQUEST Delivery Model Building Form Templates Revised March 11, 2008 KINETIC REQUEST DELIVERY MODEL DOCUMENT OVERVIEW The following document will assist with creating form templates. Form templates are service items in Kinetic Request that have elements that will get used over and over again in your other forms. These are useful for analysts to clone to create their own forms. They will often have empty sections where content would be included, but have many of the more technical areas already in place. Because of this, it is often useful for a more technical person to create the templates up front, allowing analysts to build the actual forms later, based on the templates created. CREATING A FORM TEMPLATE A form template is the same as any other form created using Kinetic Request. However, the idea of the form template is to be cloned, all or in part, to create other forms. Often templates include elements such as reusable section, some CSS styling details/classes, references to stylesheets or Javascript files and tasks for approvals and record creation. To build a good template: Look at the various forms your company would like to build. Look for consistencies in those forms. These often are: o Requester Section o Submitter Section (for ordering on behalf of someone else) o Approval Section: This is often hidden for the requester and then shown for the approver o Page Header Text o Section Headers/Titles o Footer text o Approval Models Approvals based on direct reports (A lookup in SHR:People or similar) Approvals based on categorization within the form (If they select Hardware then X, Software then Y) Approvals based on the form itself (All approvals from this form go to person X). Create a section or sections where it is obvious to form builder where to add their own content. This section could be called “Your Content Here”. Create the tasks that the form will most often need: An approval and then a record creation is the most common. Use a customized JSP to handle HTML header, page header and footer and other visual branding (See JSP section later in this document). In a typical installation, the templates created could be similar to these: Simple Form Template-No Approvals Simple Form Template-One Approval Page 2 of 6 KINETIC REQUEST DELIVERY MODEL Standard Form Template-One Approval & Create Incident Standard Form Template-Two Approvals & Create Incident These templates would then include a description about where/when to use them. It’s also a good idea to add an attribute to the template stating who the author is and the current revision. As a best practice, we usually set the “Type” of the form to be “Template”, so they are easily recognized when looking at list of forms. USING A FORM JSP Similar to building the portal, each form created in Kinetic Request uses a JSP page to layout the display of each page. The JSP page includes static HTML <head> content needed for every form display including references to the Kinetic Request JavaScript and CSS elements, other Java initialization code, and placeholders for the form definition configured by the author. The default form JSP page is: displayPage.jsp. This JSP file can be found in the root /kinetic/ directory on your web server or in the installation files. CREATE YOUR OWN JSP For most situations, it is best to create a copy of this default JSP file so that it can be customized to your own needs, without affecting the samples or simpler forms that use the default. Call this something similar to myITForm.jsp and keep it in the root of the /kinetic/ directory so the references to other files are still intact. Typically, only one customized JSP for all of the forms within a catalog, as they often share the same headers, stylesheets, etc. Then, on the “Advanced” tab of the Kinetic Request – Service Catalog Console, change the DisplayPage (JSP) value from the default JSP to the name of your copied JSP. Now, when the page is rendered, it will use your JSP instead of the default. Page 3 of 6 KINETIC REQUEST DELIVERY MODEL JSP JSP JSP JSP The illustration shows the use of JSP in a real-world situation. The header, left/right column, and footer (outside the dashed orange box) are all HTML in the JSP file. The center box is created using Kinetic Request. In this way, the form has a consistent, professional look and feel, while a non-technical person can easily create forms that fit in with the rest of the portal. In addition to the static HTML in the JSP, it is possible for the developer to insert more dynamic content. In the example the “Invoice Status Request” is the name of the form. Different forms would automatically have different titles across the top. Many form text elements can be included in the static JSP content this way: Form Name Form Description Catalog/Portal Name User’s Login Name Inserting this content in the JSP is done using the JSP “getProperty” tag <jsp:getProperty>. The Kinetic Request server bundles up the template information and user information into beans and attaches them to the JSP page for display (via the response object). All of the properties in these beans can be accessed and included this way. Of course, these elements and many others can also be embedded into the form itself (content inside the orange box) via dynamic text elements in Kinetic Request. Making the determination of which strategy to use where is up to the developer, but knowing your options is half the battle. Page 4 of 6 KINETIC REQUEST DELIVERY MODEL The additional benefit of using a single JSP for the look/feel of the form is form maintenance. If the company changes their logo or color scheme, a JSP developer can update the form in a single place and all of the forms that use the JSP get updated, as well. This makes managing your service portfolio in the long-term less complex. As you go forward building the JSP, be sure to reference the branding standards defined in the Delivery Model – Branding document. Often HTML can be cut directory from the pages referenced in that document and placed in your JSP. CSS Typical Remedy development often involves styling each individual element (question, text, boxes) individually including positioning, font, color, etc. for a form. While short-term this can sometimes be easier; it is not the most practical way of designing forms for your users. Having your forms published on the web allows other standard technologies do much of the heavy lifting for you. With a little planning, many of your forms can “draw themselves” letting CSS handle the padding, margins, font, sizing and positioning. DEFINING YOUR STYLES With CSS, it is best to take a top-down approach. The developer should style elements as much as possible at the highest possible level and handle unique situations at the element. All of the elements in Kinetic Request have their own CSS classes to make it easier to style in bulk. You can also create your own classes. Each Kinetic Request element on the style tab has a field to add your own class declarations. A typical CSS setup could include: A stylesheet (myCatalog.css) which includes html tag and CSS classes defined. o This would be attached to the portal and reference by all of the forms in the portal. They would automatically inherit these properties. o This file would define: Font family, font-size Background color Question padding & margins (questionLayer class) Question Label font-weight (often bold) (questionLabel class) Text padding & margins (dynamicText class) Section padding & margins Section headers (most sections have a title) To do this: Define your own class called sectionHeader and add this to the appropriate Dynamic Text elements in Kinetic Request TwoUp and ThreeUp styles This can be defined for sections where you want questions to show up in two or three columns rather than in a row. Add this class to questions you want to behave in this way o TwoUp: float:left; width 47%; o ThreeUp: float:left; width:31%; Page 5 of 6 KINETIC REQUEST DELIVERY MODEL Then on the form itself, define items that may be specific to the form via the Kinetic Request styling capabilities: o Again, use classes wherever possible for styling elements rather than doing them individually. o Items that may be defined on the form include: o Special fonts, font decoration, bolds, etc. Special indenting, margins Page Editor: The page editor is great for styling elements OTHER THAN positioning. Positioning can always be set in other ways, preferably by styles including: floats, margins, etc. (see TwoUp, ThreeUp). If you do want something indented use margin-left instead of draggingdropping items. Dragging and dropping elements will give a pixel-specific placement which will vary from browser to browser. Tip: Margins can be negative, moving an element up without relying on a browser specific interpretation like a “top” declaration will. Many of the forms that Kinetic Data creates have no element-specific styling, letting styles set at the HTML tag or class declarations do all of the styling. This also leads to more cross-browser compatibility for your forms. Technical Tip: The Firefox extension “Firebug” is a great way to see how any web page is styled. Install the Firefox plugin, then open Firebug. A frame on the bottom of your page will open. On the bar select “CSS” and “Inspect”. Then, any element you mouse-over will show the CSS properties included in that HTML element. It also shows inheritance of properties and where the property was defined (in an external file, in the <head>, inline). Using Firebug makes it much easier to match the style of an existing page or to troubleshoot style inheritance issues. Page 6 of 6
