text:
---
title: Contributing to Protocol
order: 2
---

Protocol, like everything else Mozilla makes, is [open source](https://developer.mozilla.org/docs/Mozilla/Developer_guide/Introduction).
We welcome contributions from people like you. Yes, you, whoever you are
reading this, can do something to make Protocol better and more useful,
no matter your skill level or area of interest.

### Reporting Bugs

The easiest way to help is to report bugs. Let us know if something isn't
doing what you think it should do and we can try to fix it.

To report an error you’ve discovered in Protocol, [submit an issue on Github](https://github.com/mozilla/protocol/issues/new/choose/)
with a detailed description of the error and steps to reproduce. If possible,
include a link to a live example and/or a screenshot of the bug in effect.
Also be sure to mention the browser (and version) and operating system.

You should search for similar issues in case it’s already been reported. In
some cases a bug may have been fixed but the fix may not have been deployed,
so it’s a good idea to search through [recently closed issues](https://github.com/mozilla/protocol/issues?q=is%3Aissue+is%3Aclosed) as well.

### Requesting New Features

If you would like to request changes to a component or a new component be
added to Protocol, please [submit an issue on Github](https://github.com/mozilla/protocol/issues/new/choose/)
using the appropriate issue template. Please try to fill out this template
as thoroughly as you can. This will help the team understand the request
and triage issues more effectively.

## Contributing code

Aside from reporting bugs or requesting features, an even more direct way to
contribute to Protocol is to write code.

Protocol is a design system, though the exact meaning of the term “design system” is
hard to pin down. For our purposes, a design system comprises the entirety of
guidelines, assets, and resources for producing websites in a specific style or
brand identity. It includes a style guide, a pattern library of coded components,
and the actual assets – fonts, graphics, CSS frameworks, JavaScript libraries –
needed to create websites.

The heart of Protocol is the pattern library – the HTML components that you can
assemble into a web page, and its soul is the CSS framework that styles those
components. We’re probably straining that metaphor but you get the point;
Protocol is made of code.

The Protocol design system comprises a CSS framework and a library of
markup patterns for web page components. There's a bit of JavaScript for a few
interactive things, but for the most part Protocol is static HTML and CSS.

The pattern library lives at [protocol.mozilla.org](https://protocol.mozilla.org)
and its source code lives at [github.com/mozilla/protocol](https://github.com/mozilla/protocol/).
That code repository is also where the Protocol CSS framework lives, as well as
all the system documentation (including this page).

To write code for Protocol you'll actually be working on the Protocol website itself.

### Installing the Protocol site locally

We've done our best to make the barrier of entry to contributing code to
Protocol as low as possible. You can do some work directly through github
without actually installing Protocol locally, but if you want to do any complex
coding you'll need to set up a local development environment.

You'll need a GitHub account.

https://github.com/join

https://help.github.com/articles/set-up-git/

You'll need to install Git.

https://git-scm.com/downloads

https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

You'll need to install Node and npm.

https://docs.npmjs.com/downloading-and-installing-node-js-and-npm

With those prerequisites met:

Fork the [Protocol GitHub repository](https://github.com/mozilla/protocol/)
      to your personal account.

https://help.github.com/articles/fork-a-repo/

Clone that remote repo to your computer.

https://help.github.com/articles/cloning-a-repository/

On your computer’s command line, navigate to the folder to which you just
      cloned the Protocol repo.

Within that folder, run `npm start`. This will install all the dependencies
      and launch a local server.

You now have a local instance of the Protocol site running on your
computer. You can load the site in a browser at http://localhost:3000.
As you edit files they will update automatically and you can see your
changes "live" on your local development environment.

The pattern library uses [Gulp](https://gulpjs.com/) to automate tasks.
The `npm start` command is a shortcut to installing and starting up the
site the first time, but you may not want to rerun the installation process
every time you sit down to work on Protocol. Once you’ve got it installed
you can skip the installation step and run `gulp` directly to build the
site and start the server, or `gulp --dev` to start the server with file
watching (so it rebuilds and refreshes automatically with every file change).

Make whatever edits you need to make, ideally in a fresh branch.

https://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging

https://help.github.com/articles/creating-and-deleting-branches-within-your-repository/

When you're done, commit your changes and push them to your GitHub remote repository.

https://help.github.com/articles/pushing-to-a-remote/

Submit a pull request from your fork to the Mozilla repo.

https://help.github.com/articles/creating-a-pull-request-from-a-fork/

You can also [make some edits directly on github.com](https://help.github.com/en/articles/editing-files-in-another-users-repository)
without installing the site locally. For that you don't even have to install
Git or Node, you just need a GitHub account. This is fine for updating docs or
minor tweaks that don’t need extensive testing or review, but for any serious
coding you really should have a local instance running so you can see your work
as it progresses.

### File structure

Once you’ve cloned the Protocol repository, you should spend some time
browsing through the folders in your local copy (or on Github) to
familiarize yourself with the general structure of the project. You’ll
have to drill down a bit to reach the really good stuff but the top-level
root folder looks something like:

```
protocol
├── bin (scripts that deploy the site to the server)
├── dist (where source files are built locally for serving [not found in git])
├── docs (documentation for Drizzle, the tool that drives the Protocol site)
├── gulpfile.js (scripts that build and process the pattern library and CSS framework)
├── src (the real source of the site; this is the meat of Protocol)
└── tests (automated test scripts)
```

There are a few other files in the project root, most of which are pretty
boring, but the most interesting is `CHANGELOG.md` that contains a historical
record of Protocol.

The real meat of Protocol is in the `src` folder, and this is where you’ll do
most of your work.

```
src
├── assets (fonts, images, scripts, and styles)
├── data (reference data used for examples)
├── pages (content that supplements the pattern library such as demos and documents [including this one])
├── patterns (the HTML components)
├── static (media assets for display on the pattern library site, but not part of Protocol itself)
└── templates (templates for the pattern library website)
```

At this level the most interesting folders are probably `patterns` and `assets`,
where the aforementioned heart and soul of Protocol can be found, respectively.
Let’s start with `patterns`.

We’ve chosen to organize our pattern library following the atomic design metaphor,
which consists of breaking a web page down into its smallest component parts,
which can then be combined and assembled in different configurations, adding
more parts in increasing complexity to arrive at the complete page. In our
`patterns` folder you’ll find separate folders for `atoms`, `molecules`, `organisms`,
and `templates`.

The files in these folders represent the actual Protocol components. They’re
snippets of HTML that, when combined with the CSS that styles them, can be assembled
to build a web page. All of the Protocol components can be found in the `patterns`
folder, and all of the related CSS is in `assets` (we’ll do a deeper dive into that folder
shortly).

## Component patterns

The component pattern examples are built with [Handlebars](https://handlebarsjs.com/guide/),
a simple templating language that is mostly plain HTML with some added enhancements.
Each component resides in its own Handlebars template file (using the extension `.hbs`),
which includes a bit of front matter in a YAML format along with the component
markup. All of this is processed into plain HTML and rendered to show a live
example of the component alongside the component markup and the front matter
for added documentation.

Here’s a minimal example of a Protocol component in Handlebars format:

```hbs
---
name: Button
description: |
  This is an example of a button.
---

<button class="mzp-c-button">Button</button>
```

The top section between the `---` is the _front matter_, comprising at minimum
a name but it can also include a description, links to examples or resources,
notes, tips, no-nos (what not to do), component status, and sorting order.

Below the front matter is the component markup, just a simple button in this case.
When the website is built, these Handlebars templates are rendered into formatted web
pages. Each pattern displays the rendered and styled component, the HTML snippet
that produces it, and the front matter notes that document it. Browse around the
Protocol site to see this for yourself.

Handlebars does a bit more than plain HTML. Every component pattern becomes a
reusable object that can be embedded into another Handlebars template as a _partial_:
helper:

```hbs
\{{> patterns.atoms.button}}
```

For more complex cases, we can also define patterns with content _blocks_ allowing
us to pass content into the pattern with the `\{{#embed}}` helper. For example, our
button might contain a block called `label`:

```hbs
<button class="mzp-c-button">
\{{#block "label"}}
  Button
\{{/block}}
</button>
```

When we embed that pattern in another template we can replace the block with
different content:

```hbs
\{{#embed "patterns.atoms.button"}}
  \{{#content "label"}}Click Me!\{{/content}}
\{{/embed}}
```

Each component occupies its own folder and some folders contain multiple
components as a collection. The site automatically concatenates all the templates
within a folder into a single page during the build process. A component folder
can optionally contain a `collection.yaml` file with metadata about the collection.

This is obviously an abbreviated introduction to our Handlebars components but
hopefully it will help you get started. Look through the various patterns in Protocol
for more robust examples and refer to the [Handlebars documentation](https://handlebarsjs.com/guide/)
to learn more about how it works.

## The Protocol CSS framework

Along with the HTML snippets that give Protocol components their structure,
Protocol also comprises a CSS framework to give it style. Our framework is built
with [Sass](https://sass-lang.com) as a pre-processor, and we author Sass using
the [SCSS](https://sass-lang.com/documentation/syntax#scss) syntax.

You can find our Sass files in the `assets/sass` folder. The `demos` and `docs` subfolders
contain styles for Protocol demo pages and the Protocol website, respectively, but the
real Protocol framework is in the `protocol` folder. This is where you’ll find all the
CSS that styles Protocol components as well as the variables, mixins, and functions
that make it all possible.

```
sass/protocol
├── base
│   ├── elements
│   ├── includes
│   └── utilities
├── components
├── includes
│   ├── fonts
│   ├── forms
│   ├── mixins
│   ├── _functions.scss
│   ├── _themes.css
│   └── _lib.scss
├── _theme-config.scss
├── protocol-components.scss
└── protocol.scss
```

As usual, it’s a good idea to explore the files and folders here to get the lay of
the land. We try to include helpful comments in each .scss file to explain what all
the different pieces do and how to use them so a lot of our documentation lives
directly within the source code.

Our styles are fragmented across numerous files in order to keep things more
self-contained and organized, and to help prevent conflicts when several people
work simultaneously on different things (when more than one person is trying to
edit the same file at the same time they’ll inevitably step on each other’s work).

The `base` folder has all the basic, general-purpose styling for common HTML elements.
The `components` folder holds the styling for individual Protocol components. And
the `includes` folder holds the supporting mixins and functions that power the entire
framework. Each of these folders in turn hold other files that import and collect the
smaller fragments. Almost all of our individual SCSS files are [Sass partials](https://sass-lang.com/guide#topic-4),
prefixed with an underscore. They’re intended to be imported into another file when
the Sass is compiled; they don’t all turn into separate CSS files of their own.

## Styling a component

All of the styling for a given component will typically be in a single `.scss` file
named for that component. Here’s a bare-bones example that we’ll imagine is a file
named `_item.scss` (this is not an actual Protocol component):

```scss
@import '../includes/lib';

.mzp-c-item {
    @include text-title-md;
    color: $color-ink-80;
    margin: $spacing-lg 0;
}
```
Even in this minimal example there’s a lot happening, and almost none of it is plain
CSS. If you’re familiar with Sass/SCSS already this will look more familiar, but if
you’re not let’s dig a bit deeper.

```scss
@import '../includes/lib';
```
First, we import the Protocol library file, `includes/_lib.scss`. Since that file
is a Sass partial we don’t need the underscore prefix or the file extension, just
referencing the relative path and filename is enough. That library file in turn
imports all of the functions, mixins, and variables Protocol needs to process the
rest of this SCSS file. Almost every file you see in the Protocol framework will
import that library at the very top.

```scss
.mzp-c-item {
```
Next we get to the proper component styles, starting with a class selector. All of
our classes follow a [standard naming convention](/docs/naming-convention.html).
They’re namespaced with `mzp` to avoid conflicts with any other styling or libraries
with which they may need to coexist, followed by a `c` prefix indicating that this
is a component.

```scss
    @include text-title-md;
```
The first style declaration is a Sass mixin that sets the font-size for the element.
We use mixins for font sizes to maintain a standardized type scale, and the mixins
also include media queries to make the sizes responsive to the viewport size; bigger
screens get bigger text. These sizing mixins are defined in `includes/mixins/_typography.scss`.
See [our page on typography](/fundamentals/typography.html) for more about our type scale.

Next we declare the text color using a variable. Protocol has an extensive color
palette, all assigned to named variables so every occurance of a given color will
always be the exact same value (`$color-ink-80` is a dark purplish black). You can
see [our entire color palette](/fundamentals/color.html) for all the different options.

```scss
    margin: $spacing-lg 0;
```
The next line sets margins above and below the element, once again using a named
variable instead of an explicit value. Assigning variables to spacing units means
we ensure consistency throughout the system, and also lets us change the value of
such a variable in one place and it will automatically propagate to every other part
of Protocol. The `$spacing-lg` variable is `24px` but if we want to change that to
`20px` we would only have to make that change once.

### Tokens

The example above shows a Sass variable used as a margin value. We call variables
like these _design tokens_ and they’re more than just variables. Design tokens are
a way to document the lowest level design attributes and share them throughout a
complex system, and even across multiple systems. We use tokens as much as possible
in place of hard-coded values, especially for colors and units of measure. Whenever
you need a basic value in CSS, see if there’s already a token for it. You can see
[a list of all the design tokens in Protocol](/fundamentals/tokens.html).

Tokens are also a partial abstraction of the value they represent. Assigning a name
to a token also implies a particular purpose a step removed from its specific value.
A token like `$spacing-md` represents "a medium unit of space" and we don't necessarily
need to think about exactly how many pixels that is, we only know it's a bit larger
than small and a bit smaller than large. For now we've decided that a medium space is
`16px`, but that could easily change to `12px` or `20px` because "medium" is relative.
Avoid misusing a token as an alias for its specific value since the whole point is
that the value can change.

Also avoid misusing a token to fill in a value for something it wasn't made for. For
example, the token `$spacing-md` is intended for spacing within or between elements.
Don't use it set the height of an image or width of a border or size of a font (unless
there's a very good reason to do so).

(Side note: The `$spacing-*` tokens are smaller units, mostly for interior spacing
inside components or between close elements. The `$layout-*` tokens are larger,
intended for wider gaps between components on the page.)

Protocol's design tokens [reside in their own repository](https://github.com/mozilla/protocol-tokens)
and are [published as their own package](https://www.npmjs.com/package/@mozilla-protocol/tokens).

### Mixins

Protocol relies on numerous [Sass mixins](https://sass-lang.com/documentation/at-rules/mixin)
to simplify and standardize repetitive code. Some are fairly simple shortcuts and
others do more complex work. We won’t list them all here, but we’ll describe a few
of the more notable ones. All our mixins are in `/includes/_mixins.scss` or in
separate files in the `/includes/mixins/` folder. You’ll find even more documentation
as comments directly in the source files.

#### Text sizes
Protocol uses a modular type scale with a range of predefined font sizes, and to
maintain the consistency of that scale we rely on mixins for all of our text sizing.
See [our page on typography](/fundamentals/typography.html) for more info and examples.

```scss
@include text-title-lg;
```

Different themes have slightly different type scales so this mixin draws its output
from the defined brand theme. See [our page on themes](/fundamentals/themes.html)
for more info and examples.

#### bidi
The bidi mixin (short for “bi-directional”) is used to declare both left-to-right and
right-to-left values for a CSS property together, and output appropriate declarations
for each. This makes it easier to support right-to-left languages – such as Hebrew and
Arabic – while keeping both styles in the same place. Whenever you’re floating or
aligning something to one side, you might prefer to use the bidi mixin to reverse that
direction for other languages. Refer to `/includes/mixins/_bidi.scss` for more
documentation and usage.

```scss
@include bidi(((float, left, right),));
```

#### at2x
at2x is a helpful mixin for applying a high-resolution background image, for display
on high definition screens (a.k.a. “retina”). It automatically outputs the standard
resolution background image with the high-resolution version in a media query, along
with the `background-size` property to scale it. Both image files should be in the same
folder and have matching names, with the high resolution version suffixed with “high-res”,
e.g. `example.png` and `example-high-res.png`

```scss
@include at2x('/img/example.png', 100px, 100px);
```

#### light-links
The light-links mixin inverts link colors in elements/components with dark backgrounds.

```scss
@include light-links;
```

#### white-links
The white-links mixin explicitly sets link colors (in all pseudo-class states) to white.
This is useful for some elements/components with dark backgrounds where the regular
inverted link colors might be undesirable, typically for utilitarian components like a
footer.

```scss
@include white-links;
```

### Themes

Protocol supports [multiple brand themes](/fundamentals/typography.html), namely the Mozilla
and Firefox brands. Themes work by defining sets of variables in Sass maps in the
`/includes/_themes.scss` file, and those variables are fetched via the `get-theme()` function.
That function determines which set of variables to draw from based on the declared brand theme,
thus any themable property in CSS can have different values for different brands.

```scss
.mzp-c-my-component {
    background-color: get-theme('background-color');
    color: get-theme('body-text-color');

    .mzp-c-my-component-title {
        color: get-theme('title-text-color');
        font-family: get-theme('title-font-family');
    }
}
```

Use the `get-theme()` function for any themeable properties, especially basic colors for
foreground (text) and backgrounds. Note that most colors have an "inverse" counterpart
to use in dark style variants. Refer to `/includes/_themes.scss` for the actual values
for each brand theme, but here are the variable names in a handy list:

```
background-color
background-color-alt
background-color-alt-inverse
background-color-inverse
body-font-family
body-text-color
body-text-color-alt
body-text-color-alt-inverse
body-text-color-inverse
button-font-family
link-color
link-color-hover
link-color-hover-inverse
link-color-inverse
link-color-visited
link-color-visited-hover
link-color-visited-hover-inverse
link-color-visited-inverse
title-font-family
title-text-color
title-text-color-inverse
```

Text sizes are also defined as theme variables, allowing different brands to have slightly
different type scales. Don't use the `get-theme()` function for text sizing; use the text
size mixins instead. The mixins already draw from the theme variables but come with baked-in
responsive styling as well.

repository: wlach/protocol

gha_language: Handlebars

repo_name: wlach/protocol


text:
# New Component Guide

> This is a very brief guide which describes what you have to do in order to implement a new component for Fundamental Vue.

::: tip

You can now use the `new_component.js` script in the `scripts` folder. Just run `node scripts/new_component.js <componentName>` and it will create
all the necessary files and make the imports. After executing it and building the doc you should see a section for your new component with some placeholder text.

**P.S:** please use the `lowerCamelCase` naming convention when passing the new component's name

:::

## Creating the files for the actual Component

For the purpose of this guide, lets assume that you want to create a component called `Flower`. Create a folder that contains all of your files. For example:

```bash
$ mkdir ui/src/components/Flower
$ touch ui/src/components/Flower/index.ts
$ touch ui/src/components/Flower/Flower.vue
$ touch ui/src/components/Flower/Blossom.vue
$ touch ui/src/components/Flower/Util.ts
```

## Implementing the Component

**ui/src/components/Flower/Flower.vue**

```xml
<template>
  <div :style="style">I am a flower</div>
</template>

<script lang="ts">
import Vue from "vue";

export default Vue.extend({
  name: "FdFlower",
  props: {
    color: String
  },
  computed: {
    styles() {
      return {
        backgroundColor: this.color
      };
    }
  }
});
</script>
```

## Exporting the new Component

You have to export the new component:

**ui/src/components/Flower/index.ts**

```typescript
import Flower from "./Flower.vue";
import { pluginify } from "@/util";
export default pluginify(Flower);
export { Flower };
```

## Documenting the new Component

In order to make your component available to the public you have to document the component. A properly documented component consists of at least two things:

- Examples
- API Documentation

## Documenting the new Component: Examples

In order to create a example for your new component create the necessary files:

```bash
$ mkdir docs/src/pages/Flower
$ touch docs/src/pages/Flower/0-default.vue
$ touch docs/src/pages/Flower/index.ts
```

Examples are implemented as single file components (in our case `docs/src/pages/Flower/0-default.vue`) because this is what most Vue developers are using. You can put anything you want in the vue-file: a `<template>`-block, a `<script>`-block and a `<style>`-block.

Fundamental Vue examples may contain additional documentation specific blocks.

**_baseline.json:**
 docs/src/api/_baseline.json

Here you add the documentation that needs to be added for your component; like the possible slots, props, events, mixins etc.

**pages.json:**
 docs/src/pages/pages.json

Here you add the page configuration in which the documentation will be shown; like the title that comes on the left section, the files that need to be read and stuff.

Lets simply implement the most basic example possible:
### Simple Example

**docs/src/pages/Flower/0-default.vue**

```xml
<template>
  <FdFlower color="red" />
</template>
```

You can include a `script` and/or `style` section if needed. If you declare custom styles make sure to make your `style`-section scoped.

### Improved Example

As already mentioned in the paragraph above, you can improve your example by using addional blocks. Namely:

- `<title>Example Title</title>`: Specify a title for your example. The title is displayed in a big font above your example.
- `<docs>Potentially long example description</docs>`: Describe the example in detail. This is displayed directly below the title. **Supports Markdown**
- `<tip>Short but useful tip related to the example/component.</tip>` If there is something important, especially useful or good to know fact use the `<tip>`-block. This is displayed in a highlighted box below the `<docs>`-block. **Supports Markdown**

**docs/src/pages/Flower/0-default.vue**

```xml
<title>Red Flower (Rose)</title>
<docs>Roses are **red**, __Violets__ are ~blue~, Sugar is sweet, And so are you.</docs>
<tip>Plant roses under trees for **best** results.</tip>
<template>
  <FdFlower color="red" />
</template>
```

## Localization

A good component should either be localized or localizable.

- A **localizable component** may display non-localized text/icons but the displayed text should be configurable by the application developer.
- A **localized component** is fully localized out of the box.

Since there is no Fundamental Vue-wide localisation and internationalization concept (localized icons, right-to-left-support, …) you should at least create an issue for the component you implemented.

## Accessibility
Having an accessible component directly means catering to a broader audience than otherwise.
It needs to be noted that each new component is expected to be accessible.

For details, please refer to: [https://www.w3.org/TR/wai-aria-practices-1.1/](https://www.w3.org/TR/wai-aria-practices-1.1/)

repository: SAP/fundamental-vue

branch_name: refs/heads/main

extension: md

gha_language: Vue

license_type: permissive

repo_name: SAP/fundamental-vue


text:
#QAFE Book

![qafelogo](http://www.qafe.com/wp-content/themes/qafe2013/img/logo.png)

## 3 QAFE Basics
In the previous chapter the software for QAFE Development was installed. Then a simple project project was created and the QAFE HelloWorld application was shown at runtime.

In this chapter we’ll dive into the anatomy of the QAFE HelloWorld Application.

```XML
<presentation-tier>
		<view>
			<window id="helloWorld" displayname="Hello World" width="300" height="250">
				<rootpanel id="rootPanelId">
					<verticallayout>
						<button id="clickMeButtonId" displayname="Click me"/>
					</verticallayout>
				</rootpanel>
				<events>
					<event id="clickMeEventId">
						<listeners>
							<listenergroup>
								<component ref="clickMeButtonId"/>
								<listener type="onclick"/>
							</listenergroup>
						</listeners>
						<dialog type="info">
							<title value="Hello Dialog"/>
							<message value="Hello World!"/>
						</dialog>
					</event>
				</events>
			</window>
		</view>
	</presentation-tier>

```

```XML
<applications  xmlns=http://qafe.com/schema
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="http://qafe.com/schema
http://www.qafe.com/schema/application-context.xsd">

  <application name="apps" id="system_app" >
    <application-mapping-file location="qafe-default-system-app.xml"/>
  </application>

  <application name="Hello World" id="myApp" >
    <application-mapping>
       <presentation-tier>
         <view>
          <window id="myWindow" displayname="Hello World">
            <rootpanel>
              <verticallayout>
           	   <button id="myButton" displayname="HellWorld"/>
           	 </verticallayout>
            </rootpanel>
          </window>
        </view>
      </presentation-tier>
    </application-mapping>
  </application>

</applications>
```

The applications that are needed are specified within the application tag in the XML. The application tag has an id and name attribute. The name attribute is shown in the system application menu shown in the virtual desktop page which is used to invoke the application. The definition of the application is done within the application-mapping tag.

In the code sample, there are in two applications: system_app and hello_world. The xml file mentioned as attribute value in the application-mapping-file tag with the id system_app represents the system application menu.

We advice you to place all your QAML files (definition of your applications based on XML) including the application-config.xml file outside the QAFE software deployment location. This may become handy when the QAFE software needs to be updated as it will make sure that your QAML files are not affected when QAFE is updated. After updation of QAFE (if any), you will only need to redefine the location of the application-config.xml in the overwritten web.xml file.

> NOTE: If you don't want to have the files in your WEB-INF directory, you can modify the application-config.xml to other file locations as long as the file is reachable through a valid URL.

If QAML contain resources that refer to their statement files, then the statements files need to be located in the same directory (since the statements files are always relative file locations).
If there is an application-config file which contains an application which on its turn has multiple filelocations for the application-mapping, make sure that the statements file in the resources are defined in a correct and concise manner.

Example:

```XML
<application id="system_app" name="sysapp">
	<application-mapping-file
	        location="file:///f:/test-web/qafe-default-system-app.xml"/>
</application>

```
To test the QAFE applications, start Apache tomcat by running the startup.bat file in the bin directory. Open a web browser and type the following in the URL bar:

http://localhost:9080/<context root>

> - localhost: server name
- 9080: server port (configured above)
- context root: “qafe-web-gwt”

repository: rjankie/testrepo

branch_name: refs/heads/master

repo_name: rjankie/testrepo


text:
# Sam Riley reveals nickname for Maleficent co-star Angelina Jolie

Published at: **2019-11-01T14:35:18+00:00**

Author: ****

Original: [Breaking News](https://www.breakingnews.ie/showbiz/sam-riley-reveals-nickname-for-maleficent-co-star-angelina-jolie-961195.html)

Sam Riley has revealed his special nickname for his Maleficent co-star, Angelina Jolie.
The British actor, who plays Diaval in the Disney blockbuster, was reunited with Jolie as the powerful fairy in the sequel Mistress Of Evil.
He told the PA news agency: “She introduces herself as Angie so you are then (invited to call her that), but if you start going home, particularly to Yorkshire, and saying ‘I’m meeting Angie’, you would get a lot of stick.

license: Unlicense

repository: dsadlollioygjmzvcxv/tdc-exported

repo_name: dsadlollioygjmzvcxv/tdc-exported


text:
# Changelog

All notable changes to this project will be documented in this file. See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines.

## [4.1.0](https://github.com/webpack-contrib/expose-loader/compare/v4.0.0...v4.1.0) (2023-03-09)

### Features

* added `globalObject` option to modify global context ([#205](https://github.com/webpack-contrib/expose-loader/issues/205)) ([1ad9096](https://github.com/webpack-contrib/expose-loader/commit/1ad90966b8676ba21e9d42d75cc0d9885e332ffc))

## [4.0.0](https://github.com/webpack-contrib/expose-loader/compare/v3.1.0...v4.0.0) (2022-05-17)

### ⚠ BREAKING CHANGES

* minimum supported `Node.js` version is `14.15.0`

## [3.1.0](https://github.com/webpack-contrib/expose-loader/compare/v3.0.0...v3.1.0) (2021-10-21)

### Features

* output links on validation errors ([#138](https://github.com/webpack-contrib/expose-loader/issues/138)) ([c897dad](https://github.com/webpack-contrib/expose-loader/commit/c897dadbd14bb6b24fa0879b294331020bfdd82c))

### Bug Fixes

* small perf improvement ([#145](https://github.com/webpack-contrib/expose-loader/issues/145)) ([6aeabd8](https://github.com/webpack-contrib/expose-loader/commit/6aeabd808d9fd35ef7dbd2dfb45f85a469c978cb))

## [3.0.0](https://github.com/webpack-contrib/expose-loader/compare/v2.0.0...v3.0.0) (2021-05-20)

### ⚠ BREAKING CHANGES

* minimum supported `Node.js` version is `12.13.0`

## [2.0.0](https://github.com/webpack-contrib/expose-loader/compare/v1.0.3...v2.0.0) (2021-02-02)

### ⚠ BREAKING CHANGES

* minimum supported `webpack` version is `5`
* inline syntax was changed: `[]` is no longer supported (i.e. `import $ from "expose-loader?exposes[]=$&exposes[]=jQuery!jquery`), please use `,` comma separator (i.e. `import $ from "expose-loader?exposes=$,jQuery!jquery`)

### [1.0.3](https://github.com/webpack-contrib/expose-loader/compare/v1.0.2...v1.0.3) (2020-11-26)

### Bug Fixes

* set side effects to false ([#122](https://github.com/webpack-contrib/expose-loader/issues/122)) ([ee2631d](https://github.com/webpack-contrib/expose-loader/commit/ee2631df243e4fa13f107189be5dc469108495b3))

### [1.0.2](https://github.com/webpack-contrib/expose-loader/compare/v1.0.1...v1.0.2) (2020-11-25)

### Bug Fixes

* don't strip loader "ref" from import string ([6271fc4](https://github.com/webpack-contrib/expose-loader/commit/6271fc4e227a63aae082b9a111e103b6967bc1ba))

### [1.0.1](https://github.com/webpack-contrib/expose-loader/compare/v1.0.0...v1.0.1) (2020-10-09)

### Chore

* update `schema-utils`

## [1.0.0](https://github.com/webpack-contrib/expose-loader/compare/v0.7.5...v1.0.0) (2020-06-23)

### ⚠ BREAKING CHANGES

* minimum supported Node.js version is `10.13`
* minimum supported `webpack` version is `4`
* `inline` syntax was changed, please [read](https://github.com/webpack-contrib/expose-loader#inline)
* list of exposed values moved to the `exposes` option, please [read](https://github.com/webpack-contrib/expose-loader#exposes)
* migrate away from `pitch` phase
* do not override existing exposed values in the global object by default, because it is unsafe, please [read](https://github.com/webpack-contrib/expose-loader#override)

### Features

* validate options
* support webpack 5
* support multiple exposed values
* interpolate exposed values
* allow to expose part of a module
* allow to expose values with `.` (dot) in the name

### Fixes

* do not break source maps
* do not generate different hashed on different os
* compatibility with ES module syntax

## [0.7.5](https://github.com/webpack-contrib/expose-loader/compare/v0.7.4...v0.7.5) (2018-03-09)

### Bug Fixes

* **package:** add `webpack >= v4.0.0` (`peerDependencies`) ([#67](https://github.com/webpack-contrib/expose-loader/issues/67)) ([daf39ea](https://github.com/webpack-contrib/expose-loader/commit/daf39ea))

## 0.7.4 (2017-11-18)

### Bug Fixes

* **hash:** inconsistent hashes for builds in different dirs. ([#28](https://github.com/webpack-contrib/expose-loader/issues/28)) ([efe59de](https://github.com/webpack-contrib/expose-loader/commit/efe59de))
* **remainingRequest:** resolve  issue when multiple variables are exposed for the same request. ([#30](https://github.com/webpack-contrib/expose-loader/issues/30)) ([335f9e6](https://github.com/webpack-contrib/expose-loader/commit/335f9e6))
* ensure `userRequest` stays unique (`module.userRequest`) ([#58](https://github.com/webpack-contrib/expose-loader/issues/58)) ([51629a4](https://github.com/webpack-contrib/expose-loader/commit/51629a4))

license: MIT

repository: webpack-contrib/expose-loader

gha_language: JavaScript

gha_license_id: MIT

repo_name: webpack-contrib/expose-loader


text:
# COVID 19 Data Parser

A utility to parse the COVID 19 data from [John Hopkins](https://github.com/CSSEGISandData/COVID-19)
Some visualizations of this output over here:
Covid-19 collection

Features
--------

* TODO

gha_language: Python


text:
# Array shift
Write a function called insertShiftArray which takes in an array and a value to be added. Without utilizing any of the built-in methods available to your language, return an array with the new value added at the middle index.

# Whitebord procees
![alt](code2.png)

# Approach and efficient
    create new array to add the new value to it it has linear time complexity and constant space complexity


text:
TFT_22_ILI9225
==============

This is a library for the ILI9225 TFT display products, forked from the screen_4D_22_library library. Ability to
use GLCD fonts has been added and the syntax has been changed to match the Adafruit libraries somewhat.

This library works with the ILI9225 based 2.2" 176x220 TFT LCD shields commonly found on eBay. Note
that there is a commonly available 2.2" 240x320 TFT module very similar in appearance but using the
ILI9341 driver.

To install the library:
* Click the **Download ZIP** button on the right to download **TFT_22_ILI9225-master.zip**
* Extract the ZIP file to the library folder your *arduinosketchfolder*/libraries/ folder. You may need to create the libraries subfolder if it's your first library.
* Rename the uncompressed folder from **TFT_22_ILI9225-master** to **TFT_22_ILI9225**
* Restart the Arduino IDE

Look at the included "Basic_Demo" example sketch for sample code and the Wiki for documentation.

repository: jacquesd/foosballino

repo_name: jacquesd/foosballino


text:
Radial Bubble Tree
==================

![bubble tree screenshot](http://driven-by-data.net/wp/wp-content/uploads/2011/06/Bildschirmfoto-2011-07-02-um-23.02.50.png bubbletree screenshot right)

The BubbleTree can be used to display hierarchical (spending) data in an interactive visualization. The setup is easy and independent from the OpenSpending platform. However, there is an optional integration module to connect with data from the OpenSpending API.

## Requirements

BubbleTree depends on the following JS libraries

 - jQuery
 - jQuery History
 - jQuery Tooltip
 - RaphaelJS
 - TweenJS

## Setup

## Configuration vars
The constructor of the bubble chart takes just one argument, the configuration object which contains all settings that can be set. This section will cover all available configuration variables.

Example:

	new BubbleTree.Loader({
		data: treeObj,
		container: '#bubbletree'
	});

### Data format

The BubbleTree expects the data in a linked tree structure. The core element in the tree are nodes which must at least consist of the properties *label* and *amount*:

	rootNode = {
		label: "Total budget",
		amount: 1000000
	}

The child nodes then are (recursivly) inserted within the *children* array.

	rootNode = {
		label: "Total budget",
		amount: 1000000,
		children: [{
			label: "Health",
			amount: 650000
		}, {
			label: "Government",
			amount: 350000
		}]
	}

You can also give the nodes unique identifier by setting the *id* property.

	node = {
		id: "gov"
		label: "Government",
		amount: 350000
	}

Another way to identify the nodes is to assign them to a taxonomy by setting the *taxonomy* and *name* properties.

	node = {
		taxonomy: "cofog",
		name: "05.3",
		label: "Government",
		amount: 350000
	}

### HTML Integration

You need to tell the BubbleTree at which point in the container HTML the visualization should be inserted. To do this, simply set the *container* property in configuration. The container can be either a HTML DOM node or a jQuery selector String

* *container* - String, jQuery selector of the container element for the visualization, must be defined in HTML code, e.g. '#bubbletree'

**Note:** The container element must be defined in the HTML page, the BubbleTree won't create it itself.

### Display Properties

* *bubbleType* - defines what class is used to render the bubbles. Possible values are plain, icon, donut. Can be either a String if the same type should be used for all bubbles or an array of strings if different bubble types should be used for different tree levels.

	config.bubbleType = 'plain'

	config.bubbleType = ['donut', 'icon', 'donut'];

### Custom Styling

It is possible to change the default display properties of each bubble by setting up bubble styles. Bubble styles can be defined once for each taxonomy (e.g. COFOG) or for individual node ids. By now, you can use bubble styles to change the colors that come out of the API or to set up icon images for the bubbleType "icon".
* *bubbleStyles* - Object that holds bubble style declarations, grouped into taxonomies.

Example:

	config.bubbleStyles = {
		'cofog': BubbleTree.Styles.Cofog,
		'itb-function': BubbleTree.Styles.ItbFunction,
	};

There are two reserved words, that can't be used as taxonomy ids: *id* and *name*. Both are used to directly apply styles to bubbles which don't belong to any taxonomy. In the following example, a color is defined for the node with the id "root". Also, all nodes with the name "italy-toscana" will get the color #dd333.

	config.bubbleStyles = {
		'id: {
			'root: { color: '#cccccc' }
		},
		'name': {
			'italy-toscana': { color: '#dd3333' }
		}
	}

## Appendix

### Integration with OpenSpending API

If you want to connect the BubbleTree with OpenSpending data you might want to use the Aggregator class.

	new Aggregator({
		apiUrl: "http://org/api",
		dataset: "cra",
		drilldowns: ["cofog1", "cofog2"],
		cuts: ['year:2008'],
		breakdown: 'region',
		callback: function(data) {
			new BubbleTree.Loader({
				data: data,
				container: '#bubbletree'
			});
		}
	});

The following config variables can be used to change the data source:

* apiUrl - String, url of a running OpenSpending API instance, e.g. "http://org/api"
* dataset - String, name of the used dataset, e.g. "israel"
* drilldowns - Array of drilldown taxonomies, e.g. ['primary', 'section', 'entity']
* cuts - Array of filters?, e.g. ['year:2010']
* breakdown - String, taxonomy for sub-breakdowns as displayed in the donut bubbles, e.g. 'cofog1'

For local testing purposes you can also use locally cached api call results by setting the *localApiCache* property.

* localApiCache - String, url to a locally stored API output JSON

### Tooltip integration

In the current implementation, tooltips are not part of the BubbleTree. Instead, the visualization provides a simple API for adding custom tooltips.

 * *initTooltip* - function that will initialize the tooltip for a given bubble.

	function initTooltip(node, bubble) {

	}

#### Event Handler
The tooltip event handler can be set with the *tooltipCallback* property in the configuration (see above).
The event handler must handle both the tooltip show and hide events. See index.html for an example implementation.

#### Event Properties
The following event properties are available

* type - can be "SHOW" or "HIDE"
* mousePos - object with numerical properties x and y, stores the actual mouse position at the time the tooltip event was thrown, relative to the container div
* bubblePos - same as mousePos, but stores the position of the bubble instead of the mouse
* node - the node of the bubble that is related to the tooltip event
* origEvent - the original event object as thrown by jQuery
* target - the related Bubble object

## Basic setup

* Create an empty HTML page with a blank DIV in it that should be used as a container for the BubbleTree
* Include the required JS libraries, which are
	* jQuery 1.5.2 (<http://www.jquery.org>)
	* jQuery History (<http://tkyk.github.com/jquery-history-plugin/>)
	* RaphaelJS 1.5.2 (<http://raphaeljs.com/>)
	* Tween.js (<https://github.com/sole/tween.js>)
	* vis4.js (<https://bitbucket.org/gka/vis4.js>)
* Include bubble

## Custom Taxonomy Styling (e.g. Icons)

### Icon Specifications
The icons are stored in /icons/ folder in standard SVG format. However, there are some specifications to ensure that the visualization can use the icons correctly.

* the svg canvas should be 100px * 100px
* the icon itself must be stored in one or many SVG path elements. Every other SVG elements like <circle> will be ignored by the viz.
* the icon SVG must not be too large to keep the viz performance. SVG filesize of under 10kb are perfect, everything above 100kb should be avoided.
* the icon paths should not exceed the bubble size

### Taxonomy to Icon Mapping
The icon filenames are arbitrary. The mapping between taxonomies and icons is done at JavaScript side by defining the *bubbleStyle* property in the configuration (see above), which is a three level nested dictionary

* *taxonomy_id* => *nodeStyles*
	* *node_name* => *styles*
		* *styles* is a dictionary of visual properties to their actual values, e.g. 'color' = '#dd0000'

Please see index.html and style.cofog.js for a working example.

## Copyright and License

Copyright (c) 2011 Open Knowledge Foundation

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

## Attribution Request

If you use Bubbletree to make a visualization we'd love it (but it's not required!) if you added a small credit text and link e.g.

    Built with Open Knowledge Foundation's Bubbletree library

## Authors

[Gregor Aisch](http://vis4.net/blog/) with a very small amount of input from [Rufus Pollock](http://rufuspollock.org/) as part of work on the [OpenSpending](http://openspending.org/) project and with financial support from [Publish What You Fund](http://www.publishwhatyoufund.org/) and the [Shuttleworth Foundation](http://www.shuttleworthfoundation.org/).


text:
---
layout: default
---

# 1996-04-16 - Re: RSA-130 Falls to NFS - Lenstra Posting to sci.crypt.research

## Header Data

From: "E. ALLEN SMITH"<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: ddf206ce6a24ca0fe18d8abb1cba8faf232d5019af8d2c3fbc89f93543603f91

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1996-04-16 21:40:19 UTC

Raw Date: Wed, 17 Apr 1996 05:40:19 +0800

## Raw message

```
{% raw  %}From: "E. ALLEN SMITH"<EMAIL_ADDRESS>Date: Wed, 17 Apr 1996 05:40:19 +0800
To<EMAIL_ADDRESS>Subject: Re: RSA-130 Falls to NFS - Lenstra Posting to sci.crypt.research
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

From: Bruce Marshall<EMAIL_ADDRESS>
>    However, I do feel that you may have a valid point when switching
>"hackers" to "opponents of the research."  Anyone with an interest in
>preventing or slowing down the progress in such a project would be more
>dangerous in my mind than your average hacker.

>    Preventing that from happening would be necessary if it is decided
>that such a threat truly exists.

	Actually, people would also have a motivation to turn in false results
if they were being paid (perhaps in ecash) for their computer time. If they
could take less time and turn in a supposedly correct job, they would be
able to be paid the same amount for less work. Fortunately, it does appear
possible to filter out bad ones. In creating such a paid system, keeping this
possibility in mind would be needed.
	-Allen

{% endraw %}
```

## Thread

+ Return to [April 1996](/archive/1996/04)

+ Return to "["E. ALLEN SMITH" <EALLENSMITH@ocelot.Rutgers.EDU>](/authors/e_allen_smith_eallensmith_at_ocelot_rutgers_edu_)"

+ 1996-04-16 (Wed, 17 Apr 1996 05:40:19 +0800) - Re: RSA-130 Falls to NFS - Lenstra Posting to sci.crypt.research - _"E. ALLEN SMITH"<EMAIL_ADDRESS>