Matt Keller

Ranch Hand
+ Follow
since Aug 22, 2016
Matt likes ...
jQuery Eclipse IDE Java
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Matt Keller

Your approach seems to be not correct.  You don't want to download a username/password to the client, and then use that to get images from server.  Having the user name and password on the browser will make them available to the world.  However, if you don't care about anyone knowing the username and there is no password then your approach is okay.

1) If you are going to load the username to the client and you have no concern about security then use something like jquery's document ready function to go get your images using an asynchronous call.  Keep in mind though that if your images are on a different server than your page came from that this operation is not allowed by the browser and is called cross site scripting.  However, there are some work arounds for this including special javascript libraries.

2) If you password does need to be protected, then you should have your web application server go get your images for your browser.  The browser will only talk to your web application server and the web app server will act as a proxy to the images server, relaying the images through itself to the browser.
7 years ago
Also, as far as I know, you don't need any of those annotations on the bean.
7 years ago
The pattern you are using is not really correct.  Here is an example controller.

Here is an example jsp being used along with it, that displays and submits to the same bean.  Notice that in the example, the field is actually inside another value object inside of the bean.    This is just to show that any level of VO embedding can be done.  I like JSTL better than the Spring tags.


You don't need to use ModelMap.  I just use that for getting stuff out of session.  Your params will land in that first param in the controller which will live only as long as the request.  You have no need for the session unless you want something to persist longer.  In that case you need to annotate a bean as being session scoped up above the controller.
7 years ago
Try changing your date variable to a string just to see if the parameter is making it through to the bean.  If you can verify that the param is making it to the form bean then there is something wrong with your string to date transformation, and you can focus on that.
7 years ago
I think the controller code I pasted for you above is probably your best resource then.  To test your service there is a nice tool called REST Console.  It's a plug in for Chrome.
7 years ago
Those 3 objects you mentioned are our custom code so you won't find them in your libraries.  The service objects are objects with methods that make database calls.  The payload objects are beans with setters which match the property names of the json object that is coming in.  So, say your json object has a property called firstName.  If that payload bean object has a setter called setFirstName then spring will parse the json object for you and send the value into the setter call. The beauty of it is that you don't have to write your own parser.  

As far as your tomcat/spring setup goes, that is complicated and really hard to assist you with through a forum like this.  However, I can lead you to a working instance of tomcat with Spring in it that you can download and use as your example.  Go to the URL in my footer in the message labeled WebRocketX.  It leads to the free SPA framework I am working on.  Go to the downloads page, accept the user agreement etc, and download the dynamic web application demo.  It contains a complete running copy of tomcat with spring, java, and jstl all wrapped up together.  Make sure you read the directions on how to get it running.  It is a windows version of tomcat btw.  If you like our SPA framework well then that is cool too. It is really the most basic configuration of tomcat with Spring you can have so its a good starting point for you for whatever you want to do with Spring and Tomcat.  I think almost all of the Spring configuration is in the xml files in the "web-inf" folder.  I hope this helps.
7 years ago
Here is what the controller for the json service looked like.  The Spring annotation @RequestBody does the magical parsing of the incoming json into your bean.

7 years ago
I'm not sure this will help you, but I worked on a project where we made both an MVC web application and a restful service run out of the same spring instance.  We just had a different controller for each.  You just map the controller methods to different URLs, and the service URL is not protected by Spring security.  The service URL instead validates the credentials that are sent as xml entries within each service request.
7 years ago
Are you sure you want a "big data" database at all.  Keep in mind that they have no foreign keys and therefore not many mechanisms to enforce relational integrity.  Of course these databases are are new and exciting but make sure that you have the right tool for the job.  If your system has a lot a data relationships and won't be storing a bunch of multi-media files you probably want to go for a classic relational database.  Here is a good article I found on the subject.

Now for which one is best.  Others have written more than I can hope to. Here is a link.
7 years ago
The notation you are using already appears to be a class search because you are using a period.  If you are searching by "id" you should use a "#" symbol.  Like Bear said you should give them all the same class and then hide them.  Keep in mind that this class can just be for your searching convenience and does not need to style the divs.  Also, the nice thing about classes is that you can put multiple in the class tag.  So, if you have a real styling class there you can keep it and it just sits alongside your "search class".  For example.

Oops. Forgot my footnotes.

* its hard to get away from having at least some state on the server, so frameworks are often still used there, like Spring for example
** advanced jquery libraries like jqueryUI register their own events on objects and since JsMVC frameworks do active DOM manipulation the libraries can step on each other toes.  This is the reason the Angular community for example has developed Angular equivalents of popular jqueryUI libraries because to avoid blowing up the library has be aware of the angular event model.
*** common JsMVC libraries are Angular, Ember, and JsMVC (the original)
I can categorize some approaches for you, but you can't completely separate what is on the server from what is on the browser because the server delivers the information to the browser.  However, I will start with what is commonly referred to as the "view".  I have not worked with Ruby or .Net so I will leave those out, but they of course are alternatives.

Server MVC Full Page Refresh (almost all state is on server):  Server side rendering of Markup (Spring, Struts, JSF, PHP) -> HTML5, Javascript [jquery, bootstrap], CSS [boostrap]

Server MVC Partial Page Refresh (still state on server but less, and more state on the browser):  Server side rendering of Markup (Spring, Struts, JSF, PHP) -> HTML5, Javascript [jquery, bootstrap], CSS [boostrap] <-- Note the stack is pretty much the same but you can gain a lot by building a Single Page App. You actually see a lot of this is architecture in the form of one off injected pages on major websites, like Netflix, TurboTax, lots and lots of places.  However, very few places have fully committed themselves to making their whole website a SPA because its just too easy to retrofit an injection here and there on top of their full page refresh.  However, I believe everyone will be going SPA eventually.  It seems that simpler apps with little need for state on the server are probably the best candidates for the REST service model outlined below.  While larger very complex sites with complex user states and strict security requirements will become HTML injection SPA's.

Server REST service: Server side is stateless json services (no ss frameworks ideally*) -> HTML5, Javascript [jquery**, bootstrap], CSS [boostrap], JsMVC***
It's been my experience that jquery, for instance, works in all mobile devices, on all the mobile device browsers.  By the way, jquery is just standard javascript, but they do all the branching for DOM manipulation for different browsers for you under the hood.  So, I am also wondering what doesn't work.  

It depends on how your using ajax.  If you are going to change your whole application to a restful service/json ajax model, then I'd say you are starting from scratch.  If you want to start bringing in partial pages instead of full pages then its more like you are just breaking up your current application into smaller pieces.