On Sun, Nov 20, 2011 at 6:40 PM, jlazeraski <[email protected]> wrote: > 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.
intuition by definition lacks reasoning :) > 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. Wicket is not some framework that came out yesterday. people have built tons of apps with it, and a good portion of them runs in a cluster. so it *can* scale. vegas.com and mobile.walmart.com are good examples of public sites that are built on top of Wicket. i doubt they run on a single machine :) > 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. youve just described the LoadableDetachableModel :) > 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. i mean that sometimes the UI is complex enough to where you cannot fit all the state in a URL. once this happens you have no choice but to use session or make everything a POST. > 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. lets get something straight, Wicket does not require the INSERTION order to be the same as the html markup. only the NESTING of components needs to be the same. as in if you say A.add(B); B.add(C); then the C div has to be inside the B div and the B div has to be inside the A div. > 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. bummer. like youve guessed, in Wicket you would just throw a FileUploadField into the form and if you happen to submit that form via ajax Wicket will do the file upload via ajax as well. -igor > 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: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
