Choose a color, enter a length, click ‘Create Gradients’. Page will generate 4 gradients (.pngs), from the selected color to transparent, along 4 axes, in both directions.
The above link illustrates the use of the dojo ColorPicker widget.
Select a color, font, and enter some text. Clicking Create Image will display a corresponding image.
ImageMagick (http://imagemagick.org) is used to create the image.
The link above demonstrates the use of a dijit ContentPane to request content from the server with a client-side request refresh, and error detection that allows the server to indicate when the requests should be stopped.
The intended use is to allow graceful monitoring of background scripts on a server.
- Use the ContentPane to display the content. A quote script is used to illustrate the content change.
- Have the server-side code count and issue a 303 See Other when processing has completed. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
- Have the client-side code catch the 303 and act accordingly. In this case, it changes the displayed text to reflect the status, puts up an alert box, and clears the timer.
Use View Source to view the client-side code, server-side code is listed at the bottom of the page.
This is a nice way to implement a refreshing iframe with dojo.
dijit’s (dojo - http://dojotoolkit.org) tundra theme is excellent.
Notes on customizing it:
- Copy dojo.css, dijit.css, tundra.css, and the supporting images out of the dojo tree and into the application’s CSS directory. Place the images in a directory under CSS, that way, the paths don’t have to be updated in the CSS files for those images. This risks later version conflicts with dojo, but also prevents inadvertant destruction of customization on upgrades. This also ensures you don’t affect other applications as you modify the files.
- Update paths in the files (tundra.css imports dijit.css). Renaming tundra.css is a good idea, since it won’t be tundra after you change it.
- Use icons from the Crystal Project (see link above). Be creative, the icons are beautiful and can be used in many ways to enhance the dijit theme.
- Strive to avoid creating new images, unless you can create them quickly. Tiny images can take a surprising amount of time. Since the majority of tundra is grey, with blue highlights, simply removing the blue images and adjusting the remainder can provide a neutral color scheme.
- Augment the tundra colors with those from you application. If you use the same hue, you can adjust the brightness and saturation to add variety to the color scheme.
- Change as little as possible, because tundra already looks great. Try to preserve the dojo CSS file structures, so that if you need to merge in changes after an upgrade, it is not too difficult.
- Use at least four other CSS files, base.css which contains application common basic layout, color.css, which contains application common color settings, ie.css for IE, and ff.css for FF specific settings. Additional page-specific CSS files, as well as some embedded style tags may be helpful as well. Configure caching to reduce the impact of these files, consider compression or bundling them together if necessary. Keep CSS as lean as possible, place design images in HTML, where they don’t incur overhead unless they are used.
- Spend time looking at the Crystal icons. Even if the icon is named ‘urgent_mailmessage.png’, if it looks good where you want to use it - use it there.
- Install the Crystal icons in DocumentRoot, then link to them with a symlink from the images directory, which should be at the same level as the CSS directory. That way, the icons can be shared by all applications and sites on the server.
Notes on using a dojo/RIA web interface to launch background (server-side) scripts.
- File uploads can run under FF and IE with dojo.io.iframe.send, and it is a nice interface. There is another post on this blog, with sample code.
- Synchronizing background server tasks with client launch and monitor requires the client to be able to identify script failure to execute, execute reporting whether the operation was successful or not.
- Two-phase, asynchronous execution can be made much more secure by storing the second-phase action on the server. Thus, if the first-phase executes correctly, no information is required from the client to continue the operation. All data submitted can be disregarded.
- Success or Error can be indicated with HTTP headers in cases where no data is required on the response.
- Client-side redirects can be used to transition to the next phase after a successful run of one phase.
- User should be alerted that scripts initiated through the web interface cannot be stopped (unless a mechanism is provided).
- User should be able to return to a previously initiated scripts and view the output.
- Background script output should be delivered to the initiator through an email. User should be able to suppress email.
- Background scripts should deliver output in text only.
- Server must be responsible for state management. Server must ensure background scripts do not collide with each other, or the data, and must provide an interface that allows the client to determine if administration should be readonly or prohibited when specific scripts are executing.
- Server must be responsible for scheduling resource intensive tasks to prevent service interruptions.
- An object is an excellent way to allow a single dialog box to submit data to different scripts without writing additional code. The object is then assigned to the AJAX content property.
- Server must have intelligence to adjust state of client, for example hiding informational messages after termination, enabling buttons to allow continuation, and providing alerts for errors.
- Initial error reporting can be limited to ‘Error’, a simple indication that something went wrong. After testing, common errors should be delivered with additional explanatory text.
- Break server side code into components such that only the code required to execute is read. This doesn’t always work out perfectly, and there are impacts to opening alot of files as well, but the server impacts are less serious than the client side, because there is no data transfer.
- Put some timing code into the application so you can see where the time goes. Use YSlow to improve page delivery performance.
- Use FireBug to monitor traffic between client and server.
- Use a log file to write out debugging information. Check the error_log frequently. Use echo, var_dump, and exit. Build graceful error reporting into the application from the beginning. This will make debugging much easier. Log all errors. Put a switch in to allow debug displays to be suppressed for production systems.
- Use a tee (*nix command) to pipe script output to a file and into mail.
- Document the entire process and describe it to the appropriate people. This will ensure you understand what is happening and that it is what is supposed to be done. Be ready to change.
- Write a good test plan and use it.
- Be mindful of security. Validate all inputs. Escape all command line parameters that are user submitted. Check for access privileges for all requests, at all times. Avoid divulging application details or data.
- Copy script output to a temporary access area, do not grant access further into the server for output display. Identify script output with the script name and session id.
- Have Apache execute as apache:apache, or nobody:nobody, and allow only those scripts that should be executed through the web to have execute permissions for that user.
- Be persistent and creative.