I'm currently developing several web projects in Ext JS and ASP.NET using Visual Studio 10. During that process, I have developed several javascript GUI components, some of which I use in more than one web project. Now, when I make any changes to one of these components, I would like them to automatically appear in all of the projects they are used in. I also would very much like to be able to have these components in their own respective projects / solutions.
When building my main ASP.NET web application which uses my components A and B, their javascript code would then have to be copied into the web application's output folder.
It's no problem to do such things with C# assemblies - you can just reference the needed DLLs. But it amazes me that I'm not being able to find a way to do something similar with javascript code (or, more general, with any sort of static files)!
Has anyone dealt with this problem before and found a viable solution?
I have wondered the same thing.
You can share projects across solutions (including those controlled by TFS, although I imagine there are limitations to this). I've read about this working for static files (like script) but I haven't gotten around to trying it. It doesn't seem ideal for all cases. This thread discusses how to "add as link", which might be useful.
I've recently set up a separate VS solution just for my JavaScript/CSS libraries with full source and a build/minification process. The final output is "compiled" and ready to go. I have also built out sample pages for each component and documentation. These samples serve also serve as great tests, because I can easily test for correct behavior in dozens of different scenarios.
It would be easy to write a script (or even a FileSystemMonitor, if you wanted to be fancy) to copy these final files into other project directories. Automatic copying won't always be the right answer, because you may want to have different solutions using different versions of your JS components. Manually copying isn't so bad, because you are usually only doing it when you have found and fixed a bug, or you are deploying a new version.
I would be interested in what other people are doing.
Related
I often compile informal datasets by running some kind of XPath/XQuery on publicly available web pages. Usually the structure of the HTML is regular enough that useful information can be extracted easily.
But today I've come across tunefind.com. This website makes extensive use of the REACTJS framework, and so most of the structure of the page is configured client-side by Javascript. The pages, when initially downloaded, are very basic and missing a lot of information. The pages are populated by a script that uses a hopelessly messy blob of JSON data at the bottom of the page.
The only way I can think of to deal with this would be to use some kind of GUI-based web engine and just not display the GUI part. But that is a preposterous amount of work for these casual little CLI tools that I use to gather information.
Is there any way to perform the javascript preprocessing without dealing with unnecessary graphics?
Even if you were to process without the graphics the react javascript will be geared towards running in a browser context, at the very least it will expect a functioning DOM to exist, the application itself may also require clicks / transitions to happen before you can see some data.
Your best bet then is to load the page in a browser, to keep this simple, there are plenty of good browser automation frameworks designed for this.
I've used a fair few libraries over the years including phantomJS and recently I've gotten the most mileage out of nightmarejs.
It runs an electron browser for you and gives you a useful promisified javascript API to control it with, that has common browser functions such as clicking, following links etc.
You can configure it to hide the browser which is useful for making a CLI tool, however its a bit of a pseudo-headless mode and will still require a windowing/graphical context (e.g. x window).
Hope this helps.
PS - If you're at all used to docker it's not hard to make this just a running container!
I want a javascript framework which has features like below:
MV*
Well structured
Html file as template
Rendering fast(maybe virtual dom?)
Combine and compatible with other plugins or libraries
Edit on tablet IDE apps and view in browser immediately by refreshing page after I changed code
When I am at home, I use PC to develop my client-side(or front-end) applications.
When go out, I use my tablet(I have no note PC), so I want to develop my applications outside.
*There are some excellent IDE apps on the Android Market.
Before I know Ember, I have been using pure javascript(jquery) + css + html to develop client-side application for daily practices or work.
But recently, when I began to learn EmberJS, a Javascript MVC framwork, I am lost.
It seems that EmberJS have to get its own server up to compile something, which generate static contents for browser rendering.
I just want to get my client-side code(files) rendering in the browser, but why I have to 'run' it as if I get apache started to serve as a php back-end.
I have googled hundreds of pages to find a solution, nothing expected result discovered.
Including Angular, backbone or any other popular Javascript MV* frameworks, they all must compile there applications.
Is there anyone who has encountered this situation?
Then any advice, please?
Increasingly most Javascript frameworks are shifting to doing a "compile step" as part of using them. This allows you to do a variety of changes to your Javascript files, which in turn makes it easier for you as a developer. An example of this is that you can use ES2015 classes and then have your compile step "transpile" them to older Javascript that will work in all browsers.
The side effect of this though is that you need to have npm running on your computer to be able to do this well.
If you really don't want to have the compile step, then I would suggest looking at VueJS. It's the only recent Javascript framework that allows working with simple non-compiled JS files. But you'all be missing out on some of the best changes to Javascript as a result (ES2015 has made life much better)
Finally, I found a nice solution(framework) that is Durandal.
Really, pure HTML+Javascript without built and server up(anyhow, a web server needed if I wanted to publish it in my hosted web server).
.html extension and designer friendly.
I can upload its source files directly in to S3 and browse the html pages.
Just found some nice examples with well structured project on github is here.
And I can work smoothly with my dear designer friends.
Though its next generation Aurelia will also be built and serve it up like Ember or others, but the current generation is enough for me.
Hope those one got help from this;)
I'm working in a small agency and we build multilingual websites that are complex enough to have me thinking about using a JS library, but not big enough to be considered a "Web App". We have developed our own "stack" that includes WordPress as the CMS and multiple tools (PHP module loader, JavaScript module loader, css preprocessors, build tool, etc.)
Most of our sites have various modules and forms that are used in multiple pages. For example in our current project one of this module makes several calls to an API and there are multiple event bindings to do in each pages.
I was considering using BackboneJS but feel like it's a bit overhead for this kind of project. Then I looked in React but since the modules doesn't always require to repaint the DOM, I wasn't sure it would be used properly. I care a lot about producing optimal and maintainable code (don't want to put everything in one big js file) so I'd like to find a solution. Unfortunately most documentations and examples I found for these libraries were for one-page apps or projects with only one module so it didn't help.
Anybody have suggestions as to what to use? Someone in a similar situation committed to a library and could give some feedback?
Thanks!
I'm creating an intranet application, the UI of which premoninently uses Ext JS 4.1.1
I have created several custom javascript classes extending Ext JS controls and other code for UI, validation, communication, etc.
Given that my code is not very huge and that my application will be deployed in a controlled & well known environment I'd ideally like to load all .js files upfront at the time of application invokation (boot). I'd like to know an approach to achieve this, mostly from within the relm of Ext JS.
What you want to do is something really usual. Take a look at the deployment section to know how to use the Sencha SDK to create one file containing all your custom javascript classes which extend extjs component here
I hope it is useful ;)
As of this month Sencha (beta) released a revamped build tool. Actually, it is a complete rewrite in Java (I believe). Sencha Cmd is the name, and it is all that the predecessor should have been!
Compile times have been crunched to maybe a 10th of its predecessor and packages/builds are now configured using a powerful command processor.
Integration into other build frameworks and CI servers is now a top priority and achieved by integrating the tool with ANT.
I just spent the past hours to migrate a project from the old Sencha SDK Tools to the new Sencha Cmd. I particularly love the new compiler.
Documentation is already pretty good.
Blog post that introduced Sencha Cmd
Official SDK documentation - there is a total of 10 articles on the subject, don't miss them, particularly the
Compiler documentation
For smaller projects that follow the standard (single-page) pattern suggested by Sencha, there is actually a range of higher-level commands that manage the entire application creation and build process.
Furthermore, Sencha has now a pattern in place for multi-page applications.
And you can always use the compiler directly and implement your own build process on top of it. That's what we did in our project.
There is one class called Ext.Loader
This is more of a server-side question than an Ext JS question. You want to include all your pages up-front? Get a JavaScript compressor to concatenate your files together, minify the whole pack, and add a <script> tag to every page in your web app.
I also work on an intranet web app that heavily uses Ext JS (both 3 and 4), but we have quite a large codebase. Since we use Tomcat, we have a Java class that includes standard files on each page, plus any file groups or individual files we need for that page. Something like that might work for you as well.
You can use Ext.Loader for dynamic loading when you need it, but that doesn't sounds like what you're looking for. Still an option though, should your codebase expand and you need a better solution.
EDIT: As mentioned in the comments, my original answer failed to address the Sencha SDK Tools. I felt it would be more beneficial to make my response part of my revised answer.
While this task may be exactly what the Sencha SDK was designed for, I feel that the product is not yet mature enough for production environments. At the time of writing, the current version is 2.0.0 Beta 3. Beta, meaning it's still under development, and it shows. Documentation is practically non-existent and the official forums are full of topics claiming the product simply does not work. At this point, it's nothing more than a toy to be played with. The most helpful document I've seen is Sencha SDK Tools 2.0 and ExtJS4: The Missing Docs, and the author even ends with "The SDK Tools need a lot of work."
When I'm choosing a product for a production environment, I want something stable, something reliable, something with good documentation, something with quality support. The Sencha SDK Tools are none of those things. Yet.
What should I use to manage growing number of JavaScript files in my application?
We are building a django application with several apps. Each app has different functionality, and has to be rendered in three different modes (pc, tablet, mobile). There is a lot of things happening in JavaScript: managing data received from the server, handling user events, injecting HTML snippets, and loading sub-components. Some of the functinality is shared between apps and view modes, but often it makes sense to write a specific functions (for example, hover and click events may have to be handled differently on a PC layout vs. a tablet layout) so we are grouping this in files based on app/layout/function.
Up to a point we were using a flat file structure with naming to differentiate types of files:
ui.common.js
ui.app1.pc.handlers.js
ui.app1.pc.domManupulators.js
ui.app1.tablet.js
ui.app2.pc.js
...
Right now, however, as the number of apps (and corner cases) grows this way is fast becoming unusuable (we're approaching 20+ files and expecting maybe 40+ by the time we're done), so we are putting everything in directories like so:
js/
common/
core1.js
ajax2.js
app1/
tablet.js
pc.js
app2/
mobile.js
...
I have been looking at JavaScriptMVC to help with this. While it does offer useful tools it doesn't seem to have anything that would specifically make managing our giant JavaScript library better. We are expanding our dev team soon and code maintainability is very important.
Is there something that may make our life easier? Are there any habits/rules of thumb you use in your work that could alleviate this?
Backbone.js is used to organize javascript heavy applications in an MVC-style pattern. It's going to take some learning, but it's definitely something you'll want to look into and learn a bit about even if you don't end up using it.
It's used on quite a few pretty impressive projects
And, here's a site to learn more with tutorials.
Typically, grouping libraries by commonality (like your second example) would be preferred. However, more importantly would be making sure you have namespaced or otherwise make them unique so that you are unlikely to get naming collisions with other potential scripts.