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 > >
