Re: RFC: Ten things every Wicket programmer must know?
Knowing what my co-workers are like, these are the most important things that I say to them. So this list is directed towards them in particular. 1. When receiving parameters in a constructor or method, a model (an instance of IModel) is almost always the right choice instead of a raw model object. Almost everyone here has mentioned this rule in different words (probably most better than mine). 2. Apply your generic object-oriented programming skills to web page programming. When dealing with pages and panels, know when to use inheritance and when not to. Inheritance is something you should usually try to avoid and use composition instead. Inheritance might save you a couple lines of code but it tends to make the code crazy difficult to understand. Having said that, it must be mentioned that there are plenty of situations where using inheritance is justified. I just think the cost of using inheritance in the wrong place is so high that it deserves to be feared. 3. A page's markup must be kept very clean. It should never be no more than 50 lines, or so. Use panels to separate parts of the page. A (positive) result of this is that the page's java file is probably clean too. The main reason for this rule is that it should always be easy for everyone to get an idea of the general structure of a page. 4. When a markup contains a wicket:id, the corresponding java file should probably contain a corresponding add-method invocation. I.e. the corresponding add-method invocation shouldn't be located in some other (unrelated) java file. For understandability's sakes. 5. Don't be afraid to refactor source codes. Even those that were originally made by someone else. There are plenty of reasons why this is important. One of them is that nobody makes perfect code the first time. You shouldn't even try to make perfect code the first time. It's usually fine if you make monolithic panels (not pages), use plenty of inner classes and make inefficient code. They will be refactored later if they are modified often and if people adhere to this rule. 6. With Wicket as the web application framework you rarely if ever need to create servlets. File downloading is possible with resources and it's possible to create bootstraps too. Okay, this rule doesn't deserve to be in the top 10, but I seriously don't want to see more servlets being made - EVER! :) 7. It's pretty important to learn about all the different types of models. They may be a little more difficult concept to understand than components. 8. WebMarkupContainer is a simple yet useful component that does nothing unless you program it do something. WebComponent is equally simple but less often useful because it can't be a parent to other components. - Original Message - From: Jeremy Thomerson Sent: 07/28/11 01:29 AM To: users@wicket.apache.org Subject: RFC: Ten things every Wicket programmer must know? 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
Re: RFC: Ten things every Wicket programmer must know?
On Wed, 27 Jul 2011 18:29:22 -0400 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? Not ten things, but a few anyway. This is what I really try to get across in training classes: - Understand how models work, that they are a shared reference to a domain object, and they connect your components. If you find yourself shoveling data around manually, have a second, third and fourth look at it, you're probably doing it wrong. - Detach your models. There's a simple rule: Any model that you instantiate or that you get passed in from elsewhere you need to either - detach yourself - or pass it to another component, thus delegating the responsibility for detaching it. Detach it or pass it on. - Try to use as few instance variables in your components as possible. Use instance variables only for handling state completely internal to your component. Use models for everything else - that is, everything that might be visible from outside your component. Internal state is stuff that never leaves your component, neither to whomever called you, nor to anything you call. The latter includes components that you aggregate in your panel. This rule greatly simplifies refactoring later on. - Did I mention that models are important? :-) Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: RFC: Ten things every Wicket programmer must know?
From my experience, stuff where I screwed up or wasted time: 1. Wicket is a UI framework, delegate as much as possible to your own neutral code base service and components. Data Models etc. Both Server and Client Side. Client Side:: Don't wrestle with Grids etc in Wicket; if you can get away with a cheap JavaScript/DHTML implementation instead. 2. Wicket Data Models should ideally wrap you native business objects. Wicket wotks over the native business objects; your business objects POJOs are not designed for wicket. 3. Use Detachable models effectively. (Am still learning the meaning of *effectively*). Example: Everyone talks about using it, but it depends on the underlying business objects in use. If they are poorly designed and load in an in-effiient manner, then load() will mess with re-loading stuff each time. 4. Do not try to instantiate Wicket Components via Spring. there is no sane reason to do this; this was an area of special interest and very tempting. One can rely on Spring for native objects and develop better mechanisms for Components to instantiate over the Spring defined layer. 5. @SpringBean is bloody useful 6. Learn to hack Mount Paths. The default Markup Page classpath relating to the component is Web non-intuitive. Its great if you can live with the default setup but learn to mess around with mounting. 7. Learn to the differences between Markup Inheritance, Use of Panels and Include when it comes to designing reusable templates and reducing boilerplate markup code. 8. Mess around with Fragments; they are useful. Like Anonamous classes ; but just in the markup world. 9. Learn atleast one other Web Framework like Struts, appreciate the beauty of Wicket. 10. Learn to respect velocity templates and the co-existence of Wicket with Velocity. Wicket-Velocity project. - Software documentation is like sex: when it is good, it is very, very good; and when it is bad, it is still better than nothing! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/RFC-Ten-things-every-Wicket-programmer-must-know-tp3699989p3700814.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
Re: RFC: Ten things every Wicket programmer must know?
Hi Jeremy, I think the most important things a wicket programmer should know relate to building their own set of resuable components.Here are my top ten on that theme: 1. Build a reusable set of components tailored for your business domain. 2. Solve a few problems then push up the common functionality into an AbstractBaseComponent class where the other uses are subclasses. 3. Or externalize the component setup choices through an interface and keep the class non-abstract. Then the callers setup an implementation of the interface for each case. The interface would control things like show/hide on no results or enable/disable certain fields, basically any choice that is useful to externalize. 4. Understand how extending FormComponentPanelBusinessObject can hide complexity and provide improved form validation options. e.g. We have a query application and the form builds the Task to be executed. We have a filter that contains ListVariableFilterfilters and each Variable Fitler is itself a ListStringoptionsList. Creating a custom Form component at each layer we can be assured that the complicated elements at each level have been validated properly before the task is submitted. Since the top level submit need only deal with the objects being assembled into the task, their internals are assured to be valid. 5. convertInput needs to setConvertedInput(new BusinessObject()) and this is what the validators run against. Only when they pass does the modelObject = convertedInput. 6. Build separate class files for custom Models and Columns (no dynamic inner classes) since any IDE can easily handle the separation and because having them separate enables more reuse. 7. Know how repeaters like ListView and DataTable work and internalize them within your own panels to hide their complexity from the callers of your panel. 8. Know how to emit javascript to the browser both as one off and in terms of a custom DOM object for your application. Especially important is how to write this javascript so that it will scale. i.e. the panel can be used more than once per page. 9. Understand wicket serialization, typically with the experience of having your spring container with some big data store write out to disk on each page change. A versioned page with ajax and this case is the most fun. And how @SpringBean creates serializable proxies that prevent this. But also how getting an inner object from the @SpringBean proxy will leave you open to the same cascading serialization issue. 10. Understand how to layer models to traverse the BusinessObject graph to access certain fields. Don't use PropertyModels in production instead layer models to access the fields of interest. e.g. new BusinessAccountModel (IModelBusinessAccountbackingModel, Type.ACCT_NUMBER) to create the get/set pair for the account number from the backing model. I can image the backing model being a LoadableDetachableModelBusinessAccount() that loads the account data from the database. See: https://cwiki.apache.org/WICKET/working-with-wicket-models.html#WorkingwithWicketmodels-WrappedObjectModels Regards, Mike - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: RFC: Ten things every Wicket programmer must know?
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. LabelInteger has an IModelInteger). 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
Re: RFC: Ten things every Wicket programmer must know?
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. LabelInteger has an IModelInteger). 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
Re: RFC: Ten things every Wicket programmer must know?
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. LabelInteger has an IModelInteger). 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
Re: RFC: Ten things every Wicket programmer must know?
Hi! I don't recall who the author is and the page is currently down (500 server error), but http://www.small-improvements.com/10-things-about-apache-wicket-i-love is a post I enjoyed reading earlier this year. Regards, Bertrand On 27/07/2011 6:29 PM, Jeremy Thomerson 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, - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: RFC: Ten things every Wicket programmer must know?
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. LabelInteger has an IModelInteger). 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* -
