For an in-browser application written in ceylon-js it would be desirable to reduce the size of the ceylon.language-1.2.0.js file to only that what is actually needed.
This question was answered already.
How to use ceylon js (also with google closure compiler)
But the given solution involves manually editing javascript code resulting from compilation. This is not desirable since a compiler should produce code that hasn´t to be edited manually after compilation (abstraction).
And it is not clear to me if google closure compiler can cope with the ceylon flavour of it in a reliable way.
Is it instead a solution to copy ceylon.language source in ceylon into the project and import only those parts of ceylon.language into the project that are required by it? Then compile to javascript. And then leave away ceylon.language-1.2.0.js at all from the client / in-browser application.
Now my questions:
What parts are needed in the most simple browser application? I think of something like Array(String) and the like.
Has that solution a chance to work absolutely reliable?
Will there be a better solution coming from the authors of ceylon that make this attempt obsolete?
The compilation of the language module to JS is a tricky process, because of the native stuff involved and because there are a couple of declarations that have to be in a certain order for things to work.
Minification is still pending, we are going to do it but it's not the highest priority right now, and we have to determine the best way to solve this problem; one option that has been discussed is to have a version of the language module without any metamodel info, for example.
Since my experience with HTML is fairly rudimentary (and pretty old), I am not sure if my requirement is realistic.
Lets say that I have quite a few files containing Lua source-code, and all of them have the ".lua" extension and available in a particular subdirectory. What I'd like to do is create a static index.html file, which when loaded in a browser, would show the list of the lua source-code files in a drop-down. Once one of the source-code files is selected, I'd like that the file gets loaded into an "area" on the same page, and is pretty-printed, i.e. with syntax-highlighting in browser. I was wondering if I could use something like the google-code-prettyfy for the syntax-highlighting part ? Also, I am not clear if an external lua sourcecode file can be loaded, and displayed within a certain region of html page as being rendered. If yes, would appreciate elaboration on the how part.
A tool like LDoc can be used to accomplish a lot of what you want, much as Doxygen would be used for a C language source kit.
Both are heavily driven by inclusion of specially formatted comments that carry documentation.
I know Doxygen can fold source code into the generated document set, I don't recall about LDoc. Both are actively under development.
It isn't necessarily a bad idea to use both tools on a project, especially if you have C source code implementing Lua modules. You could use Doxygen to build the overall document tree for your engine and C modules, and LDoc to build documentation of the Lua parts. It should be possible with a little care and configuration of both tools to get them to play well together.
I have designed a initial module lazy-loading system for a particular goal. In my special case there're a few modules that are needed to decorate forms and entities of the rest of the app.
However most of my members will only require a single one of them that will most likely never update. That is why I do not wish to load all of these modules in every request.
Now that worked like a charm until I required to provide extra view files from these modules. It appears like the module's
view_manager
config is not it merged into the
ViewManager
which is why the resolver is not capable to resolve the view file. I am now loading all these modules by default for testing -- it works.
My lazy loading mechanism bases on a
ModuleManager::loadModule()
call in case it is not it loaded already.
Do you know easy approach to properly inject/merge the config into the ViewManager? Also is this a general problem that possibly also affects other components? Or is it a error?
Thank you in advance!
I'm totally newbie at using AngularJs and although I've been through the tutorials, I still have loads of unanswered questions in my mind. My main concern right now is how should I divide my application into modules ?
Basically I need to build an app which will act as a portal to various apps, each representing a business functionality (sometimes with little to no relationship with each others).
In the tutorial, they show how to create one app with multiple views. What I need, is one app with multiple modules, each module having its own views (and I'll probably have shared views too).
Has anyone worked on an app with that kind of structure ? Could you share your experience and how you've organised things ?
The AngularJS Seed project (https://github.com/angular/angular-seed) is good but it does not really show how to build a complex application.
[EDIT]
I wrote an article on my blog to explain things in more details:
read it on sam-dev.net and you can now read part II, with code sample.
I'll answer my own question. Not because I think it's the best approach, but just because it's the one I've decided to go with.
This is how I've divided my business modules into folders
app
businessModule
controllers
index.js
firstCtrl.js
secondCtrl.js
directives
services
views
filters
anotherBusinessModule
shared
app.js
index.html
Each module has its own folder structure for controllers, directives, etc...
Each folder has an index.js file and then other files to separates each controller, each directive, etc...
The index.js file contains the definition of the module. For instance for the controllers of the businessModule above:
angular.module('myCompany.businessModule.controllers', []);
There's no dependencies here, but there could be any.
Then in firstCtrl.js, I can reuse that module and add the controller to it:
angular.module('myCompany.businessModule.controllers').controller('firstCtrl',
function(){
});
Then the app.js aggregates all the module that I want for my application by adding them to the dependencies array.
angular.module('myApp', ['myCompany.businessModule', 'myCompany.anotherBusinessModule']);
The shared folder contains directives and other things that are not specific to a business module and that can be reused anywhere.
Again, I don't know if it's the best approach, but it definitely works for me. Maybe it can inspire other people.
EDIT
As the index.js files contain modules declarations, they must be referenced in the html page before any other application scripts. To do so, I've used the IBundleOrderer of ASP.NET MVC 4:
var bundle = new ScriptBundle("~/bundles/app") { Orderer = new AsIsBundleOrderer() };
bundles.Add(bundle.IncludeDirectory("~/app", "*.js", true));
public class AsIsBundleOrderer : IBundleOrderer
{
public IEnumerable<FileInfo> OrderFiles(BundleContext context, IEnumerable<FileInfo> files)
{
files = files.OrderBy(x => x.Name == "index.js" ? 0 : 1);
return files;
}
}
Sam's method seems to be the way to go in most cases. The current Angular documentation has it setup as a module for each controller, service, etc, but this has been contradicted by Miško himself from google.
In a recent Angularjs Best Practices video by Miško, he shows how the structure of modules could be laid out for ease of testing as well as easy scaling. Keep in mind how you structure the modules is not supposed to affect performance within an angular app.
From developing angular apps, I would suggest using the best practices method for the aforementioned reasons. You may wish to make your own node script to generate your controllers, etc for the time being which could include say the module you wish to create the controller in and the name, which would then auto generate your controller and proper test spec creation.
If you want a great read on the setup there is an excellent post here regarding setting up the project based on where you think it will be heading.
you should go to the yeoman https://github.com/yeoman/yeoman and yeoman generator structure: https://github.com/yeoman/generator-angular, it becomes a better solution to setup application than angular-seed. For different business modules, you should create different app and share services and directives
For those who are interested, I made a "modularized" version of Angular Seed that fits better with Misko's best practices: https://github.com/sanfordredlich/angular-brunch-seed-modularized
It's set up with Brunch so you very quickly get page reloading, test running and much more. You can be developing quickly and if you follow the patterns in the code, your application should scale reasonably well. Enjoy!
The draw back I have found to the approach the yeoman generator takes is that it doesn't really lineup with the angular modules so it doesn't feel very cohesive to me. So as the project gets larger and you are working on a particular component I found myself flipping around a lot in the source tree.
I have recently come across a different approach here. This approach groups the files by angular modules and feels more cohesive to me. One possible drawback to this is the fact you are required to build the site you can't just run it in place. The grunt watch task in that project helps with this though.
When I compile the same project with ant many times it gives a different sizes for each compilation
I added the rsl and more option to mxml it works fine ,but the size is still changed
Please any idea to unify the size
This is not really possible, unless you do some, quite involved post-processing. Below is the list of things I know to change the size between compiles, but it may not be exhaustive:
When you compile pure AS3 project or a project that uses framework:
Resources you embed on variables have their class names generated using the current date in the name.
Flex compiler generates a tag of obscure purpose (can be removed manually, but persists in release builds), which seem to contain a GUID and a compilation time or something similar. It is usually found at the very beginning of the SWF file, somewhere after the rectangle of the SWF dimensions.
In a project that uses framework:
All code generation is suspect to generating inconsistent names, particularly, all bindings will certainly produce different assembly upon each compile. Styles and some other rarely used metadata will cause this too.
Specifically for spark skins, which come as sources rather then compiled libraries - some of them embed resources in a bad way, so you would probably need to compile them into a library and plug it into a project, removing the sources from the source path.
All in all, if you are using pure AS3 project, your task is difficult, but doable (will require following certain conventions and some post-build script that unzips the SWF, purges the compiler-added extra tag and zips the SWF back. But if it is a SWF based on the framework - I'd say the effort isn't worth it, just accept it cannot be done.