Re: The Wicket difference ...?
Hi, On Mon, Sep 29, 2008 at 4:13 PM, Ashley Aitken <[EMAIL PROTECTED]> wrote: > > 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). correct > > 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. also correct > 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. also correct. however this gets more interesting when you want that object graph to be dynamic. Frameworks that use the approach you've mentioned (such as tapestry) are usually having static component tree which can be a major flexibility limitation. > > 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. correct -Matej > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Wicket difference ...?
Ashley, Take a look at chapter 1 of Wicket In Action (free download at http://www.manning.com/dashorst/). Regards - Cemal http://www.jWeekend.co.uk http://jWeekend.co.uk Ashley Aitken wrote: > > > 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] > > > -- View this message in context: http://www.nabble.com/The-Wicket-difference-...--tp19724703p19727253.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The Wicket difference ...?
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]
