well, ive tried to write 3 posts so far but then found the solution just right before i hit submit :P
but ill tell the whole history for this one
i got an XML that got menus information on it, like
i use XStream and transform the XML into an ArrayList, so my rich datatable can read it, all good
i found myself into trouble when i found about more than 2 ppl are using my app at the sametime, so remembering my college 2 years ago, made an intermediate class between the Xstream parser of my XML and the managed Bean and made a Singleton of it
so now everyone who opens a different session gets the same instance of the class instead everyone working the XML on tis own, all good
now i realized i gotta make sure one user update the other user browser window... so i did an Observer pattern long ago as well, but now... how i do that here? my managed Bean gotta extend observer or something like that???
also, i know JSF is a framework that make things easy and i know it implements patterns as Singleton and Observer by itself, but it looks like it refers to patterns for the ui controls only, and what im doin involves bussiness rules right? or im missing the simpler solution?
Welcome to the JavaRanch, Pablo. Could you please use standard English? The ranchers claim a speak a lot of languages as their native ones, and Standard English is confusing enough to them, much less creative variations.
It's important to remember that webapps run on somewhat different rules than traditional client/server apps. One of the most important ways that they differ is that HTTP cannot emit unsolicited responses to clients. So if you have 2 users and one updates the model, the second user won't get notified. He or she will only learn of the update after making a view update request.
You can use the synchronized method attribute to ensure that critical data isn't being modified by 2 separate request threads at the same time, but in JSF, the individual properties are addressed one by one, so there's no way to transaction-wrap a set of property updates. So you can get atomic updating for properties while still having the bean as a whole get corrupted if you're not careful.
Then again, that's really only a concern for application-scope beans. Session and request scope beans are not singletons.
What you do "behind the beans" - that is, in the business layer - is entirely up to you. As you have surmised, JSF is a display technology. So your singleton bean will be better off if JSF backing beans front for it, rather than making it a backing bean itself.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Aug 11, 2009
thanks for your reply
and im sorry for my english, my main language is spanish and all the english i learned was playing PC games :P, i need to work my programming and my english a lot
i never tought that a session bean would be such a problem until 2 users tried to make critical changes as you said, at least now they use the same array which is good, im comparing changes on every user before making a final array to be saved on the XML
ill make each user get an update somehow, timed maybe, i read a post about updating the session managed bean, putting some initial code on its constructor but i couldnt make it work
De nada. Main thing you need to work on is that silly little rule where the pronoun "I" is always capitalized even though none of the other pronouns are. That and contractions. Unlike Spanish, where "De el" would become "Del", in English, we use an apostrophe as an indicator that something was removed. Por ejemplo, "I am" becomes "I'm".
Well, technically, you also should capitalize "English" and "Spanish", but most people will forgive you that one.
So much for language lessons.
As I said, your biggest challenge is that any changes you make to the singleton won't get pushed back to the clients. Instead, the next time the client makes a request, that request will find a changed singleton. So you have to allow for that.
Joined: Aug 11, 2009
I found out that refreshing the managedBean IS NOT equivalent to refresh the view :P
I also found that my 2 clients do get the updates from the other (because is the same array being called thanks to singleton), but there is nothing that tells the other client ui components to get rendered
so I used an a4j:poll and it refresh the view perfectly :P, although it feels like cheating because a real solution would be my model tell the view to get updated and not the view refreshing itself
HTTP is a request/response protocol. You send a request and you get a response. Requests and responses must always be paired. There's no way for a web server to send a response (view update) unless the client makes a request. For one thing, unlike non-Internet client/server applications, on the web, each request/response cycle is like you logged in, did the page request, got the page response and logged back out again. This is why we have session objects. Without something to hold ongoing state, web sessions as ongoing conversations would not be possible.