I have a website built on the MEAN.io stack and am trying to generate PDF files on the client side with pdfmake. One can install pdfmake with bower (it looks like they used browserify to generate the client-side version).
I am struggling to get it to work. Either the injection of pdfmake does not work (I assume it cannot be found) or the pdfmake object is undefined (if I don't add pdfmake as a dependancy). I assume pdfmake needs to be packaged in some way to make it accessible, but I don't know how.
In config/assets.json I added:
"bower_components/pdfmake/build/pdfmake.js"
In the HTML corresponding to the JS file in which I want to use pdfmake I added:
<script src="bower_components/pdfmake/build/pdfmake.js"></script>
<script src="bower_components/pdfmake/build/vfs_fonts.js"></script>
I have set up a basic version on Github. I would really appreciate it if someone could explain to me how to make it possible to make pdfmake available for use in packages/system/public/controllers/index.js, for example.
I was recently have a similar problem. It seems to come from the fact that pdfmake isn't yet "browserfiable." After much troubleshooting, I was able to get it working through simply including the two client-side scripts pdfmake.min.js and vfs_fonts.js via script tags in my build directory. That's it.
Try moving the two script tags out of the bower_components directory and into your build directory. Make sure they're before your bundle.js, or generally whatever scripts need pdfmake.
I don't fully understand how bundled scripts are able to see the global objects created by these two files, but I think it's because they're setting pdfMake to the window object:
(The vfs_fonts.js file starts like this:)
window.pdfMake = window.pdfMake || {}; window.pdfMake.vfs
Since Browserify sets the global object to window, this approach seems to work. (Though I don't fully understand why... see this Github issue on their repo for more explanation and the deglobalify npm package.)
Here's another relevant post I was able to find.
Related
I have a meteor project where I want to include the conversational form framework.
There is a npm package, however it is not properly imported (probably due to some kind of bug). According to the github issue, this:
import cf from 'conversational-form'
does not work, because the export function exports cf.ConversationalForm, not cf (but cf is needed for existing declarations). The form is created and styled, but cannot be addressed in the js.
I was already able to use the framework in a normal html/js/css project, so now I wanted to just include the external script as a workaround.
However, downloading + importing in client/main.js did not work for me.
I've tried:
import '/imports/api/conversational-form.min.js
as well as:
$.getScript
in Meteor.startup.
Do I need to write specific exports in the external .js? I'm far from a professional, so I'm a little hesitant to dissect the external .js.
Any tips on how to simply mimic the html-script-inclusion? Or other ideas on how to get the framework running?
Sincerely, desperate.
Well Meteor allows you many ways to do that, the first ideas that come to my mind are:
Depending on your project structure you can create your own meteor package as a wrapper and internally load the library.
Hardcoding the script tag in you entry point.(Im not sure if this would work to be honest but you can try).
I ended up downloading the script, modifying it to set my options and including it via \imports.
VERY hacky solution, but well, it works...
Meteor allow you to load external library and scope them in all the client
via the /compatibility folder.
Just put the file in there, and it will be scoped automaticaly.
I am trying to work PHP project using PhpStorm.
I am having an issue that one JavaScript file does not show up properly under Project folder.
According to Windows folder structure, this js file (bootstrap.min.js) exists on same folder (without any hierarchy structure).
But, inside PhpStorm, it shows up under other js file.
Is there any reason it behaves like this?
Is it anything to do with Bootstrap?
This is a new-ish thing with PHPStorm (and the rest of the family).
In general, something.min.js is the code minified version of something.js, and you generally don't care to ever open the minified version in your editor.
So, PHPStorm shows it under the one that has the unminified, human-readable version of the code.
It's not actually changing the file system at all, it's just trying to help clean up the Project window a bit.
But, inside PhpStorm, it shows up under other js file.
It's called "nesting" and it's purely visual thing -- no changes at actual file system level.
It's convenient when you have source and processed/generated files (e.g. TypeScript source and generated .js and .map files; Sass source and generated .css and .map files etc). This way you see only source (in which you are interested the most for editing purposes) and generated files are hidden (so more files can fit the screen).
Is it anything to do with Bootstrap?
No.
You can create another file (e.g. test.js and test.min.js) and it will be nested in a similar fashion.
Is there any reason it behaves like this?
It's a relatively new feature (v2016.3 or so).
To be precise it's an old feature (PhpStorm v6 or so) .. but before it worked based on File Watcher settings (and file must have been processed by File Watcher in order to be nested) .. while now (since 2016.3 I believe) it's completely separate functionality and matching happens by simple patterns.
As of 2017.2 IIRC you can edit those patterns as you wish (in earlier versions they were hardcoded) -- just choose File Nesting... in Project View panel content menu (e.g. under "cog" icon).
Every time we release a new version of our software which is bundled using Browserify, we are finding that we need to ask our users to clear their cache using the regular methods of CTRL+F5 or diving into the browser settings. It is not ideal when there are a thousand or so users. We are trying to work out a way that we can perhaps get around this. I am open to all sorts of options.
Our project is ReactJS based, so runs in the browser and connects to back end services via a RESTful API. We do track which version is loaded and this is visible from within the console. Using the version number we can compare on two different machines that one user is running the latest version whereas someone else may not be.
The code is bundled into two separate files and I feel that this is where we should be looking.
You need to change the file name on each new release.
A hash of the file is an appropriate thing you could add.
Check out md5ify to add this to your project build.
If you implement this yourself, make sure to also load the correct filename in your index.html file.
Edit:
To automatically load the correct file you need to have a placeholder in your main html.
Then you need a manifest.json file that looks like following:
{
"main.js": "main.[HASH].js"
}
This has to be created automatically after the bundling.
Now you can replace the placeholder with correct asset by doing a lookup in the manifest file.
You either have to write your own scripts for this or use something like gulp together with browserify.
Another solution would be webpack
We're beginning work on a couple of fully JavaScript-dependent web apps (our previous apps have been ASP.NET MVC, with JavaScript 'goodness' sprinkled over-the-top).
We have a few files that will be shared across the board, and it would be nice to store these files in a Common project, and 'Add As Link' them into individual projects (as would be possible with compiled code).
Obviously this doesn't work with something like JavaScript as the file isn't actually 'there' in the correct location.
Does anyone have any suggestions on keeping a single version of a shared JavaScript file, for use across multiple projects?
I know this issue is ancient, but still wanted to put forward my solution because it is a bit simpler than beardtwizzle's.
You can ensure that Visual Studio copies all linked files to where you placed the link in Visual Studio's Solution Explorer by adding this at the end of your .csproj file:
<Target Name="CopyLinkedContentFiles" BeforeTargets="Build">
<Copy SourceFiles="%(Content.Identity)"
DestinationFiles="%(Content.Link)"
SkipUnchangedFiles='true'
OverwriteReadOnlyFiles='true'
Condition="'%(Content.Link)' != ''" />
</Target>
I've described how this works in my blog post at
http://mattperdeck.com/post/Copying-linked-content-files-at-each-build-using-MSBuild.aspx
In the end, this is how I've achieved it. It may not be to everyone's taste - but worked a treat for me.
Note: In all of our projects, static resources are in a root directory called 'Assets', so for example JavaScript is always in /Assets/js/ and CSS /Assets/css/.
Solution
In the project that is going to 'import' the common code, I simply add the common .js file 'As Link' within /Assets/js/.
Go to that new addition's Properties and set 'Copy to Output Directory' to 'Copy if newer'.
Now I simply edit the project's post-build event command line to the following:
xcopy /Y /E "$(TargetDir)\Assets" "$(ProjectDir)\Assets"
When the project builds, it copies the imported files to \bin\Assets\js - the post-build event then takes a copy of those over to the project directory - in time for the site to use them.
The correct solution is embedding javascript/css files in your project. You can do this by using WebResources.axd. This is the official way microsoft embeds js in its controls. (Like validation controls)
You can find a good tutorial on: https://web.archive.org/web/20211020131200/https://www.4guysfromrolla.com/articles/080906-1.aspx
I can also see this question is ancient, but thought I would add my two cents...
I have a javascript file in a separate project. I added a linked reference and this works well for publishing, but doesn't work in IIS Express or Casinni. I tried adding custom routing to catch the missing file and manually remap it, but it is bit of a hack and for some reason stopped working when I upgraded to MVC 5.1, so rather than fix the hack, I found a better way:
System.Web.Optimization has javascript bundles.
In your shared project, set the Copy To Output Directory to 'Copy Always' and Build Action to 'Content' on your js file. This means your js files end up in the bin folder of your website project. They cannot be served from there (IIS wont serve anything in the bin folder for obvious security reasons), but they can be included in bundles
using System.Web;
using System.Web.Optimization;
public class BundleConfig
{
public static void RegisterBundles(BundleCollection bundles)
{
bundles.Add(new ScriptBundle("~/bundles/externalLibrary").Include(
"~/bin/scripts/externalLibrary.js"
));
}
}
You then need to add this to Application_Start in your global.asax file (right next to register routes)
BundleConfig.RegisterBundles(System.Web.Optimization.BundleTable.Bundles);
then use your bundle link this in your razor cshtml:
<script type='text/javascript' src='#System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/bundles/externalLibrary")'></script>
you will need the nuget package for microsoft.aspnet.web.optimization
Anyone that stumbles across this question here in the future should know that there are now Shared Projects in Visual Studio to solve this problem. Universal Windows projects use them by default and you can create your own by downloading and installing the VS extension here: https://visualstudiogallery.msdn.microsoft.com/315c13a7-2787-4f57-bdf7-adae6ed54450
Once you download the extension you can add a Shared Project (Empty) to your solution. The project can be found in the project templates for Visual C#, Visual C++, and JavaScript.
Then include the files you want to share to the shared project in any folder structure that makes sense for you.
Next you will include the shared project as a shared reference in the other projects in that solution that need access to the shared files. Right-click the other project and choose "Add Shared Project Reference".
Now you can reference the shared files in your main project as if the files in the shared project existed there. They are compiled as part of that project.
The technology was intended for Universal apps to share code between Windows Phone and Windows Store apps so be warned that you may have trouble sharing in different scenarios but it is worth a try to see if it will fill your need.
You could perhaps use visual studio templates
great question, I've been thinking about this for quite some time. The only solutions that have popped up in my mind are hosting the files on the web and using them like a cdn or using symlinks. You could add a code snippet into your visual studio to reference them.
This blog post describes an alternative solution to the answer by #beardtwizzle:
http://consultingblogs.emc.com/jamesdawson/archive/2008/06/03/using-linked-files-with-web-application-projects.aspx
The idea is similar:
Add the shared file to to web project as a link
Modify the _CopyWebApplication build step in the project, so that the linked files are copied correct destination path.
So instead of a post build event the files are copied by a modified build step. For me this solution feels a little bit cleaner (but this may well be a matter of taste). Anyway I just added this to our solution and it works great so far!
Use proper version control.
Keep the js in one location and then just git pull (or the equivelant Mercurial / Bazaar) them back into your code whenever you've updated your javascript.
I think the question says most of it. I have an autogenerated ManualSpecRunner.html file as created by maven / jasmine plug-in and I've got it to put itself into the deployable .war by using:
<jasmineTargetDir>${basedir}/pathForMyWebapp</jasmineTargetDir>
However, all the links to js files within the ManualSpecRunner.html are hard coded file:/// references - this is a bit mental, I want them to just be the relative paths to the files that are also in the webapp i.e.
Currently it gives me this path:
file:///home/username/code/HEAD/pathForMyWebapp/js/yui.js
whereas I need it to have the far more simple
/pathForMyWebapp/js/yui.js
I have tried changing two other variables in the maven script, but neither seems to have the desired effect, neither of these configuration options do what I need, the second having seemingly no effect:
<jsSrcDir>/pathForMyWebapp</jsSrcDir>
nor
<jsTestSrcDir>/pathForMyWebapp</jsTestSrcDir>
I've looked through the documentation but think I must be missing something (also, more notes on various config params listed in https://github.com/searls/jasmine-maven-plugin/blob/master/src/main/java/com/github/searls/jasmine/AbstractJasmineMojo.java are meant to do would be helpful so I can work out if I'm doing it wrong or if it's not possible!)
Any suggestions?
[p.s. I've changed some of the path names as they've got sensitive info in them, so please ignore their oddness!]
I think I understand the source of your confusion. It looks like you're trying to direct the target of the jasmine-maven-plugin to a directory inside your project's packaged *.war file so that you can run your specs against the code after it's deployed to a server, is that correct?
Unfortunately, the plugin wasn't designed with that use in mind. The jasmineTargetDir directory is usually left at its default value of target/jasmine and wasn't intended to be bundled with your application (it's analogous to the target/surefire-reports generated by maven-surefire-plugin for Java unit tests). So the reason that the script tags in ManualSpecRunner.html point to invalid locations is because that file is generated in order to be run from the local filesystem in a browser from the workstation that's building the project (to facilitate TDD).
All of that to say, if I'm reading your intention right, I think it'd be a cool feature to build a third spec runner that could be deployed with the app and executed remotely. (Especially if the project's Jasmine specs are functional/integration as opposed to isolated unit tests.) Unfortunately that's not something the project does yet.
I'm afraid that for now, if you needed to bundle the jasmine tests and execute them on the deployed server, you would need to copy ManualSpecRunner.html and jasmine into your src/main/webapp, fix the script tag references, and then manually maintain it as files are added and removed.
Make sense?