I have a proposal on how to improve WWB to support non-serializable
objects:
First let's take a look at how wicket does it in general - all objects
it displays are wrapped inside a model. You are basically doing the
same thing by either using a Model or a BeanPropertyModel. All you
need now is a hook into the model creation process.
This is best done by a factory that creates models (let's call it:
BeanModelFactory)
public interface BeanModelFactory {
IModel wrap(Object bean);
}
The factory can be held in BeanMetaData as an optional parameter (kind
of like ComponentRegistry is) so it is always available when needed.
And when user passes null for the factory parameter, you could use a
default implementation that does whatever WWB is curently doing ...
probably something like this overly simplified example:
public class DefaultBeanModelFactory {
IModel wrap(Object bean) {
if (bean instanceof IModel)
return (IModel)bean;
else
return new Model<Serializable>((Serializable) bean);
}
}
This way you can retain current functionality and provide
extensibility for the end user.
Please, tell me what you think!
Am I missing something?
Regards, Luka
I had a similar need some time ago, when trying to use WWB to edit
some java classes generated to back an XSD document. Those classes
where instantiated with factories, they didn't had no-argument
constructor, so WWB could not use them.
The problem is that WWB was designed from start with JavaBeans
specification in mind. I believe Dan intended to let WWB 1.0 be so and
rewrite much of it for WWB 2.0, with support for general objects.
Now, WWB 1.2 is about to be released, and I don't think there will
be too much work after that due to lack of time. My guess is that 1.3
will be mostly W1.5 compatibility and hopefully some of the bugs /
enhancements in the tracker fixed.
I agree with you that support for general objects would be great,
I'm not aware of any other issues this could bring, but doing it would
take some effort.
I'm willing to explore your ideas further if you can provide a
more detailed, at least partially working implementation / patch. By
the way, I don't think just casting a non-serializable object to
Serializable would always work.
Best regards,
Daniel
> Now, WWB 1.2 is about to be released, and I don't think there will
> be too much work after that due to lack of time.
Should I then be working from 1.2 on the trunk. I'll try to put
together a simple implementation, and
when W1.5 comes out if you guys feel like it, it could be inluded into
1.3.
> I don't think just casting a non-serializable object to
> Serializable would always work.
No it won't. For obvious reason. I was thinking more along the lines:
if (bean instanceof Serializable) return new Model(bean);
else throw new RuntimeException("Please, provide your own factory
implementation!");
for DefaultBeanModelFactory, which the end user could override to
provide her own IModel implementation.
Can you please describe your problem with XSDs in more detail.
Regards, Luka
I advise you to always use trunk to explore new features. But
please check with Dan what he thinks about those new features first.
> > I don't think just casting a non-serializable object to
> > Serializable would always work.
>
> No it won't. For obvious reason. I was thinking more along the lines:
> if (bean instanceof Serializable) return new Model(bean);
> else throw new RuntimeException("Please, provide your own factory
> implementation!");
> for DefaultBeanModelFactory, which the end user could override to
> provide her own IModel implementation.
>
> Can you please describe your problem with XSDs in more detail.
Yes, I wanted to use WWB to edit a tree of classes backing (and
generated from) an XSD file, I think I generated those classes with
XMLBeans. Now, the classes that mapped to the document sections were
not "beans", I could not do a "new DocumentPart()", but had to call
DocumentPartFactory.createNew() or something like that, where the
factories were generated with the same tool. Now, WWB needs just beans
to create objects whenever you want to add items to a table for
example, so the factories would not work.
I can attempt to recover some code samples next week if you are
very interested, but I don't think you will learn more that what I
explain here.
Regards,
Daniel