First of all I want to congratulate Wicket guys for their work. Until today I have developed applications based mainly on SWT/RCP and JSP/Servlets. Currently we are evaluating various frameworks in order to initiate a new
project, which will expose many of our in-house developed system (SWT/RCP)
functions through web.
It seems that Wicket is very close to what we are looking for, because more
or less we have the same logic in our gui applications.
I am trying to create a common template for edit forms responsible to edit
properties of a single pojo. In general, I want to have fool control over
the synchronization between the form’s data and pojo’s fields.
I am posting some simple code. I would appreciate if anyone has the time to take a look and tell me if I am
following a right approach about the models and the binding technique.

Out of curiosity - what are you going to do that needs this "fool control" over the binding process? I find in most cases that using CompoundPropertyModel for the whole form and overriding some fields with another PropertyModel for example is sufficient in almost every usecase. I would do something like:

public class InputForm extends Form {
        public InputForm(String id, IModel model) {
                super(id, model);
                
                add(new TextField("personCode"));
                add(new TextField("lastname"));
                add(new TextField("someSpecialField", new PropertyModel(someOtherObject, 
"fieldname"));
                
                add(new Button("save") {
                        @Override public void onSubmit() {
                                // Save
                        }
                });
        }
}

Wicket takes care of all the manual labour concerning binding you are used to 
from RCP-programming, so why not just let it shine? :)

> Is it too memory expensive to keep instances of pojos inside the form?
> Does the session keeps information for all pages or just for the current
> page?

Normally you supply the form with a IModel, and depending on the size/nature of the model object you would use a LoadableModel to avoid saving the whole object when you move on from that page.

Wicket 1.3 now uses SecondLevelCacheSessionStore per default, and I think only the current page is in memory, and that subsequent pages are saved off to disk, so normally you don't need to think about optimizing for memory usage unless you have a very special case on your hands.

-- Edvin

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to