My Top 10 (some already mentioned):
1. Use LoadableDetachableModels 2. DefaultModels get detached otherwise you need to detach your model manually (as Dan mentioned) 3. Setup components to pull in their data and state, typically via models. This includes pulling in a components isVisible/enables/list entries 4. Feel comfortable with anonymous inner classes, the inline code helps readability, just don't get so comfortable you never refactor it into its own separate class once it gets large (if it doesn't fit on your screen anymore) 5. Make sure your component hierarchy matches your markup hierarchy: did you add the component in your java code? Did you add it to the correct parent (form, repeater, page)? 6. Understand the Form processing lifecycle: Check required, converter, validation, update models, onSubmit/onError. 7. Using Ajax? Understand the difference between AjaxEventBehavior and AjaxFormComponentUpdatingBehavior (the second triggers form processing on the field) 8. Clean up your page layout using markup inheritance 9. The covariant get() methods for WebApplication and Session are super useful, create your own version in your own Application and Session to clean up your class casts. 10. Speaking of cleaning up casts... using Generics on your components (and models) are worth it. And feel free to use <Void> if there is no underlying model or object (I typically do that with Links, Buttons and simple Forms that I'm not setting a specific model on). These things are all fresh in my mind since I'm teaching Wicket this week. ;) Good luck on the article Jeremy! -Clint On Wed, Jul 27, 2011 at 8:46 PM, Dan Retzlaff <dretzl...@gmail.com> wrote: > 1. Wicket's IOC integrations are really easy to get started with, but there > are some gotchas. Since they inject serializable proxies* *to dependencies > instead of the dependencies themselves, the dependency gets > retrieved/created from Guice/Spring each time a page is deserialized. > Therefore, it's very important that you never inject anything that's meant > to maintain state across requests. This took a while for us to learn. > > 2. Also related to serialization, after one year of working with Wicket I > have a new fear/respect for the "final" keyword on local variables. > Generally speaking, any non-trivial, non-Component object should not be > serialized and should therefore not be marked final and used by an > anonymous > inner class. Alarm bells start going off for me when I see that a developer > has made such an object final. > > 3. Setting a default model on a component means it will get detached for > you. If you have a model that isn't any component's default model, you need > to detach it yourself. > > Good luck with your article! > > Dan > > On Wed, Jul 27, 2011 at 4:30 PM, Ben Tilford <b...@tilford.info> wrote: > > > 1. How "static" resources work. For a newcomer this can be > > shocking/frustrating. > > 2. Models are a context that holds a reference to a model. > > > > > > On Wed, Jul 27, 2011 at 5:21 PM, Scott Swank <scott.sw...@gmail.com> > > wrote: > > > > > Jeremy, > > > > > > I just threw together the following, which indicates that at least to > > > me Models are worth 3 of your 10 items. > > > > > > 1. Most components have a backing object of some sort. This object is > > > referenced via a Model. Significantly, the type of the component and > > > the model match (e.g. Label<Integer> has an IModel<Integer>). > > > 2. These objects live in the session and are managed in the session by > > > wicket, so that when the component goes out of scope the object is > > > removed from the session by wicket. > > > 3. Because domain objects are often too large to store in the session > > > there is a LoadableDetachableModel that is responsible for loading the > > > object whenever it is needed in a request and then flushing it at the > > > end of the request via detach(). > > > > > > Cheers, > > > Scott > > > > > > On Wed, Jul 27, 2011 at 3:29 PM, Jeremy Thomerson > > > <jer...@wickettraining.com> wrote: > > > > Hello all, > > > > > > > > I'm writing an article for a Java magazine and would like to include > > in > > > it > > > > a list of "ten things every Wicket programmer must know". Of course, > I > > > have > > > > my list, but I'd be very curious to see what you think should be on > > that > > > > list from your own experience. Or, put another way, maybe the > question > > > > would be "what I wished I knew when I started Wicket" - what tripped > > you > > > up > > > > or what made you kick yourself later? > > > > > > > > Please reply back if you have input. Please note that by replying, > > you > > > > are granting me full permission to use your response as part of my > > > article > > > > without any attribution or payment. If you disagree with those > terms, > > > > please respond anyway but in your response mention your own terms. > > > > > > > > Best regards, > > > > > > > > -- > > > > Jeremy Thomerson > > > > http://wickettraining.com > > > > *Need a CMS for Wicket? Use Brix! http://brixcms.org* > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > >
