<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#ffffff" text="#000000"> I've attempted to document what I think our approach should be for the FreeIPA Web UI. THe document is here: <a class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/wiki/UIApproach">https://fedorahosted.org/freeipa/wiki/UIApproach</a> For those adverse to clicking links, I'll inline it below as well. Please comment on specific section. <div class="wikipage"> <div id="searchable"> This page is just a draft, pending approval of the rest of the FreeIPA team. The general approach to Web UI development for IPA springs from the fact that Javascript is a fundamental aspect of web programming. Instead of using a Server side scripting language to drive development, and then attempting to shoehorn Javascript into that language, we are using Javascript as the primary programming language of the site. The command line interface (CLI) has already specified a large body of xml-rpc based APIs. We will focus on the Web UI and using same API, called via JSON-RPC, a format somewhat friendlier to the Javascript language. The current state of the art in Web design has embraced a concept called Progressive Enhancement (PE). Under Progressive Enhancement, a site is first developed with no Javascript and minimal Cascading Style Sheet (CSS) support. The goal is to build a fully functioning site that works on the widest away of browsers, with the trade off that it will have only the most rudimentary of features. While we are diverging a little bit from this approach, our default requirement for a minimal subset of Javascript will support all major browsers, and has been tested on such a minimal browser as is supported on the Palm Pre wireless device. From this baseline, we will then follow the recommendations of PE, testing the browsers for any capabilities we will require for features such as auto-complete, tabbed browsing, and enhanced text editing. This approach should maximize the number of browsers capable of using the web UI. The landing page should have a simple name, such as ipa.xhtml. The file requires no servers side scripting to render. Instead, all dynamic content, including navigation, is driven by Javascript in the browser. Each of the subordinate pages are currently implemented as HTML fragments that are included into the main page using <blockquote> $('#content').load(bodycontent); </blockquote> where content is the id for the DIV tag that contains the main content area, under the menu, and bodycontent is a string that names the page to be loaded. The page fragments are not in themselves valid xhtml, as that would require additional parsing in order to get them to render. They have the extension of .inc. For the most part, they are completely static HTML, coupled with a simple script tag that knows how to populate the fragment. Because common functions should be shared across multiple pages, the main body of work should not be inside the page fragments. Constant refactoring should occur to keep the fragments as light as possible. The menu for the site is a custom component based on the concept of a dynamic site map. In short, the site map is a tree structure, where each node maps to a page. This tree is used to generate the tabs that are the navigational structure of the site, as well as the links on these tabs. The nodes of the site map May be hided or reordered based on the role of the logged in user. The links map to the page fragments discussed above. IPA has a plugin architecture that allows the site deployer to customize the objects managed by IPA. This poses an interesting challenge for the UI. For basic functionality, it is relatively simple to specify the set of fields presented for managing one of the base objects (user, host, group). Once the user starts modifying the field set, we have several potential scenarios. 1. The user may add additional fields that they want to see on the web UI. 2. The user may modify one of the existing fields such that default validation rules no longer hold true 3. The user may remove fields from the objects. A first approximation would be to generate the UI based on the Plugin Data itself. The drawbacks of this approach are: splitting UI development over two languages, and forcing the CLI to conform to rules that may only make sense for the web UI. In addition, this approach was attempted in the past, and ended up with a very "data drive, CRUD style" approach that didn't map to the work flow users really need to make the site usable. We will take a page from the Progressive Enhancement book, and test the JSON returned from the server in order to see what values are accepted. This will help solve problems 1 and 3 above. For deleted fields, we can determine if a given field is essential. If an essential field has been removed, we will report a meaningful error message to the end user, and disable either the entire site, or some subset of functionality, based on business rules. For fields added but not exposed by the UI, we will add a single warning message to the log upon first access. After this, we will set a cookie in the browser and ignore these warnings, except perhaps to have some indicator on the page the there are unhandled fields. A validation rule is a business rule, and thus spans both the UI and business-logic layers. For field that have validation rules that have changed, the best approach is to share the validation between the browser and the back end scripting language. As such, validation rules should be represented in a subset of Regular Expressions supported both by the server side language (Python) and by Javascript. The validation rules themselves are then exposed via JSON-RPC to the Browser. For development and unit testing, all content that is fetched from JSON-RPC calls can be replaced with canned responses from files in a subdirectory named sampledata. To switch between sampledata and live JSON calls, alternately create or remove a file from the web root directory named ipadebug.js that contains the single value "ipadebug=true". This file is tracked via gitignore so that no-one accidentally checks it in. The Makefile that assembles the files from the web directories will ignore the files in sampledata. If we wish to deploy the sample data files for unit testing purposes, we can always create a separate RPM for them that does not get built or deployed be default. </div> </div> </body> </html>