This is a great idea . However as a long time Spring user , could I ask that you spin this in to full blown tutorial . Heck I will pay for an ebook (<$15) which shows Client Side Coffeescript + client side MMVC+ some client side templating + client side state with Spring on the server side. Go slow and easy on the client side JS part -- after all you would be talking to Java guys ;-). You don't need to worry about server side xml -- that is natural for us Java guys.
Sorry, but What's so special about this ? I work with Spring and can't see why it would be hard to use it with Json and Backbone.JS.
Anyone could point me the reason ?
For a Java developer, this is interesting since one might not be aware of new js libraries like Backbone.js. Java EE crowd seems to be too much embodied with only Java EE stuff that they should be aware of new stuff like backbone.js. Of course, for someone that frequents HN, backbone is familiar, but in the company I work (a Java EE shop), noone other than me has heard of backbone.js (not even other stuff like node.js)
For a non-Java developer, it might either break the myth that Java EE is too much based on XML, or reinforce it. Spring, JAX-RS, JSF etc. now allow no-XML configuration, and they are not as verbose as they used to; but still it might seem daunting for someone outside (I'm also someone from outside in this respect too, I have been doing Java EE only for the last 3 months, (I had Django/Python experience before) and it has been hard to get to learn all the Java EE technologies by myself (e.g. how many ways are there to do DI in Java EE? Spring, CDI, JSF, with or without XML etc.)
This project has a "pom.xml" (Maven configuration file) in it's root directory, so it is using Maven. While you could use alternate folder structures with Maven, that requires configuration, whereas if you use the convention, Maven reads these folders by default. So if you also had a src/test/java folder, Maven would know that your unit tests are in that folder, and would automatically run the tests as part of the build.
The org/resthub/todo part maps directly to the Java package (namespace), which would be "org.resthub.todo". As darklajid said, this is a language requirement.
These deep folder structures can be annoying if you are using a regular file browser, but Java IDEs generally flatten out the packages, so that you see all packages all at once in a list, so you don't have to do a lot of expanding of subdirectories.
Having a toplevel src/ (vs. lib/ or test/ etc) is just a convention and I have no problem with that one.
The last part of the path is required by the convention of having a unique/meaningful namespace/package name and the language requirements (not sure if I like that or not, C# doesn't have this - sometimes I love that, sometimes I curse when I search for the file that contains a certain class):
- Namespaces have to correspond to folders.
- File names have to correspond to the (first?) public class declared within.
(From memory, I hope I have no _really_ big flaws in there. Haven't touched Java for quite some time)
[+] [-] badmash69|14 years ago|reply
[+] [-] mrspeaker|14 years ago|reply
[+] [-] moondowner|14 years ago|reply
For more on Backbone here's the official page http://documentcloud.github.com/backbone/
[+] [-] cfontes|14 years ago|reply
[+] [-] ludwigvan|14 years ago|reply
For a non-Java developer, it might either break the myth that Java EE is too much based on XML, or reinforce it. Spring, JAX-RS, JSF etc. now allow no-XML configuration, and they are not as verbose as they used to; but still it might seem daunting for someone outside (I'm also someone from outside in this respect too, I have been doing Java EE only for the last 3 months, (I had Django/Python experience before) and it has been hard to get to learn all the Java EE technologies by myself (e.g. how many ways are there to do DI in Java EE? Spring, CDI, JSF, with or without XML etc.)
[+] [-] whalesalad|14 years ago|reply
Or, why is the code at:
[+] [-] nileshk|14 years ago|reply
This project has a "pom.xml" (Maven configuration file) in it's root directory, so it is using Maven. While you could use alternate folder structures with Maven, that requires configuration, whereas if you use the convention, Maven reads these folders by default. So if you also had a src/test/java folder, Maven would know that your unit tests are in that folder, and would automatically run the tests as part of the build.
The org/resthub/todo part maps directly to the Java package (namespace), which would be "org.resthub.todo". As darklajid said, this is a language requirement.
These deep folder structures can be annoying if you are using a regular file browser, but Java IDEs generally flatten out the packages, so that you see all packages all at once in a list, so you don't have to do a lot of expanding of subdirectories.
[+] [-] darklajid|14 years ago|reply
The last part of the path is required by the convention of having a unique/meaningful namespace/package name and the language requirements (not sure if I like that or not, C# doesn't have this - sometimes I love that, sometimes I curse when I search for the file that contains a certain class):
- Namespaces have to correspond to folders.
- File names have to correspond to the (first?) public class declared within.
(From memory, I hope I have no _really_ big flaws in there. Haven't touched Java for quite some time)
[+] [-] thatfunkymunki|14 years ago|reply
'/pom.xml' in root folder
[+] [-] moondowner|14 years ago|reply
No xml config meaning Spring is configured completely by annotations, as described on the GitHub page:
> "XML free Spring MVC 3.1 backend (no web.xml, no applicationContext.xml)"
pom.xml is used by Maven, and every Maven project must have one https://maven.apache.org/pom.html#What_is_the_POM