yv01p/Umbraco-CMS
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

delete fontawesome

Browse Source
This commit is contained in:
perploug
2013-09-02 15:40:14 +02:00
parent 26da26fe8d
commit 623a28c158
935 changed files with 179331 additions and 180482 deletions
Download Patch File Download Diff File Expand all files Collapse all files

318
src/Umbraco.Web.UI.Client/docs/html/belleLabTasks.html
View File

@@ -1,159 +1,159 @@
<!DOCTYPE html>
<html>
<head>
<title>doc</title>
<style>
/*github.com style (c) Vasily Polovnyov <vast@whiteants.net>*/
pre code {
display: block; padding: 0.5em;
color: #333;
background: #f8f8ff
}
pre .comment,
pre .template_comment,
pre .diff .header,
pre .javadoc {
color: #998;
font-style: italic
}
pre .keyword,
pre .css .rule .keyword,
pre .winutils,
pre .javascript .title,
pre .nginx .title,
pre .subst,
pre .request,
pre .status {
color: #333;
font-weight: bold
}
pre .number,
pre .hexcolor,
pre .ruby .constant {
color: #099;
}
pre .string,
pre .tag .value,
pre .phpdoc,
pre .tex .formula {
color: #d14
}
pre .title,
pre .id {
color: #900;
font-weight: bold
}
pre .javascript .title,
pre .lisp .title,
pre .clojure .title,
pre .subst {
font-weight: normal
}
pre .class .title,
pre .haskell .type,
pre .vhdl .literal,
pre .tex .command {
color: #458;
font-weight: bold
}
pre .tag,
pre .tag .title,
pre .rules .property,
pre .django .tag .keyword {
color: #000080;
font-weight: normal
}
pre .attribute,
pre .variable,
pre .lisp .body {
color: #008080
}
pre .regexp {
color: #009926
}
pre .class {
color: #458;
font-weight: bold
}
pre .symbol,
pre .ruby .symbol .string,
pre .lisp .keyword,
pre .tex .special,
pre .prompt {
color: #990073
}
pre .built_in,
pre .lisp .title,
pre .clojure .built_in {
color: #0086b3
}
pre .preprocessor,
pre .pi,
pre .doctype,
pre .shebang,
pre .cdata {
color: #999;
font-weight: bold
}
pre .deletion {
background: #fdd
}
pre .addition {
background: #dfd
}
pre .diff .change {
background: #0086b3
}
pre .chunk {
color: #aaa
}
</style>
</head>
<body>
<h1>Belle Lab Tasks</h1>
<h2>Applcation Structure</h2>
<ul>
<li>Work on dialogs, plenty to choose from</li>
<li>A reuseable tree component for pickers</li>
<li>migrate all the navigation stuff into a navigation service</li>
<li>a scriptloading service to replace requireJs, with labJs, $script or similiar</li>
<li>reusable modal component (show in left side, right side, generic closing events etc)</li>
</ul>
<h2>Components</h2>
<ul>
<li>tabs directive</li>
<li>date picker</li>
<li>tabs property editor</li>
<li>localization strategy?<ul>
<li>localize filter: {{This is my default english value,content.area.key | localize}}</li>
<li>So, it will use the default value if there is none found for the key, and register this
value in the localize service, keys should not contain commas</li>
</ul>
</li>
</ul>
<h2>Chores</h2>
<ul>
<li>Write a test</li>
<li>Write docs</li>
<li>Automate something<ul>
<li>OSX:<ul>
<li>start webserver</li>
<li>start grunt watch</li>
<li>improve test output?</li>
<li>phantomJs?</li>
</ul>
</li>
<li>windows<ul>
<li>start webserver</li>
<li>start grunt</li>
<li>install node stuff?</li>
<li>register chrome_bin in path</li>
<li>or register phantomJS?</li>
</ul>
</li>
</ul>
</li>
</ul>
</body>
</html>
<!DOCTYPE html>
<html>
<head>
<title>doc</title>
<style>
/*github.com style (c) Vasily Polovnyov <vast@whiteants.net>*/
pre code {
display: block; padding: 0.5em;
color: #333;
background: #f8f8ff
}
pre .comment,
pre .template_comment,
pre .diff .header,
pre .javadoc {
color: #998;
font-style: italic
}
pre .keyword,
pre .css .rule .keyword,
pre .winutils,
pre .javascript .title,
pre .nginx .title,
pre .subst,
pre .request,
pre .status {
color: #333;
font-weight: bold
}
pre .number,
pre .hexcolor,
pre .ruby .constant {
color: #099;
}
pre .string,
pre .tag .value,
pre .phpdoc,
pre .tex .formula {
color: #d14
}
pre .title,
pre .id {
color: #900;
font-weight: bold
}
pre .javascript .title,
pre .lisp .title,
pre .clojure .title,
pre .subst {
font-weight: normal
}
pre .class .title,
pre .haskell .type,
pre .vhdl .literal,
pre .tex .command {
color: #458;
font-weight: bold
}
pre .tag,
pre .tag .title,
pre .rules .property,
pre .django .tag .keyword {
color: #000080;
font-weight: normal
}
pre .attribute,
pre .variable,
pre .lisp .body {
color: #008080
}
pre .regexp {
color: #009926
}
pre .class {
color: #458;
font-weight: bold
}
pre .symbol,
pre .ruby .symbol .string,
pre .lisp .keyword,
pre .tex .special,
pre .prompt {
color: #990073
}
pre .built_in,
pre .lisp .title,
pre .clojure .built_in {
color: #0086b3
}
pre .preprocessor,
pre .pi,
pre .doctype,
pre .shebang,
pre .cdata {
color: #999;
font-weight: bold
}
pre .deletion {
background: #fdd
}
pre .addition {
background: #dfd
}
pre .diff .change {
background: #0086b3
}
pre .chunk {
color: #aaa
}
</style>
</head>
<body>
<h1>Belle Lab Tasks</h1>
<h2>Applcation Structure</h2>
<ul>
<li>Work on dialogs, plenty to choose from</li>
<li>A reuseable tree component for pickers</li>
<li>migrate all the navigation stuff into a navigation service</li>
<li>a scriptloading service to replace requireJs, with labJs, $script or similiar</li>
<li>reusable modal component (show in left side, right side, generic closing events etc)</li>
</ul>
<h2>Components</h2>
<ul>
<li>tabs directive</li>
<li>date picker</li>
<li>tabs property editor</li>
<li>localization strategy?<ul>
<li>localize filter: {{This is my default english value,content.area.key | localize}}</li>
<li>So, it will use the default value if there is none found for the key, and register this
value in the localize service, keys should not contain commas</li>
</ul>
</li>
</ul>
<h2>Chores</h2>
<ul>
<li>Write a test</li>
<li>Write docs</li>
<li>Automate something<ul>
<li>OSX:<ul>
<li>start webserver</li>
<li>start grunt watch</li>
<li>improve test output?</li>
<li>phantomJs?</li>
</ul>
</li>
<li>windows<ul>
<li>start webserver</li>
<li>start grunt</li>
<li>install node stuff?</li>
<li>register chrome_bin in path</li>
<li>or register phantomJS?</li>
</ul>
</li>
</ul>
</li>
</ul>
</body>
</html>

396
src/Umbraco.Web.UI.Client/docs/html/codereviewnotes.html
View File

@@ -1,198 +1,198 @@
<!DOCTYPE html>
<html>
<head>
<title>doc</title>
<style>
/*github.com style (c) Vasily Polovnyov <vast@whiteants.net>*/
pre code {
display: block; padding: 0.5em;
color: #333;
background: #f8f8ff
}
pre .comment,
pre .template_comment,
pre .diff .header,
pre .javadoc {
color: #998;
font-style: italic
}
pre .keyword,
pre .css .rule .keyword,
pre .winutils,
pre .javascript .title,
pre .nginx .title,
pre .subst,
pre .request,
pre .status {
color: #333;
font-weight: bold
}
pre .number,
pre .hexcolor,
pre .ruby .constant {
color: #099;
}
pre .string,
pre .tag .value,
pre .phpdoc,
pre .tex .formula {
color: #d14
}
pre .title,
pre .id {
color: #900;
font-weight: bold
}
pre .javascript .title,
pre .lisp .title,
pre .clojure .title,
pre .subst {
font-weight: normal
}
pre .class .title,
pre .haskell .type,
pre .vhdl .literal,
pre .tex .command {
color: #458;
font-weight: bold
}
pre .tag,
pre .tag .title,
pre .rules .property,
pre .django .tag .keyword {
color: #000080;
font-weight: normal
}
pre .attribute,
pre .variable,
pre .lisp .body {
color: #008080
}
pre .regexp {
color: #009926
}
pre .class {
color: #458;
font-weight: bold
}
pre .symbol,
pre .ruby .symbol .string,
pre .lisp .keyword,
pre .tex .special,
pre .prompt {
color: #990073
}
pre .built_in,
pre .lisp .title,
pre .clojure .built_in {
color: #0086b3
}
pre .preprocessor,
pre .pi,
pre .doctype,
pre .shebang,
pre .cdata {
color: #999;
font-weight: bold
}
pre .deletion {
background: #fdd
}
pre .addition {
background: #dfd
}
pre .diff .change {
background: #0086b3
}
pre .chunk {
color: #aaa
}
</style>
</head>
<body>
<h1>Codereview with Peter Bacon Darwin</h1>
<h2>Office at cogworks:</h2>
<p>71-75 Shelton Street
London
WC2H 9JQ</p>
<p>Meeting room 11 - 17</p>
<h2>Issues to go through:</h2>
<h3>Structure, dependencies and external libraries</h3>
<ul>
<li>review of modules structure and suggestions on how to handle loading things when needed.</li>
<li><p>replace requireJs for dependency loading, so we dont have to load tinyMCE, googlemaps, etc
on app start $script, yepNope, labjs?</p>
</li>
<li><p>get the app to load .aspx pages in an iframe instead of a &quot;normal&quot; view</p>
<ul>
<li>write directive for loading templates to replace ng-include</li>
<li>if .aspx, load in iframe, </li>
<li>if not found try default, finally load error msg </li>
</ul>
</li>
<li>Javascript as resources from dlls? - add a scriptService to load these? - yes
merge those resources into the umbraco.app.js file </li>
</ul>
<p><a href="http://briantford.com/blog/huuuuuge-angular-apps.html">http://briantford.com/blog/huuuuuge-angular-apps.html</a></p>
<h3>Refactoring</h3>
<ul>
<li><p>Convert tree into directive, recursive, lazy-load</p>
<ul>
<li>$watchCollection $watch on the entire tree model</li>
<li>reuse the old tree plugin to inject into dom instead of into angular</li>
<li>10 levels of digest limit</li>
<li>fine for CG, bad for release</li>
</ul>
</li>
<li><p>best practices for directives, what should we convert?</p>
</li>
<li>other areas to convert?<ul>
<li>for guidelines, look at angular/bootstrap-ui</li>
<li>replace our components with ng-bootstrap or angular-strap</li>
</ul>
</li>
</ul>
<h3>Application logic</h3>
<ul>
<li>Authentication, force login, authenticate user against acccess to sections?</li>
<li>whats the best way to handle urls, routes and state management,
so the tree, sections etc, syncs with urls and the state of the application</li>
<li>tinyMCE directive angular-ui </li>
<li>How to handle file-uploads<ul>
<li>through a service?</li>
<li>ng-upload? or jquery-upload-plugin thingy?</li>
</ul>
</li>
<li>validation, ng-form $valid and directives should be enough<ul>
<li>add remote directive: angular-app/admin/users/user-edit.js for directive code</li>
</ul>
</li>
</ul>
<h3>Dev experience</h3>
<ul>
<li><p>H Way to handle templates with missing controller? -&gt; replace ng-include? &lt;- yup
angular-app/samples/directives/fielddirective for code</p>
<ul>
<li>H generel exception handling with feedback to log or notifications service</li>
<li>L jslint code on the server?<br> <a href="http://madskristensen.net/post/Verify-JavaScript-syntax-using-C.aspx">http://madskristensen.net/post/Verify-JavaScript-syntax-using-C.aspx</a></li>
<li>L automated setup of node, grunt, jasmine and karma, powershell and .sh? </li>
</ul>
</li>
</ul>
<h3>Testing</h3>
<ul>
<li>Best way to test against service data, simply mock data in memory, or better way?</li>
<li>Testing dom manipulating components, like modals</li>
<li>e2e testing</li>
<li>teamcity intergration</li>
<li>testing templates</li>
</ul>
<h1>Notes</h1>
<ul>
<li>Javascript as resources? - add a scriptService to load these? nope, they will compile into umbraco.app.js</li>
<li>capture errors with javascript code, to not load it into the combined files
(serverside jsLint) - mads blogpost for compiling js</li>
</ul>
</body>
</html>
<!DOCTYPE html>
<html>
<head>
<title>doc</title>
<style>
/*github.com style (c) Vasily Polovnyov <vast@whiteants.net>*/
pre code {
display: block; padding: 0.5em;
color: #333;
background: #f8f8ff
}
pre .comment,
pre .template_comment,
pre .diff .header,
pre .javadoc {
color: #998;
font-style: italic
}
pre .keyword,
pre .css .rule .keyword,
pre .winutils,
pre .javascript .title,
pre .nginx .title,
pre .subst,
pre .request,
pre .status {
color: #333;
font-weight: bold
}
pre .number,
pre .hexcolor,
pre .ruby .constant {
color: #099;
}
pre .string,
pre .tag .value,
pre .phpdoc,
pre .tex .formula {
color: #d14
}
pre .title,
pre .id {
color: #900;
font-weight: bold
}
pre .javascript .title,
pre .lisp .title,
pre .clojure .title,
pre .subst {
font-weight: normal
}
pre .class .title,
pre .haskell .type,
pre .vhdl .literal,
pre .tex .command {
color: #458;
font-weight: bold
}
pre .tag,
pre .tag .title,
pre .rules .property,
pre .django .tag .keyword {
color: #000080;
font-weight: normal
}
pre .attribute,
pre .variable,
pre .lisp .body {
color: #008080
}
pre .regexp {
color: #009926
}
pre .class {
color: #458;
font-weight: bold
}
pre .symbol,
pre .ruby .symbol .string,
pre .lisp .keyword,
pre .tex .special,
pre .prompt {
color: #990073
}
pre .built_in,
pre .lisp .title,
pre .clojure .built_in {
color: #0086b3
}
pre .preprocessor,
pre .pi,
pre .doctype,
pre .shebang,
pre .cdata {
color: #999;
font-weight: bold
}
pre .deletion {
background: #fdd
}
pre .addition {
background: #dfd
}
pre .diff .change {
background: #0086b3
}
pre .chunk {
color: #aaa
}
</style>
</head>
<body>
<h1>Codereview with Peter Bacon Darwin</h1>
<h2>Office at cogworks:</h2>
<p>71-75 Shelton Street
London
WC2H 9JQ</p>
<p>Meeting room 11 - 17</p>
<h2>Issues to go through:</h2>
<h3>Structure, dependencies and external libraries</h3>
<ul>
<li>review of modules structure and suggestions on how to handle loading things when needed.</li>
<li><p>replace requireJs for dependency loading, so we dont have to load tinyMCE, googlemaps, etc
on app start $script, yepNope, labjs?</p>
</li>
<li><p>get the app to load .aspx pages in an iframe instead of a &quot;normal&quot; view</p>
<ul>
<li>write directive for loading templates to replace ng-include</li>
<li>if .aspx, load in iframe, </li>
<li>if not found try default, finally load error msg </li>
</ul>
</li>
<li>Javascript as resources from dlls? - add a scriptService to load these? - yes
merge those resources into the umbraco.app.js file </li>
</ul>
<p><a href="http://briantford.com/blog/huuuuuge-angular-apps.html">http://briantford.com/blog/huuuuuge-angular-apps.html</a></p>
<h3>Refactoring</h3>
<ul>
<li><p>Convert tree into directive, recursive, lazy-load</p>
<ul>
<li>$watchCollection $watch on the entire tree model</li>
<li>reuse the old tree plugin to inject into dom instead of into angular</li>
<li>10 levels of digest limit</li>
<li>fine for CG, bad for release</li>
</ul>
</li>
<li><p>best practices for directives, what should we convert?</p>
</li>
<li>other areas to convert?<ul>
<li>for guidelines, look at angular/bootstrap-ui</li>
<li>replace our components with ng-bootstrap or angular-strap</li>
</ul>
</li>
</ul>
<h3>Application logic</h3>
<ul>
<li>Authentication, force login, authenticate user against acccess to sections?</li>
<li>whats the best way to handle urls, routes and state management,
so the tree, sections etc, syncs with urls and the state of the application</li>
<li>tinyMCE directive angular-ui </li>
<li>How to handle file-uploads<ul>
<li>through a service?</li>
<li>ng-upload? or jquery-upload-plugin thingy?</li>
</ul>
</li>
<li>validation, ng-form $valid and directives should be enough<ul>
<li>add remote directive: angular-app/admin/users/user-edit.js for directive code</li>
</ul>
</li>
</ul>
<h3>Dev experience</h3>
<ul>
<li><p>H Way to handle templates with missing controller? -&gt; replace ng-include? &lt;- yup
angular-app/samples/directives/fielddirective for code</p>
<ul>
<li>H generel exception handling with feedback to log or notifications service</li>
<li>L jslint code on the server?<br> <a href="http://madskristensen.net/post/Verify-JavaScript-syntax-using-C.aspx">http://madskristensen.net/post/Verify-JavaScript-syntax-using-C.aspx</a></li>
<li>L automated setup of node, grunt, jasmine and karma, powershell and .sh? </li>
</ul>
</li>
</ul>
<h3>Testing</h3>
<ul>
<li>Best way to test against service data, simply mock data in memory, or better way?</li>
<li>Testing dom manipulating components, like modals</li>
<li>e2e testing</li>
<li>teamcity intergration</li>
<li>testing templates</li>
</ul>
<h1>Notes</h1>
<ul>
<li>Javascript as resources? - add a scriptService to load these? nope, they will compile into umbraco.app.js</li>
<li>capture errors with javascript code, to not load it into the combined files
(serverside jsLint) - mads blogpost for compiling js</li>
</ul>
</body>
</html>

294
src/Umbraco.Web.UI.Client/docs/html/readme.html
View File

@@ -1,147 +1,147 @@
<!DOCTYPE html>
<html>
<head>
<title>doc</title>
<style>
/*github.com style (c) Vasily Polovnyov <vast@whiteants.net>*/
pre code {
display: block; padding: 0.5em;
color: #333;
background: #f8f8ff
}
pre .comment,
pre .template_comment,
pre .diff .header,
pre .javadoc {
color: #998;
font-style: italic
}
pre .keyword,
pre .css .rule .keyword,
pre .winutils,
pre .javascript .title,
pre .nginx .title,
pre .subst,
pre .request,
pre .status {
color: #333;
font-weight: bold
}
pre .number,
pre .hexcolor,
pre .ruby .constant {
color: #099;
}
pre .string,
pre .tag .value,
pre .phpdoc,
pre .tex .formula {
color: #d14
}
pre .title,
pre .id {
color: #900;
font-weight: bold
}
pre .javascript .title,
pre .lisp .title,
pre .clojure .title,
pre .subst {
font-weight: normal
}
pre .class .title,
pre .haskell .type,
pre .vhdl .literal,
pre .tex .command {
color: #458;
font-weight: bold
}
pre .tag,
pre .tag .title,
pre .rules .property,
pre .django .tag .keyword {
color: #000080;
font-weight: normal
}
pre .attribute,
pre .variable,
pre .lisp .body {
color: #008080
}
pre .regexp {
color: #009926
}
pre .class {
color: #458;
font-weight: bold
}
pre .symbol,
pre .ruby .symbol .string,
pre .lisp .keyword,
pre .tex .special,
pre .prompt {
color: #990073
}
pre .built_in,
pre .lisp .title,
pre .clojure .built_in {
color: #0086b3
}
pre .preprocessor,
pre .pi,
pre .doctype,
pre .shebang,
pre .cdata {
color: #999;
font-weight: bold
}
pre .deletion {
background: #fdd
}
pre .addition {
background: #dfd
}
pre .diff .change {
background: #0086b3
}
pre .chunk {
color: #aaa
}
</style>
</head>
<body>
<h1>Getting up and running with Belle</h1>
<p><em>The super fast introduction to getting belle running on your local machine, both as a pre-built environment, and with the full setup with unit-tests, grunt-tasks and node.</em></p>
<h2>Running the prebuilt site</h2>
<h3>Windows</h3>
<p>Right-click the <code>/build</code> folder and choose &quot;open in webmatrix&quot;, run the website in webmatrix and browse to <code>localhost:9999/Belle/</code>, this should display the Belle login screen</p>
<p><em>Port 9999 should be used because that is the target site that the grunt build command mentioned below will launch</em></p>
<h3>OSX</h3>
<p>Open a terminal inside the &quot;/build&quot; folder and run the command:</p>
<pre><code>python -m SimpleHTTPServer 9999</code></pre>
<p>This will start a local webserver, hosting the site on <code>localhost:9999</code> browse to localhost:9999/Belle/ which should display the belle login screen.</p>
<h2>Uing the dev environment</h2>
<p><em>The dev environment is tad more tricky to get running, since it depends on a number of unit tests and automated tools, to produce the contents of the /build folder</em></p>
<p><em>The dev environment is cross platform, so will work on both osx and windows, and do not currently have any dependencies to .net</em></p>
<h3>Install node.js</h3>
<p>We need node to run tests and automated less compiling and other automated tasks. go to <a href="http://nodejs.org">http://nodejs.org</a>. Node.js is a powerfull javascript engine, which allows us to run all our tests and tasks written in javascript locally.</p>
<p><em>note:</em> On windows you might need to restart explorer.exe to register node.</p>
<h3>Install dependencies</h3>
<p>Next we need to install all the required packages. This is done with the package tool, included with node.js, open /Umbraco.Belle.Client in cmd.exe or osx terminal and run the command:</p>
<pre><code>npm install</code></pre>
<p>this will fetch all needed packages to your local machine.</p>
<h3>Install grunt globally</h3>
<p>Grunt is a task runner for node.js, and we use it for all automated tasks in the build process. For convenience we need to install it globally on your machine, so it can be used directly in cmd.exe or the terminal.</p>
<p>So run the command:</p>
<pre><code>npm install grunt-cli -g</code></pre>
<p><em>note:</em> On windows you might need to restart explorer.exe to register the grunt cmd.</p>
<p><em>note:</em> On OSX you might need to run:</p>
<pre><code>sudo npm install grunt-cli -g</code></pre>
<p>Now that you have node and grunt installed, you can open <code>/Umbraco.Belle.Client</code> in either <code>cmd.exe</code> or terminal and run: </p>
<pre><code>grunt dev</code></pre>
<p>This will build the site, merge less files, run tests and create the /Build folder, launch the web browser and monitor changes.</p>
<h3>Automated builds and tests</h3>
<p>grunt dev will continue to run in the background monitoring changes to files. When changes are detected it will rebuild the JS and also run the unit tests.</p>
</body>
</html>
<!DOCTYPE html>
<html>
<head>
<title>doc</title>
<style>
/*github.com style (c) Vasily Polovnyov <vast@whiteants.net>*/
pre code {
display: block; padding: 0.5em;
color: #333;
background: #f8f8ff
}
pre .comment,
pre .template_comment,
pre .diff .header,
pre .javadoc {
color: #998;
font-style: italic
}
pre .keyword,
pre .css .rule .keyword,
pre .winutils,
pre .javascript .title,
pre .nginx .title,
pre .subst,
pre .request,
pre .status {
color: #333;
font-weight: bold
}
pre .number,
pre .hexcolor,
pre .ruby .constant {
color: #099;
}
pre .string,
pre .tag .value,
pre .phpdoc,
pre .tex .formula {
color: #d14
}
pre .title,
pre .id {
color: #900;
font-weight: bold
}
pre .javascript .title,
pre .lisp .title,
pre .clojure .title,
pre .subst {
font-weight: normal
}
pre .class .title,
pre .haskell .type,
pre .vhdl .literal,
pre .tex .command {
color: #458;
font-weight: bold
}
pre .tag,
pre .tag .title,
pre .rules .property,
pre .django .tag .keyword {
color: #000080;
font-weight: normal
}
pre .attribute,
pre .variable,
pre .lisp .body {
color: #008080
}
pre .regexp {
color: #009926
}
pre .class {
color: #458;
font-weight: bold
}
pre .symbol,
pre .ruby .symbol .string,
pre .lisp .keyword,
pre .tex .special,
pre .prompt {
color: #990073
}
pre .built_in,
pre .lisp .title,
pre .clojure .built_in {
color: #0086b3
}
pre .preprocessor,
pre .pi,
pre .doctype,
pre .shebang,
pre .cdata {
color: #999;
font-weight: bold
}
pre .deletion {
background: #fdd
}
pre .addition {
background: #dfd
}
pre .diff .change {
background: #0086b3
}
pre .chunk {
color: #aaa
}
</style>
</head>
<body>
<h1>Getting up and running with Belle</h1>
<p><em>The super fast introduction to getting belle running on your local machine, both as a pre-built environment, and with the full setup with unit-tests, grunt-tasks and node.</em></p>
<h2>Running the prebuilt site</h2>
<h3>Windows</h3>
<p>Right-click the <code>/build</code> folder and choose &quot;open in webmatrix&quot;, run the website in webmatrix and browse to <code>localhost:9999/Belle/</code>, this should display the Belle login screen</p>
<p><em>Port 9999 should be used because that is the target site that the grunt build command mentioned below will launch</em></p>
<h3>OSX</h3>
<p>Open a terminal inside the &quot;/build&quot; folder and run the command:</p>
<pre><code>python -m SimpleHTTPServer 9999</code></pre>
<p>This will start a local webserver, hosting the site on <code>localhost:9999</code> browse to localhost:9999/Belle/ which should display the belle login screen.</p>
<h2>Uing the dev environment</h2>
<p><em>The dev environment is tad more tricky to get running, since it depends on a number of unit tests and automated tools, to produce the contents of the /build folder</em></p>
<p><em>The dev environment is cross platform, so will work on both osx and windows, and do not currently have any dependencies to .net</em></p>
<h3>Install node.js</h3>
<p>We need node to run tests and automated less compiling and other automated tasks. go to <a href="http://nodejs.org">http://nodejs.org</a>. Node.js is a powerfull javascript engine, which allows us to run all our tests and tasks written in javascript locally.</p>
<p><em>note:</em> On windows you might need to restart explorer.exe to register node.</p>
<h3>Install dependencies</h3>
<p>Next we need to install all the required packages. This is done with the package tool, included with node.js, open /Umbraco.Belle.Client in cmd.exe or osx terminal and run the command:</p>
<pre><code>npm install</code></pre>
<p>this will fetch all needed packages to your local machine.</p>
<h3>Install grunt globally</h3>
<p>Grunt is a task runner for node.js, and we use it for all automated tasks in the build process. For convenience we need to install it globally on your machine, so it can be used directly in cmd.exe or the terminal.</p>
<p>So run the command:</p>
<pre><code>npm install grunt-cli -g</code></pre>
<p><em>note:</em> On windows you might need to restart explorer.exe to register the grunt cmd.</p>
<p><em>note:</em> On OSX you might need to run:</p>
<pre><code>sudo npm install grunt-cli -g</code></pre>
<p>Now that you have node and grunt installed, you can open <code>/Umbraco.Belle.Client</code> in either <code>cmd.exe</code> or terminal and run: </p>
<pre><code>grunt dev</code></pre>
<p>This will build the site, merge less files, run tests and create the /Build folder, launch the web browser and monitor changes.</p>
<h3>Automated builds and tests</h3>
<p>grunt dev will continue to run in the background monitoring changes to files. When changes are detected it will rebuild the JS and also run the unit tests.</p>
</body>
</html>

352
src/Umbraco.Web.UI.Client/docs/html/todo.html
View File

@@ -1,176 +1,176 @@
<!DOCTYPE html>
<html>
<head>
<title>doc</title>
<style>
/*github.com style (c) Vasily Polovnyov <vast@whiteants.net>*/
pre code {
display: block; padding: 0.5em;
color: #333;
background: #f8f8ff
}
pre .comment,
pre .template_comment,
pre .diff .header,
pre .javadoc {
color: #998;
font-style: italic
}
pre .keyword,
pre .css .rule .keyword,
pre .winutils,
pre .javascript .title,
pre .nginx .title,
pre .subst,
pre .request,
pre .status {
color: #333;
font-weight: bold
}
pre .number,
pre .hexcolor,
pre .ruby .constant {
color: #099;
}
pre .string,
pre .tag .value,
pre .phpdoc,
pre .tex .formula {
color: #d14
}
pre .title,
pre .id {
color: #900;
font-weight: bold
}
pre .javascript .title,
pre .lisp .title,
pre .clojure .title,
pre .subst {
font-weight: normal
}
pre .class .title,
pre .haskell .type,
pre .vhdl .literal,
pre .tex .command {
color: #458;
font-weight: bold
}
pre .tag,
pre .tag .title,
pre .rules .property,
pre .django .tag .keyword {
color: #000080;
font-weight: normal
}
pre .attribute,
pre .variable,
pre .lisp .body {
color: #008080
}
pre .regexp {
color: #009926
}
pre .class {
color: #458;
font-weight: bold
}
pre .symbol,
pre .ruby .symbol .string,
pre .lisp .keyword,
pre .tex .special,
pre .prompt {
color: #990073
}
pre .built_in,
pre .lisp .title,
pre .clojure .built_in {
color: #0086b3
}
pre .preprocessor,
pre .pi,
pre .doctype,
pre .shebang,
pre .cdata {
color: #999;
font-weight: bold
}
pre .deletion {
background: #fdd
}
pre .addition {
background: #dfd
}
pre .diff .change {
background: #0086b3
}
pre .chunk {
color: #aaa
}
</style>
</head>
<body>
<h1>Things to do</h1>
<h2>Structure</h2>
<ul>
<li>One module pr file idea, instead of registering everything on app.js</li>
<li><p>Have core services, resources and other common items under umbraco</p>
</li>
<li><p>third party modules outside of the root umbraco module, but registered in app.js</p>
</li>
<li><p>to access 3rd party service:
ecomEditor.controller.js
angular.module(&quot;umbraco.myeditor&quot;, [&quot;ecommerce.services&quot;]).controller(&quot;ecom.editor&quot;, </p>
<pre><code> function(&quot;inventoryFactory&quot;){
do things...
});</code></pre>
</li>
<li><p>best way to setup services and controllers are:
.controller(&quot;name&quot;,[
&quot;service&quot;,
&quot;dependency&quot;,
function(s, d){</p>
<p> }
]);</p>
</li>
<li><p>move logic from controllers to services, especcially around navigation</p>
<ul>
<li>easier for testing</li>
<li>only keep view interactions, everything into a service</li>
<li>looser testing on controllers</li>
<li>for testing the dialogs, look in angular source or angular bootstrap projects</li>
</ul>
</li>
</ul>
<h2>Routing</h2>
<p>Change /section/page/id to /section/area/page/id to support all section scenarios
Have a fallback to defaults?</p>
<h2>Legacy</h2>
<ul>
<li>for UmbClientTools we can access the services in angular from
angular.element(&quot;body&quot;).injector().get(&quot;notifications&quot;);</li>
<li>rootscope available in same location</li>
<li>the bootstrap method returns the injector</li>
</ul>
<h2>ScriptLoaderService</h2>
<pre><code>- Service to load required scripts for a controller using $script
- remove requirejs dependency as it makes things muddy</code></pre>
<h2>Authentication</h2>
<p>Angular-app: common/security/interceptor.js , intercept http requests</p>
<h2>Promises</h2>
<pre><code>Use promises pattern for all our services
$http.get(url)
.then(function(response){
return response.data;
}, function(response){
return $q.reject(&quot;http failed&quot;);
}).then(function(data){
alert(&quot;our data:&quot; + data);
})</code></pre>
<h2>Think about rest services and authentication</h2>
<p>Usecase: member picker editor, which fetches member-data</p>
<h2>Avoid $resource and instead use $http</h2>
<p>Sublime linter</p>
</body>
</html>
<!DOCTYPE html>
<html>
<head>
<title>doc</title>
<style>
/*github.com style (c) Vasily Polovnyov <vast@whiteants.net>*/
pre code {
display: block; padding: 0.5em;
color: #333;
background: #f8f8ff
}
pre .comment,
pre .template_comment,
pre .diff .header,
pre .javadoc {
color: #998;
font-style: italic
}
pre .keyword,
pre .css .rule .keyword,
pre .winutils,
pre .javascript .title,
pre .nginx .title,
pre .subst,
pre .request,
pre .status {
color: #333;
font-weight: bold
}
pre .number,
pre .hexcolor,
pre .ruby .constant {
color: #099;
}
pre .string,
pre .tag .value,
pre .phpdoc,
pre .tex .formula {
color: #d14
}
pre .title,
pre .id {
color: #900;
font-weight: bold
}
pre .javascript .title,
pre .lisp .title,
pre .clojure .title,
pre .subst {
font-weight: normal
}
pre .class .title,
pre .haskell .type,
pre .vhdl .literal,
pre .tex .command {
color: #458;
font-weight: bold
}
pre .tag,
pre .tag .title,
pre .rules .property,
pre .django .tag .keyword {
color: #000080;
font-weight: normal
}
pre .attribute,
pre .variable,
pre .lisp .body {
color: #008080
}
pre .regexp {
color: #009926
}
pre .class {
color: #458;
font-weight: bold
}
pre .symbol,
pre .ruby .symbol .string,
pre .lisp .keyword,
pre .tex .special,
pre .prompt {
color: #990073
}
pre .built_in,
pre .lisp .title,
pre .clojure .built_in {
color: #0086b3
}
pre .preprocessor,
pre .pi,
pre .doctype,
pre .shebang,
pre .cdata {
color: #999;
font-weight: bold
}
pre .deletion {
background: #fdd
}
pre .addition {
background: #dfd
}
pre .diff .change {
background: #0086b3
}
pre .chunk {
color: #aaa
}
</style>
</head>
<body>
<h1>Things to do</h1>
<h2>Structure</h2>
<ul>
<li>One module pr file idea, instead of registering everything on app.js</li>
<li><p>Have core services, resources and other common items under umbraco</p>
</li>
<li><p>third party modules outside of the root umbraco module, but registered in app.js</p>
</li>
<li><p>to access 3rd party service:
ecomEditor.controller.js
angular.module(&quot;umbraco.myeditor&quot;, [&quot;ecommerce.services&quot;]).controller(&quot;ecom.editor&quot;, </p>
<pre><code> function(&quot;inventoryFactory&quot;){
do things...
});</code></pre>
</li>
<li><p>best way to setup services and controllers are:
.controller(&quot;name&quot;,[
&quot;service&quot;,
&quot;dependency&quot;,
function(s, d){</p>
<p> }
]);</p>
</li>
<li><p>move logic from controllers to services, especcially around navigation</p>
<ul>
<li>easier for testing</li>
<li>only keep view interactions, everything into a service</li>
<li>looser testing on controllers</li>
<li>for testing the dialogs, look in angular source or angular bootstrap projects</li>
</ul>
</li>
</ul>
<h2>Routing</h2>
<p>Change /section/page/id to /section/area/page/id to support all section scenarios
Have a fallback to defaults?</p>
<h2>Legacy</h2>
<ul>
<li>for UmbClientTools we can access the services in angular from
angular.element(&quot;body&quot;).injector().get(&quot;notifications&quot;);</li>
<li>rootscope available in same location</li>
<li>the bootstrap method returns the injector</li>
</ul>
<h2>ScriptLoaderService</h2>
<pre><code>- Service to load required scripts for a controller using $script
- remove requirejs dependency as it makes things muddy</code></pre>
<h2>Authentication</h2>
<p>Angular-app: common/security/interceptor.js , intercept http requests</p>
<h2>Promises</h2>
<pre><code>Use promises pattern for all our services
$http.get(url)
.then(function(response){
return response.data;
}, function(response){
return $q.reject(&quot;http failed&quot;);
}).then(function(data){
alert(&quot;our data:&quot; + data);
})</code></pre>
<h2>Think about rest services and authentication</h2>
<p>Usecase: member picker editor, which fetches member-data</p>
<h2>Avoid $resource and instead use $http</h2>
<p>Sublime linter</p>
</body>
</html>

134
src/Umbraco.Web.UI.Client/docs/src/tutorials/Adding-Configuration-To-Property-Editor.ngdoc
View File

@@ -1,67 +1,67 @@
@ngdoc overview
@name Adding configuration to a property editor
@description
##Overview
This is step 2 in our guid to building a property editor. This step continues work on the markdown editor we build in step 1, but goes further to show you how you can add configuration options to the editor.
##Configuration?
So, an important part of building good property editors, are to build something relatively flexible, so you can reuse it many many times, for different things. Like the rich text editor in Umbraco, that allows you to choose which buttons and stylesheets you want to use on each instance of the editor.
So an editor can be used several times, with different configurations, and that is what we will be working on now.
##package.manifest
So to add configuration options to our markdown editor, open the package.manifest file. rigth below the editor definition, paste in the following:
preValueEditor: {
fields: [
{
label: "Preview",
description: "Display a live preview",
key: "preview",
view: "boolean"
},
{
label: "Default value",
description: "If value is blank, the editor will show this",
key: "defaultValue",
view: "textarea"
}
]
}
**Remember to: ** seperate the editor element and prevalue editor definition with a comma, or you will get a json error.
So what did we just add? We added a prevalue editor, with a `fields` collection. This collection contains infomation about the UI we will render on the data type configuration for this editor.
So the first gets the label "Preview" and uses the view "boolean", so this will allow us to turn preview on/off and will provide the user with a simple checkbox. The name "boolean" comes from the convention that all preview editors are stored in /umbraco/views/prevalueeditors/ and then found via `<name>.html`
Same with the next one, only that it will provide the user with a textarea to input a default value for the editor.
Save the manifest **restart the app pool** and have a look at the markdown datatype in Umbraco now. You should now see that you have 2 configuration options.
##Using the configuration
The next step is to gain access to our new configuration options. For this, open the `markdowneditor.controller.js` file
Lets first add the default value functionality. So basicly when the ´$scope.model.value` is empty or undefined, we want to use the default value, to do that, we add the following to the very beginning of the controller:
if($scope.model.value === null || $scope.model.value === ""){
$scope.model.value = $scope.model.config.defaultValue;
}
You see whats new? - the `$scope.model.config` object is. And the other thing you will notice is that because of our configuration, we now have access to `$scope.model.config.defaultValue` which contains the configiration value for that key, its that easy to setup and use configuration values from code.
However, you can also use these values without any javascript, so open the `markdowneditor.html` file instead.
Because we can also use the configuration directly in our html like here, where we use it to toggle the preview `<div>`, using the ng-hide attribute:
<div ng-show="model.config.preview" class="wmd-panel wmd-preview"></div>
##Get the codes
The latest update to the markdowneditor project is on github where you can see all the files and the manifest [here](https://github.com/umbraco/Umbraco-CMS/tree/7.0.0/src/Umbraco.Web.UI.Client/src/packages/MarkdownEditor).
@ngdoc overview
@name Adding configuration to a property editor
@description
##Overview
This is step 2 in our guid to building a property editor. This step continues work on the markdown editor we build in step 1, but goes further to show you how you can add configuration options to the editor.
##Configuration?
So, an important part of building good property editors, are to build something relatively flexible, so you can reuse it many many times, for different things. Like the rich text editor in Umbraco, that allows you to choose which buttons and stylesheets you want to use on each instance of the editor.
So an editor can be used several times, with different configurations, and that is what we will be working on now.
##package.manifest
So to add configuration options to our markdown editor, open the package.manifest file. rigth below the editor definition, paste in the following:
preValueEditor: {
fields: [
{
label: "Preview",
description: "Display a live preview",
key: "preview",
view: "boolean"
},
{
label: "Default value",
description: "If value is blank, the editor will show this",
key: "defaultValue",
view: "textarea"
}
]
}
**Remember to: ** seperate the editor element and prevalue editor definition with a comma, or you will get a json error.
So what did we just add? We added a prevalue editor, with a `fields` collection. This collection contains infomation about the UI we will render on the data type configuration for this editor.
So the first gets the label "Preview" and uses the view "boolean", so this will allow us to turn preview on/off and will provide the user with a simple checkbox. The name "boolean" comes from the convention that all preview editors are stored in /umbraco/views/prevalueeditors/ and then found via `<name>.html`
Same with the next one, only that it will provide the user with a textarea to input a default value for the editor.
Save the manifest **restart the app pool** and have a look at the markdown datatype in Umbraco now. You should now see that you have 2 configuration options.
##Using the configuration
The next step is to gain access to our new configuration options. For this, open the `markdowneditor.controller.js` file
Lets first add the default value functionality. So basicly when the ´$scope.model.value` is empty or undefined, we want to use the default value, to do that, we add the following to the very beginning of the controller:
if($scope.model.value === null || $scope.model.value === ""){
$scope.model.value = $scope.model.config.defaultValue;
}
You see whats new? - the `$scope.model.config` object is. And the other thing you will notice is that because of our configuration, we now have access to `$scope.model.config.defaultValue` which contains the configiration value for that key, its that easy to setup and use configuration values from code.
However, you can also use these values without any javascript, so open the `markdowneditor.html` file instead.
Because we can also use the configuration directly in our html like here, where we use it to toggle the preview `<div>`, using the ng-hide attribute:
<div ng-show="model.config.preview" class="wmd-panel wmd-preview"></div>
##Get the codes
The latest update to the markdowneditor project is on github where you can see all the files and the manifest [here](https://github.com/umbraco/Umbraco-CMS/tree/7.0.0/src/Umbraco.Web.UI.Client/src/packages/MarkdownEditor).

210
src/Umbraco.Web.UI.Client/docs/src/tutorials/Building.ngdoc
View File

@@ -1,105 +1,105 @@
@ngdoc overview
@name Building Umbraco 7 from source
@description
##Overview
Umbraco 7 has a slightly unorthodox project structure, compared to a normal asp.net project. This is by design, and a choice from the beginning to embrace a mucher larger group then "just" the developers who know how to use Visual Studio.
As a result of that, the Umbraco UI is not a visual studio project, but simply a collection of folders and files, following certain conventions, and a small configuration file called `gruntfile` - we will get to the grunt part in a moment.
This means that anyone with a text editor can open the UI source, make changes and run the project, without having Visual Studio installed - we will get into how to do that in a moment as well.
But bottom line is that the UI project has zero dependencies on asp.net or windows, but you will need node.js installed, but don't worry we will get into that in a second.
##Prerequisites
Umbraco 7 needs a couple of things to run:
###Node.js
To compile and run the UI project you need node.js installed, you can get that at [http://nodejs.org](nodejs.org) for both windows and osx.
###Grunt
When you have node.js installed, you need to install grunt. Grunt is a simple javascript task runner, basicly like Nant, Msbuild or any traditional build system [http://gruntjs.com](more about grunt here).
To install, open a terminal and run:
npm install -g grunt-cli
For OSX users, you will most likely need to do:
sudo npm install -g grunt-cli
This installs a `grunt` command into your terminal so you can run grunt scripts with simple commands. That migth sound scary, but really isn't, for working with Umbraco 7, you will become really good friends with `grunt` and your terminal.
###Project dependencies
Now its time to install all the dependencies that the project requires to compile, debug, test, minify and so on. Luckily this is all automatic, and is done wiht the node.js package manager (which you already have installed with node)
In your terminal, browse to the `Umbraco.Web.Ui.Client` folder and run the command:
npm install
This will output a ton of feedback in your terminal, when it stops, your project is ready to run.
This might seem like a lot of stuff to do, but think of it this way, every time you setup this environment, all you have to do is run `npm install` and everything will be running smoothly.
##Running from source without Visual studio or IIS
The Umbraco 7 project includes a complete mocked data model and an embedded webserver to run off.
So to get the project up and running in a browser as fast as possible, open a terminal and browse to `Umbraco.Web.Ui.Client` folder, and run the command:
grunt dev
this will do the following:
- Compile the project files and merge them
- Compile less files to one .css file
- Lint js files for syntax and style errors
- run unit tests
- Setup a watcher to monitor for ongoing changes.
- Start a webserver on port 9999
- Open a browser to display localhost:9999/belle
This is all grunt doing that for us, and notice that it sets up a watcher, which means that every time you make a change, it will automaticly recompile and test your code, if something is wrong the terminal will tell you why.
You can now login (no user/pass) and browse the UI with dummy data, this setup is perfect for fast css and js changes that does not require any *real* data.
##Running from Visual Studio
**Note:** we will make this even easier to so the steps with node and grunt wont be required for .net developers in visual studio, but for now the below is needed:
To run from Visual Studio, simply open the solution and run the `Umbraco.Web.UI` project as a normal website project. But to get the latest Umbraco 7 files into this site you still need to open a terminal at `Umbraco.Web.Ui.Client` and run either:
grunt dev
or for a one-time build:
grunt build
This will compile all files and copy them into the appropriate folder in the VS project, if you run `grunt dev` it will also automaticly update the VS project files as you edit them.
You should never edit the /umbraco/js/umbraco.*.js files directly, these will be overwritten on each build.
##using build.bat
The Umbraco source comes with a build.bat file that runs the full build process, which is the one we use on our nightly builds, it produces a complete zip file with a ready to use distribution.
The same rules apply as with running from Visual Studio, you need to run
grunt build
Before running build.bat, then the latest UI files will be included.
##Conclusion
Having Umbraco 7 UI as a seperate project does indeed give us a bit more complexity when building and running from visual studio, since 2 build systems are in play: grunt and msbuild.
However, the alternative would be to shove everything into the msbuil process, making the entire thing inaccesible to a large number of frontend developers and with a clunkier and less uptodate system.
So see it as an additional powerfull tool in your arsenal, once you see the power, you don't want to go back.
@ngdoc overview
@name Building Umbraco 7 from source
@description
##Overview
Umbraco 7 has a slightly unorthodox project structure, compared to a normal asp.net project. This is by design, and a choice from the beginning to embrace a mucher larger group then "just" the developers who know how to use Visual Studio.
As a result of that, the Umbraco UI is not a visual studio project, but simply a collection of folders and files, following certain conventions, and a small configuration file called `gruntfile` - we will get to the grunt part in a moment.
This means that anyone with a text editor can open the UI source, make changes and run the project, without having Visual Studio installed - we will get into how to do that in a moment as well.
But bottom line is that the UI project has zero dependencies on asp.net or windows, but you will need node.js installed, but don't worry we will get into that in a second.
##Prerequisites
Umbraco 7 needs a couple of things to run:
###Node.js
To compile and run the UI project you need node.js installed, you can get that at [http://nodejs.org](nodejs.org) for both windows and osx.
###Grunt
When you have node.js installed, you need to install grunt. Grunt is a simple javascript task runner, basicly like Nant, Msbuild or any traditional build system [http://gruntjs.com](more about grunt here).
To install, open a terminal and run:
npm install -g grunt-cli
For OSX users, you will most likely need to do:
sudo npm install -g grunt-cli
This installs a `grunt` command into your terminal so you can run grunt scripts with simple commands. That migth sound scary, but really isn't, for working with Umbraco 7, you will become really good friends with `grunt` and your terminal.
###Project dependencies
Now its time to install all the dependencies that the project requires to compile, debug, test, minify and so on. Luckily this is all automatic, and is done wiht the node.js package manager (which you already have installed with node)
In your terminal, browse to the `Umbraco.Web.Ui.Client` folder and run the command:
npm install
This will output a ton of feedback in your terminal, when it stops, your project is ready to run.
This might seem like a lot of stuff to do, but think of it this way, every time you setup this environment, all you have to do is run `npm install` and everything will be running smoothly.
##Running from source without Visual studio or IIS
The Umbraco 7 project includes a complete mocked data model and an embedded webserver to run off.
So to get the project up and running in a browser as fast as possible, open a terminal and browse to `Umbraco.Web.Ui.Client` folder, and run the command:
grunt dev
this will do the following:
- Compile the project files and merge them
- Compile less files to one .css file
- Lint js files for syntax and style errors
- run unit tests
- Setup a watcher to monitor for ongoing changes.
- Start a webserver on port 9999
- Open a browser to display localhost:9999/belle
This is all grunt doing that for us, and notice that it sets up a watcher, which means that every time you make a change, it will automaticly recompile and test your code, if something is wrong the terminal will tell you why.
You can now login (no user/pass) and browse the UI with dummy data, this setup is perfect for fast css and js changes that does not require any *real* data.
##Running from Visual Studio
**Note:** we will make this even easier to so the steps with node and grunt wont be required for .net developers in visual studio, but for now the below is needed:
To run from Visual Studio, simply open the solution and run the `Umbraco.Web.UI` project as a normal website project. But to get the latest Umbraco 7 files into this site you still need to open a terminal at `Umbraco.Web.Ui.Client` and run either:
grunt dev
or for a one-time build:
grunt build
This will compile all files and copy them into the appropriate folder in the VS project, if you run `grunt dev` it will also automaticly update the VS project files as you edit them.
You should never edit the /umbraco/js/umbraco.*.js files directly, these will be overwritten on each build.
##using build.bat
The Umbraco source comes with a build.bat file that runs the full build process, which is the one we use on our nightly builds, it produces a complete zip file with a ready to use distribution.
The same rules apply as with running from Visual Studio, you need to run
grunt build
Before running build.bat, then the latest UI files will be included.
##Conclusion
Having Umbraco 7 UI as a seperate project does indeed give us a bit more complexity when building and running from visual studio, since 2 build systems are in play: grunt and msbuild.
However, the alternative would be to shove everything into the msbuil process, making the entire thing inaccesible to a large number of frontend developers and with a clunkier and less uptodate system.
So see it as an additional powerfull tool in your arsenal, once you see the power, you don't want to go back.

174
src/Umbraco.Web.UI.Client/docs/src/tutorials/Intergrating-Services-With-PropertyEditor.ngdoc
View File

@@ -1,87 +1,87 @@
@ngdoc overview
@name Integrating services with a property editor
@description
##Overview
This is step 3 in the property editor tutorial. In this part we will intergrate one of the built-in
umbraco services. For this sample we will use the dialog service to hook into the media picker and return image data to the markdown editor.
##Injecting the service.
First up, we need to get access to the service, this is done in the constructor of the controller, where we add it as a parameter:
angular.module("umbraco")
.controller("My.MarkdownEditorController",
//inject umbracos assetsServce and dialog service
function ($scope,assetsService, dialogService) { ... }
this works the same way as with the assetsService we added in step 1.
##Hooking into pagedown
The pagedown editor we are using, has a nice event system inplace, so we can easily hook into the events triggered by the media chooser, by adding a hook, after the editor has started:
//Start the editor
var converter2 = new Markdown.Converter();
var editor2 = new Markdown.Editor(converter2, "-" + $scope.model.alias);
editor2.run();
//subscribe to the image dialog clicks
editor2.hooks.set("insertImageDialog", function (callback) {
//here we can intercept our own dialog handling
return true; // tell the editor that we'll take care of getting the image url
});
});
Notice the callback, this callback is used to return whatever data we want to editor.
So now that we have access to the editor events, we will trigger a media picker dialog, by using the `dialogService`. You can inject whatever html you want with this service, but it also has a number of shorthands for things like a media picker:
//the callback is called when the use selects images
dialogService.mediaPicker({callback: function(data){
//data.selection contains an array of images
$(data.selection).each(function(i, item){
//try using $log.log(item) to see what this data contains
});
}});
##Getting to the image data
Because of Umbraco's generic nature, you don't always know where your image is, as a media object's data is basicly an array of properies, so how do you pick the right one? - you cannot always be sure the property is called `umbracoFile` for instance.
For cases like this, a helper service is available: `imageHelper`. This utillity has usefull methods for getting to images embedded in property data, as well as associated thumbnails. **Remember to** inject this imageHelper in the controller constructor as well (same place as dialogService and assetsService).
So we get the image page from the selected media item, and return it through the callback:
var imagePropVal = imageHelper.getImagePropertyVaue({ imageModel: item, scope: $scope });
callback(imagePropVal);
Now when we run the markdown editor and click the image button, we are presented with a native umbraco dialog, listing the standard media archive.
Clicking an image and choosing select returns the image to the editor which then renders it as:
![Koala picture][1]
[1]: /media/1005/Koala.jpg
The above is correct markdown code, representing the image, and if preview is turned on, you will see the image below the editor.
##Wrap up
So over the 3 previous steps, we've:
- created a plugin
- defined an editor
- injected our own javascript libraries and 3rd party ones
- made the editor configurable
- connected the editor with native dialogs and services
- looked at koala pictures.
The complete project can be found [here](https://github.com/umbraco/Umbraco-CMS/tree/7.0.0/src/Umbraco.Web.UI.Client/src/packages/MarkdownEditor).
@ngdoc overview
@name Integrating services with a property editor
@description
##Overview
This is step 3 in the property editor tutorial. In this part we will intergrate one of the built-in
umbraco services. For this sample we will use the dialog service to hook into the media picker and return image data to the markdown editor.
##Injecting the service.
First up, we need to get access to the service, this is done in the constructor of the controller, where we add it as a parameter:
angular.module("umbraco")
.controller("My.MarkdownEditorController",
//inject umbracos assetsServce and dialog service
function ($scope,assetsService, dialogService) { ... }
this works the same way as with the assetsService we added in step 1.
##Hooking into pagedown
The pagedown editor we are using, has a nice event system inplace, so we can easily hook into the events triggered by the media chooser, by adding a hook, after the editor has started:
//Start the editor
var converter2 = new Markdown.Converter();
var editor2 = new Markdown.Editor(converter2, "-" + $scope.model.alias);
editor2.run();
//subscribe to the image dialog clicks
editor2.hooks.set("insertImageDialog", function (callback) {
//here we can intercept our own dialog handling
return true; // tell the editor that we'll take care of getting the image url
});
});
Notice the callback, this callback is used to return whatever data we want to editor.
So now that we have access to the editor events, we will trigger a media picker dialog, by using the `dialogService`. You can inject whatever html you want with this service, but it also has a number of shorthands for things like a media picker:
//the callback is called when the use selects images
dialogService.mediaPicker({callback: function(data){
//data.selection contains an array of images
$(data.selection).each(function(i, item){
//try using $log.log(item) to see what this data contains
});
}});
##Getting to the image data
Because of Umbraco's generic nature, you don't always know where your image is, as a media object's data is basicly an array of properies, so how do you pick the right one? - you cannot always be sure the property is called `umbracoFile` for instance.
For cases like this, a helper service is available: `imageHelper`. This utillity has usefull methods for getting to images embedded in property data, as well as associated thumbnails. **Remember to** inject this imageHelper in the controller constructor as well (same place as dialogService and assetsService).
So we get the image page from the selected media item, and return it through the callback:
var imagePropVal = imageHelper.getImagePropertyVaue({ imageModel: item, scope: $scope });
callback(imagePropVal);
Now when we run the markdown editor and click the image button, we are presented with a native umbraco dialog, listing the standard media archive.
Clicking an image and choosing select returns the image to the editor which then renders it as:
![Koala picture][1]
[1]: /media/1005/Koala.jpg
The above is correct markdown code, representing the image, and if preview is turned on, you will see the image below the editor.
##Wrap up
So over the 3 previous steps, we've:
- created a plugin
- defined an editor
- injected our own javascript libraries and 3rd party ones
- made the editor configurable
- connected the editor with native dialogs and services
- looked at koala pictures.
The complete project can be found [here](https://github.com/umbraco/Umbraco-CMS/tree/7.0.0/src/Umbraco.Web.UI.Client/src/packages/MarkdownEditor).

62
src/Umbraco.Web.UI.Client/docs/src/tutorials/Running.ngdoc
View File

@@ -1,31 +1,31 @@
@ngdoc overview
@name Running Umbraco 7
@description
##Overview
This document explains how you can run Umbraco from one of our nightly builds on Windows.
You must have either IIS, IISExpress and/or WebMatrix installed
##Getting the build
Our buildserver runs every morning at 9 danish time, and each day it produces 3 zip files with the latest changes compiled and ready to run.
The umbraco 7 nightly builds can be downloaded from [http://nightly.umbraco.org/umbraco%207.0.0/](nightly.umbraco.org)
As you can see, there are different types of builds:
- UmbracoCms.7.0.0-build.##.zip
- UmbracoCms.AllBinaries.7.0.0.build.##.zip
- UmbracoCms.WebPi.7.0.0.build.##.zip
The first one contains the full website, ready to run in IIS, the AllBinaries one only contains the comiled .dll's and finally WebPi is for installing through microsoft platform installer.
You should download the latest of the first kind.
##Unzipping and installing
When downloaded, *Remember* to right-click the file, choose properties and select *Unblock file*
UnZip and setup IIS/IISExpress to run the site from this folder, or if you have webmatrix installed, right click it and choose "run as website from webmatrix"
During install, you can choose between Sql Server and Sql CE, both versions work, with CE being perfectly fine for local developement on machines where you dont want to bother with SQL Server.
@ngdoc overview
@name Running Umbraco 7
@description
##Overview
This document explains how you can run Umbraco from one of our nightly builds on Windows.
You must have either IIS, IISExpress and/or WebMatrix installed
##Getting the build
Our buildserver runs every morning at 9 danish time, and each day it produces 3 zip files with the latest changes compiled and ready to run.
The umbraco 7 nightly builds can be downloaded from [http://nightly.umbraco.org/umbraco%207.0.0/](nightly.umbraco.org)
As you can see, there are different types of builds:
- UmbracoCms.7.0.0-build.##.zip
- UmbracoCms.AllBinaries.7.0.0.build.##.zip
- UmbracoCms.WebPi.7.0.0.build.##.zip
The first one contains the full website, ready to run in IIS, the AllBinaries one only contains the comiled .dll's and finally WebPi is for installing through microsoft platform installer.
You should download the latest of the first kind.
##Unzipping and installing
When downloaded, *Remember* to right-click the file, choose properties and select *Unblock file*
UnZip and setup IIS/IISExpress to run the site from this folder, or if you have webmatrix installed, right click it and choose "run as website from webmatrix"
During install, you can choose between Sql Server and Sql CE, both versions work, with CE being perfectly fine for local developement on machines where you dont want to bother with SQL Server.

156
src/Umbraco.Web.UI.Client/docs/src/tutorials/Source-Code-Structure.ngdoc
View File

@@ -1,78 +1,78 @@
@ngdoc overview
@name Source code structure
@description
##Overview
This document outlines where the different files in the Umbraco 7 source code is.
The Client-side part of Umbraco 7 is located in the project folder: `Umbraco.Web.Ui.Client
##Root folders
The folders found in the root of the client-side project and what they contain:
*/Assets*
This folder contains various client-side assets, most of them are obsolete by now and will over time be merged into the source
*/Build*
The folder containing the compiled and minified bits outputted by grunt
*/Docs*
Automated documentation files by ngdoc project from inline comments in source files as well as from .ngdoc files in /docs/src/
*/Lib*
Folder containing all 3rd party dependencies used by the Umbraco web application
*/node_modules*
Dependencies used by node and grunt to build the project
*/src*
The source code of Umbraco 7 UI
*/test*
Test configuration and test files used by the karma testrunner to unit-test the project.
##Source folders
Inside the /src folder, the Umbraco 7 source code is devided into 3 groups of code:
- Less files
- Common / shared javascript
- Views
###Less files
Everything is loaded into the belle.less which specifies what files to include, the variables.less contains global variabls
###/Views
The Views folder contains all the html for the application as well as the Controllers used on those views. The convention for views and controllers are:
- /views/section/Viewname.html
- /views/section/section.viewname.controller.js
So if you are looking for the html and javascript used by the content editor look in /src/views/content/edit.html and `/src/vies/content/content.edit.controller.js`
###/Common
The Common folder contains all the items that are share between multiple parts of the application, such as Services, Directives and Filters.
So if you want to access the navigationService look in `/src/common/services/navigation.service.js`
For the Umbraco 7 application, we also have introduce the concept of a `Resource`, this term is used for a shared service which primarily is used to access data from the database and perform crud operations on this data.
Example resources could be:
- /src/common/resources/media.resource.js
- /src/common/resources/entity.resource.js
All resources returns a promise when data is fetched, they use the same pattern for errors and generally require a http backend to work.
On our serverless setup, we use a mocked http backend to simulate data.
###Packages
Folder containing various sample projects on how to use the external api, good for referencing how the package.manifest and property editors work.
###App.js and app.dev.js
The central application script, which handles what modules to inject, app.js is for production, app.dev.js is for testing
###loader.js
yepnope.js based loader for async loading javascript files, this file specifies what files to load on application start
###routes.js
Routing setup for /umbraco/ pages, by default it contains a mvc-like convention based pattern, which means that we not very often need to modify this.
@ngdoc overview
@name Source code structure
@description
##Overview
This document outlines where the different files in the Umbraco 7 source code is.
The Client-side part of Umbraco 7 is located in the project folder: `Umbraco.Web.Ui.Client
##Root folders
The folders found in the root of the client-side project and what they contain:
*/Assets*
This folder contains various client-side assets, most of them are obsolete by now and will over time be merged into the source
*/Build*
The folder containing the compiled and minified bits outputted by grunt
*/Docs*
Automated documentation files by ngdoc project from inline comments in source files as well as from .ngdoc files in /docs/src/
*/Lib*
Folder containing all 3rd party dependencies used by the Umbraco web application
*/node_modules*
Dependencies used by node and grunt to build the project
*/src*
The source code of Umbraco 7 UI
*/test*
Test configuration and test files used by the karma testrunner to unit-test the project.
##Source folders
Inside the /src folder, the Umbraco 7 source code is devided into 3 groups of code:
- Less files
- Common / shared javascript
- Views
###Less files
Everything is loaded into the belle.less which specifies what files to include, the variables.less contains global variabls
###/Views
The Views folder contains all the html for the application as well as the Controllers used on those views. The convention for views and controllers are:
- /views/section/Viewname.html
- /views/section/section.viewname.controller.js
So if you are looking for the html and javascript used by the content editor look in /src/views/content/edit.html and `/src/vies/content/content.edit.controller.js`
###/Common
The Common folder contains all the items that are share between multiple parts of the application, such as Services, Directives and Filters.
So if you want to access the navigationService look in `/src/common/services/navigation.service.js`
For the Umbraco 7 application, we also have introduce the concept of a `Resource`, this term is used for a shared service which primarily is used to access data from the database and perform crud operations on this data.
Example resources could be:
- /src/common/resources/media.resource.js
- /src/common/resources/entity.resource.js
All resources returns a promise when data is fetched, they use the same pattern for errors and generally require a http backend to work.
On our serverless setup, we use a mocked http backend to simulate data.
###Packages
Folder containing various sample projects on how to use the external api, good for referencing how the package.manifest and property editors work.
###App.js and app.dev.js
The central application script, which handles what modules to inject, app.js is for production, app.dev.js is for testing
###loader.js
yepnope.js based loader for async loading javascript files, this file specifies what files to load on application start
###routes.js
Routing setup for /umbraco/ pages, by default it contains a mvc-like convention based pattern, which means that we not very often need to modify this.

168
src/Umbraco.Web.UI.Client/docs/src/tutorials/Test-Driven-DevFlow.ngdoc
View File

@@ -1,84 +1,84 @@
@ngdoc overview
@name Test-driven developement flow
@description
##Overview
_This document tries to outline what is required to have a test-driven setup for
angular developement in Umbraco 7. It goes through the setup process as well as how
to add new services that requires mocking as well as how to use grunt to run tests automaticly._
##Setup
Make sure to have all the node dependencies in order when you start, these are updated regularly in case we need to go to a new version of a dependency, or new dependencies are added.
Simply run open a terminal / cmd in the Umbraco.Web.Ui.Client folder and run:
npm install
This should setup the entire grunt,karma and jsint setup we use for tests and pruning.
##Automated testing
To start working on the client files, and have them automaticly built and merged into the client project, as well as the VS project, simply run the command
grunt dev
This will start a webserver on :8080 and tell karma to run tests every time a .js or .less file is changed.
After linting and tests have passed, all the client files are copied to umrbaco.web.ui/umbraco folder, so it also keeps the server project uptodate on any client changes. This should all happen in the background.
##Adding a new service
The process for adding or modifying a service should always be based on passed tests. So if we need to change the footprint of the contentservice, and the way any controller calls this service, we need to make sure the tests passes with our mocked services.
This ensures 3 things:
- we test our controllers
- we test our services
- we always have mocked data available, if you want to run the client without IIS
###Example:
We add a service for fetching macros from the database, the initial implementation should happen of this service should happen in `/src/common/resources/macro.resource.js`
The macro.resource.js calls `$http` as normal, but no server implementation should be needed at this point.
Next, we describe how the rest service should return data, this is done in /common/mocks/umbraco.httpbackend.js, where we can define what data a certain url
would return.
So in the case of getting tree items we define:
$httpBackend
.whenGET( urlRegex('/umbraco/UmbracoTrees/ApplicationTreeApi/GetApplicationTrees') )
.respond(returnApplicationTrees);
The `returnApplicationTrees` function then looks like this:
function returnApplicationTrees(status, data, headers){
var app = getParameterByName(data, "application");
var tree = _backendData.tree.getApplication(app);
return [200, tree, null];
}
It returns an array of 3 items, the http status code, the expected data, and finally it can return a collection of http headers.
_backendData.tree.getApplication(app);
Refers to a helper method in `umbraco.httpbackend.helper.js` which contains all the helper methods we
use to return static json.
###In short
So to add a service, which requires data from the server we should:
- add the .service.js as normal
- add the .resource.js as normal
- call $http as normal
- define the response data in umbraco.httpbackend.helper.js
- define the url in umbraco.httpbackend.js
###ServerVariables
There is a static servervariables file in /mocks which describes the urls used by the rest service, this is currently needed as we dont have this set as a angular service, and no real conventions for these urls yet. Longer-term it would be great to have a urlBuilder which could do
urlService.url("contentTypes", "GetAllowedChildren");
//would return /<umbracodir>/<apibaseDir>/contentyTypes/getAllowedChildren
But for now, they are set in the servervariables file.
@ngdoc overview
@name Test-driven developement flow
@description
##Overview
_This document tries to outline what is required to have a test-driven setup for
angular developement in Umbraco 7. It goes through the setup process as well as how
to add new services that requires mocking as well as how to use grunt to run tests automaticly._
##Setup
Make sure to have all the node dependencies in order when you start, these are updated regularly in case we need to go to a new version of a dependency, or new dependencies are added.
Simply run open a terminal / cmd in the Umbraco.Web.Ui.Client folder and run:
npm install
This should setup the entire grunt,karma and jsint setup we use for tests and pruning.
##Automated testing
To start working on the client files, and have them automaticly built and merged into the client project, as well as the VS project, simply run the command
grunt dev
This will start a webserver on :8080 and tell karma to run tests every time a .js or .less file is changed.
After linting and tests have passed, all the client files are copied to umrbaco.web.ui/umbraco folder, so it also keeps the server project uptodate on any client changes. This should all happen in the background.
##Adding a new service
The process for adding or modifying a service should always be based on passed tests. So if we need to change the footprint of the contentservice, and the way any controller calls this service, we need to make sure the tests passes with our mocked services.
This ensures 3 things:
- we test our controllers
- we test our services
- we always have mocked data available, if you want to run the client without IIS
###Example:
We add a service for fetching macros from the database, the initial implementation should happen of this service should happen in `/src/common/resources/macro.resource.js`
The macro.resource.js calls `$http` as normal, but no server implementation should be needed at this point.
Next, we describe how the rest service should return data, this is done in /common/mocks/umbraco.httpbackend.js, where we can define what data a certain url
would return.
So in the case of getting tree items we define:
$httpBackend
.whenGET( urlRegex('/umbraco/UmbracoTrees/ApplicationTreeApi/GetApplicationTrees') )
.respond(returnApplicationTrees);
The `returnApplicationTrees` function then looks like this:
function returnApplicationTrees(status, data, headers){
var app = getParameterByName(data, "application");
var tree = _backendData.tree.getApplication(app);
return [200, tree, null];
}
It returns an array of 3 items, the http status code, the expected data, and finally it can return a collection of http headers.
_backendData.tree.getApplication(app);
Refers to a helper method in `umbraco.httpbackend.helper.js` which contains all the helper methods we
use to return static json.
###In short
So to add a service, which requires data from the server we should:
- add the .service.js as normal
- add the .resource.js as normal
- call $http as normal
- define the response data in umbraco.httpbackend.helper.js
- define the url in umbraco.httpbackend.js
###ServerVariables
There is a static servervariables file in /mocks which describes the urls used by the rest service, this is currently needed as we dont have this set as a angular service, and no real conventions for these urls yet. Longer-term it would be great to have a urlBuilder which could do
urlService.url("contentTypes", "GetAllowedChildren");
//would return /<umbracodir>/<apibaseDir>/contentyTypes/getAllowedChildren
But for now, they are set in the servervariables file.

16
src/Umbraco.Web.UI.Client/docs/src/tutorials/Validation.ngdoc
View File

@@ -1,9 +1,9 @@
@ngdoc overview
@name Creating a property editor
@description
##Overview
First, I'll explain the validation system in the manifest:
The validation specified in the manifest is for server side only. Client side validation needs to be put into markup (I will write up a whole thing on the full validation process real soon!). Preferably a dev (and ourselves) will setup the same client side validation as the server side validation but the most important validation is server side so people cannot hack stuff.
@ngdoc overview
@name Creating a property editor
@description
##Overview
First, I'll explain the validation system in the manifest:
The validation specified in the manifest is for server side only. Client side validation needs to be put into markup (I will write up a whole thing on the full validation process real soon!). Preferably a dev (and ourselves) will setup the same client side validation as the server side validation but the most important validation is server side so people cannot hack stuff.
Each validation item in the validation array specifies a validation type that is executed against the posted value. What this means is that manifest based property editors will generally only be able to store 'simple' values, otherwise are auto-validation will not