After creating a huge mess of a Play project, I decided that it would probably be a good idea to break it into sub-projects so that the dependencies are, I can compile part of the project, etc.
Unfortunately, I'm discovering that the sub-projects have slight dependencies on the whole project. The coupling is small enough that I'm not ashamed of it, but SBT won't let me declare circular dependencies. (And I think that's a good thing.)
Here's an example. I have a users sub-project that defines several models for dealing with users. There are also basic views that you would probably expect for dealing with users: login, logout, changePassword, updateSettings, etc. The problem is, these all depend on my main template so that they look like the rest of the site. So I need some way to let the users sub-project know what the main template is that it should embed its views in.
As another example, most sites have a "default" page that they send users to when they try to access information they're not authorized to access, or after they logout, etc. The sub-projects need to know what that page is so they can redirect to the default page as needed. But the default page is defined in the main project, which the sub-projects can't depend on.
I started trying to solve this problem by using my Global.onStart method in the main project to "inject" settings into the sub-projects. For example, I created a var to hold the default page, and then set controllers.users.App.defaultPage to the right value when the application started. But then I realized that every sub-project is going to need a few hooks to tell it how it fits into the main project, and trying to manually keep track of all this was just asking for trouble.
Has anyone come up with a good way of dealing with this issue? Should each sub-project have a default Configuration that the main project can modify? Is there a way for each sub-project to declare what configuration it needs, so that the main project failing to provide it would trigger an error? Should I be ashamed at how coupled my code is, and go back to the drawing board?
Thanks!
After more searching, I came across this blog entry. I'm going to give this a shot and see how it works:
http://eng.42go.com/play-framework-dependency-injection-guice/
After using this for a couple of weeks, it's been mostly a success. There are still chicken/egg problems to work out, but I think that's because I hadn't really thought through how much each of my sub-projects depended on others.
There's still no really easy way to access routes from parts of projects you don't depend on, but you probably shouldn't be linking to projects you don't depend on, anyway. I did figure out how to specify a main template and urls/calls for things like my "Not Found", "Permission Required", and "Login" pages so that all sub-projects could access them.
Related
So, I am working on a project that includes having a live follow count on it, so how do I add it? I also do not know how I can acsess the api base from inside the project.
I have wondered and I have not came up with a viable solution.
That is not possible, but it might be upcoming in a later Scratch version. For now that is beyond the limits of scratch. You can make a view counter that updates a cloud variable by one every time a project is loaded, but users could autoclick and cheat the system so that it would provide incorrect values.
Following is a question that is posted on http://dev.eclipse.org in April 2003. The original question is:
Hi all,
in eclipse i have created several java
projects representing different
modules for one web application. i'd
like to configure one output folder
for all of these projects. Any time i
build a subproject the content of the
output folder is deleted, so i loose
the classes of all other subprojects.
I think there must be a switch or
something like that to tell eclipse
not to clear the content of the output
folder when it builds a project - but
i just can't find it.
Thanks for your help!
Alex
I am trying to see if I could get a definitve answer for this question. I have tried to find out to see if this question has already been addressed and I was not able to find any except for the following answer:
Window-->Preferences-->Java-->Compiler-->Build Path
The above answer did not help me much.
Hmm... I think this approach will bring more trouble than it's worth. Sure it's a priori a quick and dirty fix to integrating your projects together but you are only pushing the problem forward. It is good practice to keep your modules as isolated as possible from each-other, trying to merge the compiled code in a single location is working against the way the IDE was designed and will only bring trouble.
I would recommend that you look into maven to build and package your modules. Then referencing them is just a matter of adding a declaration in the project that requires it and you are integrated. Of course you will need to learn it but it provides a good base of conventions that when followed yield almost effortless integration. Plus reusing some modules in another project becomes trivial so you gain in all fronts.
To answer the other question in the thread when they wish to make a tree of related projects it is possible though somewhat clumsy. Eclipse will always present projects as a flat list, however the folders can be arranged in a tree nonetheless. Just specify a custom location when creating a project or import the project from the sub-folder. Again here Maven can help a lot with it's concept of modules.
As eugener mentioned in his comment, there are plugins for maven that will make most of these tasks trivial. You may find all you are looking for just by exploring the gui, this said, reading the maven literature will give you good insight on how it works and what it can do for you.
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.
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.
I want to use the "Web Tools Editor" that is part of the Web Tools Plattform in my own RCP-Application. I think i have got some understanding on the RCP plattform by now, but I still have no clue how to access the functionality of the pagedesigner (org.eclipse.jst.pagedesigner) after adding it as a dependency to my project. Has anyone some experience in adding components of the web tools plattform into an RCP-Application and can give me a hint or something?
There's a difficulty with these sorts of requests (I am, myself, trying to include this or that feature that I saw in the Eclipse IDE, every so often).
The trick is to try and identify the component you want to bring in, and then try and pull it into your project, without bringing in too many dependencies.
The first step used to be quite hard, but since 3.4 it is a matter of using the Plug-In Spy - hold down Alt-Shift-F1 on whilst your desired component is in focus should give you a tooltip showing you the class, the bundle, etc etc.
The second step is altogether more tricky and is where I usuaully fail to get any results:
if you are lucky then you can just include the bundle in the launch configuration/.product of your app. Once you hit Add Required Bundles, you are not left with 3000 bundles (i.e. your RCP is now Eclipse).
usually, this is not the case, because the Eclipse team haven't refactored the bit of code you're interested in out into an RCP safe bundle. If so, then you're going to have to do that yourself.
Again, if you are lucky then that will mean moving some classes out of the eclipse bundle into your own, including internal classes, and that will be the end of it - i.e. the dependencies of your desired functionality are all within the bundle.
If you're unlucky, then you need to isolate/reimplement the bit of functionality that is required, and change your version of the copied code.
It is hard laborious, and pretty difficult to upgrade. I realise that none of this is what you want to hear.