I am brand new to NancyFX and currently enthralled by its low-ceremony approach to web application development. Throwing myself in at the deep-end, I also want to use CoffeeScript and investigate the benefits of Sass.
The Set-Up
To enable this combination I have created a new Empty Web Application using the VS2010 template (found in the Nancy Accessories project). I have then used the VS PackageManager to Nancify my application and add the SassAndCoffee support:
PM> Install-Package Nancy
PM> Install-Package Nancy.SassAndCoffee
So far so good. I then created an ~/Content/scripts folder and in there I have placed a file called home.coffee containing the following line of CoffeeScript.
alert "Hello Nancy!"
Now things start to get a bit fuzzy. I want to run this script on the client so I create an view called ~/Views/home.sshtml (and associated NancyModule with Get["/"] route - not shown). The view's html looks like this:
<head>
<title>Hello Nancy</title>
<script type="text/javascript" src="/content/scripts/home.js"></script>
</head>
<body>
<p>Hello #Model.User</p>
</body>
</html>
The view works just fine but the link to the home.js file just returns a 404: Not Found.
I am hoping that somehow Nancy will magically work out that I need my CoffeeScript compiled to JavaScript when it looks for the referenced home.js file and finds the home.coffee instead. This didn't work - so much for inspired guesswork.
If I change the script tag above to point to the existing home.coffee instead then the file is found but processed as a normal JavaScript file giving errors concerning the lack of tiresome ceremony namely: "unexpected string"
The Question
Now you know my set-up and simple requirements, here then is my question:
How do I get CoffeeScript to 'just work' using the NancyFX framework?
Thank you
Update
Steven Robbins (below) has answered this question by pointing to the demo code. But just in case you don't want to pull MBs of source from GitHub, here are the lines required to get things going. First add a class called Bootstrapper.cs to your project. Now add the following code (it worked like a charm for me):
public class Bootstrapper : DefaultNancyBootstrapper
{
protected override void ApplicationStartup(TinyIoCContainer container, IPipelines pipelines)
{
base.ApplicationStartup(container, pipelines);
StaticConfiguration.DisableErrorTraces = false;
Hooks.Enable(pipelines, new InMemoryCache(), container.Resolve<IRootPathProvider>());
}
}
The SassAndCoffee project doesn't hook into the static content bit in Nancy, it (or something similar) may in the future, but at the moment it's just a separate pipeline hook.
If you take a look at the sample project on github:
https://github.com/NancyFx/Nancy.SassAndCoffee/tree/master/src/Nancy.SassAndCoffee.Demo
That should show you how to get it going.
Related
I have reached a point where my ambition has exceeded my ability implementing Dojo in a Zend Framework project using an XAMPP distribution for PHP & Mysql as my dev/test environment on a Windows 7 machine. I honestly don't know if this is an ID10T issue (me) or a system failure. Should this be a failing on my part I apologise in advance.
I'm trying to implement using the V1.7 version of Dojo while remaining on a production ready environment (hence avoiding the jump to ZF 2, etc). I'm aware from documentation that in Dojo V1.7 dojo.xd.js has been superceded by dojo.js. My problem lies in trying to use a CDN source for Dojo.
The dojo content of my page renders fine, but Firebug is showing an error "NetworkError: 404 Not Found - http://ajax.googleapis.com/ajax/libs/dojo/1.7/dojo/dojo.xd.js" & the page has the following embedded in the page head:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/dojo/1.7/dojo/dojo.xd.js"></script>
Tracing the source of the problem on my page indicates it is the 'echo $this->dojo;' statement that introduces the problem.
Changing the 'setCdnVersion(1.7)' to 'setCdnVersion(1.6)' in the bootstrap file resolves the problem, but I'd really like be using V1.7+.
Pasting the embedded URI into the address bar, indeed, returns a 404 page not found.
Dogpile has no references to this specific error, that I can see.
I can't find any bug reports that appear - to my limited knowledge - relevant on dojotoolkit.org
It looks like the Dojo config I have is not recognising the need to use the dojo.js for V1.7 (although I'm not sure where the problem actually lies). So, I must confess I'm at a loss how to resolve this problem other than casting myself upon the mercy of the collective SO expertise.
bootstrap.php:
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
...
protected function _initView ()
{
// Initialize view
$view = new Zend_View();
$view->setEncoding('UTF-8');
$view->headMeta()->appendName('Content-Type', 'text/html; charset=UTF-8');
// add dojo helper path to view
$view->addHelperPath('Zend/Dojo/View/Helper','Zend_Dojo_View_Helper');
// configure Dojo view helper, disabled...
$view->dojo()
->disable()
->setCdnVersion(1.7)
->setCdnBase(Zend_Dojo::CDN_BASE_GOOGLE)
->addStyleSheetModule('dijit.themes.tundra')
->setDjConfigOption('parseOnLoad', TRUE)
->setCdnDojoPath(Zend_Dojo::CDN_DOJO_PATH_GOOGLE)
->useCdn();
// Add it to the ViewRenderer
$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('ViewRenderer');
$viewRenderer->setView($view);
// Return it, so that it can be stored by the bootstrap
return $view;
}
}
In index.phtml:
<head>
<?php echo $this->headLink()->prependStylesheet($this->baseUrl() . '/assets/css/site.css'); ?>
<link rel="stylesheet" href="https://ajax.googleapis.com/ajax/libs/dojo/1.7/dijit/themes/tundra/tundra.css">
<link rel="stylesheet" href="https://ajax.googleapis.com/ajax/libs/dojo/1.7/dojox/grid/resources/Grid.css">
<link rel="stylesheet" href="https://ajax.googleapis.com/ajax/libs/dojo/1.7/dojox/grid/resources/tundraGrid.css">
<?php
// Dojo plug-in enablers ...
echo $this->dojo();
$this->dojo()->enable();
?>
Version information:
Xampp dist - V1.7.7 (Apache/2.2.21, PHP/5.3.8)
Zend Framework dist - V1.11.11
From the 1.7 release notes:
Please note that if you are upgrading from 1.6 or earlier, we no longer make a distinction between dojo.js and dojo.xd.js (all versions work cross-domain with the new loader), so update your URLs to refer to dojo.js.
so the Dojo helper is using the filename dojo.xd.js (the cross domain version), but in 1.7 it should be just dojo.js. Dojo 1.7 was released after the Dojo integration into ZF, so it's possible this is a bug in ZF itself.
Can someone explain what happens after the java code is converted to Javascript by the GWT compiler?
how will the compiled javascript reach the client browser and when does this happen.
Well from your server, you serve a html page which should contain a tag that points to your compiled javascript.
Example of what the script tag would look like
<script type="text/javascript" language="javascript" src="http://example.com/js/project/project.nocache.js"></script>
The GWT compiler generates output files as described here.
At a very high level. There is a very tiny loader file (the .nocache.) which you should include in a script tag in your page. This file's only job is to determine the correct compiled application code files to request from the server. This load happens asynchronously after the nocache script has loaded.
The following types of tags in Lift do not seem to work for me:
<lift:snippet type="MyClass:render" />
<lift:MyClass.render/>
<lift:MyClass/>
Using these tags results in a Class Not Found error. If I attempt to call a class using
<div class=lift:myclass.mymethod />
it can work. Or if I call it using span tags. For instance, the Hello World example in Pollak's Simply Lift works for me, successfully displaying the Howdy method with the following code:
<span class="lift:helloWorld.howdy">
Welcome to your Lift app at <span id="time">Time goes here</span>
</span>
Currently, my problem is coming from attempting to implement Exploring Lift's (aka The Lift Book) OpenID example in Chapter 13.1. I have downloaded OpenID4Java using sbt as well as the lift-openid library. That example can be found at http://exploring.liftweb.net/master/index-13.html. I have implemented the change to the Boot class, and created the OpenID class and the SimpleOpenIDVendor class. But creating an html file containing
<lift:OpenID.form>
<openId:renderForm/>
</lift:OpenID.form>
causes the following error to be displayed in the browser:
Error processing snippet: openid.form
Reason: Class Not Found
XML causing this error:
<lift:openid.form xmlns="http://www.w3.org/1999/xhtml">
<openid:renderform>
</openid:renderform></lift:openid.form>
The class OpenID was placed in a package that starts with the package code, which is being implicitly found by Lift. It is included in the Boot.scala file with the line
LiftRules.addToPackages("code")
So, I am at a loss. Any ideas?
Note that other lift tags such as lift:bind-at and lift:surround and the like work fine.
As dave posted under my original comment, the problem was the HTML5 parser. Lift is case-sensitive, and cannot find a class with varying case. Since the HTML5 parser automatically makes tags lowercase, you can't use custom lift tags anymore. Instead, you have to use something like
<div class="Lift:MyClass.render"></div>
Note that you CANNOT have
<div class="Lift:MyClass.render" />
as HTML5 apparently does not support such tags.
My OpenID4Java problem is therefore resolved by using:
<div class="lift:OpenID.renderForm">
</div>
Why I don't need to use openid.form still is uncertain. It could be possible I'm implementing it slightly off, but I confirmed that it will take me to an openid login page if I put in the openid link, so it is indeed functional.
Sources:
http://groups.google.com/forum/#!topic/liftweb/H-xe1uRLW1c
https://groups.google.com/group/liftweb/browse_thread/thread/3948df1eee6ec271/ (thanks fmpwizard)
Is there a way to have some code run in the browser after coffeescript has compiled and run all the script files in the header?
Something like:
coffee.onCompiled () -> console.log "I've finished loading all the coffee files"
How else can I get this behaviour? (please don't suggest setTimeout)
At first I thought you were asking about how to attach a callback to window.onload from CoffeeScript (which is, of course, very straightforward, since "It's just JavaScript"), but now I realize that you're asking how you ensure that code runs after all
<script type="text/coffeescript" src="..."></script>
tags have been executed when using coffee-script.js.
One solution is to put a callback in the last CoffeeScript you load. Since 1.1.0, coffee-script.js has ensured that all CoffeeScript script tags are run in order (though note that they'll only run after all JavaScript script tags have run). So, for instance, if you put
<script type="text/coffeescript">
onReady()
</script>
after all your other script tags, and define window.onReady somewhere else, then that function will be called after all scripts have loaded. If you made it
$ -> onReady()
(with jQuery), then you'd ensure that the DOM is ready as well as all scripts.
Update: I posted that this is "one solution" because I wasn't 100% sure whether there's a callback that coffee-script.js invokes after all scripts have been run. But after checking the source, I can confidently say that it doesn't, so the only solution is to put code in the last <script type="text/coffeescript"> tag. (Whether it's inline or in a .coffee file doesn't matter.)
I've encountered what seems like a chicken & egg problem, and have what I think is a logical solution. However, it occurred to me that others must have encountered something similar, so I figured I'd float it out there for the masses.
The situation is that I want to use dojo's addOnLoad function to queue up a number of callbacks which should be executed after the DOM has completed rendering on the client side. So what I'm doing is as follows:
<html>
<head>
<script type="text/javascript" src="dojo.xd.js"></script>
...
</head>
<body>
...
<script type="text/javascript">
dojo.addOnLoad( ... );
dojo.addOnLoad( ... );
...
</script>
</body>
</html>
Now, the issue is that I seem to be calling dojo.addOnLoad before the entire Dojo library has been downloaded the browser. This makes sense in a way, because the inline SCRIPT contents should be executed before the entire DOM is loaded (and the normal body onload callback is triggered).
My question is this - is my approach sound, or would it make more sense to register a normal/standard body onload JavaScript callback to call a function, which does the same work that each of the dojo.addOnLoads is doing in the SCRIPT block. Of course, this begs the question, why would you ever then use dojo.addOnLoad if you're not guaranteed that the Dojo library will be loaded prior to using the library?
Hopefully this situation makes sense to someone other than me. Seems like someone else may have encountered this situation.
Thoughts?
Best Regards,
Adam Rice
You're doing it correctly. External Javascript files are loaded and executed synchronously in order, so by the time it reaches your dojo.addOnLoad( ... ); Dojo has loaded. Use dojo.addOnLoad instead of window.onload for two reasons:
it fires earlier, because it utilizes DOMContentLoaded
it handles asynchronous loading of dojo.require by postponing the execution until all required scripts have been read
Explained in DojoCampus as (dojo.addOnLoad):
dojo.addOnLoad is a fundamental aspect
of using Dojo. Passing addOnLoad a
function will register the function to
run when the Dom is ready. This
differs slightly from document.ready
and body.onload in that addOnLoad
waits until all dojo.require() (and
their recursive dependencies) have
loaded before firing.
This might have nothing to do with your problem, but ive just had a case where I had the same symptoms. For me everything worked fine for Firefox, Chrome etc, but not IE8.
I was getting what looked like dojo not being loaded, an error in IE8 saying that dojo was undefined (but not all the time) and i could strip everything down to just style sheets and importing dojo and still get the error.
I was running a local google app engine development server. This looks to be based on pythons SimpleHTTPServer which in turn uses SocketServer.BaseServer. This has BaseServer.request_queue_size which defaults to 5 - i couldn't find anything in app engine which overrode this value so i guess the development google app engine server has an upper limit of 5 connections.
Using regedit and going to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
“MaxConnectionsPerServer”=dword:00000010
“MaxConnectionsPer1_0Server”=dword:0000010
This shows that IE was going to try and open up to 10 simultaneous connections. I edited these two keys and made them 2 and restarted the computer, the problem went away.