Joe suggsted JMVC and SproutCore, both of which I've heard good things about, but can't vouch for personally. I can suggest Dojo may provide more of the structure that you're looking for, as I worked on a project with a JS guru last year, and that's what we'd used. It was a true front/back split, though - all front-end code was created and managed by Dojo, and it was all web-service calls to the back-end for the required data.
This approach may be too radically different from what you're used to, and I have to say it was for me as well at first. But having that total separation made things much easier on both of us, and allowed for easier unit/integration testing of each section. That said, the learning curve to understand Dojo - or any framework - and have it be second nature is, in my view, a big one. For people coming from a strongly-type-IDE-handles-some-things-for-me background, perhaps doubly so. I had to giggle a bit when I read a Java developer complaining of 'boilerplate' code. :) Have you considered using JavaScript on the server? Plug - one of JSMag authors is doing a series on Spring and Hibernate integration with server-side JS. This month covered the 'rhino in spring' project: http://rhinoinspring.sourceforge.net/ I know Rebecca Murphey has written about code organization in the past, and she just posted an new Dojo boilerplate project - read more at http://blog.rebeccamurphey.com/ In short, there are answers out there, but you will need to choose a toolkit and focus on learning it and the best practices associated with it to get any long term benefits. On Apr 9, 12:51 am, Ken Egervari <[email protected]> wrote: > I'm already doing these things. > > There are lots of problems that cannot be solved by just your > approaches. > > 1) Dependency management and the proper ordering of loading individual > javascript files. In big projects, you really do want to split up your > code in different files, but javascript is awful here. > > 2) The scoping rules are awful in Javascript, and the whole "var that > = this;" to get around them adds unneeded complexity. > > 3) Dealing with development and deployed javascript with the same > markup adds even more complexity. It is desirable the minify and merge > all the javascript, but this is bad for development. It is just > compounded when you are dealing with app servers and so on. It's so > much more bloated of a process than it should be. > > 4) There are all kinds of basic boilerplate and libraries that even > jquery doesn't provide that must be programmed oneself. > > 5) Rendering big snippets of HTML after a page is rendered that > duplicate the parts of the html already rendered by the server creates > a huge maintenance problem. Sometimes it is impossible to have the > server render the html in snippets because you need to investigate > data before you decide to render... but if you pre-render, it cannot > do this. > > 6) Keeping the contract between your object graph in your java code > and on your client code is a massive pain. > > 7) Testing every page whenever you add javascript code that could > potentially affect the whole site can cause errors that you have no > idea about until it's too late. This forces you to manually test every > stupid thing on your website. > > 8) The automated testing of javascript is hard and not nearly at the > level of ease or reliability as testing your java code. > > 9) As if CSS and html weren't enough, you are now dealing with html<- > > >javascipt dependency through ideas and even markup, as well as css<- > >javascript dependencies. > > The list really goes on and on. For simple stuff... sure... it's not a > big problem. But doing anything complex and it is a royal pain in the > ***. Michael Kimsal http://jsmag.com - for javascript professionals http://groovymag.com - for groovy developers 919.827.4724 -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
