The reason is rather simple. We have already an in-house developed XUL-like
framework which provides all necessary information needed to construct a gui
form dynamically (Controls, Masks, Security etc).
My first thought is to reuse these xml files to add() controls dynamically
to a wicket form. So, if all controls (textfields, buttons etc) are created
automatically from an abstract class then i need an abstract data wrapper,
something like the FormData class, to hold the model's data(?).
Then the "only" code remaining to be written would be dummy methods like
populateFormData() and captureFormData(), which can be written easily by
junior (or sometimes aged) programmers not so receptive to new techs.
But maybe i' m wrong. I need to spend a lot more time with wicket to decide
the right direction for my team. Fortunately wicket is really fun !
Edvin Syse wrote:
>
>> 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]
>
>
>
--
View this message in context:
http://www.nabble.com/Simple-edit-form-and-models-tp15186893p15200698.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
