My understanding of a GWT module is that it is a "unit of reusability".
My understanding of an EntryPoint is that it is a module that is mean to interact with a client browser. Thus, I think of an EntryPoint as sort of an "executable JAR", and a module as a library JAR or DLL.
My understanding of a fragment is that it is a sub-component of a module used for the purposes of deferred binding and codesplitting.
So first, if I am incorrect on any of these assertions, please begin by correcting me or clarifying things for me!
If I am correct, then it is obvious that you decompose a module into fragment based on need. You write your module, you test it every which way, you review your soyc compiler reports, and if you see bottlenecks, you begin to fragment and codesplit as necessary, yes?
But how do you decompose an app into modules and entry points?!? Again, I'm sure it all comes down to need and is application-specific. I just read this article on structuring a GWT app, and although it was quite helpful, it still didn't provide any litmus or set of guidelines for decomposing an app into modules/entry points.
I am already planning on splitting my app into two modules: a WebModule and an AppModule. The WebModule would be the "public" portion of the app (the website, if you will), and the AppModule will be downloaded after the user successfully logs in (I do this for security purposes).
But beyond that, I'm not really sure as to how to break my AppModule out into other modules, and how to determine whether or not those modules need entry points. So I ask: if you fragment a module to circumvent network latency issues with the code download, when/why do you modularize an app, and when does a module need an entry point?
EntryPoint is not a seperate module. It is part of a module and has a function which will be invoked when the application is started.
The point of modules is to group logical functionality so you can share code between different projects. Nothing else. GWT already comes with a bunch of modules (HTTP, Activity, Places, Debug). You may have a COMMENT or a USER module in your application if you decide to group it like that.
Codesplitting should only be used where needed. It can be a major annoyance that you can only reference code beyond fragment boundaries through the GWT.runAsync(). I suggest you only take this step if you experience your application being slow to load.
Related
Hopefully this is a question that only needs a fairly quick answer, but I haven't had much luck finding something online that is in terms I understand!
Quite simply, I'm working on my first real project in Java, a text adventure, (using IntelliJ IDEA) and I was just wondering if I need to be splitting my code into modules? So, for my monsters, should I keep all of my monster classes within a module called Monsters, or can I just keep it in the same module?
I only ask because; a) I wasn't sure whether it was a done thing in order to keep the project tidy and b) When I tried to create a Monster module, I received a warning telling me that the files in this module wouldn't be accessible from the rest of the program, which seems to defeat the object to me...
Many thanks in advance for any advice!
I believe you are referring to IntelliJ's concept of a module. As stated on their page:
A module is a discrete unit of functionality which you can compile, run, test and debug
independently.
Modules contain everything that is required for their specific tasks:
source code, build scripts, unit tests, deployment descriptors, and
documentation. However, modules exist and are functional only in the
context of a project.
So, modules should not be referencing the source code from other modules. They should essentially be completely different units.
As in thecbuilder's answer, you should look into using Java's packaging system instead.
By modules if you mean packages, then its a good habit to keep related classes in one package and distributing unrelated classes in different packages.
And to the thing, that the classes wouldn't be accessible, you'll have to make them public to access them from different packages.
More on package structuring :
http://www.javapractices.com/topic/TopicAction.do?Id=205
http://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html
https://stackoverflow.com/a/3226371/3603806
For access specifiers :
Taken from : http://www.go4expert.com/articles/java-access-specifiers-t28019/
I am working on a full-stack spring-java based web app. The app is current divided between two projects each of which produce a war file on build. One project (call it UI) serves as the front-end of the app. UI doesn't have much business logic in it. Mostly HTML templates, and JS/CSS and other resources. The other project (call it Server) carries a whole lot of weight in terms of providing auth, business logic, DB services, REST API for external world etc.
I am running into quite a few problems especially while making security work throughout the app given UI project has no direct way to authenticate a user or checking user roles etc. UI relies on invoking a REST OAuth2 password flow to Server to authenticate. So authentication itself works fine but I am having a tough time checking user access roles or any other fine grained permissions within any code in UI project.
Before I dig a whole lot deeper and try to make this all work, a couple of questions for the gurus here:
a) Is this design one of the acceptable ways to build web apps?
b) Are there any gotchas that I should be aware of if I attempt to bundle the two projects within one war?
I hope this is to the point but let me know if you need any more details, and I will be happy to add color.
Try another concept for separation:
Module 1 = core business logic -> produces jar file on build
Module 2 = web -> produces war file on build
Module 2 depends on module 1. All security stuff goes to module 2.
Hope it helps.
I have several applications that differ mostly based on resources. As of now, I'm copying the code around to each application. This can be problematic. An example, fixing a bug in one, and forgetting to update to the others.
I don't think creating a JAR is appropriate for this situation, as these are application specific UI classes, (actually android activity classes in specific) including the actual app start-up code.
It may be possible to include these source files into several packages, but then I have the problem that each file specifies a specific package name on the first line.
Most of the code is related to the UI and Activity processing. (The actual common code is already in a library). A similar question is posted here.
Are there any elegant solutions to this situation?
A jar is absolutely appropriate for this situation. You should split your application into layers, separating the application-specific classes from the shared code.
I solved this by going with Android Library projects. (Not sure of the details, perhaps they are ultimately jars) Check out details here, specifically the section 'Setting up a Library Project'.
I basically put in all my activity classes (except for the start-up one) into the library.
For true non-UI bound code, JARs, do seem to be the way to go.
I agree with artbristol.
I also recommend to use Maven and:
release the common jars to a corporate Maven repository
declare a dependency with specific versions on these jar artifacts
Like this you don't break applications if you do some incompatible changes.
I have an app written with GWT and GAE where every supported city has its own app. Clearly this is not the best way to manage the map so I want to merge them all into one app. Currently my app is at the urls sub1.myapp.com, sub2.myapp.com, sub3.myapp.com, etc, and I want them to be at myapp.com/sub1 ,myapp.com/sub2, etc. All the supported cities share common code, so I'm going to put all the that code in one module, and have a different module for each piece of unique code block. Is this going about it the right way? How will the different modules interact?
Also, I currently have JSPs at sub1.myapp.com/listofsomesort and I would like to move these to myapp.com/sub1/listofsomesort. Is there a simple way to accomplish this?
By making a module with EntryPoint for each old application, in one and the same application. Each module has one 'welcome page' which you can put in different directories. All the shared code can go into another module. The shared code can be used by the inherit setting in other modules.
The only thing I bumped into was that when you deploy to GAE, ALL modules should have an entry point, also the library modules. I solved it by adding a dummy EntryPoint to them, that does nothing, but still searching for a better solution. See my question at How to deploy GWT Project containing GWT modules without entry points with Eclipse GAE plugin?.
This seems like the job for Code Splitting :) It might require some changes in the structure of your code, though - depends how tightly coupled your classes are. A compile report should tell you if your code splits up nicely, or if not, where the connections are.
I have a large application (~50 modules) using a structure similar to the following:
Application
Communication modules
Color communication module
SSN communication module
etc. communication module
Router module
Service modules
Voting service module
Web interface submodule for voting
Vote collector submodule for voting
etc. for voting
Quiz service module
etc. module
I would like to import the application to Maven and Subversion. After some research I found that two practical approaches exists for this.
One is using a tree structure just as the previous one. The drawback of this structure is that you need a ton of tweaking/hacks to get the multi-module reporting work well with Maven. Another downside is that in Subversion the standard trunk/tags/branches approach add even more complexity to the repository.
The other approach uses a flat structure, where there are only one parent project and all the modules, submodules and parts-of-the-submodules are a direct child of the parent project. This approach works well for reporting and is easier in Subversion, however I feel I lose a bit of the structure this way.
Which way would you choose in the long term and why?
We have a largish application (160+ OSGi bundles where each bundle is a Maven module) and the lesson we learned, and continue to learn, is that flat is better. The problem with encoding semantics in your hierarchy is that you lose flexibility. A module that is 100% say "communication" today may be partly "service" tomorrow and then you'll need to be moving things around in your repository and that will break all sorts of scripts, documentation, references, etc.
So I would recommend a flat structure and to encode the semantics in another place (say for example an IDE workspace or documentation).
I've answered a question about version control layout in some detail with examples at another question, it may be relevant to your situation.
I think you're better off flattening your directory structure. Perhaps you want to come up with a naming convention for the directories such that they sort nicely when viewing all of the projects, but ultimately I don't think all of that extra hierarchy is necessary.
Assuming you're using Eclipse as your IDE all of the projects are going to end up in a flat list once you import them anyway so you don't really gain anything from the additional sub directories. That in addition to the fact that the configuration is so much simpler without all the extra hierarchy makes the choice pretty clear in my mind.
You might also want to consider combining some of the modules. I know nothing about your app or domain, but it seems like a lot of those leaf level modules might be better suited as just packages or sets of packages inside another top level module. I'm all for keeping jars cohesive, but it can be taken too far sometimes.