You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Jeremy Thomerson <je...@wickettraining.com> on 2011/07/28 00:29:22 UTC
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*
Re: RFC: Ten things every Wicket programmer must know?
Posted by Michael O'Cleirigh <mi...@rivulet.ca>.
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 FormComponentPanel<BusinessObject> 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 List<VariableFilter>filters
and each Variable Fitler is itself a List<String>optionsList.
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 (IModel<BusinessAccount>backingModel,
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
LoadableDetachableModel<BusinessAccount>() 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: RFC: Ten things every Wicket programmer must know?
Posted by Arjun Dhar <dh...@yahoo.com>.
>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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: RFC: Ten things every Wicket programmer must know?
Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Ten things every Wicket programmer must know?
Posted by vineet semwal <vi...@gmail.com>.
what hielke said +
how to
-- use images from database/filesystem
-- resources as already mentioned including shared resources..
-- show error alert next to formcomponent
-- reusability +good coding practises as already mentioned
On Thu, Jul 28, 2011 at 12:39 PM, Hielke Hoeve <Hi...@topicus.nl> wrote:
> * How models work and best practices for wicket/hibernate
> * how ajax behaviors should be used
> * how are resources defined and used
> * how to make a multilingual site using resource models
> etc
>
> Hielke
>
> -----Original Message-----
> From: Jeremy Thomerson [mailto:jeremy@wickettraining.com]
> Sent: donderdag 28 juli 2011 0:29
> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
thank you,
regards,
Vineet Semwal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Ten things every Wicket programmer must know?
Posted by Ted Roeloffzen <te...@gmail.com>.
In my humble opinion:
The most important thing that you should know are models en how powerfull
they can be used.
Models can be quite confusing, especially to programmers who've just started
using Wicket.
I remember how I struggled with the concept, when I started to use Wicket.
How and when to detach them, how to use them when using an ORM-framework,
etc.
Ted
2011/7/28 Carl-Eric Menzel <cm...@wicketbuch.de>
> On Thu, 28 Jul 2011 11:10:30 +0300
> Martin Makundi <ma...@koodaripalvelut.com> wrote:
>
> > > * "compressing" code by use of ids matching property names combined
> > > with CompoundPropertyModel and/or PropertyListView
> >
> > Oh.. that will lead to fragility.
>
> It can, but in my experience it hasn't. Our domain objects rarely
> change, and if they do, our unit tests catch that immediately. The page
> doesn't even render if the property model doesn't work, so if you have
> a simple "tester.startPage(MyPage.class);" you're safe enough in most
> cases.
>
> This is actually a good point to make for the list:
>
> - Unit test everything you can using WicketTester. It doesn't do
> everything, but it's invaluable as a smoke test at the very least. If
> possible, try and check stuff like visibility and enabled state of
> your components too.
>
> Carl-Eric
> www.wicketbuch.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Ten things every Wicket programmer must know?
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
Hi!
>> > * "compressing" code by use of ids matching property names combined
>> > with CompoundPropertyModel and/or PropertyListView
>>
>> Oh.. that will lead to fragility.
>
> It can, but in my experience it hasn't. Our domain objects rarely
> change, and if they do, our unit tests catch that immediately.
It will bias towards not refactoring domain objects and it migh
require thorough coverage of junit tests (... which is good).
> The page doesn't even render if the property model doesn't work, so if you have
> a simple "tester.startPage(MyPage.class);" you're safe enough in most
> cases.
That's a smoke test, but you might need to see the page in various
states (repeaters, popups, etc.).
> - Unit test everything you can using WicketTester. It doesn't do
> everything, but it's invaluable as a smoke test at the very least. If
> possible, try and check stuff like visibility and enabled state of
> your components too.
I agree. But the more thorough your tests are the more covered you
are, though the more costly it is and more costly to make changes.
For example we have lots of prototype/beta user interfaces and it
simply isn't practical to make thorough junit tests for all and we
refactor a lot so compounds are not an option.
**
Martin
>
> Carl-Eric
> www.wicketbuch.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Ten things every Wicket programmer must know?
Posted by Carl-Eric Menzel <cm...@wicketbuch.de>.
On Thu, 28 Jul 2011 11:10:30 +0300
Martin Makundi <ma...@koodaripalvelut.com> wrote:
> > * "compressing" code by use of ids matching property names combined
> > with CompoundPropertyModel and/or PropertyListView
>
> Oh.. that will lead to fragility.
It can, but in my experience it hasn't. Our domain objects rarely
change, and if they do, our unit tests catch that immediately. The page
doesn't even render if the property model doesn't work, so if you have
a simple "tester.startPage(MyPage.class);" you're safe enough in most
cases.
This is actually a good point to make for the list:
- Unit test everything you can using WicketTester. It doesn't do
everything, but it's invaluable as a smoke test at the very least. If
possible, try and check stuff like visibility and enabled state of
your components too.
Carl-Eric
www.wicketbuch.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Ten things every Wicket programmer must know?
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
> * "compressing" code by use of ids matching property names combined with CompoundPropertyModel and/or PropertyListView
Oh.. that will lead to fragility.
**
Martin
>
> - Tor Iver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Ten things every Wicket programmer must know?
Posted by Wilhelmsen Tor Iver <To...@arrive.no>.
Also:
* How to avoid excessive use of Labels and AttributeModifiers (with ResourceModels) just for l10n, by using wicket:message in the template instead
* "compressing" code by use of ids matching property names combined with CompoundPropertyModel and/or PropertyListView
- Tor Iver
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Ten things every Wicket programmer must know?
Posted by Hielke Hoeve <Hi...@topicus.nl>.
* How models work and best practices for wicket/hibernate
* how ajax behaviors should be used
* how are resources defined and used
* how to make a multilingual site using resource models
etc
Hielke
-----Original Message-----
From: Jeremy Thomerson [mailto:jeremy@wickettraining.com]
Sent: donderdag 28 juli 2011 0:29
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: RFC: Ten things every Wicket programmer must know?
Posted by Clint Checketts <ch...@gmail.com>.
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 <dr...@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 <be...@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 <sc...@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
> > > <je...@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-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
Re: RFC: Ten things every Wicket programmer must know?
Posted by Dan Retzlaff <dr...@gmail.com>.
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 <be...@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 <sc...@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
> > <je...@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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: RFC: Ten things every Wicket programmer must know?
Posted by Ben Tilford <be...@tilford.info>.
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 <sc...@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
> <je...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: RFC: Ten things every Wicket programmer must know?
Posted by Scott Swank <sc...@gmail.com>.
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
<je...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: RFC: Ten things every Wicket programmer must know?
Posted by Carl-Eric Menzel <cm...@wicketbuch.de>.
On Wed, 27 Jul 2011 18:29:22 -0400
Jeremy Thomerson <je...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org