We have a configuration file that we use in our AngularJS app. Because we need our configuration information during the build phase, we define it as a value. The configuration file contains information about where to find the assets for one of several Assessments, so we have a configurationService with an updateAssessment() function that looks in the configuration file at the various Assessments that are defined and then copies the properties from the specific Assessment into another value, assessmentSettings.
We have some situations where we want to read in some additional settings from an XML files, but when those settings are already provided as part of the configuration for that Assessment, we want to ignore them. I have a test that checks that this is done and it runs and passes.
However, massaging the project configuration value, then calling configurationService.updateAssessment(1) in that test causes 41 other tests in different files to fail. My understanding is that Angular should be torn down and brought back up for each test and should certainly not cross-contaminate across different files. Is there something different about values that would cause this to happen?
Note that the project itself seems to load and run fine. I haven't provided code examples because it would be a fair amount of code and I don't think it would be that enlightening. Angular 1.3.
Related
I've created a web page that's for all intents and purposes, a style guide for other developers working on our application.
I have my .scss files within the _sass directory in my Jekyll project, and it's created all the CSS files beautifully. On my page however I want to display the code from these .scss files in the page within some <pre><code> tags.
Currently I have the code in here repeated in both places. When it was quite small it wasn't such a problem, but now it's got bigger it needs DRY-ing out.
I first went down the path of using Jekyll's {% include [path/to/file] %}, and then realised that only works for stuff in the _includes folder, and I couldn't use the include_relative option either as the _sass folder isn't a child of the location it's used.
Secondly I tried using the angular approach, as I'm already using it in my application. Threw in some <pre><code ng-include="'../_sass/components/_sflButton.scss'"> and expected it to work. Of course, it didn't because the _sass folder isn't generated into the actual site when you run it. And I can't seem to find a way of getting it to include it. Tried changing a few things in _config.yml to no avail.
So, TL;DR, I want to either be able to include the code from my _sass folder onto my page via Jekyll, or find a way of getting the _sass folder to be loaded into the generated site so I can load it in with Angular. Am I trying to do an impossible task here? Willing to listen to any suggestions that mean the code is only written in one place.
The theory behind getting this done is as follows:
_sass is a special directory for Jekyll (similar to _layouts, _includes) that is handled differently in comparison to other directories you create. Its contents are not output to the destination directory.
you can write simple ruby programs and add them to a directory called _plugins and Jekyll will run those custom programs during the build process. (Ignored by GitHub Pages).
Now write a ruby program to "read" the contents of _sass and have the resulting data be formatted as a hash and have this hash fed to existing site_payload
The hash can be additionally passed as a Drop instance to have the data available via the Liquid templates.
I concede this answer doesn't actually solve your problem esp., if you're not familiar with Ruby, and Jekyll codebase. but it'll serve as a starting point..
I'm developing a web-application with angular and this will be used for different customers. Each customer has his own needs (specific functionality) and style (css). A lot of the functionality is shared though.
What I'm looking for is a total solution to keep this project clean and maintainable. The code will be running on the local server of each customer and the customers shouldn't see the specific code for the other customers (with other words, something like grunt should have filtered the deployment).
What I had in mind:
Define different tasks in grunt to watch, build, etc per customer
Define parent controllers (~inheritance) and parent views to share functionality
Use a subfolder for each customer
e.g. views:
app/views/general/home.html (loads main.tpl.html)
app/views/customer1/main.tpl.html
app/views/customer2/main.tpl.html
e.g. controllers:
app/scripts/controllers/general/...
app/scripts/controllers/customer1/... (extends general controllers)
e.g. css
app/styles/general/...
app/styles/customer1/...
Grunt will select only the files relevant for the customer and should remove the customer-related paths. (e.g. both app/views/customer1/ and app/views/customer2/ should go to app/views/customer, which is loaded by app/views/general/home.html)
A big disadvantage will be that the app/views/general/home.html will have a reference to unexisting file while developing. The same goes for index.html where I need to include the controllers from the target dist folder, not from the project folder structure (while developing). Which makes everything a bit less readable and logical.
Do you think this is a good approach? Are there optimizations or alternatives coming to mind? Do you know of any grunt modules or angular modules aiding for such set-up?
Thanks in advance!
One approach you could use is to run a basic node server that will store and serve up, using a rest call, the user preferences. So you would save user specific settings such as layout, etc and update these in a simple JSON file stored on a local or remote node server.
I have an angular constant which defines webservice end point
angular.module('myModule').constant('mywebservice_url', 'http://192.168.1.100')
The problem is that for dev I have a different end point while staging and production its different. Every time I try to check in to git I have to manually reset this file.
Is there any way git permenantly ignore this file but checks out the file while clone or checkout?
Is there any way I can make angular pickup file dynamically from something like environment variable.
NOTE: I don't want to depend on server to do this, ie I don't want to use apach SSI or any of those technologies as it will work only one set of servers.
Delaying the injection via backend processing. I usually just create a global object on html page called pageSettings which values like this is getting injected from the backend, i.e. environment variables, etc. and just pass that global pageSettings object into that angular constant or value.
Build system injection. If you don't have a backend, i.e. pure SPA... maybe you can put this inside your build system, i.e. create multiple task for building the different environments in gulp or grunt and replace that value during the build process.
In e.a. your app init code:
var x = location.hostname;
Then define 2 different constants.
One based off the domain name of your develop environment and one for your production.
I would like to know your opinion about how you would organize the files/directores in a big web application using MVC (backbone for example).
I would make the following ( * ). Please tell me your opinion.
( * )
js
js/models/myModel.js
js/collections/myCollection.js
js/views/myView.js
spec/model/myModel.spec.js
spec/collections/myCollection.spec.js
spec/views/myView.spec.js
This is how I've traditionally organized my files. However, I've found that with larger applications it really becomes a pain to keep everything organized, named uniquely, etc. A 'new' way that I've been going about it is organizing my files by feature rather than type. So, for example:
js/feature1/someView.js
js/feature1/someController.js
js/feature1/someTemplate.html
js/feature1/someModel.js
But, oftentimes there are global "things" that you need, like the "user" or a collection of locations that the user has built. So:
js/application/model/user.js
js/application/collection/location.js
This pattern was suggested to me because then you can work on feature sets, package and deploy them using requirejs with relatively little effort. It also reduces the possibility of dependencies occurring between feature sets, so if you want to remove a feature or update it with brand new code, you can just replace a folder of 'stuff' rather than hunting for every file. Also, in IDE's, it just makes the files you're working on easier to find.
My two cents.
Edit: What about the spec files?
A few thoughts - you'll just have to pick the one that seems most natural to you I think.
You could follow the same 'feature folder' pattern with the spec files. The upside being that all of the specs are in one place. The downside is that now, much like what you're currently doing, you have to places for one feature's files.
You could put the specs in a 'spec' folder of the feature folder. The upside is that you now have actual packages that can be wrapped up in a single zip file with no chance of clobbering other work. It's also easier to find directly related files for writing tests - they're all in the same parent folder. The downside is that now your production code and test code is in the same folder, publishing it (possibly) to the world. Granted you'll probably end up compiling the production javascript down to one file at some point.. so I'm not sure that's much of an issue.
My suggestion - if this is a large application and you figure you're going to have a few hands touching the files, leave something like a 'package.json/yml/xml' file in the folder. In there, list out the production, spec, and any data files you need for testing (you can most likely write a quick shell script to do this for you). Then write out a quick script to look through your source folder for 'package.whateverYouChose' files, get the test files and then build your unit testing page with it. So, let's say you add another package.. run 'updateSpecRunner' or whatever you name the script, and it'll generate you another SpecRunner.html file (or whatever you named the file your running the specs on). Then you can manually test it in a browser, or automate it using phantomjs/rhino.
Does that make sense?
You can find a good example how to organize your application to this link
Backbone Jasmine examples
It looks more or less like your implementation.
We have a config spec that we use for our builds that we encourage all developers in our organization to use so that they can run any task in our build without fear of failure. Every now and again we need to update that config spec to include new elements or exclude old elements.
When we do this, the process is to write a quick mail to all of our developers telling them to manually update any views that they use to build our system with the current config spec.
This is annoying and error prone and thus leads many developers to just ignore those mails and then we get called because the build's broken.
I'm very interested in defining the config spec centrally somehow so that all views can use that config spec and we can update it underneath of people. This may seem draconian but when you have hundreds of developers and they're all supposed to be running the same builds, it seems to make sense.
I've already investigated the idea of using a share to store the config spec and then include it in the developer's views using an include line, but as the documentation states: "Include files are re-read on each execution of setcs and edcs." This appears in testing to mean what it seems to mean, that the only time the rules are re-evaluated are in the context of editing the config spec in some way.
The solution I'm looking for would re-evaluate the config spec every time you interact with clearcase, or at the very least update. In that way, I could manage the config spec for everyone.
Thoughts?
I can work, especially if your included config spec doesn't change too often.
Each time it will change, your users will have to run
cleartool setcs -current
(as explained in the example#2 of this technote)
You will then need to decide where to store that common config spec:
on a share drive
on a ClearCase view in order to benefit from the history feature for that common config spec content.
You can see a full debate in this thread:
However, I have encountered situations where a version controlled
include file was necessary because it referred to plenty of elements
from a legacy code which users had to use to continue their work on some
of the new code. It was pain and we had to live with it.
Just like with any other 'process', this too needs some 'education' to
the users.