Marc Cracco

Ranch Hand
+ Follow
since Mar 09, 2010
Merit badge: grant badges
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 Marc Cracco


I've been a java dev for about 5 years now and work on a spin off of Apache's ofbiz platform. Ofbiz is a huge MVC platform and the offshoot I'm on has hibernate added as an ORM, so I can say I have a bit of experience w/ MVC design that include hibernate. I've looked at working with Spring a few times but every time I start working with it I feel like I'm going from being a java developer to an XML one. It just feels like the platform is hugely built around these xml files that, to me, feel like they're sucking the joy out of coding. Is this something I just need to get past that's only there as part of the infrastructure of my project or is this something that I'd be constantly doing working on a Spring project.


Hope no one minds but trying a bump before I post elsewhere.
So I'm probably doing this all wrong but here goes...

I have two objects Party and Event.



and then the association table


In my party.hbm.xml I have

Now here is a query I try to run:

The code builds and start properly but when I try to run the above query I get:

illegal attempt to dereference collection [] with element property reference [eventType]

Also am I looking at this correctly: My events are unique so my party to event is a 1 : many but my event to part is 1:1. Using a table to map a relationship to the two how would I setup the hbm file on the event to get it's party since it's not a set and a one to one entry doesn't show an association table to use?
I am using jquery but still try to keep the view setup where it's meant to be (imo anyways), that being the templating engine of my Web app.

Bear Bibeault wrote:By your description, the HTML might or might not be used. If it's going to be used 99% of the time, then maybe, maybe, I'd include it. Otherwise, why include something that might be discarded?

Worrying about performance at this juncture, rather than doing what makes the most sense (unknown without more info), is premature optimization.

Another point: is there a bunch of metadata that needs to be returned, or just status? If the latter, then the response status should be sufficient. Custom response headers could also be used to convey metadata.

The response will always be used but based on the status then the browser will react differently, in some case it will stay as is after inserting html in others it might just focus to another tab and so on. Custom response header are a good possibility, didn't think of that option. I'll look into it because at this point my response status are very simple, i.e. success, failure, error.... As for worrying about performance, it's a must at this point since this is a release to a live production application. I don't want to have to redo most of my view logic because I moved it from server side to client side. Another reason why I really hesitate adding a lot of complex view function to the client side is browser compatibility. We support all major browser in this instance will still need to support IE7.... You can see where I would try to keep the actual JS to a minimum.
The slowest part of most transactions can be the transit time back and forth, why would you do a double request when you can do it in one? What's the downfall to nesting html in a json obj?

Ulf Dittmer wrote:It sounds like returning HTML is not the best approach; why does it do that? Rather it sounds like JSON that encapsulates status code and data would be the way to go.

Because there is a large amount of formatted data being returned in some case and passing just straight json data and then having all the processing done on the client side would be much more time consuming (and probably slower, I doubt the JS engine can pump that data out as fast as my backend server). Also parsing and styling large amount of html based on conditions isn't the javascript engines job. In some case we're talking formatted forms which depending on the situation could be different and in some case contain values while in others not. To code all this in JS seems like the worst thing possible to do, especially when I have a full blow templating engine built in to my webapp.
So I'm currently working on a webapp (tomcat) where all ajax calls from clients get routed through one servlet. They all share a common url and then based on parameters the work gets routed to different areas of the app. The main thing these all have in common is that they return html. The problem I'm running into is that based on conditions (i.e. success, failure...) I will not only return different html but need the browser to act differently. In some case I might want to change focus onto something else, or hide something. I need to pass more than the html back to the browser. I was thinking of using a json object as a wrapper for the html and the status of the request. Is there any downfall to doing so? any better way to do this?

Sorry if this isn't the best location for this. Mods feel free to move if needed.
More documentation for those who might have similar issues.

JQuery Ajax Documentation

Mozilla Article on CORS that led me to figure out my answer.

Bear Bibeault wrote:Thanks for posting back with your findings.

So here it is... this can be done:

had to add

as an ajax param

as my response headers
Further look into this seems to show that Firefox sets the domain correctly yet chrome does not. Interestingly enough is that while the response in firefox shows the cookies they are not being stored.

Bear Bibeault wrote:From the point of view of cookies, they are different domains. Whether you are using CORS or not does not affect this. The cookies, and therefore the session, will not be shared across the different domains.

The TOMCAT cookie is never set to include http or https so it's the same domain. It just returns a cookie with domain set to and the cookie is used on both http and https pages afterwards. If it were considered different domain then why would the same cookie that I normally get on an http page also work on an https one? My problem here isn't that they are different domains, it's that the domain value isn't being set.
To put a little bit more detail on this. I am aware that this (http to https) XMLHttpRequest is considered different origin according to the same-origin policy. I am making use of the cross-origin resource sharing mechanism by adding a header to the response "Access-Control-Allow-Origin" with my http domain name. This seems to enable me to get the response accordingly but this is when the cookie domain return blank.
I'm hoping someone can help me out with this as I'm a little rusty when it comes to ajax requests. I'm working on a webapp (Tomcat is embedded) where we want to allow the user to login via an ajax call.

Let's say the user is on and clicks to login, a popup opens asking for creds, that form submits via ajax to which in turn verifies credentials and returns a response including the Tomcat JSESSIONID cookie and ROUTEID cookie. When hitting the login url directly I get the correct response with cookies, when hitting it via ajax I get the correct response with cookies EXCEPT the cookies domain value is blank and therefore not associated with which leads to the user not getting updated as logged in. Any advise?

To note I did post a question on StackOverflow 2 days ago but have received no answers.