Not attaching a model to a component is an anti pattern, I agree on that. However it is not an anti pattern to want to access your model outside of the component you're attaching to.

When working with detachable models, you generally want to postpone getting the actual getting of the object as long as you can. That case, a lot of those models will only be attached on rendering components, which could be another request than when the models were attached to components in case the render was redirected to.

So, this makes it logical to pass models instead of object references, like:

   public CustomerAccountPrintPage(final IModel customerAccountModel)
   {

instead of

   public CustomerAccountPrintPage(final CustomerAccount customerAccount)
   {

Now, if I decide later on that I want to use the actual object, I could do:

public CustomerAccountPrintPage(final IModel customerAccountModel)
{
super(customerAccountModel);
final CustomerAccount customerAccount = (CustomerAccount)getModelObject();
final Account payable = customerAccount.getBill("payable");
add(new Label("foo", payable.getSaldo());
...


As we now can attach models to pages and panels, the larger part of the problem I had is gone as you can see from above. Still there can be cases where you want to use the model directly before actually coupling it to a component, though it is true that this can generally viewed as an antipattern, just as passing more than one model in constructors is.

JFYI,

Eelco


Chris Turner wrote:



The question that I have is why do we have any models that are not associated with components? I would tend to consider this to be an anti-pattern. The Wicket Model/DetachableModel concept has (in my opinion) a very clear responsibility in providing the binding between Wicket components and the underlying business data or objects. Thus, using models for things other than this is outside the primary contract of the interface. I would like to see some examples of the exact use cases of why we need to use models that are not associated with components and then to provide a mechanism, guidelines or additional functionality that solves this problem without needing to alter the existing model approach.

-1 for changes to Model/DetachableModel
+1 for finding out why and stopping the anti-pattern of using models that are not associated with Wicket components




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop

Reply via email to