In order to provide nice URLs between parts of our app we split everything up into several modules which are compiled independently. For example, there is a "manager" portion and an "editor" portion. The editor launches in a new window. By doing this we can link to the editor directly:
/com.example.EditorApp?id=1
The EditorApp module just gets the value for id and loads up the document.
The problem with this is ALL of the code which is common between the two modules is duplicated in the output. This includes any static content (graphics), stylesheets, etc.
And another problem is the compile time to generate JavaScript is nearly double because we have some complex code shared between both modules which has to be processed twice.
Has anyone dealt with this? I'm considering scrapping the separate modules and merging it all back into one compile target. The only drawback is the URLs between our "apps" become something like:
/com.example.MainApp?mode=editor&id=1
Every window loads the main module, checks the value of the mode parameter, and and calls the the appropriate module init code.
I have built a few very large applications in GWT, and I find it best to split things up into modules, and move the common code into it's own area, like you've done. The reason in our case was simple, we had some parts of our application that were very different to the rest, so it made sense from a compile size point of view. Our application compiled down to 300kb for the main section, and about 25-40kb for other sections. Had we just put them all in one the user would have been left with a 600kb download, which for us was not acceptable.
It also makes more sense from a design and re-usability point of view to seperate things out as much as possible, as we have since re-used a lot of modules that we built on this project.
Compile time is not something you should generally worry about, because you can actually make it faster if you have seperate modules. We use ant to build our project, and we set it to only compile the GWT that has changed, and during development to only build for one browser, typical compile times on our project are 20 seconds, and we have a lot of code. You can see and example of this here.
One other minor thing: I assume you know that you don't have to use the default GWT paths that it generates? So instead of com.MyPackage.Package you could just put it into a folder with a nice name like 'ui' or something. Once compiled GWT doesn't care where you put it, and is not sensitive to path changes, because it all runs from the same directory.
From my experience building GWT apps, there's a few things to consider when deciding on whether you want multiple modules (with or without entry points), or all in one: download time (Javascript bundle size), compile time, navigation/url, and maintainability/re-usability.
...per download time, code splitting pretty much obviates the need to break into different modules for performance reasons.
...per compile time, even big apps are pretty quick to compile, but it might help breaking things up for huge apps.
...per navigation/url, it can be a pain to navigate from one module to another (assuming different EntryPoints), since each module has it's own client-side state...and navigation isn't seamless across modules.
...per maintainability/re-usability, it can be helpful from an organization/structure perspective to split into separate modules (even if there's only one EntryPoint).
I wrote a blog post about using GWT Modules, in case it helps.
Ok. I really get the sense there really is no "right" answer because projects vary so much. It's very much dependent on the nature of the application.
Our main build is composed of a number of in-house modules and 3rd party modules. They are all managed in seperate projects. That makes sense since they are used in different places.
But having more than one module in a single project designed to operate as one complete application seems to have overcomplicated things. The original reason for the two modules was to keep the URL simple when opening different screens in a new window. Even though had multiple build targets they all use a very large common subset of code (including a custom XML/POJO marshalling library).
About size... for us, one module was 280KB and the other was just over 300KB.
I just got finished merging everything back into one single module. The new combined module is around 380KB. So it's actually a bit less to download since most everyone would use both screens.
Also remember there is perfect caching, so that 380KB should only ever downloaded once, unless the app is changed.
Related
I'm going to deploy a QML based application. Now I'm wondering it's better to use resources system for .qml files and their associated files or using relative addressing or there is a better way?
The first way maybe make the project difficult to manage if the number of qml files and your images become larger and larger. Also I think it would be harder to deploy third party plugins like Qt desktop components.
And the second way is not secure as it should be. Every one can open a text editor and edit your .qml files.
Is there a better way?
Using Resource system :
Binds all the dependencies into one single binary, thus no problem of placing them at exact locations as per the paths given in your code.
Many times you would not want to share your qml code/images etc. [close source projects], helpful in those cases. Also it is more secured as no one can modify your files and cripple your application possibly.
You will not be able to modify these dependent files at run time, which might be required in some cases.
The first way maybe make the project difficult to manage if the number of qml files and your images become larger and larger.
Contrary to what you say, I think its easier to manage them, how so many files there might be. You can see here how easy it is to do using Qt Creator.
Relative addressing:
All the dependencies are scattered at different locations, thus problem of placing them at exact locations as per the paths given in your code.
Since your files are directly available to anyone who would want to access them, unsecure.
If there is a modification required in one the files at run time, you can do it. Eg. having a log file and writing/reading some data into/from it.
Difficult to manage(compared to first approach) when number of files increase as exact paths have to be given.
One personal advantage I have found of second approach is in situations like this :
I need to send my Qt apps for Demos to clients with managers, offshore. These demos go on full day. If some minor UI feature ( eg size of a button seems very small ) is getting too much negative attention, we can direct the manager over call to the respective qml file, and make him do small changes ( eg. scale : 1.5 ) This is helpful as we wont have time to build the whole system, resend the exes to them etc.
Is there a better way? Not that I have seen any. I thinks its a matter of finding which one of the above suits your requirements more.
So, Not a very sophisticated question, but since I never did it before I need your advice.
I have my main project, which includes 2 more sub projects that produces static libraries that the main project uses.
Now, I want to add a Loggin framework to my project, and I want to be able to use it inside my main project and inside my static libraries as well.
As you can witness here, it's not very hard, only 3 files needs to be included.
However, I'm not sure what's the best way to do it.
Adding those 3 files to each of the projects would probably cause symbols redefinition.
Adding to just one of the static libraries is not enough, unless I make the other one dependent on it, which is not quite correct logically.
I can probably make another static library project from these 3 files, and make my project and my 2 other sub projects dependent on it, but it feels like an overkill.
What's the best course of action here ?
Thanks!
Putting those files in yet another separate library or framework would be my take.
You should perhaps reconsider if you really need your sub projects precompiled in static libraries (what advantage is that providing to you? are they really that huge that recompiling them now and then is that bothersome?).
A single Xcode project with everything on it might be a better solution, and is what I usuallly favor these days. That way you also don't have to worry about missing architectures in your libs or having compiled the lib with a compiler version and the main project with another, bugs within the libs can be debugged and traced more easily, etc…
Context
big project with multi maven module or single maven module structure
Question
did you finally use multi-maven-module or single-maven-module structure?
Details
If you've worked on a big project that had long development duration and contains lots of functionality(i.e. not a trivial project), did you choose to split the project into multiple maven modules or went with the single-module approach?
For example, having a multi-module structure, crashes when running maven commands like mvn gwt:eclipse(see http://bit.ly/gs4Rmo). I guess this would have worked well with single module GWT project. And there could be other commands like the above that has issues with multi-module structure.
However, the multi-module structure could bring the benefits of a faster development, i.e. if you separate the "server" from "client" module, you could compile the business logic(server) separately and package it into resulting web archive. Compiling the GWT code, takes about 20 seconds, so if you only modify the server package, it could save you lots of time in the long run.
Which other cases like the one above did you encounter when working with a multi-module/single module project?
Thank you!
A few notes:
On development server you don't have to compile the code "by hand": dev server compiles the code automatically and reloads it. Just keep dev server running, change some code and then reload the page in browser. (this is only true if you change existing classes and don't change project structure)
Multiple maven modules have nothing to do with multiple GWT modules.
You would want to have multiple GWT modules (= multiple entry points) if you have code that executes in different environments: for example you have web and mobile sites that have quite different code bases. Then you would split the project into three modules: web, mobile and common. Then you'd reference common in both web and mobile.
Another case for multiple GWT modules would be if you, for some reason, want to have a multiple host (entry) HTML pages. There are rare cases when you'd want this, for example when you need to do redirects when integrating OpenID. The other case would be that you already have existing Web pages where you are only adding GWT to add some functionality.
Don't split the GWT project into multiple modules just to reduce download size: use Code Splitting instead.
If your main gripe is long gwt compile times then read: How do I speed up the gwt compiler?
We started with multiple modules and eventually merged into a single module. The main reason for this was maintenance of modules is a huge overhead. Each module had a pom to build the UI, RPC layer and backend services. So with 30 modules we had 90 maven projects to manage.
Merging the modules turned 90 maven projects into 3 with one parent level pom.
This considerably lowers maintenance overhead and improves build times. GWT's compiler is notoriously slow so having a single compile parsing source files once instead of multiple times makes things much faster.
On the flip side, a single module means the compiler slurps everything up into memory at once. This could make split points intolerably slow to find if you insert any in your code. Therefore if you intend to split, it may be worth considering where you're putting those points and arrange your project accordingly.
I completed my very first project in zend framework!! Thanks to stackoverflow community!!
While uploading files, i didn't know how to include zend library so i uploaded the whole library in the /library folder of my project base.
Is there a way to determine which library is used and which in not (like compilation that automatically copies dependent files to library folder incase webhost does not provide zend library ..)? i would be awfully bad to manually add each file and test weather the particular library is added or not.
This answer essentially says don't worry about including the whole library. I usually put the whole library in the project library folder, just like you did.
But if it is truly problematic to include the whole library, you could take a look at Jani Hartikainen's Packageizer which, at least in a previous form that I played with, allowed you to specify the components you needed and it would chase the dependencies and wrap them in a neat little package.
Disk space is cheap. Just have the entire ./Zend library directory (and maybe ./ZendX, if you are using that) into your own library directory where it will used. With autoloading, nothing that isn't being used will take up any significant memory. taking even 5 minutes trying to figure out is time (and therefore money) that is more usefully spent writing code.
I wonder if it would be worthwhile/reliable to subclass the autoloader for this and have it optionally log each class it loads during site operation (sort of how Zend_Translate can log untranslated strings).
You could have it turned off normally but in your testing environment you would turn it on (via your application.ini), and have it build your dependency list while your unit tests are running.
I'm developing a web app.
If I include a jQuery plugin (or the jQuery file itself), this has to be put under my static directory, which is under SCM, to be served correctly.
Should I gitignore it, or add it, even if I don't plan on modifying anything from it?
And what about binary files (graphic resources) that might come with it?
Thanks in advance for any advice!
My view is that everything you need for your application to run correctly needs to be managed. This includes third-party code.
If you don't put it under SCM, how is it going to get deployed correctly on your production systems? If you have other ways of ensuring that, that's fine, but otherwise you run the risk that successful deployment is a matter of people remembering to do all the right things, rather than some automated low-risk "push the button" procedure.
If you don't manage it under SCM or something similar, how do you ensure that the versions you develop against and test against are the same? And that they're the same as production? Debugging an issue caused by a version difference you don't notice can be horrible.
I generally add external resources to my project directly. Doing so facilitates deployment and ensures that if someone changes the version of this file in your project, you have a clear audit history of what happened in case it causes issues in the code that you've written. Developers should know not to modify these external resources.
You could use something like git submodules, I suppose, but I haven't felt that this is worth the hassle in the past.
Binary files from external sources can be checked in to the project as well, although if they're extremely large you may want to consider a different approach.
There aren't a lot of reasons not to put external resources like jQuery into your repo:
If you pull it down from jQuery every time you check out or deploy, you have less control over which version you're using. This holds true for most third-party libraries; you probably don't want to upgrade your libraries without testing with your code to see if it breaks something.
You'll always have a complete copy of your site when you check out your repository and you won't need to go seeking resources that may have become unavailable.
For small (in terms of filesize) things like jQuery and images, I'd just add them unless you're really, really concerned about space.
It depends.
These arguments relate to having a copy of the library on your system and not pulling it from it's original location.
Arguments in favour:
It will ensure that everything needed for your project can be found in one place when someone else joins your development team. I've lost count of the number of times I've had to scramble around looking for the right versions of libraries in order to be able to get something working.
If you make any modifications to the library you can make these changes to the source controlled version so when a new version comes out you use the source control's merging tools to ensure your edits don't go missing.
Arguments against:
It could mean everyone has a copy of the library locally - unless you map the 3rd party tools to a central server.
Deploying could be problematical - again unless you map the 3rd party tools to a central server and don't include them in the deploy script.