I am attempting to integrate kendo into my site, and one of the processes I need to do is to build it with gulp.js. I notice that kendo already has grunt.js support, but that isn't what I am using; I tried to reverse engineer its own gruntfile.js to figure out the right way to do this, but have met with nothing but failure.
In general, the main thing I cannot figure out is the order to assemble the files in. I simply cannot find this anywhere. There are so many, I only know that kendo.core.js needs to be first. Is there a list somewhere of the correct order to put all of the other kendo.*.js files in to get the same result as kendo.all.js that I would get from the CDN?
References:
kendo ui gruntfile.js
Try in the order they're listed in here (the complex widgets that are part of commercial and not listed there, e.g. the grid, should go last).
Related
I'm pretty new to laravel and so far I'm liking it. Due to some situations where I forgot to include my new js or css files into my layout, Im looking for a way to link all files from those folders.
Im totally willing to create this myself, but I'm not sure what is the best way to do this. So far I have registered some serviceproviders, like viewcomposers and helpers. I was thinking I can make another viewcomposer which collects the folders I want, and link it to the desired layout.
But I don't want to create unnecessary functions (which might already exist). I'm hoping you guys can give me some insight in what's possible in laravel, good/bad practice, useful classes to use etc.
I wouldn't do this.
I would use Elixir (depending on which version of Laravel you are using) to compile and version my assets. This will mean that you only need to include the references to one file CSS file and one JS file in your view.
https://laravel.com/docs/5.3/elixir
You then just need to maintain your gulpfile.
Versioning your assets also means that you never need to CTRL+F5 to refresh them.
I have many bundles (let's say hundreds) and it is quite difficult to specify relation between bundles+features-distrubutions in UI. Image, at first I define all relations between bundles, features and distribution. Than I want to update some bundles... it is almost impossible to find them in current implementation of UI. They are not groupped and one list of all bundles without any search bar is really hard to work with.
Is there any support for a file based solution. For example Apache ACE would watch a certain folder containing distribnution's bundles. When ever I make a change there, it would be propagate it to all targets.
There is currently no file based solution that matches what you describe, however, I think there are still a couple of solutions that might help you:
There are two types of associations between artifacts and features in ACE: static and dynamic ones. The latter can be of help to you, as they always automatically bind to the highest version of a bundle. So, once you've made all your associations, you can simply upload a set of newer bundles and the associations will adapt.
There is also a REST API you can use to programmatically talk to ACE. You can use that to further automate your process.
That said, you have a valid point that it is difficult to keep an overview when there are a lot of artifacts in the first column. I would advise you to watch, or even contribute to the following issues that were all created to improve this situation:
https://issues.apache.org/jira/browse/ACE-319
https://issues.apache.org/jira/browse/ACE-320
https://issues.apache.org/jira/browse/ACE-321
I am using WIX installer to develop installer.
I want to enhance the installer in terms of UI. I want to change the images at run-time on the same screen (not like billboard) like below
I have fixed 5 features. So there will be no scroll bar and all. I just want to show the current feature being installed and if any error occurs for particular feature red error icon should be displayed.
Is this possible using WIX
You could probably put stack various images on top of each other and set the hide/show conditions based upon some kind of properties that says if the feature is installed/installing/errored
I'm not sure about doing this dynamically such that you could only have to code it for one feature and then it would apply to all features.
Seeings as you only have five features its probably easy to duplicate the code a few times but obviously this isn't a good idea in the long run in terms of maintainability
EDIT: you might be able to design a T4 template that would generate such a UI for you automatically, in this case the code essentially would still be duplicated but it would only exist once in the T4
See WiX tricks and tips for more on T4 generation
This is my first attempt at creating linked work items in TFS. I'm using VS2010 TFS with the Agile template out of the box. I created a Requirements type Work Item for creating a class specifying several requirements. In Test Driven Design style I created a test project with tests for the requirements.
Now I would like to link the Requirements Work Item to the source code file with the tests. When I select the All Links tab in the Work Item window and then use the Link to button the dialog it brings up won't let me specify a source file. It seems to only want to link to another Work Item. I'd like to link it to the source file so when the requirements change there will be a link to the test source file to be changed. Is there a way to do this. Thanks in advance.
Jon Newbill
The way TFS associates work items with code is at checkin. One of the reasons for this is that a source file might implement many requirements, tasks and bug fixes over time. You want to associate the changes to the file to a work item, not the file itself.
A requirement (or bug fix or task) might involve changes to multiple files so you should checkin files in logical groups. I.e. if you've changed 3 source files and a config file to fix a bug then you can check those files in separately and associate the changes to the bug work item at each checkin. You could also check in all 4 files at the same time and associate that single checkin to the work item.
If you change 3 source files and a config file to fix a bug, and you have also changed another source file to add extra functionality, you should avoid checking this file in with the others as it will be held in the same changeset and associated with the same work items as the bug fix code.
In your specific case, if the requirements change then I think you should probably create a new work item. That way you can see the code that implemented the original requirement and the changes to the file will be associated to the change in requirements.
You can associate changesets to Work Items as seen in this picture
CKeditor's installation instructions tell me to just unzip the whole distribution file on my webserver's production directory. But it is full of files I definitely don't want there, like source code, examples, and even server-side code in PHP. I got rid of most of these files but there is one I'm not sure about: contents.css.
I can see this file uses a lot of styles I definitely don't want to see in my site. My question is:
Is contents.css required by CKeditor, or used by default? Do I even need this file on my production site?
I suppose it depends on what you're using in CKeditor, or what you plan to use later. Personally, I'd suggest renaming the file (something like) contents.css.old and creating a new contents.css file, copy across all the styles that you think you'll need and then destruct-test your implementation of CKeditor, to assess whether you've got all the styles that you need.
Add to, or remove from, that file to get your finished version and then use that one. I'd strongly advise keeping the original version around though, for future development purposes.
To your specific questions, though:
Is contents.css required by CKeditor, or used by default?
I believe so.
Do I even need this file on my production site?
Not so far as I know, its absence will likely cause things to look a little less-pretty, though, until you apply your own styles.
As suggested, above, though, I'd rename the original and then create your own stylesheet with the same name, it's rather easier than going through all the various js files looking for, and changing as appropriate, references to contents.css.