Copyright © 2013 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.
This is a work in progress! For the latest updates from the Web Applications (WebApps) Working Group possibly including important bug fixes, please look at the draft on GitHub.
This specification defines a manifest, which provides developers with a centralized place to put metadata about a web application. This includes, amongst other things, the ability to specify the name of the web application, links to icons, as well as the preferred URL at which the web application should open when it is launched by the user.
With this metadata, user agents can provide, for example, enhanced bookmarking capabilities such as being able to add a web application to the homescreen of a device - as well as the various icons needed to effectively integrate with an OS's task switcher and system preferences. The specification also defines an API to enable bookmarking from within a document, as well as a means to check if an application is running in a special mode called "standalone".
This specification also defines the manifest
link type,
which provides a declarative means for a web document to be associated
with a manifest.
This is a work in progress! This specification is for review and not for implementation! For the latest updates, including important bug fixes, please look at the draft on GitHub instead.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation phase should join the aforementioned mailing lists and take part in the discussions.
This document was published by the Web Applications (WebApps) Working Group as a First Public Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to<EMAIL_ADDRESS>(subscribe, archives). All comments are welcome. You can also File a bug.
Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This section shows how the expected usage of the various features provided by this specification.
This section is non-normative.
The following shows a typical manifest.
{ "name": "Example", "url": "/start.html", "mode": "standalone", "icons": [{ "src": "icon/lowres", "density": "1", "width": "64", "type": "image/webp" }, { "src": "icon/hd", "density": "2", "width": "64" }] }
Example of using a link
element to associate a website
with a manifest. The example also shows how HTML fallbacks, such as
"application-name", can
be used to support legacy user agents that don't implement this
specification.
<!doctype html> <html> <head> <title>The Best News - international</title> <!-- link to bookmark metadata --> <link rel="manifest" href="add_to_homescreen.json"> <!-- fallback metadata for legacy browsers --> <meta name="application-name" content="Best News!"> <link rel="shortcut icon" src="favicon.ico"> </head> ...
Check if the application is running in standalone mode.
<script> if("standalone" in navigator && navigator.standalone){ //Do standalone specific stuff... document.documentElement.classList.add("standalone"); } </script>
Let the user bookmark the application through clicking a button.
<script> var installButton = document.querySelector("#install"); //Bookmarking only works if initiated by user interaction installButton.addEventListener("click", function(e){ navigator.requestBookmark("path/to/bookmark.json") .then(thankUser, stopBuggingUser); }); </script> <button id="install"> Bookmark <b>Awesome App!</b> </button>
This document attempts to address the Use Cases and Requirements for Installable Web Apps.
A manifest is a [JSON] document that consists of a top-level object that can contain zero or more members, some of which contain other objects. Each of the members, as well as how their values are processes, are defined below.
Algorithms in this specification use the conventions described in [ECMASCRIPT], such as the use of steps and sub-steps, and so on. The parseFloat method, ToString, HasOwnProperty, [[GetOwnProperty]], and ToBoolean abstract operations, and the Type(x) notation referenced in this section are defined in [ECMASCRIPT]. Processing also relies on various algorithms defined in [HTML], [FETCH], and [URL].
As the manifest format is a [JSON] document, this specification relies on the types defined in [JSON] specification: namely object, array, number, and string. Strict type checking is not enforced by this specification. Instead, each member's definition specifies the steps required to process a particular member.
When an algorithm asks the user agent to issue a developer warning, the user agent MAY report the conformance violation to the developer in a user-agent-specific manner (e.g., show the problem in the error console), or MAY ignore the error and do nothing
In the algorithms, to ignore means that the user agent MUST act as if the developer had not declared the particular member in the manifest document.
name
member
The name
is a string that
represents the name of the application as is usually displayed to the
user (e.g., amongst a list of other applications, or as a label
underneath an icon).
The steps for
processing the name of an application is given by the following
algorithm. The algorithm takes a manifest as an argument.
It returns either undefined
, a string, or an error.
false
, then return undefined
.
url
member
The url member is the URL that is loaded when the application is launched. When it's missing from the manifest, the UA loads the URL from the manifest was fetched.
The steps for
processing the url
member are given by the
following algorithm. The algorithm returns a URL.
false
, then return undefined
.
url
".
undefined
or Type(value) is not
"string":
icons
member
The icons is a list of icon objects that represents a set of icons that the application can make use.
The steps for
processing the icons
member are given by the
following algorithm. The algorithm returns a list of icons, which can
be empty, or undefined
.
false
, then return undefined
.
icons
".
src
member of
an icon. If the result is an error, stop processing this
potential icon and move to the next potential
icon in value, if any.
type
member
of an icon.
orientation
member
This is issue 74 on GitHub. We are looking for feedback!
Orientation of an application is dependent on the media features of the display. For example an application might need to be launched in landscape on phones (in order to have sufficient display width), but prefer to be in portrait on tablets. (see Orientation section in the use cases document).
When analyzing applications across various runtimes, we've found evidence that such applications are common (e.g., basically any application on the iPhone that has an iPad counterpart will be designed to constrain to a particular orientation based on the device being used: LinkedIn, Flipboard, GoodReads, etc. will all go from portrait-primary on the iPhone to allowing "any" orientation on the iPad. A more extreme example is BBC iPlayer - which supports portrait-primary on the iPhone, but both landscape orientations on iPad. The same can be seen on Android devices. Unlike native apps, Web Apps should not target devices/OS's - they have to be device neutral.
In order to address the use cases, we currently have two proposals.
Option 1: Provide a list of orientation sets in the manifest. The user agent uses the first one with a matching media query. The order in which the orientations are listed by a developer does not imply a preference for setting the orientation - it is always left up to the user agent to pick the best orientation given, for example, how the user is holding the device. In the example below, no orientation is given for widths of 721px or above, so the default is used: allowing all orientations supported by the device.
{ "orientations": [{ "media": "max-width: 320px", "supported": ["portrait-primary", "landscape"] }, { "media": "max-width: 720px", "supported": ["landscape"] }] }
In this example:
Option 2: The second proposal is to remove orientation from the manifest and use CSS @viewport instead [css-device-adapt]. This would mean::
<head> <style> /*set it by default to portrait primary for small screens */ @media (max-width: 320px) { @viewport { orientation: portrait-primary, landscape; } } /*Tablet, switch to landscape only*/ @media (max-width: 720px) { @viewport { orientation: landscape; } } /* similarly on screens with a width of 721px or more, all orientations are allowed */ </style> </head>
Problem with using @viewport
at the moment is that
the specification is progressing a bit slowly and no one has
implemented the "orientation" descriptor. It also lacks
definitions for "-primary" and "-secondary" contraints, which are
important for various applications, and doesn't currently allow
providing multiple allowed orientations - hopefully the CSS
Device Adaption spec can align with the Screen Orientation spec.
mode
member
The mode member represents that mode of operation in which the web application will be launched. When the developer omits the value, the user agent assumes the value "bookmark".
The mode of operation in which a web application can be launched include:
Standalone mode can also be displayed in the following view modes:
A valid application mode is one that conforms to the following [ABNF]:
mode = "bookmark" / "standalone" ["-" presentation] presentation = "fullscreen"
The steps for
processing the mode
member of an icon are given by
the following algorithm. The algorithm returns a string.
mode
" as the argument.
The steps for fetching a manifest are given by the following algorithm. It takes a url URL as an argument. It returns either a response (which may be in error).
The steps to processing a manifest are given by the following algorithm. The algorithm takes a text string as an argument.
name
member. If the returned value is
undefined
or an error:
link
element, and the document
has a meta
element whose name
attribute matches
"application-name
",
then the user agent could use the value of that
meta
element's content
attribute as a
fallback. Otherwise, then the document's title
can
be used. Alternatively, the user could be prompted to provide a
custom name using as a place holder.
mode
member. If processing returns an
error, report the error, and set mode to
"bookmark
".
orientation
member.
url
member.
icons
member.
The manifest
keyword can be used with a [HTML]
link element. This keyword creates an external resource link.
| Link type | Effect on... | Brief description | |
|---|---|---|---|
link
|
a and area
|
||
manifest
|
External Resource | not allowed | Imports or links to a manifest. |
The default media type for resources associated with the
manifest
link
type is application/manifest+json
.
In cases where more than one
link
element with a manifest
link type
appears in a document
, the user agent MUST use the first inserted link element
and ignore all subsequent
link
elements with a manifest
link type
(even if the first element was in error).
The appropriate time to fetch the manifest is when the external resource link is created
or when its element is inserted into a
document, whichever happens last. However, a user agent
MAY opt to delay fetching a
manifest until after the document and its other resources have loaded
(i.e., to not delay the availability of content and scripts required
by the document
).
Certain error conditions can result in a manifest being treated as an invalid manifest. An invalid manifest is one that is deemed to be non-conforming in such a way that it would not be possible for the user agent to continue processing (e.g., it can't be parsed by the JSON parser because of a syntax error, it could be fetched from the network). In such a case, issue a developer warning. In either case, when a step results in an invalid manifest the user agent MUST abort whatever step or sub-step caused the condition.
To fetch a manifest, as user agent MUST:
link
element lacks a href attribute, abort
this algorithm.
href
attribute as the url, and let response
be the response.
This section is non-normative.
Although proprietary extensions are undesirable, they can't realistically be avoided. As such, the RECOMMENDED way to add proprietary extension is to use a vendor prefix.
This following is an example of two hypothetical vendor extensions.
{ ... "webkit-fancyfeature": "some/url/img", "moz-awesome-thing": { ... } ... }
When an application is launched:
Each icon object represents an icon for an application suitable to use at some dimensions and screen density.
density
member
The density
member of an icon is the device pixel density for which this icon was
designed. The device pixel density is expressed as the number of dots
per 'px' unit (equivalent to a dppx as defined in [css3-values]). The value
is a positive number greater than 0. If the developer ommits the
value, the user agent assumes the value 1
.
The steps for processing a density of an icon are given by the following algorithm. The algorithm thanks an icon object as an argument and returns a positive number.
density
" as the argument.
NaN
, +0, −0, +∞, or −∞, or
less than 0, return 1.
width
and height
members
The width and height members represent the natural width of the icon in pixels. Their corresponding value is a positive number greater than 0.
The steps
for processing a dimension of an icon are given by the
following algorithm. The algorithm takes an icon and a
key ('width" or "height") as an argument. The algorithm
returns a positive number, undefined
, or an error.
false
, then return undefined
.
NaN
, +0, −0, +∞, or −∞, or
less than 0, return undefined.
src
member
The src member of an icon is a URL from which the icon can be fetched.
The steps for
processing the src
member of an icon are given by
the following algorithm. The algorithm takes a icon object
as an argument and returns a URL or undefined
.
false
, then return undefined
.
src
" as the argument.
type
member
The type member of an icon is a hint as to the media type of the icon. The purpose of this member is to allow a user agent can ignore icons of media types it does not support.
The steps for
processing the type
member of an icon are given by
the following algorithm. The algorithm takes an icon
object as an argument, and returns either string or
undefined
.
false
, then return undefined
.
type
" as the argument.
This section contains the required text for MIME media type registration with IANA.
The media type for a
manifests is application/manifest+json
.
If the protocol over which the manifest is transferred supports the [MIME-TYPES] specification (e.g. HTTP), it is RECOMMENDED that the manifest be labeled with the media type for a manifests.
As the manifest format is JSON and will commonly be encoded using [UNICODE], the security considerations described in [JSON] and [UNICODE-SECURITY] apply. In addition, implementors need to impose their own implementation-specific limits on the values of otherwise unconstrained member types, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.
Web applications will generally contain ECMAScript, HTML, CSS files, and other media, which are executed in a sand-boxed environment. As such, implementors need to be aware of the security implications for the types they support. Specifically, implementors need to consider the security implications outlined in the [CSS-MIME] specification, the [ECMAScript-MIME] specification, and the [HTML] specification.
As web applications can contain content that is able to simultaneously interact with the local device and a remote host, implementors need to consider the privacy implications resulting from exposing private information to a remote host. Mitigation and in-depth defensive measures are an implementation responsibility and not prescribed by this specification. However, in designing these measures, implementors are advised to enable user awareness of information sharing, and to provide easy access to interfaces that enable revocation of permissions.
As this specification allows for the declaration of URLs within certain members of a manifest, implementors need to consider the security considerations discussed in the [URL] specification. Implementations intending to display IRIs and IDNA addresses found in the manifest are strongly encouraged to follow the security advice given in [UNICODE-SECURITY].
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in [RFC2119].
There is only one class of product that can claim conformance to this specification: a user agent.
This document reuses text from the WHATWG [HTML] specification as permitted by the license of that specification. The [HTML] specification is edited by Ian Hickson.


Technical Skills
- Languages: Java, C, C++, Python
- Scripting & Web: HTML, CSS, JavaScript, SQL
- Frameworks: AngularJS, Spring, Maven, Bootstrap, ExtJS, JUnit, Protractor, Grunt
- Tools: IntelliJ IDE, Subversion, Git
- Others: SOA, Android
Honors and Awards
Technical
- 1st prize in Code Golf (to write shortest code possible) in GS (global) in Java
- 1st prize in Code Golf in GS in C++
- 1st prize in event ‘Software Design’ in National Level Technical Fest Avishkar’10 at MNNIT-Allahabad, India.
- 2nd prize in event ‘Website Hosting and Design’ in Avishkar’10.
- 3rd prize in event ‘Java - Cafe’ in Avishkar‘10. – A Java programming event.
- Consolation prize in event ‘Logical Rhythm’ at Avishkar‘09. – A Unix programming event.
- Got Merit in Mathematics and Social Science in Indian Certificate of Secondary Education. Among 0.0001% student in India.
Co-curricular Activities
- 1st prize in Puzzle Solving event at National level Technical Fest Avishkar‘10.
- 2nd prize in Online Puzzle Solving event at Avishkar‘10.
- Won Folk Dance competition on 3 occasions (2009, 2010, 2011) in the college’s cultural festival.
- Coordinated many events in college and industry in both Technical and cultural fests.


27 January 2004
The Ministry of Health in China has today confirmed the presence of highly pathogenic H5N1 avian influenza in poultry in the southern province of Guangxi. The H5N1 strain was detected in samples taken from a duck farm.
Testing is under way of samples from poultry outbreaks in the adjacent Hunan and Hubei provinces. Ducks are involved in the outbreak in Hunan, and chickens are involved in Hubei.
Strict measures to control all outbreaks, including culling and quarantine, have been undertaken.
No cases of human illness linked to these outbreaks have been detected to date.


Intent: The purpose of this User Audit is to capture information about the usage of the surevey application and in particular possible drop out points along the user path. This will be used as part of a ASP.net MVC application
Motivation: A survey taker enters the application and after logging in proceeds to answer questions, the system owner is particularly interested in points where the survey taker abandons the survey. The goal is to use this data to hypothesis the reasons that a use may abandon the survey
Applicability: This aspect of the application is to be used against methods in a controller class and to capture the url accessed by the survey taker, their identity and IP address.
Consequences: The data captured by the Audit Sub System will be stored as a JSON structure in a noSql Document Database. The trade off agains the speed and ease of storage is that subsequent systems that access the data captured will have to perform a number of activities to re-structure the data to mapp it to other information eg. IIS Logs and User Profile data.
Implementation: This will be implemented as a c# custom attribute to decorate methods within the MVC application


Site Content
Geometry 1.0
Building Area
# of Floors
Floor Area
Floor Height
# of Footprint Shapes
Footprint Shape
Massing Generator
Perimeter Depth
Orientation
Footprint dimensions
Length
50
Width
50
Thickness


---
layout: archive
title: Lean Prover Zulip Chat Archive
permalink: 144837PRreviews/81686748asymptoticsandtheFrchetderivative.html
---
The archive URL format has changed. Please find this page at:
https://leanprover-community.github.io/archive/stream/144837-PR-reviews/topic/.23748.20asymptotics.20and.20the.20Fr.C3.A9chet.20derivative.html


WITNESS LIST Health Services, Interim Committee February 8, 2002 - 1:00P Invited Testimony ON: Gilbert, Don Commissioner (Health and Human Services Commission), Austin, TX Hine, Jim Commissioner (Department of Human Services), Austin, TX Public Testimony ON: Denton, Judy Director of Texas Works (Texas Department of Human Services), Austin, TX Dunkelberg, Anne Senior Policy Analyst (Center for Public Policy Priorities), Austin, TX


I can teach you the physics of riding a bicycle. Indeed, the classical mathematics is relatively straightforward. Gravity, friction, angular momentum, center of mass, and so forth, can be demonstrated with less than a page full of equations. Given those formulae I could provide you that bicycle riding is practical and give you all the knowledge you needed to make it work. And you'd still fall down the first time you climbed on that bike. Coding is no different.
GitHub surely does its thing. But as from my side you have no cookies, no IP or other kind of trackers, no ads, no logs about whatever you do. Nothing. The entire codebase is 100% transparent for everyone. Technically there are no ways I can "trick" the system to secretly add a spyware or an ad spammer.
My approach is to constantly improve this project on a daily basis. Even if the next morning I will not have the energy for the corporate work. Still with all of this, I am asking for your patience. I would love to do more, but maybe at some point I will have this wonderful opportunity.
You can use any content and file from this github repository entirely or just a portion of it in any way it helps you. There is NO any legal restriction from my part. Referencing this github page as the source for any content you copied is appreciated but never mandatory.
The book provides a general and simplified look about how a computer works, which are the main components that makes it easily programmable, how a program really looks and gets executed on a computer. All the examples and illustrations are well explained so the entire book can be easily understood. It can give you the taste about the different aspects any programming language deals with in different ways.


1. Overview
1.1. What is Mmadu?
Mmadu (pronounced um-a-du) is derived from an Igbo word meaning people.
Have you ever found yourself in a state of deja-vu when ever you write user management logic? Mmadu provides a set of tools that ensures that you never have to repeat user management logic. It helps to manage users, takes care of registration work flows and exposes APIs for authentication.
With Mmadu, you can have a dedicated system for managing users across all your applications.
1.2. Features
1.2.1. User Authentication
By calling an API, you can authenticate users of your application with Mmmadu. By passing a username and (encrypted) password, the rest api can determine whether the username/password combination is correct. This provides a basic method of integration with web security frameworks.
1.2.2. Domain Management
By creating an managing domains, you can logically separate users. Users in a domain are typically used for one application. My storing users in multiple domains, you can use a single mmadu installation to manage users across multiple applications.
1.2.3. User Management
The user service provides basic CRUD operations to help you manage and query your users.
1.2.4. Token Management
Mmadu utilizes tokens to secure its APIs. You can create tokens that grant access to one domain or utilize the admin token which has access to all domains.
1.2.5. User Registration
Mmadu provides the web logic for registering users. With configured fields and field types, the registration api generates dynamic and configurable registration forms that domain users fill to be registered in an application.
1.3. What’s New
| Version | Features |
|---|---|
v1.3.0 |
- Introduced user registration - Added docker installation features |
v1.1.0 |
- User management API redesigned and made user friendly - Bug fixes |
v1.0.0 |
- Domain and user management API was introduced - Token security for domain and user management API was introduced. |
v0.0.1 |
- Api for creating and updating user information created. - Api for authenticating username and password information has been created. |
1.4. Getting Started
Mmadu can be installed in a number of ways since it is built and distributed with jar files. The easiest way to install mmadu is using docker.
1.4.1. Getting Started with Docker
Requirements
-
Docker
-
Docker Compose
Installation
-
Create a folder (we will use mmadu as the created folder)
mkdir mmadu && cd mmadu
-
Download the docker compose file
wget https://raw.githubusercontent.com/geraldoyudo/mmadu/v1.3.0/docker/docker-compose.yml
-
Download the default environment file
wget https://raw.githubusercontent.com/geraldoyudo/mmadu/v1.3.0/docker/.env
-
Make the necessary modifications to suite your configuration (you can use it as is)
-
Start the services
docker-compose up
Using the default settings
The docker compose installation comes pre-configured with default settings. You can access the api from each service using the default admin token 2222. The user management service, registration service and token service are at ports 15551, 15552 and 15553 respectively.
|
Note
|
Do not use default settings for configuration on production. |
Using the services
To find out more about how to consume the service API, please see API
2. Architecture
Mmadu is built using a service oriented architecture. Each basic functionality is encapsulated in an independent service.
The core service is the user management service which handles authentication, user and domain management. The token service is used by all other services for token authentication.
Currently, mmadu has the following services:
| Service | Description |
|---|---|
Token Service |
Service for managing and checking tokens and permissions. |
User management Service |
Manages domain authentication as well as administration of domains and users. |
Registration Service |
Provides a dynamic registration form for each domain. Exposes API endpoints to configure registration form fields. |
3. API
3.1. Security
If token security is enabled, you will need a token to access the api.
Simply set the domain-auth-token header to the value of the token. For more information on tokens, see token management.
3.1.1. Permissions
A token has admin permissions, while others have domain permissions. The admin token can access all parts of the API, while domain tokens can only access parts of the api that returns resources pertaining to the domain.
3.2. Token Service
Mmadu service uses token based security. Access to API can be done using admin and domain tokens. The default port for the token service is 15553
3.2.1. Admin Token
An admin token is automatically created with an id "admin-token". This token will grant you access to all resources in the API.
3.2.2. Domain Tokens
Domain tokens are created and assigned to a domain configuration. Every domain can have one domain token. Multiple domains can share a domain token. Domain token grants the API user access to user resources for that domain.
3.2.3. Token Encryption
If encryption is enabled, the token values will be encrypted before storing in the database. It uses an AES CBC cipher to encrypt token values.
Encryption can be enabled by setting the environment property mmadu.domain.encrypt-keys
to true
.
Token values are encrypted under the master-key.
Changing the Encryption Master Key
To change the encryption master key, set the environment property mmadu.security.master-key
to the desired value.
3.2.4. Generating a Token
A GET request will create a new token and return the token value. If token encryption is enabled, the token value returned is encrypted.
Request
GET /token/generate HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Response Fields
This API returns the newly generated token
| Path | Type | Description |
|---|---|---|
|
|
The token ID |
|
|
The token value (Encrypted under master key if encryption is enabled) |
Example:
HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Length: 314
Content-Type: application/json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
{
"id" : "5d1dd7316fc6c30f1c2fa625",
"value" : "2613ec6bcf71f75a1f02f5ddb44092c800ea97417ee78724f2e043eb19f53c8a870f00cde4fb798434aaa0d130dd76285b4dfc57b6eb7bd62eca82763a773dfc2f5d9468ef90a88c23db432a6077377aaaaff8cce4e954ddd9206e2ee7f6c73a8e3d06e4957d461657b87857a1e2c8ea1bc7d3064531fb9cef7fb0f1a65cd95e"
}
3.2.5. Retrieving a Token
A GET request will get a token with the ID.
Path Parameters
| Parameter | Description |
|---|---|
|
The token ID |
Example:
GET /token/retrieve/1 HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Response Fields
This API returns an AppUser with these fields:
| Path | Type | Description |
|---|---|---|
|
|
The token ID |
|
|
The token value (Encrypted under master key if encryption is enabled) |
Example:
HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Length: 39
Content-Type: application/json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
{
"id" : "1",
"value" : "1234"
}
3.2.6. Resetting a Token
A GET request will generate a new token value for the token.
Path Parameters
| Parameter | Description |
|---|---|
|
The token ID |
Example:
GET /token/reset/1 HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Response Fields
This API returns a token with the following fields:
| Path | Type | Description |
|---|---|---|
|
|
The token ID |
|
|
The token value (Encrypted under master key if encryption is enabled) |
Example:
HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Length: 291
Content-Type: application/json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
{
"id" : "1",
"value" : "4ae568b84d271d8c34c5146fefbf46a47614d33b212a9525985eb895a70e2cb186a3c6bddd062088430ce6c9a8bb458798edb1cedb2067c82dd3c5ed4a9b5664ba1742181d7d12a32703fcc12b43da2ed495a34f5c2fd6d365a0d0ec668f49a8c4994b10600441e43c61a59204c70542cad0c6f992fd1aeb2b44a7f8b2136db3"
}
3.2.7. Setting a Domain Token
A POST request will set a domain’s token.
Request Fields
| Path | Type | Description |
|---|---|---|
|
|
The id of the token |
|
|
The domain id |
Example:
POST /token/setDomainAuthToken HTTP/1.1
domain-auth-token: 2222
Content-Length: 39
Content-Type: application/json
Host: localhost:8080
{"tokenId":"1","domainId":"1111111111"}
Response Fields
This API returns a 204 no content response.
Example:
HTTP/1.1 204 No Content
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
3.2.8. Getting the token associated to a Domain
A GET request will get a domain’s token.
Path Parameters
| Parameter | Description |
|---|---|
|
The domain ID |
Example:
GET /token/domainAuth/1111111111 HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Response Fields
This API returns a token with these fields:
| Path | Type | Description |
|---|---|---|
|
|
The token ID |
|
|
The domain ID |
Example:
HTTP/1.1 200 OK
Pragma: no-cache
Content-Length: 53
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Type: application/json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
{
"tokenId" : "1",
"domainId" : "1111111111"
}
3.3. User Management Service
The user management service provides APIs for authentication and user management. The default port for the user management service is 15551
3.3.1. Authentication
Using the rest api, you can authenticate users given a username and password.
A post request authenticates a user on a domain.
Request Fields
| Path | Type | Description |
|---|---|---|
|
|
The user identification |
|
|
The user’s password |
Path Parameters
| Parameter | Description |
|---|---|
|
The user authentication domain id |
Example:
POST /domains/test-app/authenticate HTTP/1.1
Content-Type: application/json
domain-auth-token: 1234
Host: localhost:8080
Content-Length: 63
{
"username" : "test-user",
"password" : "my-password"
}
Response Fields
This API returns a JSON response with the following fields:
| Path | Type | Description |
|---|---|---|
|
|
The authentication status. One of the following: AUTHENTICATED, USERNAME_INVALID, PASSWORD_INVALID |
Example:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Length: 34
{
"status" : "AUTHENTICATED"
}
3.3.2. Managing Domains
A client application references users in one domain. A domain is referenced by a domain id. Applications can share the same user base by using the same domain id.
Security
If token security is enabled, the domain api can be accessed with the admin token.
Token security is enabled by default. To disable, set the environment property mmadu.domain.api-security-enabled
to false
.
Creating A domain
A POST request will create a domain
Request Fields
| Path | Type | Description |
|---|---|---|
|
|
The domain name |
|
|
ID of the domain (optional, auto-generated) |
Example:
POST /appDomains HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Content-Length: 51
{
"id" : "00111111",
"name" : "new-domain"
}
Response Fields
This API returns a HTTP 201 CREATED response with an empty body.
Getting a domain with an ID
A GET request will get a domain with an ID.
Path Parameters
| Parameter | Description |
|---|---|
|
The domain ID |
Example:
GET /appDomains/00111111 HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Response Fields
This API returns an AppDomain with these fields:
| Path | Type | Description |
|---|---|---|
|
|
The domain name |
|
|
Domain item resource links |
Example:
HTTP/1.1 200 OK
Content-Type: application/hal+json;charset=UTF-8
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Length: 223
{
"name" : "new-domain",
"_links" : {
"self" : {
"href" : "http://localhost:8080/appDomains/00111111"
},
"appDomain" : {
"href" : "http://localhost:8080/appDomains/00111111"
}
}
}
Getting All Domains
A GET request will get all domains.
Example:
GET /appDomains HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Response Fields
This API returns a list of all domains with these fields:
| Path | Type | Description |
|---|---|---|
|
|
The name of the domain |
|
|
Domain item resource links |
|
|
Resource links |
|
|
Page information |
Example:
HTTP/1.1 200 OK
Content-Type: application/hal+json;charset=UTF-8
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Length: 1421
{
"_embedded" : {
"appDomains" : [ {
"name" : "global-config",
"_links" : {
"self" : {
"href" : "http://localhost:8080/appDomains/0"
},
"appDomain" : {
"href" : "http://localhost:8080/appDomains/0"
}
}
}, {
"name" : "test",
"_links" : {
"self" : {
"href" : "http://localhost:8080/appDomains/1"
},
"appDomain" : {
"href" : "http://localhost:8080/appDomains/1"
}
}
}, {
"name" : "test",
"_links" : {
"self" : {
"href" : "http://localhost:8080/appDomains/test-app"
},
"appDomain" : {
"href" : "http://localhost:8080/appDomains/test-app"
}
}
}, {
"name" : "Test domain For Config",
"_links" : {
"self" : {
"href" : "http://localhost:8080/appDomains/1111111111"
},
"appDomain" : {
"href" : "http://localhost:8080/appDomains/1111111111"
}
}
} ]
},
"_links" : {
"self" : {
"href" : "http://localhost:8080/appDomains{?page,size,sort}",
"templated" : true
},
"profile" : {
"href" : "http://localhost:8080/profile/appDomains"
}
},
"page" : {
"size" : 20,
"totalElements" : 4,
"totalPages" : 1,
"number" : 0
}
}
Updating A Domain with an ID
A PATCH request will update a domain with an ID.
Path Parameters
| Parameter | Description |
|---|---|
|
The domain ID |
Example:
PATCH /appDomains/00111111 HTTP/1.1
Content-Type: application/json
domain-auth-token: 2222
Host: localhost:8080
Content-Length: 23
{"name":"changed-name"}
Response Fields
This API returns a HTTP 204 NO CONTENT response.
Example:
HTTP/1.1 204 No Content
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Removing A Domain
A DELETE request will remove a domain with an ID.
Path Parameters
| Parameter | Description |
|---|---|
|
The domain ID |
Example:
DELETE /appDomains/00111111 HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Response Fields
This API returns a HTTP 204 NO CONTENT response.
Example:
HTTP/1.1 204 No Content
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
3.3.3. Users
This contains user information for a specific user. A user could have a username, password, roles, authorities and any other properties that the client deems fit.
3.3.4. Creating A User
A POST request will create a user.
Fixed Request Fields
| Path | Type | Description |
|---|---|---|
|
|
The user’s username (must be unique) |
|
|
The user’s id (unique identifier used to reference user in your application) |
|
|
The user’s password |
|
|
The user’s assigned roles |
|
|
The user’s granted authorities |
Example:
POST /domains/test-app/users HTTP/1.1
Content-Length: 116
Content-Type: application/json
domain-auth-token: 1234
Host: localhost:8080
{"id":"123","username":"user","password":"password","roles":["admin"],"authorities":["manage-users"],"color":"blue"}
As seen in the example, you can also add custom properties like the "color" property.
Response Fields
This API returns a HTTP 201 CREATED response with an empty body.
3.3.5. Getting A User with an ID
A GET request will get a user with an ID.
Path Parameters
| Parameter | Description |
|---|---|
|
The user’s ID |
|
The domain id of the user |
Example:
GET /domains/test-app/users/123453432 HTTP/1.1
domain-auth-token: 1234
Host: localhost:8080
Response Fields
This API returns an AppUser with these fields as well as custom fields provided by the client:
| Path | Type | Description |
|---|---|---|
|
|
The user’s id |
|
|
Username of the user |
|
|
password of the user |
|
|
List of roles assigned to this user |
|
|
List of authorities given to ths user |
Example:
HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Length: 159
Content-Type: application/json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
{"id":"123453432","username":"test-user","password":"my-password","roles":["admin-role"],"authorities":["admin"],"favourite-colour":"blue","country":"Nigeria"}
As you can see, this user has two extra properties: favourite-color
and country
.
3.3.6. Getting All Users In a Domain
A GET request will get all users regardless of domains.
Request Parameters
The request includes page information to request for particular sets in the list.
| Parameter | Description |
|---|---|
|
page number to request |
|
maximum number of items in page |
Example:
GET /domains/test-app/users?page=0&size=10 HTTP/1.1
domain-auth-token: 1234
Host: localhost:8080
Response Fields
This API returns a list of all users with the fields below. The response also has fields that display the page information of result. These fields are shown in the example response and are self explanatory.
| Path | Type | Description |
|---|---|---|
|
|
The user’s unique identification |
|
|
Username of the user |
|
|
password of the user |
|
|
List of roles assigned to this user |
|
|
List of authorities given to ths user |
Example:
HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Type: application/json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Length: 663
{"content":[{"id":"123453432","username":"test-user0","password":"my-password0","roles":["admin-role"],"authorities":["admin"],"country":"Nigeria","favourite-color":"blue"},{"id":"123453432","username":"test-user1","password":"my-password1","roles":["admin-role"],"authorities":["admin"],"country":"Nigeria","favourite-color":"blue"},{"id":"123453432","username":"test-user2","password":"my-password2","roles":["admin-role"],"authorities":["admin"],"country":"Nigeria","favourite-color":"blue"}],"totalElements":3,"last":true,"totalPages":1,"size":10,"number":0,"numberOfElements":3,"sort":{"sorted":false,"unsorted":true,"empty":true},"first":true,"empty":false}
3.3.7. Removing A User with an ID
A DELETE request will remove a user with an ID.
Path Parameters
| Parameter | Description |
|---|---|
|
The user’s domain ID |
|
The user’s ID |
Example:
DELETE /domains/test-app/users/123453432 HTTP/1.1
domain-auth-token: 1234
Host: localhost:8080
Response Fields
This API returns a HTTP 204 NO CONTENT response.
Example:
HTTP/1.1 204 No Content
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
3.3.8. Updating A User with an ID
A PUT request will update a user with an ID. Not, this api will completely overwrite the properties of the existing user. There are no partial updates.
Path Parameters
| Parameter | Description |
|---|---|
|
The user’s domain ID |
|
The user’s ID |
Example:
PUT /domains/test-app/users/123453432 HTTP/1.1
Content-Length: 171
Content-Type: application/json
domain-auth-token: 1234
Host: localhost:8080
{"id":"123453432","username":"changed-username","password":"changed-password","roles":["admin-role"],"authorities":["admin"],"favourite-colour":"blue","country":"Nigeria"}
Response Fields
This API returns a HTTP 204 NO CONTENT response.
Example:
HTTP/1.1 204 No Content
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
3.3.9. Getting A User with a username and domain id
A GET request will get a user with the specified username and domain id.
Path Parameters
| Parameter | Description |
|---|---|
|
The domain id of the user |
Request Parameters
| Parameter | Description |
|---|---|
|
The username of the user |
Example:
GET /domains/test-app/users/load?username=test-user HTTP/1.1
domain-auth-token: 1234
Host: localhost:8080
Response Fields
This API returns an AppUser with the fields below and other custom fields provided by the domain client.
| Path | Type | Description |
|---|---|---|
|
|
The user’s id |
|
|
Username of the user |
|
|
password of the user |
|
|
List of roles assigned to this user |
|
|
List of authorities given to ths user |
Example:
HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Length: 159
Content-Type: application/json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
{"id":"123453432","username":"test-user","password":"my-password","roles":["admin-role"],"authorities":["admin"],"favourite-colour":"blue","country":"Nigeria"}
3.3.10. Querying Users
A GET request can search for users by username, and other custom fields created by the client.
|
Note
|
Query string can only support custom string, integer and boolean fields currently. |
|
Warning
|
Ensure to put individual criteria in parenthesis |
Request Parameters
The request includes page information to request for particular sets in the list.
| Parameter | Description |
|---|---|
|
The query search string. Use any of your custom properties for this search including username |
|
page number to request |
|
maximum number of items in page |
Example:
GET /domains/test-app/users/search?page=0&size=10&query=%28country+equals+%27Nigeria%27%29+and+%28favourite-color+equals+%27blue%27%29 HTTP/1.1
domain-auth-token: 1234
Host: localhost:8080
Response Fields
This API returns a list of all users with the fields below. The response also has fields that display the page information of result. These fields are shown in the example response and are self explanatory.
| Path | Type | Description |
|---|---|---|
|
|
The user’s unique identification |
|
|
Username of the user |
|
|
password of the user |
|
|
List of roles assigned to this user |
|
|
List of authorities given to ths user |
Example:
HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Type: application/json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Length: 663
{"content":[{"id":"123453432","username":"test-user0","password":"my-password0","roles":["admin-role"],"authorities":["admin"],"country":"Nigeria","favourite-color":"blue"},{"id":"123453432","username":"test-user1","password":"my-password1","roles":["admin-role"],"authorities":["admin"],"country":"Nigeria","favourite-color":"blue"},{"id":"123453432","username":"test-user2","password":"my-password2","roles":["admin-role"],"authorities":["admin"],"country":"Nigeria","favourite-color":"blue"}],"totalElements":3,"last":true,"totalPages":1,"size":10,"number":0,"numberOfElements":3,"sort":{"sorted":false,"unsorted":true,"empty":true},"first":true,"empty":false}
3.3.11. Partial User update
A PATCH request can update users partially based on a query criteria
|
Note
|
Query string can only support custom string, integer and boolean fields currently. |
|
Warning
|
Ensure to put individual criteria in parenthesis |
Path Parameters
| Parameter | Description |
|---|---|
|
The domain id of the user |
Request
The PATCH request accepts a query string and an array of update operations.
| Path | Type | Description |
|---|---|---|
|
|
The query criteria for updating users |
|
|
The kind of update operation to make: (SET, INCREMENT, ADD, REMOVE |
|
|
The property to update |
|
|
The value used by the update operation |
Example:
PATCH /domains/test-app/users HTTP/1.1
Content-Length: 105
Content-Type: application/json
domain-auth-token: 1234
Host: localhost:8080
{"query":"(country equals 'Nigeria')","updates":[{"operation":"SET","property":"color","value":"green"}]}
Response Fields
The API returns 204 No content for a successful update.
Example:
HTTP/1.1 204 No Content
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
3.4. Registration Service
The registration service provides an api to access the registration page for a domain. The registration page generates a form from the configured fields and field types of a domain.
3.4.1. Displaying the registration form
The registration form can be accessed in the browser using the url:
http://[registration-host]:[registration-port]/[domain-id]/register
For example, accessing the default domain with the default configuration can be done by entering the url below on your browser.
http://localhost:1552/0/register
The registration services redirects to the defaultRedirectionUrl specified in the registration profile for this domain. To specify a url to redirect to, add the redirectUrl parameter
http://localhost:1552/0/register?redirectUrl=http://myapp.com
3.4.2. Customizing Registration Forms
Registration forms for a domain can be customized by adding and removing fields and field types. The registration service ensures that form fields are created for each field.
3.4.3. Registration Profiles
Each domain has a registration profile object that is used for configuring the applications behaviour during registration.
|
Note
|
There can be only one registration profile for a domain. |
Creating a Registration Profile
A POST Request will create a registration profile.
Fixed Request Fields
| Path | Type | Description |
|---|---|---|
|
|
Registration profile ID (auto generated if absent) |
|
|
domain ID |
|
|
Roles assigned to newly registered users |
|
|
Authorities assigned to newly registered users |
|
|
Url to redirect to after registration success |
|
|
Main registration page title - h1 |
|
|
Secondary registration page title - h2 |
|
|
Tertiary registration page title - h3 |
|
|
Instruction message for registering users displayed at the top of the form |
|
|
Submit button text |
Example:
POST /repo/registrationProfiles HTTP/1.1
domain-auth-token: 2222
Content-Length: 358
Host: localhost:8080
{
"id" : "1",
"domainId" : "0",
"defaultRedirectUrl" : "http://my.app.com/home",
"defaultRoles" : [ "member" ],
"defaultAuthorities" : [ "view-list" ],
"headerOne" : "My App",
"headerTwo" : "Register",
"headerThree" : "Fill all required fields",
"instruction" : "Ensure that all fields are filled",
"submitButtonTitle" : "Go"
}
Response Fields
This API returns a HTTP 201 CREATED response with an empty body.
Obtaining Registration Profile by Profile ID
A GET Request will return a registration profile with its ID
Path Parameters
| Parameter | Description |
|---|---|
|
The registration profile ID |
Example:
GET /repo/registrationProfiles/1 HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Response Fields
This API returns the registration profile with the following fields:
| Path | Type | Description |
|---|---|---|
|
|
Registration profile ID (auto generated if absent) |
|
|
domain ID |
|
|
Roles assigned to newly registered users |
|
|
Authorities assigned to newly registered users |
|
|
Url to redirect to after registration success |
|
|
Main registration page title - h1 |
|
|
Secondary registration page title - h2 |
|
|
Tertiary registration page title - h3 |
|
|
Instruction message for registering users displayed at the top of the form |
|
|
Submit button text |
Example:
HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Type: application/hal+json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Length: 563
{
"domainId" : "0",
"defaultRedirectUrl" : "http://my.app.com/home",
"defaultRoles" : [ "member" ],
"defaultAuthorities" : [ "view-list" ],
"headerOne" : "My App",
"headerTwo" : "Register",
"headerThree" : "Fill all required fields",
"instruction" : "Ensure that all fields are filled",
"submitButtonTitle" : "Go",
"_links" : {
"self" : {
"href" : "http://localhost:8080/repo/registrationProfiles/1"
},
"registrationProfile" : {
"href" : "http://localhost:8080/repo/registrationProfiles/1"
}
}
}
Updating Registration Profile by ID
A PATCH Request will update a registration profile. The example below updates the defaultRegistrationUrl property.
Path Parameters
| Parameter | Description |
|---|---|
|
The registration profile ID |
Example:
PATCH /repo/registrationProfiles/1 HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Content-Length: 48
{"defaultRedirectUrl":"http://modified.app.com"}
Response Fields
This API returns a HTTP 204 NO CONTENT response.
Example:
HTTP/1.1 204 No Content
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Deleting a Registration Profile by ID
A DELETE request will delete a registration profile.
|
Warning
|
Deleting a registration profile will remote all fields associated with the profile and a registration page for that domain will be unavailable. |
Path Parameters
| Parameter | Description |
|---|---|
|
The registration profile ID |
Example:
DELETE /repo/registrationProfiles/1 HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Response Fields
This API returns a HTTP 204 NO CONTENT response.
Example:
HTTP/1.1 204 No Content
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
3.4.4. Field Types
Field type objects specify the properties of a field type in the registration form. You can create a field type that can be used by fields in a registration form.
See Defining Markup for fields for more information on how to customize field types.
Creating a field Type
A POST request will create a field type
Request Fields
| Path | Type | Description |
|---|---|---|
|
|
Field Type ID |
|
|
Allowed string pattern for field type |
|
|
Minimum value for field type |
|
|
Maximum value for field type |
|
|
Style applied to all fields of the type |
|
|
Data type of to field type (integer, date, time, datetime, string, decimal) |
|
|
css for all fields with this type (can be overriden by field css) |
|
|
Script for field |
|
|
css classes for field |
|
|
HTML markup for field type |
|
|
The field type name |
|
|
The element enclosing the field |
Example:
POST /repo/fieldTypes HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Content-Length: 521
{
"id" : "1",
"name" : "Age",
"markup" : "<label for='$field.name' class='sr-only'>$field.label</label><input type='number' id='$field.name' name='$field.name' class='form-control' placeholder='$field.placeholder' $maxValue $minValue autofocus $required $inputField $inputStyle $errorStyle >$errorDisplay",
"fieldTypePattern" : "",
"type" : "integer",
"enclosingElement" : "div",
"classes" : [ "form-control" ],
"style" : null,
"script" : "",
"css" : "",
"max" : "100",
"min" : "10"
}
Response Fields
This API returns a HTTP 201 CREATED response with an empty body.
Getting a field type with an ID
A GET request will get a field type with an ID.
Path Parameters
| Parameter | Description |
|---|---|
|
The field type ID |
Example:
GET /repo/fieldTypes/1 HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Response Fields
This API returns a FieldType object with these fields:
| Path | Type | Description |
|---|---|---|
|
|
Field Type ID |
|
|
Allowed string pattern for field type |
|
|
Minimum value for field type |
|
|
Maximum value for field type |
|
|
Style applied to all fields of the type |
|
|
Data type of to field type (integer, date, time, datetime, string, decimal) |
|
|
css for all fields with this type (can be overriden by field css) |
|
|
Script for field |
|
|
css classes for field |
|
|
HTML markup for field type |
|
|
The field type name |
|
|
The element enclosing the field |
Example:
HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Type: application/hal+json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Length: 696
{
"name" : "Age",
"markup" : "<label for='$field.name' class='sr-only'>$field.label</label><input type='number' id='$field.name' name='$field.name' class='form-control' placeholder='$field.placeholder' $maxValue $minValue autofocus $required $inputField $inputStyle $errorStyle >$errorDisplay",
"fieldTypePattern" : "",
"type" : "integer",
"enclosingElement" : "div",
"classes" : [ "form-control" ],
"style" : null,
"script" : "",
"css" : "",
"max" : "100",
"min" : "10",
"_links" : {
"self" : {
"href" : "http://localhost:8080/repo/fieldTypes/1"
},
"fieldType" : {
"href" : "http://localhost:8080/repo/fieldTypes/1"
}
}
}
Getting All Field Types
A GET request will get all field types.
Example:
GET /repo/fieldTypes HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Response Fields
This API returns a list of all field types with these fields:
| Path | Type | Description |
|---|---|---|
|
|
Allowed string pattern for field type |
|
|
Minimum value for field type |
|
|
Maximum value for field type |
|
|
Data type of to field type (integer, date, time, datetime, string, decimal) |
|
|
css for all fields with this type (can be overriden by field css) |
|
|
Script for field |
|
|
css classes for field |
|
|
HTML markup for field type |
|
|
The field type name |
|
|
The element enclosing the field |
Example:
HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Content-Length: 1170
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Type: application/hal+json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
{
"_embedded" : {
"fieldTypes" : [ {
"name" : "Age",
"markup" : "<label for='$field.name' class='sr-only'>$field.label</label><input type='number' id='$field.name' name='$field.name' class='form-control' placeholder='$field.placeholder' $maxValue $minValue autofocus $required $inputField $inputStyle $errorStyle >$errorDisplay",
"fieldTypePattern" : "",
"type" : "integer",
"enclosingElement" : "div",
"classes" : [ "form-control" ],
"style" : null,
"script" : "",
"css" : "",
"max" : "100",
"min" : "10",
"_links" : {
"self" : {
"href" : "http://localhost:8080/repo/fieldTypes/1"
},
"fieldType" : {
"href" : "http://localhost:8080/repo/fieldTypes/1"
}
}
} ]
},
"_links" : {
"self" : {
"href" : "http://localhost:8080/repo/fieldTypes{?page,size,sort}",
"templated" : true
},
"profile" : {
"href" : "http://localhost:8080/repo/profile/fieldTypes"
}
},
"page" : {
"size" : 20,
"totalElements" : 1,
"totalPages" : 1,
"number" : 0
}
}
Updating A Field Type
A PATCH request will update a field type
Path Parameters
| Parameter | Description |
|---|---|
|
The field type ID |
Example:
PATCH /repo/fieldTypes/1 HTTP/1.1
domain-auth-token: 2222
Content-Length: 19
Host: localhost:8080
{"name":"New Type"}
Response Fields
This API returns a HTTP 204 NO CONTENT response.
Example:
HTTP/1.1 204 No Content
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Removing A Field Type
A DELETE request will remove a field type.
Path Parameters
| Parameter | Description |
|---|---|
|
The field type ID |
Example:
DELETE /repo/fieldTypes/1 HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Response Fields
This API returns a HTTP 204 NO CONTENT response.
Example:
HTTP/1.1 204 No Content
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
3.4.5. Fields
Fields contain information used in rendering each field in a registration form. Fields utilize properties of their field types in order to render an adequate representation of the field. Fields also specify the user property that the input field is bound to. Fields can override and extend certain properties of the field types.
See Defining Markup for fields for more information on how to customize fields.
Creating a field
A POST request will create a field
Request Fields
| Path | Type | Description |
|---|---|---|
|
|
Field ID |
|
|
Allowed string pattern for field |
|
|
css style for input element in field |
|
|
Input field label |
|
|
input field placeholder |
|
|
Id of the field’s type |
|
|
User property that the field will set |
|
|
Order of the field in Layout |
|
|
If the field input is required or not |
|
|
the form name of the field |
|
|
the ID of the domain |
Example:
POST /repo/fields HTTP/1.1
Content-Length: 251
domain-auth-token: 2222
Host: localhost:8080
{
"id" : "1",
"domainId" : "1",
"name" : "username",
"placeholder" : "Enter Username",
"property" : "username",
"fieldTypeId" : "1",
"style" : "",
"label" : "Username",
"order" : 1,
"pattern" : "",
"required" : true
}
Response Fields
This API returns a HTTP 201 CREATED response with an empty body.
Getting a field type with an ID
A GET request will get a field with an ID.
Path Parameters
| Parameter | Description |
|---|---|
|
The field ID |
Example:
GET /repo/fields/1 HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Response Fields
This API returns a Field object with these fields:
| Path | Type | Description |
|---|---|---|
|
|
Field ID |
|
|
Allowed string pattern for field |
|
|
css style for input element in field |
|
|
Input field label |
|
|
input field placeholder |
|
|
Id of the field’s type |
|
|
User property that the field will set |
|
|
Order of the field in Layout |
|
|
If the field input is required or not |
|
|
the form name of the field |
|
|
the ID of the domain |
Example:
HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Type: application/hal+json;charset=UTF-8
Content-Length: 414
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
{
"domainId" : "1",
"name" : "username",
"placeholder" : "Enter Username",
"property" : "username",
"fieldTypeId" : "1",
"style" : "",
"label" : "Username",
"order" : 1,
"pattern" : "",
"required" : true,
"_links" : {
"self" : {
"href" : "http://localhost:8080/repo/fields/1"
},
"field" : {
"href" : "http://localhost:8080/repo/fields/1"
}
}
}
Getting All Fields in Domain
A GET request will get all fields in a domain.
Request Parameters
| Parameter | Description |
|---|---|
|
Domain ID of the request |
Example:
GET /repo/fields/search/findByDomainId?domainId=1 HTTP/1.1
domain-auth-token: 2222
Host: localhost:8080
Response Fields
This API returns a list of all fields with these properties:
| Path | Type | Description |
|---|---|---|
|
|
Allowed string pattern for field |
|
|
css style for input element in field |
|
|
Input field label |
|
|
input field placeholder |
|
|
Id of the field’s type |
|
|
User property that the field will set |
|
|
Order of the field in Layout |
|
|
If the field input is required or not |
|
|
the form name of the field |
|
|
the ID of the domain |
Example:
HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
Content-Length: 658
X-Content-Type-Options: nosniff
Content-Type: application/hal+json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
{
"_embedded" : {
"fields" : [ {
"domainId" : "1",
"name" : "username",
"placeholder" : "Enter Username",
"property" : "username",
"fieldTypeId" : "1",
"style" : "",
"label" : "Username",
"order" : 1,
"pattern" : "",
"required" : true,
"_links" : {
"self" : {
"href" : "http://localhost:8080/repo/fields/1"
},
"field" : {
"href" : "http://localhost:8080/repo/fields/1"
}
}
} ]
},
"_links" : {
"self" : {
"href" : "http://localhost:8080/repo/fields/search/findByDomainId"
}
}
}
Updating A Field
A PATCH request will update a field
Path Parameters
| Parameter | Description |
|---|---|
|
The field ID |
Example:
PATCH /repo/fields/1 HTTP/1.1
domain-auth-token: 2222
Content-Length: 34
Host: localhost:8080
{"placeholder":"Enter a Username"}
Response Fields
This API returns a HTTP 204 NO CONTENT response.
Example:
HTTP/1.1 204 No Content
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Removing A Field
A DELETE request will remove a field.
Path Parameters
| Parameter | Description |
|---|---|
|
The field ID |
Example:
PATCH /repo/fields/1 HTTP/1.1
domain-auth-token: 2222
Content-Length: 34
Host: localhost:8080
{"placeholder":"Enter a Username"}
Response Fields
This API returns a HTTP 204 NO CONTENT response.
Example:
HTTP/1.1 204 No Content
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
3.4.6. Defining Markup for Fields
You define how you want your registration fields by configuring fields and field types. The markup property in the field type is used to define the markup of that specific field type. An age field type markup can be defined as shown:
<label for='$field.name' class='sr-only'>$field.label</label>
<input type='number' id='$field.name' name='$field.name' class='form-control'
placeholder='$field.placeholder' $maxValue $minValue autofocus $required $inputField $inputStyle $errorStyle >
$errorDisplay"
Mmadu registration service uses apache velocity to generate markup for fields. It provies the following in
the template context for use in defining fields. You reference context objects by adding the $
prefix. For example,
the $field.name
returns the name property in the field object.
| Object Name | Description |
|---|---|
field |
The field object |
type |
The field type object |
inputField |
Input attribute and value that marks an element as a model input |
inputStyle |
style attribute, any element with this property will have the field type style property appended to that element |
errorStyle |
style attribute, any element with this property will have the style appended with the error style when the field contains errors |
errorDisplay |
HTML markup for displaying field errors |
maxValue |
max attribute, any element with this will have the max attribute set to the max value of the field type |
minValue |
min attribute, any element with this will have the min attribute set to the min value of the field type |


General Information
- Breed Purpose
- Dual Purpose
- Comb
- Single
- Broodiness
- Seldom
- Climate Tolerance
- All Climates
- Egg Productivity
- High
- Egg Size
- Large
- Egg Color
- Brown
- Breed Temperament
- Friendly,Easily handled,Calm,Bears confinement well,Docile
- Breed Colors/Varieties
-
Black and
Red
- Breed Size
- Large Fowl
Black Star and Red Star are trade names used for hybrids of two other recognized breeds, not itself an APA recognized breed. They are one of many hybrids more commonly called Red Sex-Linked or Black Sex-links.
Typically a red male chicken breed is crossed with a white or barred female to breed them.
Crossing a Rhode Island Red male and a Delaware female makes a Red Star. By crossing a Rhode Island Red male and a Barred Plymouth Rock female, a Black Star is created.
Typically a red male chicken breed is crossed with a white or barred female to breed them.
Crossing a Rhode Island Red male and a Delaware female makes a Red Star. By crossing a Rhode Island Red male and a Barred Plymouth Rock female, a Black Star is created.


The NVIDIA Accelerated Linux Graphics Driver supports all standard VGA and VESA modes, as well as most user-written custom mode lines; double-scan and interlaced modes are supported on all GPUs supported by the NVIDIA driver.
To request one or more standard modes for use in X, you can simply add a "Modes" line such as:
Modes "1600x1200" "1024x768" "640x480"
in the appropriate Display subsection of your X config file (see the xorg.conf man page for details). Or, the nvidia-xconfig(1) utility can be used to request additional modes; for example:
nvidia-xconfig --mode 1600x1200
See the nvidia-xconfig(1) man page for details.
While not directly a concern when programming modes, the bits used per pixel is an issue when considering the maximum programmable resolution; for this reason, it is worthwhile to address the confusion surrounding the terms "depth" and "bits per pixel". Depth is how many bits of data are stored per pixel. Supported depths are 8, 15, 16, 24, and 30. Most video hardware, however, stores pixel data in sizes of 8, 16, or 32 bits; this is the amount of memory allocated per pixel. When you specify your depth, X selects the bits per pixel (bpp) size in which to store the data. Below is a table of what bpp is used for each possible depth:
| Depth | BPP |
|---|---|
| 8 | 8 |
| 15 | 16 |
| 16 | 16 |
| 24 | 32 |
| 30 | 32 |
Lastly, the "pitch" is how many bytes in the linear frame buffer there are between one pixel's data, and the data of the pixel immediately below. You can think of this as the horizontal resolution multiplied by the bytes per pixel (bits per pixel divided by 8). In practice, the pitch may be more than this product due to alignment constraints.
The NVIDIA Accelerated Linux Graphics Driver and NVIDIA GPU-based graphics cards support resolutions up to 16384x16384 pixels for Fermi and newer GPUs, and up to 32767x32767 pixels for Pascal and newer GPUs, though the maximum resolution your system can support is also limited by the amount of video memory (see Useful Formulas for details) and the maximum supported resolution of your display device (monitor/flat panel/television). Also note that while use of a video overlay does not limit the maximum resolution or refresh rate, video memory bandwidth used by a programmed mode does affect the overlay quality.
Using 4K resolutions over HDMI requires a high single-link pixel clock that is only available on Kepler or later GPUs.
Using HDMI 2.0 4K@60Hz modes in the RGB 4:4:4 color space requires a high single-link pixel clock that is only available on GM20x or later GPUs. In addition, using a mode requiring the YCbCr 4:2:0 color space over a DisplayPort connection requires a GP10x or later GPU. If driving the current mode in the RGB 4:4:4 color space would require a pixel clock that exceeds the display's or GPU's capabilities, and the display and GPU are capable of driving that mode in the YCbCr 4:2:0 color space, then the color space will be overridden to YCbCr 4:2:0. On all Turing and earlier GPUs, and on all DisplayPort display devices regardless of GPU, YCbCr 4:2:0 mode is not supported on depth 8 X screens, and is not currently supported with stereo or the GLX_NV_swap_group OpenGL extension.
The maximum resolution is a function both of the amount of video memory and the bits per pixel you elect to use:
In other words, the amount of video memory used is equal to the horizontal resolution (HR) multiplied by the vertical resolution (VR) multiplied by the bytes per pixel (bits per pixel divided by eight). Technically, the video memory used is actually the pitch times the vertical resolution, and the pitch may be slightly greater than (HR * (bpp/8)) to accommodate the hardware requirement that the pitch be a multiple of some value.
Note that this is just memory usage for the frame buffer; video memory is also used by other things, such as OpenGL and pixmap caching.
Another important relationship is that between the resolution, the pixel clock (also known as the dot clock) and the vertical refresh rate:
In other words, the refresh rate (RR) is equal to the pixel clock (PCLK) divided by the total number of pixels: the horizontal frame length (HFL) multiplied by the vertical frame length (VFL) (note that these are the frame lengths, and not just the visible resolutions). As described in the XFree86 Video Timings HOWTO, the above formula can be rewritten as:
Given a maximum pixel clock, you can adjust the RR, HFL and VFL as desired, as long as the product of the three is consistent. The pixel clock is reported in the log file. Your X log should contain a line like this:
(--) NVIDIA(0): ViewSonic VPD150 (DFP-1): 165 MHz maximum pixel clock
which indicates the maximum pixel clock for that display device.
In traditional XFree86/X.Org mode validation, the X server takes as a starting point the X server's internal list of VESA standard modes, plus any modes specified with special ModeLines in the X configuration file's Monitor section. These modes are validated against criteria such as the valid HorizSync/VertRefresh frequency ranges for the user's monitor (as specified in the Monitor section of the X configuration file), as well as the maximum pixel clock of the GPU.
Once the X server has determined the set of valid modes, it takes the list of user requested modes (i.e., the set of modes named in the "Modes" line in the Display subsection of the Screen section of X configuration file), and finds the "best" validated mode with the requested name.
The NVIDIA X driver uses a variation on the above approach to perform mode validation. During X server initialization, the NVIDIA X driver builds a pool of valid modes for each display device. It gathers all possible modes from several sources:
The display device's EDID
The X server's built-in list
Any user-specified ModeLines in the X configuration file
The VESA standard modes
For every possible mode, the mode is run through mode validation. The core of mode validation is still performed similarly to traditional XFree86/X.Org mode validation: the mode timings are checked against things such as the valid HorizSync and VertRefresh ranges and the maximum pixelclock. Note that each individual stage of mode validation can be independently controlled through the "ModeValidation" X configuration option.
Note that when validating interlaced mode timings, VertRefresh specifies the field rate, rather than the frame rate. For example, the following modeline has a vertical refresh rate of 87 Hz:
# 1024x768i @ 87Hz (industry standard) ModeLine "1024x768" 44.9 1024 1032 1208 1264 768 768 776 817 +hsync +vsync Interlace
Invalid modes are discarded; valid modes are inserted into the mode pool. See MODE VALIDATION REPORTING for how to get more details on mode validation results for each considered mode.
Valid modes are given a unique name that is guaranteed to be unique across the whole mode pool for this display device. This mode name is constructed approximately like this:
<width>x<height>_<refreshrate>
(e.g., "1600x1200_85")
The name may also be prepended with another number to ensure the mode is unique; e.g., "1600x1200_85_0".
As validated modes are inserted into the mode pool, duplicate modes are removed, and the mode pool is sorted, such that the "best" modes are at the beginning of the mode pool. The sorting is based roughly on:
Resolution
Source (EDID-provided modes are prioritized higher than VESA-provided modes, which are prioritized higher than modes that were in the X server's built-in list)
Refresh rate
Once modes from all mode sources are validated and the mode pool is constructed, all modes with the same resolution are compared; the best mode with that resolution is added to the mode pool a second time, using just the resolution as its unique modename (e.g., "1600x1200"). In this way, when you request a mode using the traditional names (e.g., "1600x1200"), you still get what you got before (the 'best' 1600x1200 mode); the added benefit is that all modes in the mode pool can be addressed by a unique name.
When verbose logging is enabled (see “How can I increase the amount of data printed in the X log file?”), the mode pool for each display device is printed to the X log file.
After the mode pool is built for all display devices, the requested modes (as specified in the X configuration file), are looked up from the mode pool. Each requested mode that can be matched against a mode in the mode pool is then advertised to the X server and is available to the user through the X server's mode switching hotkeys (ctrl-alt-plus/minus) and the XRandR and XF86VidMode X extensions.
Additionally, all modes in the mode pool of the primary display device are implicitly made available to the X server. See the IncludeImplicitMetaModes X configuration option for details.
You can request a special mode by name in the X config file, named "nvidia-auto-select". When the X driver builds the mode pool for a display device, it selects one of the modes as the "nvidia-auto-select" mode; a new entry is made in the mode pool, and "nvidia-auto-select" is used as the unique name for the mode.
The "nvidia-auto-select" mode is intended to be a reasonable mode for the display device in question. For example, the "nvidia-auto-select" mode is normally the native resolution for flat panels, as reported by the flat panel's EDID, or one of the detailed timings from the EDID. The "nvidia-auto-select" mode is guaranteed to always be present, and to always be defined as something considered valid by the X driver for this display device.
Note that the "nvidia-auto-select" mode is not necessarily the largest possible resolution, nor is it necessarily the mode with the highest refresh rate. Rather, the "nvidia-auto-select" mode is selected such that it is a reasonable default. The selection process is roughly:
If the EDID for the display device reported a preferred mode timing, and that mode timing is considered a valid mode, then that mode is used as the "nvidia-auto-select" mode. You can check if the EDID reported a preferred timing by starting X with logverbosity greater than or equal to 5 (see “How can I increase the amount of data printed in the X log file?”), and looking at the EDID printout; if the EDID contains a line:
Prefer first detailed timing : Yes
Then the first mode listed under the "Detailed Timings" in the EDID will be used.
If the EDID did not provide a preferred timing, the best detailed timing from the EDID is used as the "nvidia-auto-select" mode.
If the EDID did not provide any detailed timings (or there was no EDID at all), the best valid mode not larger than 1024x768 is used as the "nvidia-auto-select" mode. The 1024x768 limit is imposed here to restrict use of modes that may have been validated, but may be too large to be considered a reasonable default, such as 2048x1536.
If all else fails, the X driver will use a built-in 800 x 600 60Hz mode as the "nvidia-auto-select" mode.
If no modes are requested in the X configuration file, or none of the requested modes can be found in the mode pool, then the X driver falls back to the "nvidia-auto-select" mode, so that X can always start. Appropriate warning messages will be printed to the X log file in these fallback scenarios.
You can add the "nvidia-auto-select" mode to your X configuration file by running the command
nvidia-xconfig --mode nvidia-auto-select
and restarting your X server.
The X driver can generally do a much better job of selecting the "nvidia-auto-select" mode if the display device's EDID is available. This is one reason why it is recommended to only use the "UseEDID" X configuration option sparingly. Note that, rather than globally disable all uses of the EDID with the "UseEDID" option, you can individually disable each particular use of the EDID using the "UseEDIDFreqs", "UseEDIDDpi", and/or the "NoEDIDModes" argument in the "ModeValidation" X configuration option.
When log verbosity is set to 6 or higher (see “How can I increase the amount of data printed in the X log file?”), the X log will record every mode that is considered for each display device's mode pool, and report whether the mode passed or failed. For modes that were considered invalid, the log will report why the mode was considered invalid.
Some functionality, such as Active Stereo with TwinView, requires control over exactly which mode timings are used. For explicit control over which mode timings are used on each display device, you can specify the ModeLine you want to use (using one of the ModeLine generators available), and using a unique name. For example, if you wanted to use 1024x768 at 120 Hz on each monitor in TwinView with active stereo, you might add something like this to the monitor section of your X configuration file:
# 1024x768 @ 120.00 Hz (GTF) hsync: 98.76 kHz; pclk: 139.05 MHz Modeline "1024x768_120" 139.05 1024 1104 1216 1408 768 769 772 823 -HSync +Vsync
Then, in the Screen section of your X config file, specify a MetaMode like this:
Option "MetaModes" "1024x768_120, 1024x768_120"


How the Internet Works
Interested in learning about the Internet? Click below to check it out!
IP Addresses, Packets, and Routing
Learn how IP addresses help accurately request and send data.
Go To PageHTTP and HTTPS Protocol
Learn how to safely visit a website and protect your private information.
Go To Page


using UnityEngine; using System.Collections; using System; public class LaserGun : Weapon { //initialization public new void Start () { base.Start(); damage = 25; timeBetweenShots = 1.5f; } public override string getName() { return "Laser Gun"; } public override void fire() { if (timeSinceFired > timeBetweenShots) //controls the fire rate { timeSinceFired = 0; for (int i = 0; i < bullets.Length; i++) { bullets[i].direction = aimVector; bullets[i].damage = damage; Bullet bul = Instantiate(bullets[i], bulletOrigin.transform.position, player.transform.rotation) as Bullet; bul.transform.rotation = transform.rotation; } } } }


All Classes
BasicFileList
BasicFileTable
BasicFileTree
BmpImage
ColorRGB
CSVAnalyzer
CSVHandler
DrawGraph
ExcGreen
FileFunctions
FileNode
Histogram
HistogramPanel
ImageDisplay
ImageFunctions
MeanH
PaintBrush
PaintFrame
PhenoViewer
Pixel
PlotFormat
PlotPanel
PopupTest
ReNameJFrame
TimeSeriesOperator
VisualRhythm
VRhythmPanel


BOTTLE ROCKET A film review by Zak Forsman Copyright 1997 Zak Forsman
Crime Pays
Directed by WES ANDERSON Written by WES ANDERSON and OWEN WILSON
OWEN WILSON as Dignan LUKE WILSON as Anthony ROBERT MUSGRAVE as Bob ANDREW WILSON as Future Man LUMI CAVAZOS as Inez JAMES CAAN as Mr. Henry
In 1993, a group of young independent filmmakers submitted a black and white short film titled, BOTTLE ROCKET for consideration at the 1994 Sundance Film Festival. It was accepted. There, the short film caught the eye of Texas-based screenwriter L.M. Kit Carson. Two years later, we have the feature-length version of the same film produced by James L. Brooks. This is every struggling filmmaker's dream.
BOTTLE ROCKET, dubbed as "Reservoir Geeks", is one of the funniest and most originally written films I've seen in a long while. We follow Anthony played by Luke Wilson who is just getting out of a voluntary hospital for what he describes as 'exhaustion'. From there he re-teams with Dignan and Bob, his two old friends. I really would hate to ruin a single scene if you haven't watched this film yet. All I will tell you is that nothing leads where you'd expect it, the characters are simple, charming and wonderful to watch, and the film has a great little ending that will leave you with a smile on your face (and maybe some sympathy in your heart).
The film was written by its director, Wes Anderson and by Owen Wilson who plays the character, Dignan. These guys bring to the screen a film-sense all their own. The characters were certainly written to play for laughs, but each is portrayed honestly and we almost begin to respect them for how simply they approach their lives. There is also a great last line that gives us a sense of closure--that things have come full circle. I'd like to see this film up for Best Original Screenplay. It won't be.
The film was directed in the same manner by which it was written, which is to say, it presents the visual imagery under the same mindset that produced the dialogue. Half of what you laugh at in this film comes from visual cues expressed by the director, Wes Anderson. He knows what his actors are capable of and how to send an idea about a scene through use of the camera, shot selection and editing. His film is kinetic, it feels alive. Also, he has composed an ending sequence for this film that will be in my memory forever. I was actually a little moved by it.
Every single person in this film was casted perfectly, perhaps because the characters were written for them. If you think about the fact that three brothers and a few friends (excluding James Caan) comprise the cast, it is even more impressive. They really have to be seen to be believed. But then, the writing lends itself to the character quirks that make them seem more human. My favorite line happens when Future Man has been making fun of Dignan's jumpsuit. Anthony tries to cheer him up by saying, "Don't worry about it, Dignan. Did you see what he was wearing?" And Dignan replies sheepishly, "Yeah. It was pretty cool."
In closing, if you enjoy films such as THE HUDSUCKER PROXY or RAISING ARIZONA, you will love BOTTLE ROCKET. And the choice of title is pretty interesting, too. The idea of a bottle rocket--it's something vivacious and alive, and prone to violence, but the thing is really relatively harmless. This describes Dignan perfectly. You've got to see it.

Zak Forsman, filmmaker
Swan Pictures Independent http://www.epix.net/~swan/<EMAIL_ADDRESS>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


Structure type to access the Nested Vectored Interrupt Controller (NVIC).
More...
#include <core_cm4.h>
Structure type to access the Nested Vectored Interrupt Controller (NVIC).
§ IABR
| __IO uint32_t NVIC_Type::IABR[8] |
Offset: 0x200 (R/W) Interrupt Active bit Register
§ ICER
| __IO uint32_t NVIC_Type::ICER[8] |
Offset: 0x080 (R/W) Interrupt Clear Enable Register
§ ICPR
| __IO uint32_t NVIC_Type::ICPR[8] |
Offset: 0x180 (R/W) Interrupt Clear Pending Register
§ IP
| __IO uint8_t NVIC_Type::IP[240] |
Offset: 0x300 (R/W) Interrupt Priority Register (8Bit wide)
§ ISER
| __IO uint32_t NVIC_Type::ISER[8] |
Offset: 0x000 (R/W) Interrupt Set Enable Register
§ ISPR
| __IO uint32_t NVIC_Type::ISPR[8] |
Offset: 0x100 (R/W) Interrupt Set Pending Register
§ RESERVED0
| uint32_t NVIC_Type::RESERVED0[24] |
§ RESERVED2
| uint32_t NVIC_Type::RESERVED2[24] |
§ RESERVED3
| uint32_t NVIC_Type::RESERVED3[24] |
§ RESERVED4
| uint32_t NVIC_Type::RESERVED4[56] |
§ RESERVED5
| uint32_t NVIC_Type::RESERVED5[644] |
§ RSERVED1
| uint32_t NVIC_Type::RSERVED1[24] |
§ STIR
| __O uint32_t NVIC_Type::STIR |
Offset: 0xE00 ( /W) Software Trigger Interrupt Register
The documentation for this struct was generated from the following file:
- examples/atmel_samg55/src/ASF/thirdparty/CMSIS/Include/core_cm4.h


JavaScript is disabled on your browser.
Skip navigation links
Overview
Package
Class
Tree
Index
Help
Prev
Next
Frames
No Frames
All Classes
Hierarchy For All Packages
Package Hierarchies:
com.aspose.html
,
com.aspose.html.api
,
com.aspose.html.model
,
com.aspose.html.options
,
com.aspose.html.tests
Class Hierarchy
java.lang.Object
com.aspose.html.
ApiClient
com.aspose.html.
AuthAnswer
com.aspose.html.tests.
BaseTest
com.aspose.html.tests.
ConvertEpubTest
com.aspose.html.tests.
ConvertHtmlTest
com.aspose.html.tests.
ConvertHtmlTestAsync
com.aspose.html.tests.
ConvertImageToSVGTest
com.aspose.html.tests.
ConvertMarkdownTest
com.aspose.html.tests.
ConvertMHTMLTest
com.aspose.html.tests.
ConvertSVGTest
com.aspose.html.tests.
ConvertXhtmlTest
com.aspose.html.tests.
StorageTest
com.aspose.html.tests.
VectorizeImageToSVGTest
com.aspose.html.
Configuration
retrofit2.Converter.Factory
com.aspose.html.
EnumConverterFactory
com.aspose.html.model.
DateTime
com.aspose.html.model.
DiscUsage
com.aspose.html.options.
DOCConversionOptions
(implements com.aspose.html.options.
Options
)
com.aspose.html.
EnumUtils
com.aspose.html.model.
FileExist
com.aspose.html.tests.
FileFormatTest
com.aspose.html.model.
FilesList
com.aspose.html.model.
FilesUploadResult
com.aspose.html.model.
FileVersions
com.aspose.html.
HtmlApi
com.aspose.html.options.
ImageConversionOptions
(implements com.aspose.html.options.
Options
)
com.aspose.html.tests.
IsUrlTest
com.aspose.html.
JobBuilder
com.aspose.html.
ConverterBuilder
com.aspose.html.
VectorizationBuilder
com.aspose.html.model.
JobData
com.aspose.html.model.
DataSource
com.aspose.html.model.
DataTarget
com.aspose.html.model.
JobRequest
com.aspose.html.
JSON
com.aspose.html.model.
Links
com.aspose.html.options.
MarkdownConversionOptions
(implements com.aspose.html.options.
Options
)
com.aspose.html.model.
ObjectExist
com.aspose.html.model.
OperationResult
com.aspose.html.options.
PDFConversionOptions
(implements com.aspose.html.options.
Options
)
com.aspose.html.model.
ResponseMessage
com.aspose.html.tests.
SerializatorTest
com.aspose.html.model.
StorageExist
com.aspose.html.model.
StorageExistResponse
com.aspose.html.model.
StorageFile
com.aspose.html.model.
FileVersion
com.aspose.html.tests.
TestHelper
com.google.gson.TypeAdapter<T>
com.aspose.html.
JSON.DateTypeAdapter
com.aspose.html.
JSON.LocalDateTypeAdapter
com.aspose.html.
JSON.OffsetDateTimeTypeAdapter
com.aspose.html.
JSON.OptionalTypeAdapter
<E>
com.aspose.html.
JSON.SqlDateTypeAdapter
com.aspose.html.
Utils
com.aspose.html.options.
VectorizationOptions
(implements com.aspose.html.options.
Options
)
com.aspose.html.options.
XPSConversionOptions
(implements com.aspose.html.options.
Options
)
Interface Hierarchy
com.aspose.html.api.
ConversionApi
com.aspose.html.options.
Options
com.aspose.html.api.
StorageApi
Enum Hierarchy
java.lang.Object
java.lang.Enum<E> (implements java.lang.Comparable<T>, java.io.Serializable)
com.aspose.html.model.
OutputFormats
com.aspose.html.model.
InputFormats
Skip navigation links
Overview
Package
Class
Tree
Index
Help
Prev
Next
Frames
No Frames
All Classes


{% extends "settings/base.html" %} {% block title %}Settings - Fleet MOTD{% endblock %} {% block head %} {{ super() }} {% endblock head %} {% block content %}
$ts$ gets replaced with the server address


You got Iceland! Enjoy the aurora borealis, world-renowned hot springs, Viking history, an eclectic music scene, or even visit a volcano! This tiny European country is right up your alley.
You got Iceland! Enjoy the aurora borealis, world-renowned hot springs, Viking history, an eclectic music scene, or even visit a volcano! This tiny European country is right up your alley.
You got Prince Edward Island! This Canadian island is perfect for a relaxing, laid-back vacation. Take a walk along the beach, visit the home of one of literature's most beloved heroines (Anne of Green Gables), got parasailing, or just relax in your cabin by the ocean.
You got Costa Rica! This tropical paradise has it all: ziplining through lush forests, jumping off waterfalls, snorkeling, and is even a habitat to sloths (if you're into that...).
You got Dubai! The glitz and glam combined with tradition is perfect for you. Go visit the world's tallest building, visit man-made islands, ride camels in the desert, people-watch, or shop until you drop.


148_ph52.py
from typing import List
class Solution:
def minDays(self, grid: List[List[int]]) -> int:
# size of the grid
N = len(grid)
M = len(grid[0])
# the total number of land
total = sum([sum(row) for row in grid])
# check if the grid is connected by `count` lands
def isConnected(count: int) -> bool:
for x in range(N):
for y in range(M):
# for the first land
if grid[x][y] == 1:
# use bfs to visit the graph
visited = set()
visited.add((x, y))
q = [(x, y)]
while q:
i, j = q.pop()
for ni, nj in [(i - 1, j), (i + 1, j), (i, j - 1), (i, j + 1)]:
if 0 <= ni < N and 0 <= nj < M and ((ni, nj) not in visited) and grid[ni][nj] == 1:
visited.add((ni, nj))
q.append((ni, nj))
return len(visited) == count
return False
if not isConnected(total):
return 0
for px in range(N):
for py in range(M):
if grid[px][py] == 1:
# assume we remove this land
grid[px][py] = 0
if not isConnected(total - 1):
return 1
grid[px][py] = 1
return 2


All Packages Class Hierarchy This Package Previous Next Index
Class com.jclark.xml.tok.PartialCharException
java.lang.Object
|
+----java.lang.Throwable
|
+----java.lang.Exception
|
+----com.jclark.xml.tok.TokenException
|
+----com.jclark.xml.tok.PartialTokenException
|
+----com.jclark.xml.tok.PartialCharException
- public class PartialCharException
- extends PartialTokenException
Thrown to indicate that the subarray being tokenized is not the
complete encoding of one or more characters, but might be if
more bytes were added.
-
getLeadByteIndex()
- Returns the index of the first byte that is not part of the complete
encoding of a character.
getLeadByteIndex
public int getLeadByteIndex()
- Returns the index of the first byte that is not part of the complete
encoding of a character.
All Packages Class Hierarchy This Package Previous Next Index


In 2013, Project Career was developed to support undergraduates with traumatic brain injury (TBI). The project’s goal is to identify best practices and strategies for using cognitive support technology (also called assistive technology for cognition), such as a tablet computer and applications (apps). These technologies help students accommodate the challenges resulting from the TBI. They help students achieve positive academic outcomes and support them in successful employment or graduate school transitions. To provide website users with the most up-to-date findings from Project Career and access to available tools, information, and other materials, the electronic portal is provided that integrates the Student, Technology, Accommodations, and Resources (STAR) resources.
The Project Career portal is for many different audiences: college students who have a TBI, their family members and caregivers, college advisors, educators, health and rehabilitation providers, active service members, veterans, and advocates. It provides information on technology tools, apps, accommodations, and employment-supporting resources that can enhance college and career achievements of those with TBI. Project Career helps students with TBI:
The portal provides a special entry point for active service members and veterans.
The Project Career information portal is called the Student, Technology, Accommodation, and Resources or STAR. By accessing STAR, users can obtain information and resources for specific stakeholders to both understand Project Career and to access the provided array of multimedia documents. STAR includes publicly available best practices, videos, evaluation data, and strategies used by Project.
Project Career is based at three universities (Kent State University, Boston University, and West Virginia University). STAR’s materials allow any student with a TBI to use his or her own mobile device to benefit from the project’s successful practices, findings and research. STAR does not require the student’s institution to be involved in Project Career. All students and others can use the resources and strategies for themselves.
To get started, just click on the appropriate audience group on the main page.