Antranig Basman amb26

## SwitchDemo.js
/*
Copyright The Infusion copyright holders
See the AUTHORS.md file at the top-level directory of this distribution and at
https://github.com/fluid-project/infusion/raw/main/AUTHORS.md.

Licensed under the Educational Community License (ECL), Version 2.0 or the New
BSD license. You may not use this file except in compliance with one these
Licenses.

You may obtain a copy of the ECL 2.0 License and BSD License at

## testSwitch.js
    fluid.tests.switchUI.makeSwitch = function (enabled) {
        var togo = fluid.promise();
        var that = fluid.tests.switchUI(".flc-switchUI", {
            model: {
                enabled: enabled
            },
            listeners: {
                onCreate: function (that) {
                    togo.resolve(that);
                }

## README.md

      
              1 file
            
          
              0 forks
            
          
              0 comments
            
          
              0 stars
            
          
                amb26
                / README.md
            
            
              Created
              June 1, 2021 18:28
            
          
    Textfield Controls Client-Side Demo

This is a simple replication of the existing Textfield Controls demo hosted at
https://build-infusion.fluidproject.org/demos/textfieldcontrol/ for the rewrite of the textfield controls components using the new
renderer. Since this is a serverless demo, includes are written out in the old literal style, but this is not
anticipated to be a common use pattern. Due to the lack of a server side, the fluid.resourceLoader.staticMountTable
needs to be written out inline in the code so that the component can locate its templates. It's imagined that in
other serverless contexts, some kind of rollup or webpack plugin will take responsibility for these.
To see the demo, browse to index.html using some form of static hosting.

  
## biwt-readme.md

      
              1 file
            
          
              0 forks
            
          
              0 comments
            
          
              0 stars
            
          
                amb26
                / biwt-readme.md
            
            
              Last active
              May 27, 2021 11:26
            
              
                biwt-readme.md
              
          
    IMERSS Bioinformatics Working Group Data Archive, Pipelines and Visualisations

This repository houses the working data of the IMERSS biodiversity informatics working group
together with algorithms for transforming, reconciling and projecting observation and checklist data into formats
suitable for publication, submission to global authorities such as GBIF, as well as map-based and graphical
visualisations.
Data Archive

All data is stored in CSV files in subdirectories under data although some unprocessed checklist data is a variety of

  
## question10.txt
10. Q: What existing data or datasets are you aware of that could help build AI-empowered solutions in this space? What data needs to be collected to be successful?

A: The notion of "collecting" data is inherently faulty and centralising. The communities already have their data, they merely need the tools to express their ownership, control, and relationships which centre on it, at a price they can afford.

## fully renderised.txt
Top-level driver:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <meta content="width=device-width, initial-scale=1.0" name="viewport">

    <link rel="stylesheet" type="text/css" href="../../node_modules/infusion/src/framework/core/css/fluid.css" />
    <link rel="stylesheet" type="text/css" href="../../textfieldControl/css/TextfieldSlider.css" />

## fuseNode.js
    fluid.renderer.fuseNode = function (target, source) {
        while (source.childNodes.length > 0) {
            target.appendChild(source.firstChild);
        }
        for (var i = 0; i < source.attributes.length; i++) {
            var attrib = source.attributes[i];
            if (attrib.name !== "class" && attrib.name !== "id") {
                target.setAttribute(attrib.name, attrib.value);
            }
        }

## qabal-29-04-21.txt
Thu, Apr 15 2021
the-t-in-rtf
So, I was reviewing some older fluid-handlebars work and wanted to ask about your current thinking about conditional renderering in the new world.
The simplest example is having different class names on a particular element based on aspects of the model.
A more complex example would be a search, where you might have a bunch of results you want to render, or you might just want to display "no results found" or some other diagnostic.
If each result is a sub-component, that raises one set of questions.
If on the other hand you want to have one thing generate the whole list (or the "no results found" message), it raises another question, namely are there iteration operators.
These two things are most of the useful smart bits in a template language like handlebars.
there's also the ability to create "helpers", so I was wondering about expanders in the future and whether we would be able to refer those in whatever syntax we use to express what should be rendered.
But I kind of thought

## tangledMat.md

      
              1 file
            
          
              0 forks
            
          
              0 comments
            
          
              0 stars
            
          
                amb26
                / tangledMat.md
            
            
              Last active
              April 7, 2021 14:46
            
          
    forgiving-data

What is this?

Algorithms for processing and relating data in ways which promote ownership, representation and inclusion,
maintaining rather than effacing provenance.
How to use it?

This is very early-stage work. The file jobs/WeCount-ODC.json5 contains a very simple three-element

  
## DataBindingTests.js
// Linked from https://github.com/fluid-project/infusion/pull/1038/files#diff-6972ab970b7ccb5a497ebc0fc51a19df59946de2ba24f58b1577c4ae40546f8cR1005-R1036

fluid.defaults("fluid.tests.fluid6390booleanRoot", {
        gradeNames: "fluid.modelComponent",
        model: {
            shouldComponentExist: 1
        },
        dynamicComponents: {
            conditionalComponent: {
                source: "{that}.model.shouldComponentExist",
	/*
	Copyright The Infusion copyright holders
	See the AUTHORS.md file at the top-level directory of this distribution and at
	https://github.com/fluid-project/infusion/raw/main/AUTHORS.md.

	Licensed under the Educational Community License (ECL), Version 2.0 or the New
	BSD license. You may not use this file except in compliance with one these
	Licenses.

	You may obtain a copy of the ECL 2.0 License and BSD License at
	fluid.tests.switchUI.makeSwitch = function (enabled) {
	var togo = fluid.promise();
	var that = fluid.tests.switchUI(".flc-switchUI", {
	model: {
	enabled: enabled
	},
	listeners: {
	onCreate: function (that) {
	togo.resolve(that);
	}
	10. Q: What existing data or datasets are you aware of that could help build AI-empowered solutions in this space? What data needs to be collected to be successful?

	A: The notion of "collecting" data is inherently faulty and centralising. The communities already have their data, they merely need the tools to express their ownership, control, and relationships which centre on it, at a price they can afford.
	Top-level driver:

	<!DOCTYPE html>
	<html lang="en">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
	<meta content="width=device-width, initial-scale=1.0" name="viewport">

	<link rel="stylesheet" type="text/css" href="../../node_modules/infusion/src/framework/core/css/fluid.css" />
	<link rel="stylesheet" type="text/css" href="../../textfieldControl/css/TextfieldSlider.css" />
	fluid.renderer.fuseNode = function (target, source) {
	while (source.childNodes.length > 0) {
	target.appendChild(source.firstChild);
	}
	for (var i = 0; i < source.attributes.length; i++) {
	var attrib = source.attributes[i];
	if (attrib.name !== "class" && attrib.name !== "id") {
	target.setAttribute(attrib.name, attrib.value);
	}
	}
	Thu, Apr 15 2021
	the-t-in-rtf
	So, I was reviewing some older fluid-handlebars work and wanted to ask about your current thinking about conditional renderering in the new world.
	The simplest example is having different class names on a particular element based on aspects of the model.
	A more complex example would be a search, where you might have a bunch of results you want to render, or you might just want to display "no results found" or some other diagnostic.
	If each result is a sub-component, that raises one set of questions.
	If on the other hand you want to have one thing generate the whole list (or the "no results found" message), it raises another question, namely are there iteration operators.
	These two things are most of the useful smart bits in a template language like handlebars.
	there's also the ability to create "helpers", so I was wondering about expanders in the future and whether we would be able to refer those in whatever syntax we use to express what should be rendered.
	But I kind of thought
	// Linked from https://github.com/fluid-project/infusion/pull/1038/files#diff-6972ab970b7ccb5a497ebc0fc51a19df59946de2ba24f58b1577c4ae40546f8cR1005-R1036

	fluid.defaults("fluid.tests.fluid6390booleanRoot", {
	gradeNames: "fluid.modelComponent",
	model: {
	shouldComponentExist: 1
	},
	dynamicComponents: {
	conditionalComponent: {
	source: "{that}.model.shouldComponentExist",