BackboneJS ToDo list example with Spring 3.1 (no xml config) and MongoDB(github.com)
github.com
BackboneJS ToDo list example with Spring 3.1 (no xml config) and MongoDB
https://github.com/sdeleuze/spring-backbone-todo
14 comments
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.
Ah phew, another framework for making ToDo apps. It needs to be added to the TODOMakerMaker! https://github.com/mrspeaker/TODOMakerMaker
Backbone is for much more than ToDo apps, this is just the exampe app customized to use Spring 3.1 and MongoDB (here's the original example http://documentcloud.github.com/backbone/examples/todos/inde...)
For more on Backbone here's the official page http://documentcloud.github.com/backbone/
For more on Backbone here's the official page http://documentcloud.github.com/backbone/
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.)
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.)
So, how are you enjoying your foray into Java EE? I may be making a similar move and would be interested in your thoughts. Things like what version of Java EE are you using, what pain points have you found, do you feel hampered by the java environment, etc.
Thanks!
Thanks!
Tools to be productive in Java:
1. Maven + Eclipse/IntelliJ
2. JavaEE 6 and Spring 3.1 (note the specific version)
3. Spring Data (previously known as Hades)
4. JUnit or TestNg and Mockito.
5. Findbugs, Checkstyle, Sonar, and Hudson.
You can ignore JSF unless it is the mandate. Sticking with minimum JSP or transmiting JSON works fine regardless your stack of choice.
PS: JavaEE 6 supports dependency injection and a bit of AOP.
1. Maven + Eclipse/IntelliJ
2. JavaEE 6 and Spring 3.1 (note the specific version)
3. Spring Data (previously known as Hades)
4. JUnit or TestNg and Mockito.
5. Findbugs, Checkstyle, Sonar, and Hudson.
You can ignore JSF unless it is the mandate. Sticking with minimum JSP or transmiting JSON works fine regardless your stack of choice.
PS: JavaEE 6 supports dependency injection and a bit of AOP.
IMHO - I love to work with java, I've used all kinds of JEE frameworks and my favorite setup is Spring 3 + Spring MVC for almost all sites... If I need to work on a form filled web site I would use Vaadin or JSF2 + primefaces + EJB 3.1 (EJB 3.1 which is way better then previous versions).
Java is great and you can be as productive as you want.
Another thing is that the JVM environment is getting richer every year, with more Frameworks and languages.
As I said before, Java is a work horse. My fun coding is now in Javascript and Scala, but to work, for me nothing beats Java and it's stack.
Java is great and you can be as productive as you want.
Another thing is that the JVM environment is getting richer every year, with more Frameworks and languages.
As I said before, Java is a work horse. My fun coding is now in Javascript and Scala, but to work, for me nothing beats Java and it's stack.
I've never understood the intensely nested folder structure of Java apps. See: http://c.boxd.in/2S3X3n1s0x3d042j2A09
Or, why is the code at:
Or, why is the code at:
spring-backbone-todo/src/main/java/org/resthub/todoThe src/main/java part is a Maven convention: http://maven.apache.org/guides/introduction/introduction-to-...
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.
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.
You have to admit having a folder per package level is a bit silly, especially considering so many projects contain empty "org.foo"/"com.bar" folders.
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)
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)
'(no xml config)'
'/pom.xml' in root folder
'/pom.xml' in root folder
I admit, the title isn't completely descriptive.
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
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