Bind API for property models revisited

View: New views
9 Messages — Rating Filter:   Alert me  

Bind API for property models revisited

by Martijn Dashorst :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

We've been discussing a typesafe property model before, and I'd like
to see where the current crop of such APIs and suggestions is. With
Wicket 1.4 imminent, and our migration to Java 5 this should be much
more easy to implement than before.

One such library is
http://code.google.com/p/logicalpractice-collections/ where they make
selectors available on standard collections.

Using their library one can write the following:

smiths = select(from(people).getLastName(),  equalToIgnoringCase("smith"));


Putting my Wicket head on, I think something like:

bind(new Label("foo")).to(person).getLastName());

or

add(new Label("foo").bind(person).getLastName());

Would be nice.

Not sure how this jives with our desire to remove the default model
slot. I think having a binding API might nicely coincide with removing
a default slot. The details of this are left as an exercise to the
reader ;-)

Martijn

Re: Bind API for property models revisited

by nino martinez wael :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Yeah looks nice, Im waiting anxiously to see it in wicket :) One part
that I really like are that it's very readable. Another of course are
that it are refactor safe.

2009/5/19 Martijn Dashorst <martijn.dashorst@...>:

> We've been discussing a typesafe property model before, and I'd like
> to see where the current crop of such APIs and suggestions is. With
> Wicket 1.4 imminent, and our migration to Java 5 this should be much
> more easy to implement than before.
>
> One such library is
> http://code.google.com/p/logicalpractice-collections/ where they make
> selectors available on standard collections.
>
> Using their library one can write the following:
>
> smiths = select(from(people).getLastName(),  equalToIgnoringCase("smith"));
>
>
> Putting my Wicket head on, I think something like:
>
> bind(new Label("foo")).to(person).getLastName());
>
> or
>
> add(new Label("foo").bind(person).getLastName());
>
> Would be nice.
>
> Not sure how this jives with our desire to remove the default model
> slot. I think having a binding API might nicely coincide with removing
> a default slot. The details of this are left as an exercise to the
> reader ;-)
>
> Martijn
>

Re: Bind API for property models revisited

by Johan Compagner :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

this we already kind of have.

But it uses currently proxies. And is build on commons proxy that wants us
to hard code the proxie implementation
that you should use, thats in my eyes a wrong implementations, the whole
point of a wrapping class around a proxy
is that i dont want to choose at compile time which one i want!

But our property model can do what you are describing just fine.

johan



On Tue, May 19, 2009 at 10:09, Martijn Dashorst
<martijn.dashorst@...>wrote:

> We've been discussing a typesafe property model before, and I'd like
> to see where the current crop of such APIs and suggestions is. With
> Wicket 1.4 imminent, and our migration to Java 5 this should be much
> more easy to implement than before.
>
> One such library is
> http://code.google.com/p/logicalpractice-collections/ where they make
> selectors available on standard collections.
>
> Using their library one can write the following:
>
> smiths = select(from(people).getLastName(),  equalToIgnoringCase("smith"));
>
>
> Putting my Wicket head on, I think something like:
>
> bind(new Label("foo")).to(person).getLastName());
>
> or
>
> add(new Label("foo").bind(person).getLastName());
>
> Would be nice.
>
> Not sure how this jives with our desire to remove the default model
> slot. I think having a binding API might nicely coincide with removing
> a default slot. The details of this are left as an exercise to the
> reader ;-)
>
> Martijn
>

Re: Bind API for property models revisited

by James Carman-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I've tried pushing through the runtime implementation resolution
(similar to slf4j), but nobody seems keen on it.  At least, they
didn't answer my emails.  So, perhaps I'll just refactor it myself and
put it out there and see what happens?

On Mon, Jun 8, 2009 at 7:27 AM, Johan Compagner<jcompagner@...> wrote:

> this we already kind of have.
>
> But it uses currently proxies. And is build on commons proxy that wants us
> to hard code the proxie implementation
> that you should use, thats in my eyes a wrong implementations, the whole
> point of a wrapping class around a proxy
> is that i dont want to choose at compile time which one i want!
>
> But our property model can do what you are describing just fine.
>
> johan
>
>
>
> On Tue, May 19, 2009 at 10:09, Martijn Dashorst
> <martijn.dashorst@...>wrote:
>
>> We've been discussing a typesafe property model before, and I'd like
>> to see where the current crop of such APIs and suggestions is. With
>> Wicket 1.4 imminent, and our migration to Java 5 this should be much
>> more easy to implement than before.
>>
>> One such library is
>> http://code.google.com/p/logicalpractice-collections/ where they make
>> selectors available on standard collections.
>>
>> Using their library one can write the following:
>>
>> smiths = select(from(people).getLastName(),  equalToIgnoringCase("smith"));
>>
>>
>> Putting my Wicket head on, I think something like:
>>
>> bind(new Label("foo")).to(person).getLastName());
>>
>> or
>>
>> add(new Label("foo").bind(person).getLastName());
>>
>> Would be nice.
>>
>> Not sure how this jives with our desire to remove the default model
>> slot. I think having a binding API might nicely coincide with removing
>> a default slot. The details of this are left as an exercise to the
>> reader ;-)
>>
>> Martijn
>>
>

Re: Bind API for property models revisited

by Johan Compagner :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

+1 !

On Mon, Jun 8, 2009 at 13:30, James Carman <jcarman@...>wrote:

> I've tried pushing through the runtime implementation resolution
> (similar to slf4j), but nobody seems keen on it.  At least, they
> didn't answer my emails.  So, perhaps I'll just refactor it myself and
> put it out there and see what happens?
>
> On Mon, Jun 8, 2009 at 7:27 AM, Johan Compagner<jcompagner@...>
> wrote:
> > this we already kind of have.
> >
> > But it uses currently proxies. And is build on commons proxy that wants
> us
> > to hard code the proxie implementation
> > that you should use, thats in my eyes a wrong implementations, the whole
> > point of a wrapping class around a proxy
> > is that i dont want to choose at compile time which one i want!
> >
> > But our property model can do what you are describing just fine.
> >
> > johan
> >
> >
> >
> > On Tue, May 19, 2009 at 10:09, Martijn Dashorst
> > <martijn.dashorst@...>wrote:
> >
> >> We've been discussing a typesafe property model before, and I'd like
> >> to see where the current crop of such APIs and suggestions is. With
> >> Wicket 1.4 imminent, and our migration to Java 5 this should be much
> >> more easy to implement than before.
> >>
> >> One such library is
> >> http://code.google.com/p/logicalpractice-collections/ where they make
> >> selectors available on standard collections.
> >>
> >> Using their library one can write the following:
> >>
> >> smiths = select(from(people).getLastName(),
>  equalToIgnoringCase("smith"));
> >>
> >>
> >> Putting my Wicket head on, I think something like:
> >>
> >> bind(new Label("foo")).to(person).getLastName());
> >>
> >> or
> >>
> >> add(new Label("foo").bind(person).getLastName());
> >>
> >> Would be nice.
> >>
> >> Not sure how this jives with our desire to remove the default model
> >> slot. I think having a binding API might nicely coincide with removing
> >> a default slot. The details of this are left as an exercise to the
> >> reader ;-)
> >>
> >> Martijn
> >>
> >
>

Re: Bind API for property models revisited

by James Carman-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Yeah, I agree.  I would like to make ProxyFactory an interface and
split commons-proxy into 4 modules.

commons-proxy-api - contains the api classes and perhaps some useful
superclasses for folks to use to write their own impls.
commons-proxy-jdk - jdk proxy implementation
commons-proxy-javassist - the javassist implementation
commons-proxy-cglib - the cglib implementation

Then, at runtime, it'd look for something on the classpath to
determine which implementation to use.

On Mon, Jun 8, 2009 at 7:33 AM, Johan Compagner<jcompagner@...> wrote:

> +1 !
>
> On Mon, Jun 8, 2009 at 13:30, James Carman <jcarman@...>wrote:
>
>> I've tried pushing through the runtime implementation resolution
>> (similar to slf4j), but nobody seems keen on it.  At least, they
>> didn't answer my emails.  So, perhaps I'll just refactor it myself and
>> put it out there and see what happens?
>>
>> On Mon, Jun 8, 2009 at 7:27 AM, Johan Compagner<jcompagner@...>
>> wrote:
>> > this we already kind of have.
>> >
>> > But it uses currently proxies. And is build on commons proxy that wants
>> us
>> > to hard code the proxie implementation
>> > that you should use, thats in my eyes a wrong implementations, the whole
>> > point of a wrapping class around a proxy
>> > is that i dont want to choose at compile time which one i want!
>> >
>> > But our property model can do what you are describing just fine.
>> >
>> > johan
>> >
>> >
>> >
>> > On Tue, May 19, 2009 at 10:09, Martijn Dashorst
>> > <martijn.dashorst@...>wrote:
>> >
>> >> We've been discussing a typesafe property model before, and I'd like
>> >> to see where the current crop of such APIs and suggestions is. With
>> >> Wicket 1.4 imminent, and our migration to Java 5 this should be much
>> >> more easy to implement than before.
>> >>
>> >> One such library is
>> >> http://code.google.com/p/logicalpractice-collections/ where they make
>> >> selectors available on standard collections.
>> >>
>> >> Using their library one can write the following:
>> >>
>> >> smiths = select(from(people).getLastName(),
>>  equalToIgnoringCase("smith"));
>> >>
>> >>
>> >> Putting my Wicket head on, I think something like:
>> >>
>> >> bind(new Label("foo")).to(person).getLastName());
>> >>
>> >> or
>> >>
>> >> add(new Label("foo").bind(person).getLastName());
>> >>
>> >> Would be nice.
>> >>
>> >> Not sure how this jives with our desire to remove the default model
>> >> slot. I think having a binding API might nicely coincide with removing
>> >> a default slot. The details of this are left as an exercise to the
>> >> reader ;-)
>> >>
>> >> Martijn
>> >>
>> >
>>
>

Re: Bind API for property models revisited

by Erik van Oosten :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

That would be great!

A colleague has been voicing the exact same modularization (not related
to Wicket). He would certainly start using it.

Regards,
    Erik.


James Carman wrote:

> I've tried pushing through the runtime implementation resolution
> (similar to slf4j), but nobody seems keen on it.  At least, they
> didn't answer my emails.  So, perhaps I'll just refactor it myself and
> put it out there and see what happens?
>
> On Mon, Jun 8, 2009 at 7:27 AM, Johan Compagner<jcompagner@...> wrote:
>  
>> this we already kind of have.
>>
>> But it uses currently proxies. And is build on commons proxy that wants us
>> to hard code the proxie implementation
>> that you should use, thats in my eyes a wrong implementations, the whole
>> point of a wrapping class around a proxy
>> is that i dont want to choose at compile time which one i want!
>>
>> But our property model can do what you are describing just fine.
>>
>> johan
>>
>>
>>
>>    

--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/


Re: Bind API for property models revisited

by igor.vaynberg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

how would you handle a situation where commons-proxy-jdk is not a drop
in replacement for others because it cannot proxy concrete classes.

-igor

On Mon, Jun 8, 2009 at 4:59 AM, James
Carman<jcarman@...> wrote:

> Yeah, I agree.  I would like to make ProxyFactory an interface and
> split commons-proxy into 4 modules.
>
> commons-proxy-api - contains the api classes and perhaps some useful
> superclasses for folks to use to write their own impls.
> commons-proxy-jdk - jdk proxy implementation
> commons-proxy-javassist - the javassist implementation
> commons-proxy-cglib - the cglib implementation
>
> Then, at runtime, it'd look for something on the classpath to
> determine which implementation to use.
>
> On Mon, Jun 8, 2009 at 7:33 AM, Johan Compagner<jcompagner@...> wrote:
>> +1 !
>>
>> On Mon, Jun 8, 2009 at 13:30, James Carman <jcarman@...>wrote:
>>
>>> I've tried pushing through the runtime implementation resolution
>>> (similar to slf4j), but nobody seems keen on it.  At least, they
>>> didn't answer my emails.  So, perhaps I'll just refactor it myself and
>>> put it out there and see what happens?
>>>
>>> On Mon, Jun 8, 2009 at 7:27 AM, Johan Compagner<jcompagner@...>
>>> wrote:
>>> > this we already kind of have.
>>> >
>>> > But it uses currently proxies. And is build on commons proxy that wants
>>> us
>>> > to hard code the proxie implementation
>>> > that you should use, thats in my eyes a wrong implementations, the whole
>>> > point of a wrapping class around a proxy
>>> > is that i dont want to choose at compile time which one i want!
>>> >
>>> > But our property model can do what you are describing just fine.
>>> >
>>> > johan
>>> >
>>> >
>>> >
>>> > On Tue, May 19, 2009 at 10:09, Martijn Dashorst
>>> > <martijn.dashorst@...>wrote:
>>> >
>>> >> We've been discussing a typesafe property model before, and I'd like
>>> >> to see where the current crop of such APIs and suggestions is. With
>>> >> Wicket 1.4 imminent, and our migration to Java 5 this should be much
>>> >> more easy to implement than before.
>>> >>
>>> >> One such library is
>>> >> http://code.google.com/p/logicalpractice-collections/ where they make
>>> >> selectors available on standard collections.
>>> >>
>>> >> Using their library one can write the following:
>>> >>
>>> >> smiths = select(from(people).getLastName(),
>>>  equalToIgnoringCase("smith"));
>>> >>
>>> >>
>>> >> Putting my Wicket head on, I think something like:
>>> >>
>>> >> bind(new Label("foo")).to(person).getLastName());
>>> >>
>>> >> or
>>> >>
>>> >> add(new Label("foo").bind(person).getLastName());
>>> >>
>>> >> Would be nice.
>>> >>
>>> >> Not sure how this jives with our desire to remove the default model
>>> >> slot. I think having a binding API might nicely coincide with removing
>>> >> a default slot. The details of this are left as an exercise to the
>>> >> reader ;-)
>>> >>
>>> >> Martijn
>>> >>
>>> >
>>>
>>
>

Re: Bind API for property models revisited

by James Carman-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Proxy throws an exception if it's unable to proxy a class you're
asking it to proxy.  So, you'd get an exception (runtime).  For
wicket, you'd probably want to choose one of the more robust proxying
frameworks.

On Mon, Jun 8, 2009 at 12:38 PM, Igor Vaynberg<igor.vaynberg@...> wrote:

> how would you handle a situation where commons-proxy-jdk is not a drop
> in replacement for others because it cannot proxy concrete classes.
>
> -igor
>
> On Mon, Jun 8, 2009 at 4:59 AM, James
> Carman<jcarman@...> wrote:
>> Yeah, I agree.  I would like to make ProxyFactory an interface and
>> split commons-proxy into 4 modules.
>>
>> commons-proxy-api - contains the api classes and perhaps some useful
>> superclasses for folks to use to write their own impls.
>> commons-proxy-jdk - jdk proxy implementation
>> commons-proxy-javassist - the javassist implementation
>> commons-proxy-cglib - the cglib implementation
>>
>> Then, at runtime, it'd look for something on the classpath to
>> determine which implementation to use.
>>
>> On Mon, Jun 8, 2009 at 7:33 AM, Johan Compagner<jcompagner@...> wrote:
>>> +1 !
>>>
>>> On Mon, Jun 8, 2009 at 13:30, James Carman <jcarman@...>wrote:
>>>
>>>> I've tried pushing through the runtime implementation resolution
>>>> (similar to slf4j), but nobody seems keen on it.  At least, they
>>>> didn't answer my emails.  So, perhaps I'll just refactor it myself and
>>>> put it out there and see what happens?
>>>>
>>>> On Mon, Jun 8, 2009 at 7:27 AM, Johan Compagner<jcompagner@...>
>>>> wrote:
>>>> > this we already kind of have.
>>>> >
>>>> > But it uses currently proxies. And is build on commons proxy that wants
>>>> us
>>>> > to hard code the proxie implementation
>>>> > that you should use, thats in my eyes a wrong implementations, the whole
>>>> > point of a wrapping class around a proxy
>>>> > is that i dont want to choose at compile time which one i want!
>>>> >
>>>> > But our property model can do what you are describing just fine.
>>>> >
>>>> > johan
>>>> >
>>>> >
>>>> >
>>>> > On Tue, May 19, 2009 at 10:09, Martijn Dashorst
>>>> > <martijn.dashorst@...>wrote:
>>>> >
>>>> >> We've been discussing a typesafe property model before, and I'd like
>>>> >> to see where the current crop of such APIs and suggestions is. With
>>>> >> Wicket 1.4 imminent, and our migration to Java 5 this should be much
>>>> >> more easy to implement than before.
>>>> >>
>>>> >> One such library is
>>>> >> http://code.google.com/p/logicalpractice-collections/ where they make
>>>> >> selectors available on standard collections.
>>>> >>
>>>> >> Using their library one can write the following:
>>>> >>
>>>> >> smiths = select(from(people).getLastName(),
>>>>  equalToIgnoringCase("smith"));
>>>> >>
>>>> >>
>>>> >> Putting my Wicket head on, I think something like:
>>>> >>
>>>> >> bind(new Label("foo")).to(person).getLastName());
>>>> >>
>>>> >> or
>>>> >>
>>>> >> add(new Label("foo").bind(person).getLastName());
>>>> >>
>>>> >> Would be nice.
>>>> >>
>>>> >> Not sure how this jives with our desire to remove the default model
>>>> >> slot. I think having a binding API might nicely coincide with removing
>>>> >> a default slot. The details of this are left as an exercise to the
>>>> >> reader ;-)
>>>> >>
>>>> >> Martijn
>>>> >>
>>>> >
>>>>
>>>
>>
>