Howdy All,
Just trying to explain to some colleagues how some of Wicket works (differently than most other Web frameworks), so please correct me if I am wrong.
From my understanding Wicket differs from most other Web frameworks in that it doesn't manage the creation of the object graphs representing Web pages (it's done simply through the Java new operator and composition of objects by the constructors within that super hierarchy).
The positive side of this is that it removes the need for Web page factories that take strings as arguments to construct the object graphs, and thus are not easily refactored within Java IDEs. The "negative" side of this is that page caching now needs to be done by saving the object graph in some form, e.g. directly in the session or serialising to a file.
The more common alternative, as mentioned above, is to have some sort of factory that manages the construction of the object graphs representing Web pages. As the framework can do this, as needed, it doesn't need to cache the entire object graph, it can just save the data needed to refill within a Web page.
Of course, this is probably just one difference and may not be the most important aspect of Wicket. It is, however, I believe why Wicket needs to have detachable models, so that the large models don't also need to be saved.
Apologies in advance for any mistakes or poor communication. Any comments or clarifications?
Cheers, Ashley. -- Ashley Aitken Perth, Western Australia mrhatken at mac dot com Skype Name: MrHatken (GMT + 8 Hours!) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
