Hi Igor, You have valid points. I've not built a Wicket app yet to compare, so I can't honestly say. My intuition knowing about how session replication occurs to provide at least fault tolerance does however make me believe that in the end, wicket will scale much less than a stateless app with minimal session objects.
Let me explain, however, that you are correct in that most developers that don't know any better just stick everything in the session. It's convenient, and works. Until you suddenly need to handle scaling and fault tolerance. Thinking about that as an after thought is in my opinion a bad idea. I know many developers, architects, even non-tech business folk that come up with the ideas always think..just get it to market..make it work..we'll worry about scalability later.. yadda yadda. Sure..that's possible, but if you've already developed apps and know of the issues that can occur when the time comes to scale.. why not use that at the start of your next project so you don't get into a situation... even if you don't, building the application to be ready to scale is a good thing to do from the start. You bring up a good point as well.. just sticking objects in the session and hoping that the containers can replicate them correctly, is what most developers do. However, with a little bit of thought, you can provide a very scalable statelss application while putting whatever you want in the session. The trick is a hybrid database/memory approach, and I don't mean cache. I mean, you put in the session only the info you need to help reconstruct the rest of the user session. For example, a User object with a List of emails.. do you need the List reference in memory? No. It's convenient, but you can retrieve the list at any time with just the user id of the User object. So rather than make the List serializable so that it too replicates across the cluster using up memory on two (or more) servers.. you only replicate the UserID. When the user.getEmails() is called on another server (perhaps due to the 1st server failure, or round robin with no regard to session->same server balancing), it will see it's null and then load it up from the database at that point. Now, the list of emails is still not in the session, but it's reachable from the user object that is in the session. Even so, the User object isnt replicated either..just the id. That way you're barely doing any replication and the memory used is only temporary while a user is logged in and it's not part of the session, its held in memory via a reference. It works very well, assures minimal replication time and memory use, and allows for the app to be almost completely stateless. I am not sure about what you mean when a web page sends tons of data? A Form can submit plenty of data, as can an XHR ajax request at any time. File uploads along with data can be sent via XHR or FORM or iFrame FORM post. So I am unsure about your argument with regards to some pages having tons of data. My guess is you were referring to completely stateless on the server side such that ALL the user data is sent back as part of a page, and then having to all be transmitted again..thus the server is stateless? Yah..I will agree that is bad too if that is the case. Using the hybrid approach, all of that is handled. As for the object tree insertion in the same order as the page.. well you may very well be right. I just cringe at the thought that you have to always insert something in the same order as it appears in the object tree on the page. I haven't read the entire post you linked though, and given that Wicket 6 is coming, and I am not at liberty to use Wicket just yet anyway, I'll wait and see what it provides to alleviate that issue. On another note.. I did want to mention about the use of components and ajax. I've read many comments that ajax support.. or perhaps components with ajax built in is a bit weak within Wicket. I absolutely HATE dealing with javascript, css, layout issues across browsers, platforms etc. If there is any one thing that would make me switch, it's this. Right now I am trying to figure out how to add a jQuery file upload feature.. and while there are some good examples.. I imagine with Wicket it's as simple as inserting a single component that handles file uploads? It's frustrating because while I know javascript somewhat, I've not used it much the past many years and a lot has changed.. or perhaps a lot of new creative libraries have just been built. Regardless.. I've spent the better part of 5 days trying to get this stupid dialog to upload a file and the server code to handle it and still don't have it working. Part of the reason is I have to work within two other developers existing code and not break anything, but this along with css layout issues is the most aggravating part of my job.. I know some of it, just not an expert in all areas from the UI to the back end. It's part of why I am a bit afraid to try to start my own contract company and bid on projects..cause I know about 80% of the front to back.. but I am not an expert in database, and not an expert in UI. Kind of pisses me off that so many jobs these days want people that are experts in every area of the process.. and pay about 1/2 of what we got a couple years ago. Ridiculous! </rant> -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4090297.html Sent from the Users forum mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
