Ryan Sonnek wrote:
I don't want to sound like a databinder basher,
Oh I hope not, I was just about to link to your post and say nice things!
In my opinion, database access should be abstracted away from the UI
layer altogether, which leaves the goals of databinder
questionable. Does anyone
Hey Nathan. Thanks so much for your reply.
Thanks for understanding my comments. I *really* didn't want to come off
like a jerk, and I *do* think that there is a place for databinder, it's
just not my cup of tea for my current project.
Please feel free to take whatever I've done to use with
Ryan Sonnek wrote:
Please feel free to take whatever I've done to use with databinder. If
there's anything I can do to help make the integration as seemless as
possible, let me know.
Making sure that releases of it go into the central Maven repository is
the only thing I can think of. I'm
Hi,
I noticed that you get the field like this:
String fieldName = propertyModel.getPropertyExpression();
Class type = propertyModel.getTarget().getClass();
...
Field field = type.getDeclaredField(fieldName);
...
That means that the lookup is done on every configuration. Also will
this work for
Thanks for the advice Matej!
The current implementation does *not* support OGNL type nested expressions.
I even have a unit test for it right now. =)
I'll gladly look into the IPropertyReflectionAwareModel interface to see if
I can improve on this.
I'm not too concerned about this lookup
Just sending out a quick release announcement for a new Hibernate/Wicket
integration in the wicketstuff project. The
HibernateAnnotationComponentConfigurator automatically configures a wicket
component based on the POJO's Hibernate annotations.
one especially cool feature is that you can
This sounds very cool! Does it work with Hibernate Validator Annotations
also ?
Thanks, Paolo
On 6/23/07, Ryan Sonnek [EMAIL PROTECTED] wrote:
Just sending out a quick release announcement for a new Hibernate/Wicket
integration in the wicketstuff project. The
The current implementation uses:
* NotNull annotation automatically sets the component to be required
(setRequired(true))
* Length annotation automatically adds a MaxLength validator *and* adds html
maxlength attribute to the markup.
If there are other annotations that would be useful, let me
On 6/23/07, Ryan Sonnek [EMAIL PROTECTED] wrote:
Just sending out a quick release announcement for a new Hibernate/Wicket
integration in the wicketstuff project. The
HibernateAnnotationComponentConfigurator automatically configures a wicket
component based on the POJO's Hibernate annotations.
On 6/23/07, Ryan Sonnek [EMAIL PROTECTED] wrote:
Just sending out a quick release announcement for a new Hibernate/Wicket
integration in the wicketstuff project. The
HibernateAnnotationComponentConfigurator automatically configures a wicket
component based on the POJO's Hibernate annotations.
this might be nice too
onbeforerender(component c) {
if (c.hasbeenrednered()) return;
...
}
Good catch!
I'm still relatively new to wicket's rendering lifecycle. Thanks for the
help and let me know if you see other optimizations.
I've looked at databinder in the past, and although it may be useful, I
think it's a bit heavyweight for what I'm trying to achieve.
In my opinion, database access should be abstracted away from the UI layer
altogether, which leaves the goals of databinder questionable. Does anyone
remember the
I don't want to sound like a databinder basher, but I want to make this
solution very *non-invasive*. I don't want to have to implement specific
interfaces or use specific components for this to work.
My solution works with standard wicket components and property models. No
need to change your
13 matches
Mail list logo
