Is there any way to perform "last minute" substitutions in the HTML (or other) resources that are part of your worklight application?
For example, I want to set the lang and dir attribute on the <html> element based on the end-user's locale.
some background:
I realize I can do dynamic DOM manipulation, but my question comes more from a background of client-server architecture where you have an opportunity on the server-side to replace some variables etc. in your HTML (or other resources) based on the requester's context. We have an existing app already and I'm investigating what it would take to integrate it with worklight including (for performance reasons) moving files from the server-side to the client-side without incurring too much refactoring of the current code.
Update: per the edit to your question, I don't think the below will make any significant impact on your app. Since you say you may move files from the server to client, this means like network traffic and with today's devices I suspect this may even be a boost to the performance rather than a penalty.
My suggestion is to try the below if the above is what you're planning to do.
I'm not even sure how else would you even do that from the server - change the application's UI based on the user's device local's, from the server. Doesn't make much sense to me to do that remotely.
To answer your question, I'll provide some background information that is relevant, I think, to a good user experience in this kind of scenario (as I see it):
By default, Worklight dismisses the splash screen once the framework has finished loading.
However, if you're using Worklight 6.2 then you can use the extended Splash Screen feature to display the splash screen for a longer duration, and during that time you could perform the required tasks -- like altering the UI based on the user's locale. Once you're done, you can then programmatically dismiss the splash screen on your own.
Reading materials:
Common UI Controls training module (slide #29)
Managing the splash screen user documentation topic (for both JS and Native support)
Example:
You need to uncomment the following in common\js\initOptions.js:
// # To disable automatic hiding of the splash screen uncomment this property and use WL.App.hideSplashScreen() API
//autoHideSplash: false,
You can then dismiss the splash screen when ready:
function wlCommonInit() {
function changeUiBasedOnLocale();
...
...
}
function changeUiBasedOnLocale() {
... // get device local
... // use JS to alter CSS
WL.App.hideSplashScreen();
}
Any basic DOM manipulation will help. Here is one example with D3.js
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>D3 Test</title>
<script type="text/javascript" src="d3.js"></script>
</head>
<body>
<script type="text/javascript">
d3.select("html").attr("lang","en_EN");
</script>
</body>
</html>
Related
I'm looking for a way to inject a custom script into the _Layout.cshtml purely from code. _Layout.cshtml cannot know anything about it. Just like Browser Link does it.
You simple write this:
app.UseBrowserLink();
And this gets injected into the body at runtime.
<!-- Visual Studio Browser Link -->
<script type="application/json" id="__browserLink_initializationData">
{"requestId":"a717d5a07c1741949a7cefd6fa2bad08","requestMappingFromServer":false}
</script>
<script type="text/javascript" src="http://localhost:54139/b6e36e429d034f578ebccd6a79bf19bf/browserLink" async="async"></script>
<!-- End Browser Link -->
</body>
There is no sign of it in _Layout.cshtml.
Unfortunately Browser Link isn't open source so I can't see how they have implemented it. Browser Link source now available
So I was wondering how it was done?
It's not open source, but you can easily decompile it to see how it works.
From a comment in the source code:
This stream implementation is a passthrough filter. It's job is to add links to the Browser Link connection scripts at the end of HTML content. It does this using a connection to the host, where the actual filtering work is done. If anything goes wrong with the host connection, or if the content being written is not actually HTML, then the filter goes into passthrough mode and returns all content to the output stream unchanged.
The entire thing seems pretty involved, but doesn't seem to use anything not available out of the box, so I guess it can be possible to code a similar thing.
Razor allows you to do this quite easily - you can even use a flag.
Example:
In your controller:
ViewData["RegisterCustomCode"] = "true";
In your View (.cshtml):
#if (ViewData["RegisterCustomCode"] == "true")
{
<text>
<script src="..."></script>
</text>
}
For whatever reason, whenever I build my project, any changes I've made to a view that are not html do not get displayed. Instead it pulls all the info from the partial view (which in our application doesn't get updated when I make a change in the view). So every time I build my project, the application serves me the partial view and I have to go into each view that I made changes in and make some sort of html change in order for the changes I made prior to the build display. Eventually, this functionality will change, but right now my boss doesn't want to mess with it just yet. I've tried disabling cache in chrome's dom (f12) as well as downloading an extension to force the page to not display any chached versions of pages but that doesn't seem to help. What else can I do until we get the partial views removed properly?
UPDATE:
I kinda goofed on the title. Whats happening is the generated files are what are being served to me from my localhost rather than any changes I made to a view (html or otherwise), if I made those changes prior to a build.
so in the view I'd have this:
<body>
<div>Hello World!</div
<div><h2>Sample Text</h2></div>
</body>
<script>
$(document).ready(function () {
//Some Javascript code
});
Which is the way the page was originally created by someone else. They also manually made a partial generated file and that file doesn't rre-generate when I make changes to the view.
So if I made these changes:
<body>
<div>Hello World again!</div
<div><h2>Sample Text</h2></div>
</body>
<script>
$(document).ready(function () {
//Some Javascript code
});
and then built the project, it would not serve me these changes, it would grab the generated file (which didn't get updated with my changes) and serve that to me unless AFTER I do the build, I go into that specific view and make an HTML Change (for some reason making a change with Javascript doesn't help). Then I can see my changes. AND it will stay that way until I do another build at which point, everything reverts back to the partial generated views until I make an HTML change in the view.
Deleting the Generated files is the only way I can see to fix the problem I just wasn't sure if it would break the application and it doesn't.
I'm exploring Electron and I've run into a roadblock. I can't figure out how to load the Dojo Toolkit and use it in Electron.
For example, here is the simple "Hello World" for Dojo:
<!DOCTYPE html>
<html>
<head>
<title>Tutorial: Hello Dojo!</title>
</head>
<body>
<h1 id="greeting">Hello</h1>
<!-- load Dojo -->
<script src="//ajax.googleapis.com/ajax/libs/dojo/1.10.4/dojo/dojo.js"
data-dojo-config="async: true"></script>
<script>
require([
'dojo/dom',
'dojo/dom-construct'
], function (dom, domConstruct) {
var greetingNode = dom.byId('greeting');
domConstruct.place('<em> Dojo!</em>', greetingNode);
});
</script>
</body>
</html>
That works fine in a browser, but doesn't work at all in Electron. After a couple hours of googling and trying 50 different experiments I've gotten nowhere.
Can someone please enlighten me?
While you can disable node-integration as Shwany said, I believe that will effectively render the ipc modules useless, which will probably pose undesirable limitations since you won't be able to communicate between the main and renderer processes.
However, it is possible, with a bit of finagling, to get Dojo to play nice with Electron. There are only a couple of things you need to do in your entry page.
Firstly, force the host-node has feature to false. This can be done by setting it in dojoConfig.has, e.g.:
var dojoConfig = {
async: true,
has: {
'host-node': false
}
}
Secondly, as Shwany pointed out, Dojo is going to see the already-existing require, so we need to move that out before loading Dojo:
// Move Electron's require out before loading Dojo
window.electronRequire = require;
delete window.require;
After loading dojo.js, you can move Dojo's require elsewhere and move Electron's back, if you wish. Whether you want to do this may depend on how you intend to code the client side of your application. Ostensibly, Dojo's global require is never needed, since you can request a context-sensitive require in any defined module via the 'require' module ID.
If you want to see a scaffolded Electron application incorporating Dojo, I created a boilerplate a few weeks ago (though be advised it's currently relying on a fork of electron-packager). If you want to see an example of a more full-blown Electron/Dojo application, I wrote a music player called Nukebox a couple of months ago which uses Dojo and dgrid (though its scaffolding is a bit different than the newer boilerplate).
I have your test code working in Electron.
First, I assume you are trying to load dojo.js from the web. //ajax.googleapis... etc will probably attempt to pull the file from the file system. I added http: to the front of it. That allowed me to open a .html file in the browser and work. I am not sure if that was an oversight or not.
Secondly, because the browser-window has node-integration on by default, 'require' is already defined and it does not understand what you are passing to it because it expects a path not an array. If you construct your browser window with node-integration turned off it should work:
app.on('ready', function() {
mainWindow = new BrowserWindow({width: 800, height: 600, "node-integration": false});
mainWindow.loadUrl('file://' + __dirname + '/index.html');
mainWindow.openDevTools();
mainWindow.on('closed', function() {
mainWindow = null;
});
});
Note the "node-integration": false. This may cause additional issues if you want to use node integrations in your app. However, your code should work.
A while back, I looked into a solution for the "flash of unstyled content" when using Dojo and Dojo themes. Someone suggested to combine everything by creating a build, and it'll reduce the load/parse time and remove the need to use preloader overlays, etc.
However, it seems like Dojo is severely lacking in straightforward, "real world" useage examples and tutorials for a lot of its functionality, this especially. A lot of the resources tell you how to set up a build, but not how to implement it.
Let's say I have this in "pageinit.js":
require([
'dojo/parser',
'dojo/dom',
'dojo/dom-class',
//etc...
'dijit/form/ValidationTextBox',
'dijit/form/CheckBox',
// etc...
// Dom Ready call
'dojo/domReady!']
function(
Parser,
Dom,
Class,
// etc...){
// do stuff with parser, dijits, so on.
}
)
Some of the require calls were removed for brevity, but there's a handful of dom requires, style classes, some dijits, etc. When this page loads, there's the flash of unstyled content and then it's fine.
Using the Dojo Web Builder, I selected the modules I'm using, and ran it. It downloaded a zip with a lot of files under it, including a new dojo.js and custom_layer.js.
So my question is now, how do I use these new combined and minified files in place of my "non-build" version? What do I require? Or do I?
So confused...
First, let's understand how the AMD(require/define) API works.
require([
'dojo/parser',
'dojo/dom',
'dojo/dom-class'
], function(parser, dom, domClass){
});
This is going to call the require function, specifying that I need three modules in order to do some work. require will get each module. If will determine if the module has been loaded. If it hasn't it will asynchronously get the file, and load the module into the javascript runtime. Once require has retrieved all of your required modules, it will execute your callback (the function) passing the modules as arguments to the function.
Next, let's understand the build. The dojo build does exactly what you describe. It will compress a bunch of the individual files into a single file. this will make the page load quicker and prevent that 'flash' that you describe.
Finally, putting it all together, you should include the custom_layer.js file along with the dojo.js file.
<script type="text/javascript" src="path/to/dojo/dojo.js" />
<script type="text/javascript" src="path/to/custom_layer.js" />
The web browser will load these two files and evaluate the code. Instead of lazily loading each module in it's own file, the module will already be loaded because it was defined in the custom_layer.js.
So, the answer to your final question is that you should NOT change any of your code based on the specific version of code (source vs custom build) that you are using. Using the AMD api, it should just work.
Not sure if it's best practice or not, but I was seeing the flash of unstyled content when I first started (a few days ago), and saw several examples somewhere that takes care of by just hiding the <body>. Parse will unhide it when it's ready to show something.
<body style="visibility: hidden;">
I have decided to have some fun with VB.NET and make a bot for some online games.
First of all, I plan on viewing the game through a webview control, which I believe is perfectly possible... unless I can't see Flash/Java content?
If it is possible, I've been wondering how would you "simulate a click" in the web view control? And, of course, keyboard input?
Perhaps a little late and I have no experience with VB.NET but to work with keys on a web page you need to use Javascript. For example:
<html>
<head>
<script>
document.onkeyup = function(event){ console.log(event); };
</script>
</head>
<body>
press a key within this document.
</body>
</html>
Cursor keys don't generate a keypress event hence the use of onkeyup. Also note it's lowercase. onKeyUp is not correct. If you're using Chrome or Firefox console.log will output the object that you can inspect. Not sure about IE but I think later versions support this too. Properties and methods can be used to get the keycode, character and any modifiers.
This code was tested on Chrome 12 beta. There are differences between IE and other browsers (as usual). This page shows an example of some of the differences: http://www.w3schools.com/jsref/event_onkeypress.asp
Not sure what you mean by "simulate a click" but I suspect you're not referring to testing.
Try for WatiN, its like testing a web application