<!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 been working with the "add host " and "host details" pages for the past couple of days. It is getting time to refactor how we do add and details, to avoid cutting and pasting. Here's the general structure I'm approach on taking. For each collection (user, group, host, etc) there will be an instance of a SearchForm object that maps to that collection. This object will have a reference to at a minimum two other form objects, one for details, one for "add". Here's changes for the Search Form Objects <ul> <li> objects will be held in global scoped variables, not inside function scope as it is currently done now.</li> <li> Search Forms will not contain any state. All state will be contianed in the primary key, the json responses, and the form params.</li> <li>Instead of rendering the search form in the constructor, it will have a "build" function that performs the same actions.</li> </ul> The same general approach will happen with the Add and Details approach. In general, each page will have an instance of some type of "Form" object. The difference between the user search form and the group search form is which instance all of the methods look for. so the Update button will be bound to <blockquote> function() { userDetailsForm.update() }; </blockquote> or <blockquote> function() { groupDetailsForm.update() }; </blockquote> appropriately. The goal here is to reduce duplicated code, and the corresponding copy-and-paste errors it introduces. Ideally I'd like to do something like: <blockquote>var activeDetailsForm; ... activeDetails = userDetailsForm; ... $("#addEdit").click( function() { activeDetailsForm.addEdit() }; ); </blockquote> my one concern is making sure that variables like activeDetailsForm get set correctly upon back-button. For now I am going to put the details work in the host.js file, as I don't want to get into a knarly merge with details.js. At some point, Pavel and I will coordinate moving it into details.js. I am considering adding add.js for that functionality, but am reluctant to add yet another file, as that increased the download time for initial view of the site. search, details, and add are all considered facets inside the code. If you look at the URL, you should see something like: <blockquote> #tab=user&facet=search </blockquote> or <blockquote> #tab=group&facet=details&pkey=ipausers </blockquote> Every collection will have these three facts, but will have a collection of 0 or more additional facets. For example, user will have a membership facet. This collection of facets will be used to create the links off of the details page at the top. The general trend is going to be to divide code up into one of three categories: Framework, Domain Objects, Wiring. Thus, things like search, details, and navigation in the abstract are framework, user and groups and so forth are domain objects, and wiring is the population of things like the navigation and facets. There is obviously some blurring between wiring and domain objects, but the guiding principal will be that wiring is for Fitting together the overall site, such as how the navigation is set up, where as Domain is for UI behavior specific to a collection. This will not be a single patch, but instead will be the target of several small refactorings as I implement features in the site. I've already started with the DetailsForm, but need to create the AddForm, and will do so as I implement add hosts. </body> </html>