looks cool, but apprarently, the wicket devs have something up their
sleeve:)
As for localization, theres also the wonderfully
http://code.google.com/p/jpa-translator/ it's still not completely
there. The goal are to make it transparent..
Maarten Bosteels wrote:
Hi,
I haven't yet tried it out, but I think bean-properties [1] could be
really useful for creating a type-safe, refactorable PropertyModel
It's basically the same idea as wicket models but applied on a
finer-grained level: on object properties instead of objects.
I think it's a really cool idea, with a lot of potential when you want
to get rid of the "string-based" binding used in so many frameworks.
Strange that the project didn't get more attention. It's kind of
stalled for the moment.
Are there wicket users that have already tried to combine Wicket with
bean-properties ?
Other property approaches, but they do require language changes:
http://www.jroller.com/scolebourne/entry/java_7_properties_terminology
[1] https://bean-properties.dev.java.net/
regards,
Maarten
On Thu, Jun 19, 2008 at 7:38 AM, Nino Saturnino Martinez Vazquez Wael
<[EMAIL PROTECTED]> wrote:
I can really see the need for using generics for models, especially if you
do some generic stuff for a detachable model, something like below.
Another thing which I havent that through at all but it would also be very
handy if we somehow could make using propertymodels type safe/refractorable.
Eg something like this new PropertyModel(myObj, MyObj.Property), since it
will be refactorable.. Instead of doing it with strings, but it might just
not be possible, can't see how..
package zeuzgroup.application.models;
import org.apache.wicket.injection.web.InjectorHolder;
import org.apache.wicket.model.LoadableDetachableModel;
import org.apache.wicket.spring.injection.annot.SpringBean;
import zeuzgroup.core.BaseEntity;
import zeuzgroup.core.provider.IDBDao;
public class BaseEntityDetachableModel <E extends BaseEntity> extends
LoadableDetachableModel {
@SpringBean(name = "dBDao")
protected IDBDao dBDao;
private Long id;
private Class<E> clazz;
public BaseEntityDetachableModel() {
InjectorHolder.getInjector().inject(this);
}
public BaseEntityDetachableModel(E baseEntity) {
this();
this.id = baseEntity.getId();
this.clazz = (Class<E>) baseEntity.getClass();
}
public void setBaseEntityDetachableModel(E baseEntity) {
this.id = baseEntity.getId();
this.clazz =(Class<E>) baseEntity.getClass();
}
@Override
protected E load() {
if(clazz!=null)
{
return dBDao.findEntity(id, clazz);
}
else{
return null;
}
}
}
Sven Meier wrote:
IMHO we shouldn't blame everything on the fact that each component has a
model. I'm working with Wicket for three years now and the whole component
<-> model relation worked out nicely most of the time.
I won't say that we shouldn't try to improve the matter ;).
So .. what do you have against using generic for models?
Sven
Ryan Holmes schrieb:
I'm not sure how useful this is, but I think you should seriously
consider dropping generics altogether at this point. Obviously, you should
use them internally wherever it makes sense but keep them out of the API.
Here are my reasons, as obvious and simple-minded as they may be:
1) Casting model objects is not a major pain point. The users who are
most bothered by it are motivated more by philosophical considerations and
personal preference than by actual technical impediments. iow, I've never
heard anyone complain that "man, I like Wicket but all that casting is
really slowing me down and breaking my application".
2) A generified Wicket API will cause actual technical impediments and a
potentially major reduction in productivity. So, in this case, I think the
"solution" for non type-safe models presents worse problems than the problem
it was meant to solve.
3) As you're all well aware, the implementation of generics in Java has
severe limitations and complications. Generics are still very useful but,
due to the implementation, they either don't work or tend to spiral out of
control in complex situations.
4) I think it's inconsistent with the design of Component for it to take
a model type parameter at all (even if generics were implemented cleanly in
Java). Generics work well for classes whose primary purpose is to hold other
objects (like a collection or "Pair") or that represent highly cohesive
functionality (like the Comparable interface). Component does not fall into
either of these categories. In fact, the model of a component should be
entirely optional and freely assignable without having to worry about what
type of component to which it belongs (within certain limitations, of
course). In short, I think the Component type parameter makes the
relationship between a component and its model too rigid / inflexible /
brittle.
Another thing I'd like to point out is that I don't think most users know
what they're asking for when they say they really want a generified Wicket.
I don't think they understand the design implications and how much it will
complicate the API and I think they would change their minds if they did.
Java programmers tend to always gravitate toward more type safety because we
know how much value static type checking provides. But, inevitably, an
obsession with type safety leads to a loss of flexibility and an increase in
complexity. At least that's been my experience.
I'm sure most of this falls into the category of "stating the obvious",
but hopefully my somewhat blunt opinion adds something to the discussion...
-Ryan Holmes
On Jun 4, 2008, at 4:53 AM, Matej Knopp wrote:
The generics discussion seems to have no end. But one thing seems to
be quite apparent to me. Most people using Wicket 1.4 on real project
aren't really happy with it. But everyone agrees that there are
benefits too. So say we went the way of generics for models only, i.e.
Component getModel would return IModel<?> and getModelObject would
return Object. We would also leave get/setModel and get/setModelObject
non final (with a big fat javadoc explaining why) so that we would
allow generified subclasses where it makes sense (ListView/ListItem).
What potential caveats would this approach have? (Except maybe for the
obvious less strict type checking)
-Matej
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
