Sun Web Application Guidelines - Version 4.1
|
| Search Guidelines | Send Feedback | Developers.sun.com |
| [ Table of Contents | 0 Revision History | 1 Introduction | 2 Visual Design | 3 Windows and Pages | 4 Mastheads | 5 Top-Level Navigation | 6 Content Area | 7 Simple Elements | 8 Complex Elements | 9 Tables | 10 Topology | 11 Contextual Help | 12 Search | 13 Wizards | 14 Alerts and Messages | 15 Progress Indicators | 16 Alarms and Status Indicators | 17 Login Page | 18 Version Page | Appendices ] |
How To Use These Guidelines - An Introduction
<IP_ADDRESS> Comparative Attribute Line Colors
<IP_ADDRESS> Graph Title Text: Property Page
<IP_ADDRESS> Other Graph Types and Tips
This chapter addresses the design of complex user interface elements that are used in similar ways across applications. These elements are usually groups of simple elements that together perform a more complex common interaction. In the Java Look and Feel Guidelines, they are called idioms.
When using the user interface elements described in this chapter and elsewhere in these guidelines, remember to use them with cultural considerations in mind. For example, applications must be able to format and display time, date, and calendar data according to local cultural conventions.
To ensure that cultural considerations are addressed when using user interface controls, follow the guidelines in Appendix H, Globalization Requirements.
For most elements there are these states:
For fields which do not show a data value, such as the file chooser and client-side file upload, the only applicable states are enabled and disabled. The possible appearances are documented for each type of field.
For more information on the placement of read-only fields within a page, see 6.8.1 Noneditable User Interface Elements.
All buttons on components should be secondary buttons.
Use an editable scrolling list to manage a list of single-line text strings. Allow users to view the list of text strings, add new text strings, or remove existing text strings.
The editable scrolling list is not intended for strings which are so long as to cause horizontal scrolling on the page.
Here is an example with the editable scrolling list with the list below the text field (the "list-on-bottom" version):
Here is an example of an editable scrolling list with the list above the text field (the "list-on-top" version), with Move to Top and Move to Bottom buttons included:
When the editable scrolling list is noneditable (read-only), the lists and buttons should be replaced with a simple list of text strings (regardless of whether the entry field was above or below when it was editable), separated by commas, some other separator character, or line breaks like this:
When the editable scrolling list is disabled (does not apply in the current situation), its buttons, text field, and list should be disabled, like this:
The editable scrolling list has the following basic behavior (see the table below for more detailed button descriptions):
The editable scrolling list differs from the 8.2 Add-and-Remove Idiom. The add-and-remove idiom is used to select any number of items from a list so that those items can be used for some other purpose. In contrast, the editable scrolling list simply enables users to add and remove items from a list of text strings.
Use the list-on-top version or the list-on-bottom version of the editable scrolling list, depending on the problem at hand.
When using the list-on-top version, place validation error alerts (see 14.5 Validation Error Alerts) for the text field *below* the editable scrolling list so it is next to the text field to which it applies. Otherwise, it will be above the list even though it applies to the text field below.
At the bottom of the list, include a line longer than the longest possible value, or a line a bit longer than the average/most common value, as makes sense for the expected values for the list. This line, which consists of a string of underscores (_), is programmatically kept below all the entries as items are added and removed. This strategy maintains a fixed line width for the list or minimizes the expansion/contraction when entries are added/removed, which keeps the geometry of the entire idiom stable. Otherwise, the buttons and list could move substantially based on the width of the remaining list items.
Compute the number of underscores based on both the text box's width and the font size of the underscores.
If the user selects the string of underscores (either by itself or with other entries) and clicks any button, nothing should happen.
Both fields must have labels for accessibility reasons. However, the labels can be either left of the fields or above them. These labels should be normal font.
A label for the entire editable scrolling list is optional. If such a label is provided, place it above the editable scrolling list, left justified. This label should be bold and in larger text, like this:
When having at least one value in the list is required, mark the list -- not the entire component or the entry field --to indicate that, like this:
A maximum length can be set for values, and the entry field will not allow more than that number of characters to be entered. Within that maximum, the list will grow horizontally as larger values are entered. This maximum should be chosen to include all reasonable values for the situation at hand, but is helpful in keeping the buttons from scrolling off the right side of the page otherwise.
Provide Add and Remove buttons for the editable scrolling list.
Provide Move Up, Move Down, and optionally Move to Top and Move to Bottom buttons if it makes sense for the application.
For more information on button types, see 7.1 Action Buttons.
Follow these guidelines for all buttons used in the editable scrolling list. These guidelines do not apply to buttons not used in the editable scrolling list.
| Button | Description | Additional Guidelines |
|---|---|---|
| Add | Adds the entered item to the list. | See discussion below for a comparison of validated and unvalidated additions. |
| Remove |
Removes the selected items from the list. |
The Remove button is available only while one or more items are selected in the list. Optionally, display a JavaScript alert to confirm removal of the items. |
| Search |
Enables users to search to find an item to add to the editable scrolling list. |
To help users identify an appropriate value to add to the list, provide the Search button if the value exists in some other area of the application. Use the following interaction design:
|
| Move Up |
Moves the selected items one row up in the current list. |
Provide the Move Up button if the order of the choices is relevant. If Move Up is provided, also provide Move Down. If a user applies the Move Up button to a selection containing nonadjacent items, the button works as if the user performed it on each item separately. As a result, the selected items retain their positions relative to one another. The moved items remain highlighted, and the user may move them up another step. If the user continues to click Move Up after the top item goes to the top of the list, continue to move up all selected items that are below unselected items until they are together at the top. When all selected items are already at the top, the Move Up button should be disabled. |
| Move Down |
Moves the selected items one row down in the current list. |
Provide the Move Down button if the order of the choices is relevant. If Move Down is provided, also provide Move Up. If a user applies the Move Down button to a selection containing nonadjacent items, the button works as if the user performed it on each item separately. As a result, the selected items retain their positions relative to one another. The moved items remain highlighted, and the user may move them down another step. If the user continues to click Move Down after the bottom item goes to the bottom of the list, continue to move down all selected items that are above unselected items until they are together at the bottom. When all selected items are already at the bottom, the Move Down button should be disabled. |
Move to Top
|
Moves the selected items to the top of the current list. |
Provide the Move to Top button if the order of the choices is relevant and many items are expected to be in the list. If Move to Top is provided, also provide Move to Bottom. If a user applies the Move to Top button to a selection containing nonadjacent items, move all selected items to the top, keeping them in their original order relative to one another. When all selected items are already at the top of the list, the Move to Top button should be disabled. |
Move to Bottom
|
Moves the selected items to the bottom of the current list. |
Provide the Move to Bottom button if the order of the choices is relevant and many items are expected to be in the list. If Move to Bottom is provided, also provide Move to Top. If a user applies the Move to Bottom button to a selection containing nonadjacent items, move down all selected items to the bottom, keeping them in their original order relative to one another. When all selected items are already at the bottom of the list, the Move to Bottom button should be disabled. |
To enable users to add an item to the editable scrolling list without verifying that the item is valid, use the following design:
For an interactive example of an Editable List, see
http://webdev2.sun.com/example/faces/editablelist/editableList.jsp
Use an add-and-remove idiom when users are likely to choose more than two values from an existing list and it is likely they want to see selected values together to verify them, or the order of the selected values is significant, or both.
The add-and-remove idiom is not intended for strings which are so long as to cause horizontal scrolling on the page.
Design the Available and Selected lists so that 10 to 15 values can be shown at once in each list. The Available list is comprised of items that are eligible for selection. The Selected list is comprised of items that have been added from the Available list. Items in the Selected list are the items that will have future actions applied to them.
Do not use any grouping methods for the items in the lists. See <IP_ADDRESS>.1 Grouping Menu Items for examples of grouping methods.
Enable the same multiple selection techniques used in <IP_ADDRESS> Multiple Selection Scrolling List; however, do not note them on the page as their use is completely optional.
Multiple selection techniques provide shortcuts for users who would otherwise have to perform the add action repeatedly to select multiple list items. Experienced users expect all add-and-remove idioms to provide these shortcuts.
Place a label for the entire add-and-remove idiom above the Available and Selected list labels. Make the label plural, as shown in the example above.
Both lists must also have labels for accessibility reasons.
Apply headline capitalization to all of these labels (see 2.5 Text Capitalization).
If the two lists are too wide to fit side-by-side on the page, orient the lists vertically, as shown here:
When the add-and-remove idiom is noneditable (read-only), the lists and buttons should be replaced with a simple list of text strings separated by commas or some other separator character, or separated by line breaks, like this:
When the add-and-remove idiom is disabled (does not apply in the current situation), it should have the buttons and lists disabled, like this:
Allow double-clicking on an item in the Available list to immediately add that item to the Selected list. Allow double-clicking on an item in the Selected list to immediately remove that item from the Selected list.
At the bottom of the Available and Selected lists, include a line longer than the longest possible value. This line, which consists of a string of underscores (_), is programmatically kept below all the entries as items are added and removed. This strategy maintains a fixed line width for both lists, which keeps the geometry of the entire add-and-remove idiom stable. Otherwise, the buttons and lists would move based on the width of the remaining list items.
Compute the number of underscores based on the desired width of the text box and the font size of the underscores.
If the user selects the string of underscores (either by itself or with other entries) and clicks any button, nothing should happen.
When one or more selections is required, mark the selected list -- not the entire component -- to indicate that, like this:
A label for the entire add-and-remove idiom is optional. If such a label is provided, use a standard field label and place it either
Provide Add and Remove buttons when using the Add-and-Remove idiom. Only one will be enabled at once, however, based on which list the user is on. Remove is disabled when the user is on the Available list, and Add is disabled when the user is on the Selected list. If the user is not on either list, neither will be enabled.
Provide Add All and Remove All buttons if it makes sense for the application.
Provide Move Up and Move Down buttons if it makes sense for the application. These buttons apply exclusively to the Selected list.
For more information on button types, see 7.1 Action Buttons.
Follow these guidelines for all buttons used in the add-and-remove idiom. These guidelines do not apply to buttons not used in the add-and-remove idiom.
| Button | Description | Additional Guidelines |
|---|---|---|
| Add | Adds items to the Selected list. |
More precisely, the Add button copies all selected items from the Available list and adds them to the Selected list at the end or, if the Selected list is sorted, in the correct order. The Add button then deletes the items from the Available list -- unless they can be added to the selected list multiple times in different contexts so remain there for reuse. Finally, the Add button selects the copied items in the Selected list and deselects any previously selected items in the Available list. The Add button is available only while one or more items are selected in the Available list. |
| Add All |
Moves or copies all items from the Available list to the
Selected list and then selects them in the Selected list. |
Provide the Add All button if users will want to select all the items even occasionally. If Add All is provided, also provide Remove All. The Add All button is available only while the Available list is not empty. |
| Remove |
Removes items from the Selected list. |
More precisely, the Remove button removes the selected items from the Selected list, adds them to the Available list (at the end or, preferably, at their previous positions) and, finally, selects the items in the Available list, deselecting the Selected list. Removing an item from the Selected list has no effect on the Available list if that item is already in the Available list. The Remove button is available only while one or more items are selected in the Selected list. |
| Remove All |
Moves all items from the Selected list to the Available list. |
Provide the Remove All button if users will want to clear the list of selected items even occasionally (for example, to start a whole new selection). Remove All may be provided without Add All. The Remove All button is available only while the Selected list is not empty. |
| Move Up |
Moves the selected items one row up in the selected items list. Applies to the Selected list only. |
Provide the Move Up button if the order of the choices is relevant. If Move Up is provided, also provide Move Down. If a user applies the Move Up button to a selection containing nonadjacent items, the button works as if the user performed it on each item separately. As a result, the selected items retain their positions relative to one another. The moved items remain highlighted, and the user may move them up another step. If the user continues to click Move Up after the top item has hit the top of the list, continue to move up all selected items which are below unselected items, until they are together at the top. When all selected items are already at the top of the list, the Move Up button should be disabled. |
| Move Down |
Moves the selected items one row down in the selected items list. Applies to the Selected list only. |
Provide the Move Down button if the order of the choices is relevant. If Move Down is provided, also provide Move Up. If a user applies the Move Down button to a selection containing nonadjacent items, the button works as if the user performed it on each item separately. As a result, the selected items retain their positions relative to one another. The moved items remain highlighted, and the user may move them down another step. If the user continues to click Move Down after the bottom item goes to the bottom of the list, continue to move down all selected items which are above unselected items, until bthey are together at the bottom. When all selected items are already at the bottom of the list, the Move Down button should be disabled. |
For an interactive example of an Add-and-Remove Idiom, see http://webdev2.sun.com/example/faces/addremove/AddRemove.jsp
The orderable list allows users to manually order the items in single selection and multiple selection scrolling lists. This may be useful if users have to arrange items in order of preference or by some other criteria. The list may be either single-selection or multiple-selection.
The orderable list is not intended for strings which are so long as to cause horizontal scrolling on the page.
Do not use the orderable list if any automatic sorting of the list is being provided.
When the orderable list is noneditable (read-only), the list and buttons should be replaced with a simple list of text strings separated by commas or some other separator character, or separated by line breaks, like this:
When the orderable list is disabled (does not apply in the current situation), it should have the buttons and list disabled, like this:
The list must have a label for accessibility reasons.
Provide Move Up and Move Down buttons.
Provide Move to Top and Move to Bottom buttons if it makes sense for the application.
For more information on button types, see 7.1 Action Buttons.
Follow these guidelines for all buttons used in the orderable list. These guidelines do not apply to buttons not used in the orderable list.
| Button | Description | Additional Guidelines |
|---|---|---|
| Move Up |
Moves the selected items one row up in the current list. |
If a user applies the Move Up button to a selection containing nonadjacent items, the button works as if the user performed it on each item separately. As a result, the selected items retain their positions relative to one another. The moved items remain highlighted, and the user may move them up another step. If the user continues to click Move Up after the top item goes to the top of the list, continue to move up all selected items which are below unselected items, until they are together at the top. When all selected items are already at the top of the list, the Move Up button should be disabled. |
| Move Down |
Moves the selected items one row down in the current list. |
If a user applies the Move Down button to a selection containing nonadjacent items, the button works as if the user performed it on each item separately. As a result, the selected items retain their positions relative to one another. The moved items remain highlighted, and the user may move them down another step. If the user continues to click Move Down after the bottom item goes to the bottom of the list, continue to move down all selected items which are above unselected items, until they are together at the bottom. When all selected items are already at the bottom of the list, the Move Down button should be disabled. |
Move to Top |
Moves the selected items to the top of the current list. |
Provide the Move to Top button if many items are expected to be in the list. If Move to Top is provided, also provide Move to Bottom. If a user applies the Move to Top button to a selection containing nonadjacent items, move all selected items to the top, keeping them in their original order relative to one another. When all selected items are already at the top of the list, the Move to Top button should be disabled. |
| Move to Bottom |
Moves the selected items to the bottom of the current list. |
Provide the Move to Bottom button if many items are expected to be in the list. If Move to Bottom is provided, also provide Move to Top. If a user applies the Move to Bottom button to a selection containing nonadjacent items, move down all selected items to the bottom, keeping them in their original order relative to one another. When all selected items are already at the bottom of the list, the Move to Bottom button should be disabled. |
Do not use special "separator" choices as a distinguisher between "above the line" choices and "leftover" choices -- for that situation, the Add-and-Remove Idiom is the appropriate element to use instead (see 8.2 Add-and-Remove Idiom).
For an interactive example of an Orderable List, see http://xdesign.sfbay.sun.com:8080/example/faces/orderablelist/OrderableList.jsp
There are two forms of date and time selection. A simple pop-up calendar for entering dates graphically from a date text field, and a full scheduler panel for more complicated needs that include time, repeat intervals, or other details.
If your task requires the input of a single date into a text field, the pop-up calendar can be used to allow the user to select a date and insert it into the field. In some cases it may be appropriate to display a set of text fields where users can specify, for example, starting and ending dates. Each text field would include its own calendar.
The following two images show how this looks before and after the pop-up calendar is displayed.
Pop-up calendar, before the pop-up calendar is opened:
Editable version, after the pop-up calendar is opened:
Allow users to display the pop-up calendar by clicking the iconic Calendar button, , located to the right of the text field.
When the calendar is popped up, display it below the iconic Calendar button.
The popped up calendar displays the current month and year by default. The current date is bolded in the calendar, and displayed in text at the top of the calendar. The drop-down menus at the top of the calendar can be used to change the current month and year. To step through the months one at a time, users can click the arrow buttons to the left and right of the month drop-down menu.
If there is a date in the text field when the calendar is invoked, display this date as the default selection in the calendar when it is displayed. Selected dates are bold with a highlighted background. If the text field is empty when the calendar is invoked, show no default selection in the calendar when it is displayed.
Allow users to close the calendar in the following ways:
When the user selects a date, close the calendar and insert the selected date into the text field.
Editable version, after the date is selected from the pop-up calendar:
If the user closes the calendar by a means other than selecting a date, do not update the text field. If a date had been entered into the text field before the calendar was invoked, do not change it. If the text field was blank when the calendar was invoked, leave it blank.
The Scheduler element is used for setting schedules within an application. This element is made up of several simple elements (labels, text fields, buttons, and lists) and a calendar element. It was formerly known as the Date/Time Element. Here is an example:
The example above shows the Scheduler element as it would appear within the
context of a larger page. Also shown here is the legend that describes the red
asterisk image associated with the Date field. This asterisk image identifies a required field, and a legend must appear in the appropriate place on the page to inform users that the field is required (see 7.3.2
Editable Text Fields for more information). The asterisk image should appear to the right of the field labels as shown above.
Note that Date is generally a required field. However when the Scheduler element is used on a page with other elements, there may be times when, given the context of the application, it does not make sense to make the Date a required field. In this situation, the Date field can be made optional. This is only allowable for the inline Scheduler element.
An example of a situation where it would not make sense to make the Date required might be when the user has to specify when a report gets run and it is valid to specify a particular date, or just a time that the report will be run every day.
In the above picture, the user can specify the date either by clicking on it in the calendar or entering it into the Date field. The Preview in Calendar button is available if the user enters the date into the Date field and then wants to see it reflected in the calendar before clicking the OK button. The user can also use Preview in Calendar to update the calendar to reflect the values entered into the other applicable fields. Note that time information is not reflected in the calendar.
When designing the monthly calendar for the Scheduler element, follow these guidelines:
If an existing schedule is reflected in the Scheduler element, the scheduled dates are displayed in bold with a highlighted background, just as when the user first selects them.
The example at the beginning of this section shows how a defined schedule would display when it is opened for viewing or editing. All fields are set to their defined values, and the calendar element displays the scheduled dates.
Follow these guidelines for the content of the Repeat Interval list, which is programmable:
Follow these guidelines for the Repeat Limit field, which sets a limit on the number of repetitions:
Provide a Preview in Calendar button (see 7.1 Action Buttons) to allow users to update the calendar to reflect the data entered in the fields. Changes in these fields are not reflected in the calendar until the Preview in Calendar button is clicked. Note, however, that when a new date is selected in the calendar, the selection is treated as the new Date and the values in these fields are used to update the calendar to reflect the new starting date.
Include simple elements (which are programmable) within the Scheduler element as required for your application.
Various applications might only need a subset of the functionality provided in the preceding example. For example, there might be a need for repeat intervals but not repeat limits. Or, there might only be a need for a Start Time without an End Time. To provide this flexibility, the API to this element should allow for the display of a subset of simple elements. Simpler versions might include the monthly calendar and Date field only for date selection or a pair of drop-down menus for time selection.
The labels used for the time fields, Start Time and End Time, should be programmable based on the application needs. The Start and End labels were used as generic examples. The application developer may choose whatever labels are most appropriate.
If a Repeat Interval is shown, the label for date might be changed to Start Date or something more specific for the date being chosen.
The following example mimics the scheduling fields in a Solaris crontab(1) file (with the exception that the crontab file does not use a year field). Such files do not specify an End Time or a Repeat Limit. Users who might require additional functionality unique to the cron utility would typically use the actual command in a terminal window.
The Scheduler element can be embedded within a page, but can also be invoked in a pop-up window.
As with the Scheduler element embedded within a page, the fields displayed in the Scheduler element in a pop-up window can be displayed in full or adjusted to the needs of the application.
For example, the following picture shows a Scheduler pop-up window that could be used when the user clicks the calendar icon next to a set of fields asking for Scheduler information on a main browser page. The only fields needed are the Date and Time fields. The user specifies the date and time and then clicks OK.
General guidelines for displaying a noneditable version of the Scheduler Element are to show the fields as text only. See 7.3.2 Editable Text Elements for details. The calendar could appear and perhaps allow browsing months and years, but should not allow clicking on new dates. A future version of the guidelines may provide more details for this design.
There are two forms of file selection. Client-Side File Upload is used for selecting files on the client, while File Chooser (and Folder Chooser) are used for selecting files (or folders) on the server. Choose the appropriate one based on the location (client or server) from which the user will be selecting files.
When it is necessary to upload a file from the client to the server, the client-side file upload element can be used. The client-side file upload element is not used to browse files on the server. For this, use the file chooser element (see 8.5.2 File Chooser Element).
The client-side file upload element consists of a labeled text field with an associated Browse... button as shown below. The text field and label should behave like any other text field. See 7.3 Text Elements for guidelines.
There is no design for the client-side file selection window itself, as it is provided by the operating system, and is platform-specific.
When the Browse... button is clicked, the browser-specific client-side file chooser window is displayed. In this window, the user chooses the file to be uploaded to the server. When the user has completed making a selection in this window, the fully qualified name of the selected file is displayed in the text field of the client-side file upload element.
When the page is submitted, the specified file is uploaded to the server and handled by the application. For example, the file may be opened and displayed, or it might be saved.
Note that the Browse... button used in this element is a standard form element. Therefore, the style of the button cannot be made to match the style of the buttons shown in other images in these guidelines.
When the client-side file upload is disabled (does not apply in the current situation), it should have the button and field disabled, like this:
(There is no noneditable client-side file upload, as having a read-only version of an action would not apply.)
For an interactive example of Client-Side File Upload, see http://webdev2.sun.com/example/faces/chooseruploader/fileUploader.jsp
The file chooser element is used to browse files on the server. The file chooser element is based on standard file choosers from Java and Windows applications.
Web browsers, by default, bring up a platform-specific file selection dialog that is used to browse files available to the client the browser is running on. The file chooser element is not used to browse files on the client. To browse files on the client, and then upload a selected file from the client to the server, use the client-side file upload element (see 8.5.1 Client-Side File Upload Element).
The file chooser is used to navigate through the server's file system by searching for a specific file. The list shows all folders and files within the currently selected folder.
The file chooser can be displayed in a pop-up window or inline on a secondary content page in the main browser window. When on a main browser page, it can appear by itself or with other user interface elements that are not specific to the file chooser, but are relevant to the page on which the file chooser is displayed.
Here is an example file chooser shown in a pop-up window:
When the file chooser element appears on a main browser page:
Place the server name at the top of the dialog page.
Include a Look In text field and apply the following guidelines:
Use the Look In text field to show the hierarchical path to the currently displayed list.
If the folder name specified does not exist, present an inline error message including the value entered in the Look In field (See 14.1 Inline Alert Messages for more details), and reset the Look In field and other fields to the previous valid folder. This avoids losing the location the user had been on, which would have often forced canceling and starting over in order for the user to continue.
For the list, which shows all folders and files within the currently selected folder, follow these guidelines:
(Each newly opened folder updates the path in the Look In text field).
The Back Up One Level iconic button navigates up one level in the file system hierarchy and displays the files and folders at the new level in the list.
If a file selection is made, clicking the Choose File button returns the full path of the file to the application and invokes the proper window behavior: pop-up windows close and return the file name to the application while inline file choosers return the file name, clear the Selected File text field, and either close, or wait for additional user input at the application designer's discretion.
Include a Selected File text field and apply the following guidelines:
If a file is selected in the list, display the name of the file in the Selected File text field. If multiple files are selected, display all of the files names separated by commas. Do not display folder names in the Selected File text field (see later discussion about the Selected Folder text field).
Allow the user to specify a new path in the Selected File text field. After the user enters the new path and hits enter, update the list and the Look In text field to reflect the new path. If a user types a path that begins with '/' or '\', take that as the full path name. Otherwise, append what the user types to the path in the Look In text field.
Clear selected file text if the user selects a different folder in the list. Replace existing text in the Selected File text field only when the user selects a new file name from the list or types a new file name. No other action should replace existing text in the Selected File text field.
Allow the user to specify a file name in the Selected File text field by typing a full path, or without a path if the file is contained in the current Look In folder. Once the user types in a valid file name and presses the Enter key, the window should react appropriately: pop-up windows should close and return the file name to the application while inline file choosers should return the file name, clear the Selected file text field, and either close or await additional user input at the application designer's discretion.
If the user makes an error when typing a file or folder name in the Selected File or Selected Folder fields, display an inline alert message (See 14.1 Inline Alerts for more details), but leave the value entered in the field for the user to edit it. Note this is slightly different behavior than when the user puts an incorrect folder name in the Look In field, as in this case leaving the incorrect values does not lose the location the user had been on.
Multiple selection: Most file chooser elements should support multiple selection unless the application designer has a compelling reason not to (such as that only one file selection makes sense for the situation). See the following example of a file chooser element that supports multiple selection.
Multiple selection is allowed through standard use of the Shift (contiguous selection) and Ctrl (disjoint selection) keys. In this case, clicking the Choose Files button returns a list of all selected file path names.
If multiple files can be selected:
Folder Chooser Variant: Some applications might require browsing the
server's file structure to locate a folder (rather than a file). This version
of the chooser is called a folder chooser and is slightly different, as shown
below.
Although files can be selected, no action can be performed on them. The lighter gray color is used to indicate that files cannot be acted upon in the folder selection version of the file chooser. Files are included in the list as an informational aid only, allowing the user to see the entire contents of a given folder.
The requirements listed for the file chooser element apply to the folder chooser, with the following exceptions:
Replace the "Choose File" button with a "Choose Folder" button, or the "Choose Files" button with a "Choose Folders" button if multiple selection is allowed.
The "Selected File" field label is changed to "Selected Folder," or the "Selected Files" field label is changed to "Selected Folders" if multiple selection is allowed.
Display the folder name(s) in the Selected Folder(s) text field. Do not display file names there.
Double-clicking a file does not perform any action. (Double clicking a folder opens it as in the file chooser. It does not select that folder.)
(On a future release, the File Filter field may be changed to be a Folder Filter in the folder chooser.)
(There is no noneditable File Chooser or Folder Chooser, as having a read-only version of an action would not apply.)
For an interactive example of a File Chooser, see http://webdev2.sun.com/example/faces/chooseruploader/fileChooser.jsp
For an interactive example of a Folder Chooser, see http://webdev2.sun.com/example/faces/chooseruploader/folderChooser.jsp
The line graph guidelines provide basic visual design specifications. The design elements covered here are primarily limited to font treatments, line weights, color palette, and basic layout guidelines. These designs were developed for implementation with JFreeChart, a Java class library for generating charts, although the designs should be generic enough to use with other packages.
Line graphs should be displayed on a white background.
Graphs should not take on the appearance of a three-dimensional display.
Offer a graph title. The title should provide a general, yet concise, description of the graph.
Provide detailed title information in a subtitle placed directly below the graph title.
A legend should be provided with the graph.
If presenting a duel-axis graph (two y-axis), use separate legends to describe each.
If possible, include the title "Legend:" above the legend information. If including a title is not possible, provide inline help text with the legend to describe it. For guidelines on providing inline help see 11.1 Inline Help.
The visual presentation of the legend may vary based on implementation constraints, but the final design should never visually compete with the graph itself.
If the user has selected a specific scale (Daily, Weekly, Monthly), scale the graph accordingly.
Space out the tick mark intervals to suit the size of the graph.
Use a minimum of 10 pixels distance between the tick labels on an axis.
If possible, provide tool tips for data points. The tool tips could contain more detailed information about the data points.
When using time values in charts, follow the localization guidelines for time located in Appendix H - Globalization Requirements.
When displaying 24-hour time, add "24-hour time" to the axis label.
To support accessibility, give the user the choice of a graph or table representation of the data. The table display could be offered via the longdesc HTML attribute in the image tag that links to a page that shows the data, or via a configuration option during the setup process for the graph.
Basic Graph
Graph Tick Line Variations: Solid Gray or Dotted Gray Tick Lines
The following palette colors are recommended for use within line charts. The palette colors have been evaluated for accessibility using Vischeck, an online tool that can emulate how a page or graphic will appear to colorblind users. The line graph colors selected mitigate the display differences. See http://vischeck.com/ for more information. Product teams can use alternate colors, as long as the colors are tested for accessibility.
There are two recommended color palettes, a comparative color palette and a threshold palette, which when combined provide a single palette of six colors. Using only six colors (maximum) in any given graph limits the cognitive burden of interpreting a large number of color-coded associations. It also makes distinguishing between multiple attributes and threshold lines easier for the user.
For users to distinguish between attributes, each attribute charted should use a unique line color.
The maximum number of attributes that can be presented on a graph at any one time is six.
If you need to use alternate palette colors, see 1.4 Resources for Application Designers to determine the approvals required for doing this.
Threshold lines can be provided on graphs to indicate alarm, status, or other thresholds. There are three colors in the threshold palette which can be used for threshold lines. See 8.6.2 Lines and Data Points for more information. The three colors in the threshold palette indicate severity levels: critical (red), major (yellow/orange) and minor (blue).
Use the colors in the palette shown below for the threshold lines.
Threshold Palette
If a peak threshold needs to be represented in the graph, use any remaining color in the threshold or comparative palettes.
If thresholds need to be presented, only use one attribute per graph and black for the attribute line color as shown in the example below.
Single Attribute with Data Points, Threshold Lines, and Peak Threshold Line
The comparative palette colors are primarily used in graphs that present multiple attribute lines. When graphs present multiple attributes, unique colors for each attribute line helps the user distinguish between them.
Graphs with multiple attributes should not include threshold lines.
When threshold lines are not included in the graph, the comparative palette can be extended with colors from the "threshold" palette.
Use the colors in the following palette for charting attributes in multiple attribute graphs.
Comparative Palette (*plus threshold colors)
Graph with Multiple Attributes and Duel Axis
Graphs do not need a border around them.
Graphs must have axis lines which are 1 pixel wide, color #999999.
Tick mark grid lines should be less than 1 pixel wide, if possible.
Tick mark lines should be solid and a light gray color, such as #CCCCCC or lighter. A dotted or dashed gray line is also acceptable.
Threshold lines should be dotted (or very short dashes). The dots should be 2 pixels wide and 2 pixels high.
A peak threshold line should be a solid line, in a lighter line weight than the attribute line.
Data points are represented as small, 4 x 4 pixel squares which match the colors of the associated lines.
Use long dashes to indicate predicted data as shown in the example below.The dashed, predictive, segment of the attribute line uses the same color and line weight characteristics as the non-predictive segment.
Predictive Graph With Dashed Lines
All text should use "Arial," or the system's default sans serif font.
The default type style is: plain, 12px/pt, black, unless specified otherwise.
Tick mark labels align to the graph. If tick mark labels are on the left of the table, the text aligns right. If tick mark labels are on the right of the table, the text aligns left. If the tick mark labels are above or below the table, the label center aligns to the tick line that it refers to.
Tick mark label text is "Arial," 10 px/pt.
To conserve horizontal space, tick mark labels should be forced to wrap onto two lines (i.e. Oct 17 on top line and 10:00 AM on the 2nd line).
Axis titles should be separated 10 pixels from the tick mark labels.
Vertical axis labels are rotated 90 degrees to read vertically beside the axis.
Text for the axis labels is "Arial," Bold, 12 pt, #666666.
If the axis label is above or below the table, the label is center-aligned to the graph.
Text for graph title is "Arial", Bold, 16 pt.
Text for the subtitle for the graph is: "default."
Graph title and subtitle text should be center-aligned to the graph, and positioned 10 pixels above it.
Text for property page title is: "Arial", Bold, 12 pt, #666666.
Text for the property page subtitle is: "default."
Property page title and subtitle text should be center-aligned to the graph, and positioned 10 pixels above it.
Text for the legend data is: "default."
Text for the legend title, if presented, is: "Arial", Bold, 12 pt, #666666.
If a description of the legend is provided, it should follow the style guidelines for "Inline Help", see 11.1 Inline Help.
While only line graphs are detailed above, there are many other graph types which will be appropriate to different situations. Limited information for other graph types is provided below, and detailed guidelines for other graph types may be provided in a later release.
When creating pie charts, do not use 3D representations as they distort the data.
Additional tips for creating graphs can be found at this external resource: http://lilt.ilstu.edu/gmklass/pos138/datadisplay/sections/goodcharts.htm#Times%20Series%20Charts
This external reference is provided for your supplementary information. It is not part of the Web Application Guidelines. If there are any conflicts between this document and the Web Application Guidelines, use the web application guidelines for building your application. Also, some of the tips included in that document may not be possible in JFreeChart.
This section provides design specifications for user interface elements that are used within Sun-branded portal pages. A definition of a portlet is given, and the portlet table and portlet tab components are discussed. Basic page layout suggestions for presentation of a portlet within a Web page are also presented. Navigation or technical considerations of portal site design are not discussed.
The portlet table and portlet tab elements described here are based on the components in the Sun Common UI Component Library (in open source, the Project Woodstock components), but shown with a visual treatment specifically for use in the portlet environment.
Portlets are Java-based Web constructs, managed by a portlet container, which offer aggregated, customized, and dynamic content. They are presented on a Web portal page containing one or many portlets. For more information refer to the JSR (Java Specification Request) 168 Portlet Specification.
This portlet user interface design is comprised of the portlet content area and a title bar. The title bar contains the portlet title and the portlet controls.
A close button is provided in the far right corner to close that portlet.
Portlets also offer action controls which act on the level of the portlet. The controls are initiated through an Edit drop-down menu. This menu is placed at the top right, left only of the close control.
The drop-down menu generally contains items that allow users to modify the portlet's view and content. Some examples include collapsing or hiding the portlet container, changing its position on a page, or setting preferences for what is to be shown in the portlet.
An additional drop-down menu item may launch a "Help" window page as a secondary window. For guidelines regarding secondary windows, refer to section 3.8 Secondary Content Pages. Development teams may also want to include application-specific buttons.
The Edit drop-down menu remains open until the user makes a menu selection or clicks the drop-down toggle button to dismiss the menu.
Edit Drop-down menu selections should be visually indicated by highlighting the selected item, or by using a checkmark icon. Use the same highlight color chosen for other areas within the application. The highlight selection color should be consistent throughout the user interface.
Regardless of functionality, both controls use the same visual characteristics to indicate three different action states: default (not pressed), hover, and pressed. See the examples below:
Portlet content area should have a white background color, unless a portlet is used for login.
The border for the content area should be a 1-pixel gray line.
If a portlet is used for user login, use a background gradient as shown in the following section, to emphasize and distinguish it from other portlets on the page.
As an initial configuration, portlets are typically combined within a Web portal page. Users can most often tailor portlet configuration and content from this presentation. Consistent spacing between portlets will help to maintain a usable page design, despite changes to the portlet configurations. The recommended spacing between portlets is illustrated below.
Portlets should be spaced 20 pixels apart from one another, and other components, when combined on a Web portal page together.
Like other page elements, portlets should also maintain the 10-pixel margin for the page edge.
If a specific portlet needs to be emphasized on the page, place it in the upper left-hand corner of the content area.
The portlet table is used within the content area of a portlet. The table design for a portlet is a modified version of the Sun Common UI Component Library (in open source, the Project Woodstock components) table design. It offers all of the same functionality as the Sun Common UI Component Library, yet has a different visual treatment for presentation within a portlet window.
The portlet table is distinguished from the standard table by its visually diminished table title and title bar background, no table background element, and different visual treatment for the table action bar and column headers. These combined differences allow the portlet table to exist within the portlet without visually overwhelming it and distracting the user from the data inside.
While the portlet table offers the same functionality as the standard Sun Common UI Component Library (in open source, the Project Woodstock components) table, you should avoid employing full table functionality in a portlet environment. Full table functionality, with its visual affordances, can easily overwhelm the condensed portlet display and make it difficult for users to find information.
The ideal presentation of the portlet table is a property table or a table with only a few actions. If the tabular data needs more robust table functionality, you should redirect users to another Web page containing a standard table display.
Avoid offering full table functionality with a portlet table.
When a lighter weight table is needed outside the portal, just use the standard table and leave off the action bar. Only use the portal light weight table inside portals.
Restrict the width of the table to ensure that the portlet content and controls are always visible on the desktop.
The portlet mini-tab group is used within the content area of a portlet. The mini-tab group is a modified version of the Sun Common UI Component Library (in open source, the Project Woodstock components) tab component design. The portal tabs can only have one level of tabs, as opposed to the standard tab design which can have up to three levels. The portlet tab design offers a simple means of switching views between a few tabbed content panes. It is visually distinct from the standard Sun Common UI Component Library tab design because background shading behind the tabs is absent and a containment box encloses the tabbed pane. See the example below:
Portlet tabs are restricted to one level.
Portlet tabs should not wrap to a second tab row or cause a scroll bar within the portlet.
Restrict the number of tabs to ensure that the portlet content and controls are always visible on the desktop.
| [ Table of Contents | 0 Revision History | 1 Introduction | 2 Visual Design | 3 Windows and Pages | 4 Mastheads | 5 Top-Level Navigation | 6 Content Area | 7 Simple Elements | 8 Complex Elements | 9 Tables | 10 Topology | 11 Contextual Help | 12 Search | 13 Wizards | 14 Alerts and Messages | 15 Progress Indicators | 16 Alarms and Status Indicators | 17 Login Page | 18 Version Page | Appendices ] |
| Privacy Policy | Terms of Use | Trademarks | Copyright 2007 Sun Microsystems, Inc. |


Our pride is our people, we ensure that each and every individual we hire within Core Intelligence is the correct fit for us, just as every individual we represent to our customers not only meets the technical specification but also fits the team and organisation.
Creating a strong bond with our customers allows us to better understand their needs, their company needs, but also a “glove like” fit for the people we put forward.
Our unique four point interview process is tailored to each role, ensuring a well thought out engagement process which will ensure the correct information has been passed on to the candidate and the correct candidate passed on to our customer.
At Core we use a technical assessment examination where each candidate completes a technical use case to prove their technical knowledge rather than just talk about it.


This tool will drop (and reset) database collection for database cleanup for continuous testing.
Status:
Clear


Instructions
To start the game just click on the "save slot" cards. I had the name entry disabled so no one can get creative with the names! ;-)
Take the customer's order... Make the cupcakes... Give it to the customer. If it's done correctly, you get a big tip!
It gets hard when there is more than one customer to deal with at once!


include 'ArrayList.con'
import standard.C.io
import standard.C.math
import standard.C.time
define FILENAME "test.txt"
class Main {
function RandomString(len) {
var buffer = "";
var list = new ArrayList();
list[0] = "a";
list[1] = "b";
list[2] = "c";
srand(time());
for (var i = 0; i<len; i++)
buffer += list[rand()%3];
return buffer;
}
function Main() {
var fd;
var bytes;
var buffer;
// Generate the buffer
buffer = RandomString(10);
// Open file in text mode
if (fd = fopen(FILENAME, "w+t")) {
echo "Contents of buffer = " + buffer + "\n";
bytes = fwrite(buffer, 1, 10, fd);
echo "Wrote " + bytes + " items\n";
fclose(fd);
} else
echo "Problem opening the file\n";
// Open file in text mode
if (fd = fopen(FILENAME, "r+t")) {
buffer = "";
bytes = fread(buffer, 1, 10, fd);
echo "Number of items read = " + bytes + "\n";
echo "Contents of buffer = " + buffer + "\n";
fclose(fd);
} else
echo "File could not be opened\n";
}
}
Results
Contents of buffer = bacccaabba
Wrote 10 items
Number of items read = 10
Contents of buffer = bacccaabba
|


{FeatureTitle}
{SuccessMessage}
This file will be available for download and view for 24 hours. All uploaded and output files will be deleted from our servers in 24 hours.
Thanks,
Aspose Support Team.
Aspose.app
Copyright © 2019 Aspose, all rights reserved.
Aspose Pty Ltd, Suite 163, 79 Longueville Road, Lane Cove, NSW, 2066, Australia.


src/rx/endlessSubject.js
/* eslint no-param-reassign: [2, {"props": false}] */
import Rx from 'rxjs/Rx';
/**
* EndlessSubject extension of Rx.Subject.
* This is pretty hacky, but so far I'd found no better way of having
* Subjects that do no close on multicasted stream completion and on multiple errors.
* For documentation refer to
* [Rx.Subject docs](@link https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/subjects/subject.md).
* The only difference is that EndlessSubject never triggers '.complete()' and
* does not closes observers on errors (thus allowing to continuously dispatch them).
*/
class EndlessSubject extends Rx.Subject {
/**
* Dummy method override to prevent execution and Rx.Observable completion
* @return {void}
*/
complete() {}
/**
* Override of error method that prevents stopping that Rx.Observer
* @param {Error} error - Error to be dispatched
* @return {void}
*/
error(error) {
this.thrownError = error;
// dispatch to all observers
this.observers.forEach(os => {
// dispatch directly to destination
os.destination._error.call(os.destination._context, error);
});
}
}
export {EndlessSubject};


biochar soil yield Biochar {border-style application nutrient plant px;} use #ffffff;} Soil soils available effects Field Sci. effect properties Plant different reported agricultural carbon tropical Environ. crop production retention straw Lehmann Nair agriculture greenhouse organic role studies water (pH Increase amendment growth px; systems {font-family Crop Zhang addition clay font-size increase mitigation phosphorus potential produced relatively review sandy source Jeffery Rice availability benefits biochar, double; emissions feedstock field management manure productivity research soil. sustainable total ./s--- Based Bioenergy Freitas Maize Res. Rice; Table Wang Wheat area based biomass border-color border-width capacity climate composting feedstocks fertilizer improving increased inorganic land microbial physical ratio recent sequestration smallholder solid; stability stabilization temperature water-holding {font-style {font-weight ./gcbb. ./j.geoderma... Agegnehu Available Chen Effects Figure Geoderma Maize; Pot WHC Zheng aggregate agroecosystem biochars bold compost concluded conditions. content courier; crops em; environmental farms high husk improvement increases increasing knowledge leaching loam loamy manure, materials meta-analysis negative nutrients properties. pt;} release rice sand sand, soil, soils: specialty strategy terms tree using various


WITNESS LIST Finance Committee April 26, 2004 - 1:00P Property Tax ON: Allaway, Bill (Texas Taxpayers Association of Texas), Austin, TX Moehring, Red (Self), Granger, TX Turner, Lucille (Self), Cedar Park, TX Reformed Franchise Tax FOR: Boone, Michael M. Attorney (Dallas Citizens Council and Greater Dallas Chamber), Dallas, TX ON: Craymer, Dale Chief Economist (Texas Taxpayers Association of Texas), Austin, TX Huddleston, Albert Legacy Investments (Self), Dallas, TX Rosenbaum, Glen Attorney (Law Firm Legislative Coalition), Houston, TX Revenue Options for Public School Finance ON: Bittick, Susan (Foley's Department Store), Houston, TX Crevoiserat, Joanne CFO (Foley's Department Store), Houston, TX Le Bas, James Revenue Estimator (Comptroller's Office), Austin, TX Warren, Ed Revenue Estimator (Comptroller's Office), Austin, TX Zodrow, George Economics Professor (Self), Houston, TX Registering, but not testifying: On: Phillips, Preston Investment Analyst (Self), Dallas, TX


web spider humidity temperature silk prey webs climate properties change Blamires mean high orb capture effects performance max model strain, used {border-style impact low material px;} stiffness) #ffffff;} strain Biol Blackledge changes silks Harmer species Exp energy threads values Argiope breaking different thread Table dynamic extended projectile property range scenarios. temperatures (−% likely medium Opell ability affect constructs effect functionality plasticity predictions spiral stiffness variation web. Alam Boutry However, Soc environments influence modelling px; showed spiders vary {font-family Blackledge, Ecol Fig. University Vollrath and/or conditions data fitness font-size important integrity kinetic make phenotype phenotypic radial ranges scenarios specific tension webs. web’s (i.e. Plaza Sci Sensenig Stellwagen Tarakanova Webb complex double; extreme functional future individual studies study using Behav DiRienzo Figure Hennessy, Moreover, Roy affected analysis animal architecture based border-color border-width cases changing climatic common construct damage expected genetic glue glycoprotein humidity, increase interactions models multibody number orb-weaving orb-web parameters predicted reported results retention scenario solid; spider’s structural supercontraction test tested toughness various web, webs, work {font-style {font-weight A), Bailey, Blamires, Buehler, Climate D), Evol F). Interf Lin Plasticity Rep Sydney Sydney, Temperature Waite adhesive adhesiveness architectural behaviour bold courier; decrease em; environmental evolution features flying following follows: function gluey impacts interplay low-humidity major need predict prey. produce pt;} radon shown silk: single time


CYBORG A film review by Dale L. Skran, Jr. Copyright 1989 Dale L. Skran, Jr.
CYBORG belongs to a small sub-genre, the Science-Fiction Martial Arts film. This sub-genre is larger than might be supposed, since it includes all those terrible "gladiators in a future arena" movies such as DEATH RACE 2000 and AFTER THE FALL OF NEW YORK. Another recent example is STEEL DAWN which has a slightly more substantial SF plot than the various "death races." A +1 film that fits into this sub-genre is THE RUNNING MAN which featured Arnold Schwarzenegger duking it out on a game show with hockey-stick wielding psychos. These films as a group are poorly made and exhibit low quality, unrealistic fighting.
Recently, a number of martial artists have attempted to put on the screen a higher level of realism in fighting. The two major examples are Steven Senegal, an Akidoist starring in ABOVE THE LAW and Jean Claude Van Damme in BLOODSPORT. Neither film has a very strong or believable plot, but both contain excellent fight scenes that are well above the typical Hollywood slam-bang. A digression into the world of stunt-fighting is called for at this point. Hopefully movie audiences are aware that movie fights are carefully planned to maximize the breakage to surrounding walls, tables, lamps, etc. to increase the drama of the moment. Another "Hollywoodism" is that scene where the hero, punched/kicked many times by the villain, draws from deep within themselves the resources to go on and win. Another "Hollywoodism" is the villain gaining the upper hand, and then squandering it to explain their plans for world domination or just getting the girl (guy). A final "Hollywoodism" is that in spite of all the slam-bang, people just dust themselves off, and escape more or less unharmed.
 The framing plot is about -3, the training scenes about 0 level, but the fights are +2. They are excellently filmed, diverse, and very well thought out. Van Damme is an extremely flexible martial artist who clearly has mastery of an enviable variety of techniques. He is pleasing on the screen, and seems fairly convincing in his relatively simple roll. Much of the impetus of the story derives from the knowledge that it is supposedly true: a Frank Dux really exists who claims to have won just such an underground tournament. I have read interviews with Dux, and apparently the fights are fairly close to what he claims actually happened. BLOODSPORT was a very low budget film that played surprisingly well and propelled Van Damme into the limelight.
With this background, it was with bated breath that a tiny group of fans of SF Martial Arts awaited CYBORG, a new SF movie starring Van Damme. It should be noted that there is also a written branch of SF martial arts, notably STREETLETHAL and THE KUNDALINI EQUATION by real- life Kung-fu stylist Steven Barnes, who co-authored DREAM PARK with Larry Niven. Other examples include MATADORA and THE MAN WHO NEVER MISSED by Steve Perry, and to some extent all cyber-punk, but especially NEUROMANCER, JOHNNY MNEMONIC, HARDWIRED, and VOICE OF THE WHIRLWIND.
Variety reviewed CYBORG as just a series of futuristic fights. This would have been a considerable improvement! In fact, there is just enough plot to seriously impede the fights. CYBORG resembles MAD MAX in that they are both revenge tales with colorful villains set in a violent post-holocaust world. Both have boring and ill conceived sets of flashbacks to the bucolic days the hero spent with a wife/girlfriend who eventually gets wasted by the colorful villain. Both have a few good scenes here and there, but overall are very poor films.
There are several things that make CYBORG much worse than it should have been. One is that Van Damme's female sidekick is totally miscast. She should have been played by an unknown but technically proficient female martial artist who had some minimal acting skills. Instead, she is played by your basic movie bimbo. Her continued survival in spite of her obvious lack of martial skill and general stupidity greatly decreases the credibility of the film.
Another problem is that a lot of CYBORG builds up to a big fight between Van Damme and a colorful villain. There is nothing wrong with this, but unfortunately, all the interesting fighting takes place between Van Damme and various henchmen about mid-way through the film. Many of these scenes were fairly realistic and well executed. Unfortunately, when Van Damme confronts the main villain, he forgets all the skills he displayed earlier, and behaves like someone who knows zip about what he is doing. The same pattern is repeated in their final confrontation. Basically both fights are pure Hollywood and a considerable waste of the audience's time.
I also should mention that the dialog is not very good, and many scenes are mis-directed, although production values are higher than in most low-budget films.
It is unfortunate that CYBORG is not better than it is, since it may sink Van Damme's career. Overall, CYBORG comes in as a low (-1) or high (-2). The squeamish are reminded that although CYBORG is not a "splatter" film, it is "R" rated for a reason, and it is fairly violent.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Personal Shopper
Our guests lead busy lives, with a luxurious style and a never ending love for fashion. Our personal shoppers are professional stylists; they have worked with one of the world's most extravagant celebrities. Our team is mostly based in Beverly Hills, California. If our guests are located in another city, we offer a free Skype session with one of our personal stylists. (Items shipped over night from day of purchase)


Speech
Matthew Hancock, Skills Minister, speaks to the Sunday Times Festival of Education about vocational education.
Thank you very much for that introduction. It’s great to be here.
In this country - and, for that matter, in this room - all our fast and furious debates about schools, teachers, exams, curricula, are overshadowing an unsung success story.
Britain’s educational Achilles heel - our failure to provide world-class vocational education - is finally getting fixed.
The reforms this government is introducing are potentially the most profound and far-reaching since the 1944 Education Act - affecting thousands upon thousands of young people every single year.
This is a huge change. It’s a massive opportunity.
It is a vital subject, but it hides in plain sight.

More than half of young people study vocational courses at some stage of their education - either before or after 16.
But for far too long and far too often, vocational education has been overlooked and undervalued.
So I’m here today to redress the balance.
I want to celebrate this country’s excellence in vocational education just as we celebrate its academic achievements.
I want to champion the new norm - when every young person leaving school or college can choose between university or an apprenticeship, confident that each option is just as well-respected and gives them just as great a start to their future.
And I want to encourage everyone in our education system - and our society - to join me. To celebrate and champion success - and to celebrate and champion our young people who are working harder, and going further, than ever before.
We know that education is increasingly important. Data released by the ONS just this week showed that the more educated people are, the more likely they are to be in work - while fewer than half of those with no qualifications are employed.
So this government is taking urgent action to improve our education system.
You know about the academic reforms: to GCSEs , A levels and the curriculum.
But here’s a well-kept secret: everything we’ve done for academic qualifications, we’ve also done for vocational qualifications. And we tackled vocational first.
One of our first priorities in government was to ask Professor Alison Wolf to review the quality of vocational education .
She produced one of the most important pieces of work on the subject.
Her report found that between a quarter and a third of young people - 350,000 teenagers - were being fobbed off with poor-quality qualifications that were not valued by employers and did not prepare them adequately for employment or further study.
It was a tragic waste of talent, on an industrial scale.
No more.
We accepted and implemented every recommendation in the Wolf report, and in some cases went even further. And 3 years on, standards have already started to rise.
We are breaking down barriers between academic and vocational education. Because life and work need knowledge, skills and behaviours.
Our new national curriculum has much more relevant, practical content.
Under the old curriculum, pupils often spent most of their time talking about making things. Under our new curriculum - they’ll actually make them.
In design and technology, for example, the old curriculum made pupils discuss how to plan a meal - but didn’t require them to cook anything. To discuss how they might design a product - instead of actually designing it.
Now, they get real-life experience in a kitchen or a workshop, cooking, soldering, 3D printing - getting to grips with real processes.
The same goes for computing. The old curriculum taught pupils how to use existing programs. Now, they will learn how to program - how to write software for themselves in different languages like HTML and Java, to create search algorithms, set up a computer network, and encrypt devices.
Under the previous system, there was also an explosion in poor-value vocational qualifications - the sort which claimed, falsely, to be ‘equivalent’ to several GCSEs ; but which were completely irrelevant in the workplace.
Acting on Alison Wolf’s recommendations, we set out clear requirements of non- GCSE KS4 qualifications - and as a result removed a staggering 97% of them out of league tables.
So we stripped them out of league tables. From 3,175 vocational qualifications available to 14- to 16-year-olds, now there are just 186. And we’re working with awarding organisations to make sure these qualifications meet the needs of industry and demonstrate real rigour and quality.
We’ve scrapped the confusion of different pathways, at 14, 16 and beyond - and brought in a new, rigorous, ambitious vocational offer from 14 right through to 19 and beyond.
As I announced earlier this week , between 14 and 16, new Technical Awards - each one genuinely equivalent to a GCSE - will bring much greater rigour to the learning of hands on skills, putting practical and vocational and academic qualifications on the same level playing field for the first time.
With external marking; graded, not pass or fail; developed in partnership with employers; they will offer young people the chance to develop the real-life, practical skills and knowledge which employers value.
From 16 to 19, alongside or instead of A levels , students can study new, rigorous Tech Levels - every single one endorsed by employers, trade or professional bodies.
For the most talented, those Tech Levels can form part of our Technical Baccalaureate, or TechBacc - a new league table measure recognising the achievements of young people who study Tech Levels, level 3 mathematics and an extended project qualification.
On Wednesday we announced that some of the first high-performing schools and colleges to offer the TechBacc will carry out pioneering work with local employers as our TechBacc Trailblazers, spread across the country from Barnet to Blackpool.
The final part of the puzzle is a new category of Substantial Vocational Qualifications - intermediate qualifications designed for 16- to 19-year-olds who wish to progress immediately into a skilled trade, or to prepare for a related Tech Level.
All of these qualifications will need public backing from employers and rigorous assessment, giving students confidence that the qualification they’re taking is worthwhile.
But the path is now simple: GCSEs and Tech Levels at 16, then A levels or Tech Levels as the occupational options at 18.
And of course, from the age of 16 onwards, our reformed apprenticeships, now being designed and delivered by top employers, offer young people real, paid jobs for at least 12 months with meaningful training - creating the skilled professionals of tomorrow.
All of this work is designed to make sure that our vocational education is truly world class.
But the most important vocational skills are simple. Good maths and English.
They are essential in every job - from professors to plumbers, fighter pilots to firefighters.
But under the old system, 300,000 18-year-olds were starting adult life without crucial English and maths GCSE at grades A* to C, every single year.
Without, in other words, the bare minimum that most colleges or employers would demand as a matter of course.
Once they fell behind at 16, the overwhelming majority had fallen behind for good.
Fewer than 1 in 10 young people who didn’t achieve at least a C in maths or English GCSE at the age of 16 went on to reach that level by age 19.
No wonder that fewer than a quarter of adults in this country have the maths skills we expect of our 16-year-olds - or only just over half in English.
Last year, the OECD released a sobering verdict on the scale of England’s problems.
It found that 16- to 24-year-olds in this country are among the least literate and numerate in the developed world.
Out of 24 nations, they ranked 22nd for literacy, and 21st for numeracy. England was the only country in the survey where young people performed no better in English and maths than their grandparents, whose education finished many decades before.
So we are putting English and maths right at the heart of our education system.
English and maths GCSEs are being reformed, for first teaching in schools from September 2015, to make them more stretching and more ambitious - with a greater focus on problem solving in maths, and spelling and grammar in English.
Our new 16 to 19 study programmes - building on the Wolf Review’s recommendations - ensure that students who don’t get at least a C in English and maths GCSE by age 16 must keep on working towards them.
From September this year, these higher requirements for maths and English will become a condition of 16 to 19 funding - and it’s been great to see how well 16 to 19 providers are responding.
By linking the education system much more closely to the world of work: with more relevant, respected qualifications, more employer influence over courses, and more focus on English and maths for all students, we are - at long last - ensuring that all young people, no matter what path they choose, get the best possible start in life.
We will close the great divide between vocational and academic education.
No longer are we allowing thousands of young people to be left behind, or left out.
This is an economic necessity. But more than that, it is a matter of social justice. Clear pathways. Straightforward choices between high-quality, valuable courses. Bringing together vital knowledge, skills and behaviours. That is our policy, and the goal to help every child - every child - reach their potential.
Thank you.
Published: 20 June 2014


--- layout: example categories: example/v1.0.0 version: v1.0.0 title: Change zoom control location description: Move the zoom control to a different corner tags: - ui - zoom ---


--- layout: post title: More rounded corners with CSS tags: [] status: publish type: post published: true meta: {} ---
I think a while back I posted this ALA article on rounded corners for liquid CSS layouts, here the author expands on his previous article showing you how to accommodate gradient backgrounds.
Incidentally ALA also has a few other articles up there worth checking out: CSS drop shadows and delivering context (media) sensitive content using CSS, which takes the concept of different CSS types (eg: print, screen, etc...) to a new level.


class ObjectNameDefinition
Methods
|
__construct(string $fullyQualifiedName = null)
See the definition for $this->fullyQualifiedName. |
||
| string |
getFullyQualifiedName()
Returns a formatted / trimmed version of the fully qualified name of this object including the class name. |
|
|
setFullyQualifiedName($fullyQualifiedName)
Sets a new fully qualified name to be parsed by the definition. |
||
| string |
getAlias()
|
|
| ObjectNameDefinition |
setAlias(string $alias)
Aliases are used when generating "Use" statements in the import section of the object. |
|
| string |
getName()
Returns the object name sans namespaces. |
|
| ObjectNameDefinition |
setName($name)
Updates the object name. |
|
| string |
getVarName()
See: $this->getVarNameFrom() |
|
| array |
getNamespaces()
Will return an array of namespaces if they exist or an empty array if the object is not in a namespace. |
|
| ObjectNameDefinition |
setNamespaces(array $namespaces)
Sets a new namespace for the object using the given array of namespace segments. |
|
| mixed |
getNamespace()
Returns the fully qualified namespace that the object will be defined in if it exists or false if the object does not have a namespace defined. |
|
| ObjectNameDefinition |
setNamespace(string $namespace)
Switches out the namespace that the object resides in. |
|
| VariableDefinition |
getVariableDefinition(string $scope, string $description = null)
Takes a scope and description and returns a variable definition that represents this object name. |
|
|
toArray()
|
||
| string |
__toString()
Convenience method for echo'ing and dumping a name definition. |
Details
at line 62
public
__construct(string $fullyQualifiedName = null)
See the definition for $this->fullyQualifiedName.
at line 73
public string
getFullyQualifiedName()
Returns a formatted / trimmed version of the fully qualified name of this object including the class name.
at line 81
public
setFullyQualifiedName($fullyQualifiedName)
Sets a new fully qualified name to be parsed by the definition.
at line 94
public string
getAlias()
at line 108
public ObjectNameDefinition
setAlias(string $alias)
Aliases are used when generating "Use" statements in the import section of the object.
E.g...
use Namespace\ObjectName as Alias;
at line 133
public string
getName()
Returns the object name sans namespaces.
at line 143
public ObjectNameDefinition
setName($name)
Updates the object name.
at line 155
public string
getVarName()
See: $this->getVarNameFrom()
at line 166
public array
getNamespaces()
Will return an array of namespaces if they exist or an empty array if the object is not in a namespace.
at line 178
public ObjectNameDefinition
setNamespaces(array $namespaces)
Sets a new namespace for the object using the given array of namespace segments.
at line 192
public mixed
getNamespace()
Returns the fully qualified namespace that the object will be defined in if it exists or false if the object does not have a namespace defined.
at line 203
public ObjectNameDefinition
setNamespace(string $namespace)
Switches out the namespace that the object resides in.
at line 289
public VariableDefinition
getVariableDefinition(string $scope, string $description = null)
Takes a scope and description and returns a variable definition that represents this object name.
at line 299
public
toArray()
at line 309
public string
__toString()
Convenience method for echo'ing and dumping a name definition.


Hello User, this program is supposed to convert temperatures. You can convert Celsius to Fahrenheit and vice versa.
Follow the instructions below to insert the temperature.
Click the button below and enter the temperature in Celsius, it will convert to Fahrenheit.
Or you can click the button below and convert Fahrenheit to Celsius


We’re at the Tom Love Innovation Hub in Norman Oklahoma.
Come learn HTML, CSS, JavaScript, and web development with us! From beginners looking to get started to more experienced coders looking to help others while improving their own skills, everyone is welcome!
Join us and introduce yourself and meet others who are also learning to code. Create a free account on freeCodeCamp.org and bring your laptop if you have one! If you don’t have one, message one of the organizers on meetup.com and we will try and prepare one for you.
Don’t worry if you can’t make it at 6:30 on the dot, or if you can’t stay the whole two hours. Feel free to join us when you can and for as long as you want!
You can find our up to date calendar and RSVP at meetup.com/freecodecamp-norman. It’s 100% Free!
freeCodeCamp.org is a supportive group of over one million coders who build projects, earn free certificates, and get experience by coding for non-profits. Go to freeCodeCamp.org to sign up for free online based tutorials and get started.
Help us improve this page. Fork it on GitHub!


Plugin Information |
|---|
No information for the plugin 'kagemai' is available. It may have been removed from distribution. |
Kagemai Plugin
This plugin integrates Kagemai to Hudson. Kagemai is a free web-based bugtracking system written in Ruby scripting language.
Kagemai Bug Id in changelogs are now hyperlinked to the corresponding Kagemai issue pages (complete with tooltips),
and Kagemai issue list.
Configuration
System Configuration
First, you need to go to Hudson's system config screen to tell Hudson where's your Kagemai.
- URL - the root URL of your Kagemai installation, eg. http://example.org/kagemai/guest.cgi
- Encode - the encoding of your Kagemai setting, default EUC_JP. (option)
- HTTP Basic Authentication - user Basic Authentication UserName and Password of your Kagemai installation. (option)
Project Configuration
In the top section, select the url of your Kagemai installation.
The Kagemai ProjectID of your Kagemai project. It looks the following.
Post-build Actions
In the Post-build Actions section, choose "Record kagemai issue list" (option).
Changelog
Version 1.3 (2009/12/29)
- Update uses of deprecated APIs
Version 1.2 (2009/03/04)
- First release
Attachments:
kagemai2.jpg (image/jpeg)
kagemai3.jpg (image/jpeg)
kagemai4.jpg (image/jpeg)
kagemai5.jpg (image/jpeg)
kagemai7.jpg (image/jpeg)
kagemai8.jpg (image/jpeg)


--- layout: post title: Parse incoming CSVs date: 2012-05-07 13:32:40.000000000 +01:00 type: post parent_id: '0' published: true password: '' status: publish categories: - python tags: [] meta: _edit_last: '1' author: Noel permalink: "/parse-incoming-csvs/" ---
As close as you can get to a string input:
import csv for row in csv.reader(['one,two,three']): print row
And from a file:
for row in csv.reader(open('C:/test.csv')): print row


HPRequestOperation Class Reference
| Inherits from | NSOperation |
| Declared in | HPRequestOperation.h HPRequestOperation.m |
Overview
A request operation that gets queued and run by HPRequestManager
This class is an NSOperation wrapper around NSURLConnection that uses blocks to communicate with its delegates. Provides easy access to all kinds of HTTP calls, authentication methods, custom parsing, progress and completion handling. It can also be identified and cancelled very easily.
Tasks
-
requestMethod
HTTP request method
property -
requestURL
Target request URL
property -
startTime
Start time of the request operation
property -
loggingEnabled
Logging mode for this operation
property -
identifier
NSString identifier for this operation
property -
indexPath
NSIndexPath identifier for this operation
property -
postType
Type of POST operation attached to this request
property -
parserBlock
Parser block for this request operation
property -
uploadProgressBlock
Upload progress block for this request operation
property -
progressBlock
Progress block for this request operation
property -
username
Username for Basic Authentication
property -
password
Password for Basic Authentication
property -
+ requestForURL:withData:method:cached:
Returns an autoreleased request operation
-
– initWithURL:data:method:cached:
Initializes a request operation
-
– addCompletionBlock:
Adds a completion block for this operation
-
– addCookie:
Adds a cookie for this request
-
– hasCachedResponseAvailable
Checks whether a cached response for this request is available
-
– completeRequestWithCachedResponse
Prematurely completes this request and calls completion blocks with cached data
Properties
identifier
NSString identifier for this operation
@property (nonatomic, copy) NSString *identifier
Discussion
NSString identifier for this operation
This property can be used to cancel load operations for specific actions.
Declared In
HPRequestOperation.h
indexPath
NSIndexPath identifier for this operation
@property (nonatomic, copy) NSIndexPath *indexPath
Discussion
NSIndexPath identifier for this operation
This can be used to cancel load operations for specific UITableView rows as the scroll view is moving.
Declared In
HPRequestOperation.h
loggingEnabled
Logging mode for this operation
@property (nonatomic, assign, getter=isLoggingEnabled) BOOL loggingEnabled
Discussion
Logging mode for this operation
If enabled, request details will be logged in the debugger
Declared In
HPRequestOperation.h
parserBlock
Parser block for this request operation
@property (nonatomic, copy) id ( ^ ) ( NSData *loadedData , NSString *MIMEType ) parserBlock
Discussion
Parser block for this request operation
This can be any piece of code that takes the loadedData and its MIMEType, and returns an object parsed from the incoming data. By default, HPRequestManager will set this property to a JSON parser block that will convert the data to a JSON object.
Declared In
HPRequestOperation.h
password
Password for Basic Authentication
@property (nonatomic, copy) NSString *password
Discussion
Password for Basic Authentication
Declared In
HPRequestOperation.h
postType
Type of POST operation attached to this request
@property (nonatomic, assign) HPRequestOperationPostType postType
Discussion
Type of POST operation attached to this request
Value of this property determines the Content-Type header for the request. Available options are:
- HPRequestOperationPostTypeForm: Form post type, uses Content-Type application/x-www-form-urlencoded
- HPRequestOperationPostTypeJSON: JSON post type, uses Content-Type application/json
- HPRequestOperationPostTypeFile: File post type, uses Content-Type multipart/form-data
Default value is HPRequestOperationPostTypeForm.
Declared In
HPRequestOperation.h
progressBlock
Progress block for this request operation
@property (nonatomic, copy) void ( ^ ) ( float progress ) progressBlock
Discussion
Progress block for this request operation
If set, this block will get called with the progress of the download operation whenever the NSURLConnection reports an update. Value of the progress parameter will be between 0.0 and 1.0
Declared In
HPRequestOperation.h
requestMethod
HTTP request method
@property (nonatomic, readonly, assign) HPRequestMethod requestMethod
Discussion
HTTP request method
Declared In
HPRequestOperation.h
requestURL
Target request URL
@property (nonatomic, readonly, retain) NSURL *requestURL
Discussion
Target request URL
Declared In
HPRequestOperation.h
startTime
Start time of the request operation
@property (nonatomic, readonly, retain) NSDate *startTime
Discussion
Start time of the request operation
This attribute will be populated when the connection actually begins
Declared In
HPRequestOperation.h
uploadProgressBlock
Upload progress block for this request operation
@property (nonatomic, copy) void ( ^ ) ( float progress ) uploadProgressBlock
Discussion
Upload progress block for this request operation
If set, this block will get called with the progress of the upload operation whenever the NSURLConnection reports an update. Value of the progress parameter will be between 0.0 and 1.0
Declared In
HPRequestOperation.h
Class Methods
requestForURL:withData:method:cached:
Returns an autoreleased request operation
+ (HPRequestOperation *)requestForURL:(NSURL *)url withData:(NSData *)data method:(HPRequestMethod)method cached:(BOOL)cached
Parameters
- url
NSURL that determines the target URL
- data
Optional NSData attribute for uploading data with the request
- method
Method type for this request, available options are:
- HPRequestMethodGet: Request method GET
- HPRequestMethodPost: Request method POST
- HPRequestMethodPut: Request method PUT
- HPRequestMethodDelete: Request method DELETE
- cached
Boolean that determines whether the response to this request should be cached. Passing YES to this parameter will also make the operation check for an available cached item for this request before starting.
Discussion
Returns an autoreleased request operation
See initWithURL:data:method:cached: for more details.
Declared In
HPRequestOperation.h
Instance Methods
addCompletionBlock:
Adds a completion block for this operation
- (void)addCompletionBlock:(void ( ^ ) ( id resources , NSError *error ))block
Parameters
- block
A completion block that receives the resource object and an NSError instance
Discussion
Adds a completion block for this operation
Request operations can have more than one completion block. A block that will be called when this operation is complete can be added using this method.
Declared In
HPRequestOperation.h
addCookie:
Adds a cookie for this request
- (void)addCookie:(NSString *)cookie
Parameters
- cookie
A valid HTTP cookie that will get appended to the Cookie header
Discussion
Adds a cookie for this request
In rare cases when cookies are required for authentication or for other purposes, this method can be used to add an NSString cookie header to the request
Declared In
HPRequestOperation.h
completeRequestWithCachedResponse
Prematurely completes this request and calls completion blocks with cached data
- (BOOL)completeRequestWithCachedResponse
Return Value
BOOL Boolean value that indicates whether request could be completed from cache
Discussion
Prematurely completes this request and calls completion blocks with cached data
Declared In
HPRequestOperation.h
hasCachedResponseAvailable
Checks whether a cached response for this request is available
- (BOOL)hasCachedResponseAvailable
Return Value
BOOL Boolean value that indicates whether this request has a cached response available
Discussion
Checks whether a cached response for this request is available
Declared In
HPRequestOperation.h
initWithURL:data:method:cached:
Initializes a request operation
- (id)initWithURL:(NSURL *)url data:(NSData *)data method:(HPRequestMethod)method cached:(BOOL)cached
Parameters
- url
NSURL that determines the target URL
- data
Optional NSData attribute for uploading data with the request
- method
Method type for this request, available options are:
- HPRequestMethodGet: Request method GET
- HPRequestMethodPost: Request method POST
- HPRequestMethodPut: Request method PUT
- HPRequestMethodDelete: Request method DELETE
- cached
Boolean that determines whether the response to this request should be cached. Passing YES to this parameter will also make the operation check for an available cached item for this request before starting.
Discussion
Initializes a request operation
Declared In
HPRequestOperation.h


People who demonstrate integrity, respect, and teaming.
People with energy, enthusiasm, and the courage to lead.
People who build relationships based on doing the right thing.
Our values define who we are. They are the fundamental beliefs of our global
organization. They guide our actions and behavior. They influence the way we
work with each other – and the way we serve our clients and engage with our
communities.
CA Gautam Jain qualified Chartered Accountant and law Graduate from Mumbai University. Gautam is an Ex- Price Waterhouse Coooper’s , Mumbai.
After completing his 5 years stint with Price Waterhouse Coopers in year 2010 he became Partner with PDK & Co, Mumbai. As a Partner he completed 6 years stint with PDK & Co, Mumbai. Originally a native from Indore he moved his base from Mumbai to Central India, Indore. He established his own CA Firm JG & Company . He is one of few of renowned Ind AS Experts and has successfully converged Ind AS financials for more than 12 companies both in Indore and Mumbai.
Is to provide world class services to our clients and
build long term relationships.
Adoption of Best Practices , Maintain and
Uphold the highest standards of professionalism, creativity and
integrity.
Believe in client’s personal attention and counselling.
Fathom business complexities and its requirements.
Devote time in understanding complex operational, strategic and
financial issues facing our clients.
With Rich Experience and dedicated team ensure Best practices and
generate values for the clients.