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.
Related
I have a FIORI application (lunched from launchpad) in which I am using unified shell to persist variants.
In my index.html, I first bootstrap the ushell_abap and then ui bootstrap like this
<script id="sap-ushell-bootstrap" src="https://sapui5.hana.ondemand.com/1.90.0/resources/sap/ushell_abap/bootstrap/abap.js"></script>
<script id="sap-ui-bootstrap" src="https://sapui5.hana.ondemand.com/1.90.0/resources/sap-ui-core.js"
data-sap-ui-libs="sap.ushell, sap.collaboration, sap.m, sap.ui.layout, sap.ui.ux3"
data-sap-ui-theme="sap_belize"
data-sap-ui-resourceroots='{"cvg.wallapp": "./"}'
data-sap-ui-compatVersion="edge"
data-sap-ui-async="true"
data-sap-ui-frameOptions="trusted"
data-sap-ui-bindingSyntax="complex"
data-sap-ui-oninit="module:sap/ui/core/ComponentSupport">
</script>
My app works fine, including variant persistence when running in localhost.
I now deploy the APP to my Fiori server and the bootstrapping process falls apart.
It completely fails to load my theme and associated styling (no custom styling just using the belize theme).
In the console I get the following errors:
includeStylesheet-dbg.js:77 GET https://xxxx:yyyy/sap/public/bc/themes/~client-810/~cache-Bo-MdJE9H9k-CMXXsBrbgsL9ZXQ/UI5/sap/suite/ui/commons/themes/Fiori_LP_Home_Theme/library.css net::ERR_ABORTED 404 (Not found)
One or more parameters could not be found. - sap.ui.core.theming.Parameters
As soon as I remove the bootstrapping of ushell_abap everything works (except the persistence of variants of course).
I have exhausted google searches and reading through the ushell documentation here https://sapui5.hana.ondemand.com/sdk/#/api/sap.ushell
Anyone with an idea on why bootstrapping is failing when truing to use ushell_abap ?
The main issue here was that the app was using a different version of the css libraries than the bootstrap libraries which caused errors (in this case core had new elements in css styling not available in the old css library for core).
If your APP is set up as a standalone APP as explained by Benedikt Kromer and you bootstrap to a specific sapui5 version in the index.html, you can force the app to use the same version css libraries by applying the style to the core on init of the main app.
In on init I just added:
sap.ui.getCore().applyTheme("sap_belize");
This forced the app to load css libraries from the same version I used to bootstrap.
You can see this by watching the network tab in developer tools.
I think you missed one key aspect of the launchpad.
"launched from launchpad" could mean:
It is opening a new tab - standalone -> no need to mention launchpad in the question.
Staying in the same tab - standard/desired setup.
If (1) and you try to load the launchpad theme in your 1.90.0 app. Make sure the ui5 version match exactly.
"parameters could not be found" Could indicate your Theme was create for an older UI5 version.
Possible solutions:
You could generate a theme, matching the standalone ui5 version upload it into an own BSP.
You can ignore the error, there may be some
ui-glitches.
In any case 404 errors indicate also that you didn't link the theme correct in the first place.
If (2), then your index.html is never called. UI5 is starting from the component.js. Hence all your bootstrapping there dosen't count.
In this case index.html is only the playground for local development.
For the shell, this is already in place. I'm not sure why you want to load it again.
I started experimenting with Wicket AJAX functionality and wanted to implement an AjaxLink.
This is the associated markup/java-code:
<a wicket:id="testlink"></a>
---
AjaxLink<Component> link = new AjaxLink<Component>("testlink") {
#Override
public void onClick(AjaxRequestTarget target) {
System.out.println("called");
}
};
add(link);
But the onClick-method is never called, I guess because the generated HTML looks like this:
<a wicket:id="testlink" id="testlink7" href="javascript:;"></a>
Any ideas on what I am doing wrong?
This href="javascript:;" works because Wicket 6 uses JavaScript Event registration. Look at your webpage in some browser dev tool like in firefox. Point the inspector to the link and read it's id, then go the the head section and expand one of the <script type= text/javascript></script> tags. There you should find the id of the link and see that there is an line where a click event is attached to the id of the link. The URL there is executed when you click the link.
Thanks Robert for clarifying the ajax mechanisms of Wicket 6 - I'm rather new to this topic and the insights you gave me helped solve the problem.
Actually it was caused by some jQuery inconsistency I still haven't fully untangled, apparently coworkers used different jQuery-versions within different of our Wicket modules and somehow Wicket used not the one it was shipped with but a wrong one when trying to attach the event listener to the component.
When removing the unneccessary old jQuery libraries Wicket started to work fine - now I just have to get the components depending on the other jQuery libraries working again, but thats a different story :)
In my situation, I removed the following onload on body tag and the AjaxLink onclick function worked again.
<body onLoad="MM_preloadImages('template-image/searchbto.png');">
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.
I have a tinyMCE plugin (for the post/page editor) that I am loading from my Wordpress plugin that needs to have several external javascript files loaded in order for my tinyMCE plugin to work.
In Wordpress 3.3.1 I can just register and enqueue the scripts from the mce_external_plugins filter but any Wordpress version below that doesn't load the scripts.
Anybody have experience in this?
The method that I found to work with my problem is by hooking to after_wp_tiny_mce and then in the callback, calling wp_print_scripts directly. It still handles all the dependencies of the scripts.
Also, because wp_localize_script won't work with this method due to the scripts not being enqueued, I am echoing my objects directly above my calls to wp_print_scripts like this:
<script type="text/javascript">
/* <![CDATA[ */
var MyLocalizedData = {"foo": "barito"};
/* ]]> */
</script>
EDIT :
This fix will only work in Wordpress >= 3.2
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.