|
»
»
CompoundModel based on proxies
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 - 5 | Next > |
 |
Re: CompoundModel based on proxies
by Sam Barnum
::
Rate this Message:
IntelliJ does a good job of locating String usages of property names
when you refactor a property name, which is nice. Not sure if Eclipse/Netbeans do this also. If you use CompoundPropertyModels then wouldn't refactoring your business objects will still silently break code? It seems that ideally you'd just reference a property by its name, and continue using things like CompoundPropertyModel, PropertyResolver, etc. which accept string representations of properties. Using a code generation tool + generation gap pattern is a good way to accomplish this for now, have the code generation template generate String constants for all your property names in the generated entity superclass java file. All that said, this is a pretty nifty trick. I wonder how much it will actually benefit developers, though. -Sam On Feb 26, 2008, at 10:43 AM, Igor Vaynberg wrote: > not really sure. but this is how it would work. > > proxies in cglib take handlers. so you would do: > > String key=modelclass.getname(); > Class proxy=cache.get(key); > if (proxy==null) { > proxy=cglib.createproxy(modelclass); > cache.put(key,proxy); > } > proxyhandler handler=new proxyhandler(this); > Object instance=proxy.getconstructor(handler.class).newinstance > (handler); > > so we reuse the generated proxy class for all instances of the given > model class, and use a fresh handler to intercept all calls to proxy > and build the expression. > > -igor > > > > On Tue, Feb 26, 2008 at 10:36 AM, James Carman > <james@...> wrote: >> So, you would cache the generated class (based on the type passed in) >> and then have it generate a new object each time. Then, cast that >> object to Factory and set its callbacks? >> >> >> >> On 2/26/08, Igor Vaynberg <igor.vaynberg@...> wrote: >>> we can cache the created proxy class and simply give each instance a >>> new handler... >>> >>> >>> -igor >>> >>> >>> >>> On Tue, Feb 26, 2008 at 10:26 AM, James Carman >>> <james@...> wrote: >>>> Have you tried this out using load testing? You are creating a new >>>> class every time you create a model. Have you run out of permgen >>>> space? >>>> >>>> >>>> >>>> On 2/26/08, Sebastiaan van Erk <sebster@...> wrote: >>>>> Well, there's a problem with normal PropertyModels (or >>>>> CompoundPropertyModels). >>>>> >>>>> For example, if you have the following textfield: >>>>> >>>>> TextField tf = new TextField("name", new PropertyModel(customer, >>>>> "customerName")); >>>>> >>>>> Then a refactor of the customerName property (and the >>>>> getCustomerName() >>>>> method) in an IDE such as Eclipse or NetBeans will *silently* >>>>> break the >>>>> above code, which you will discover only at runtime... >>>>> >>>>> The proxy based approach solves exactly this problem. >>>>> >>>>> Regards, >>>>> >>>>> Sebastiaan >>>>> >>>>> >>>>> >>>>> >>>>> atul singh wrote: >>>>>> I feel this approach does NOT solve a problem.....Its just an >>>>>> alternative .. >>>>>> >>>>>> On Tue, Feb 26, 2008 at 4:48 PM, Matej Knopp >>>>>> <matej.knopp@...> wrote: >>>>>> >>>>>>> We've reworked the implementation a bit,it works like this: >>>>>>> >>>>>>> >>>>>>> SafePropertyModel<Person> p = new SafePropertyModel<Person> >>>>>>> (new Person()); >>>>>>> TextField field = new TextField("name", p.bind(p.property >>>>>>> ().getFirstName())); >>>>>>> >>>>>>> It's attached to the JIRA issue: >>>>>>> https://issues.apache.org/jira/browse/WICKET-1327 >>>>>>> >>>>>>> -Matej >>>>>>> >>>>>>> >>>>>>> On Tue, Feb 26, 2008 at 11:32 AM, Sebastiaan van Erk >>>>>>> <sebster@...> wrote: >>>>>>>> Matej Knopp wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk >>>>>>>>> <sebster@...> wrote: >>>>>>>>>> Matej Knopp wrote: >>>>>>>>>>> model.getFirstName() can't really return IModel, if >>>>>>>>>>> Customer.getFirstName() returns string. >>>>>>>>>>> >>>>>>>>>>> Anyway, I like the idea, but I don't like the syntax. >>>>>>>>>>> instead of >>>>>>> one >>>>>>>>>>> line [add(new TextField("id", model).setRequred(true)) ] >>>>>>>>>>> you have >>>>>>> now >>>>>>>>>>> three separate lines. >>>>>>>>>>> >>>>>>>>>>> So I was thinking of something more like >>>>>>>>>>> >>>>>>>>>>> SafePropertyModel<Customer> model = new >>>>>>> SafePropertyModel<Customer>(customer); >>>>>>>>>>> >>>>>>>>>>> add(new TextField("tf", model.bind(model.proxy >>>>>>> ().getCustomerName() >>>>>>>>>>> )).setRequired(true)); >>>>>>>>>>> >>>>>>>>>>> This way you can have it one one line. >>>>>>>>>>> >>>>>>>>>>> -Matej >>>>>>>>>> >>>>>>>>>> So proxy() returns a Customer proxy? >>>>>>>>>> >>>>>>>>>> And model.bind() takes an Object argument (considering we >>>>>>>>>> don't >>>>>>> know in >>>>>>>>>> advance what type getCustomerName() returns)... What about >>>>>>> primitive >>>>>>>>>> types? Overload bind() for those as well? >>>>>>>>> Well, the return object is not important at all. What is >>>>>>>>> important is >>>>>>>>> the getCustomerName() call. That marks somewhere in the >>>>>>>>> model that >>>>>>>>> last accessed property was called "customerName". and then >>>>>>> immediately >>>>>>>>> after this model.bind takes this information. >>>>>>>> >>>>>>>> OK, that's what I described. :-) And I was being stupid >>>>>>>> with respect to >>>>>>>> the overloading. If bind takes an object as argument, then >>>>>>>> overloading >>>>>>>> will not be necessary due to autoboxing. :-) >>>>>>>> >>>>>>>> >>>>>>>>>> And the call to getCustomerName() has the side effect of >>>>>>>>>> setting a >>>>>>> model >>>>>>>>>> object somewhere (e.g., in an instance field of model) >>>>>>>>>> which >>>>>>>>>> model.bind() can subsequently return? >>>>>>>>> Model bind will return a model (variation of propertymodel >>>>>>>>> probably). >>>>>>>>> It will take the information that getCustomerName call on >>>>>>>>> proxy >>>>>>>>> provided. >>>>>>>> >>>>>>>> Ok, so the proxy remembers which getter was called last, >>>>>>>> and you use >>>>>>>> that to construct the model in bind(). Of course. >>>>>>>> >>>>>>>> >>>>>>>>>> Very interesting. I don't like the proxy() method name >>>>>>>>>> though. If >>>>>>> you >>>>>>>>>> call it something like property() it will look more like >>>>>>>>>> you're >>>>>>> binding >>>>>>>>>> to a property of Customer: >>>>>>>>> Well, the naming can certainly be improved. I'm not sure about >>>>>>>>> "property()" though. Well, we can discuss this more anyway. >>>>>>>>>> model.bind(model.property().getCustomerName()) >>>>>>>> >>>>>>>> Neither am I. :-) For one, it's quite long. But on the >>>>>>>> other hand, you >>>>>>>> do bind to a model property, and so it reads ok. I think >>>>>>>> that proxies >>>>>>>> should be "invisible" for general users, so they shouldn't >>>>>>>> have to >>>>>>>> understand the magic going on here, nor that proxies are >>>>>>>> involved. >>>>>>>> >>>>>>>> >>>>>>>>>> VERY neat idea though... :-) >>>>>>>>> Thanks. >>>>>>>> >>>>>>>> What I really like about this solution is that it can be >>>>>>>> implemented >>>>>>>> completely separately from wicket-core, so you can just put >>>>>>>> it in it's >>>>>>>> own project. :-) >>>>>>>> >>>>>>>> Regards, >>>>>>>> Sebastiaan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -Matej >>>>>>>>>> Regards, >>>>>>>>>> Sebastiaan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Feb 8, 2008 at 6:17 PM, Johan Compagner < >>>>>>> jcompagner@...> wrote: >>>>>>>>>>>> don't worry about creating the models >>>>>>>>>>>> That will happen anyway in 1.3 (that needs to be done for >>>>>>> example to get the >>>>>>>>>>>> right object especially when we generify stuff) >>>>>>>>>>>> >>>>>>>>>>>> see CompoundPropertyModel.wrapOnInheritance() >>>>>>>>>>>> >>>>>>>>>>>> joan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Feb 8, 2008 5:41 PM, Scott Swank >>>>>>>>>>>> <scott.swank@...> >>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Interesting. So >>>>>>>>>>>>> >>>>>>>>>>>>> model.getFirstName() >>>>>>>>>>>>> >>>>>>>>>>>>> would return a PropetyModel based on the results of >>>>>>> proxy.eval()? If >>>>>>>>>>>>> I understand you correctly that creates many models >>>>>>>>>>>>> (one per >>>>>>>>>>>>> component) instead of reusing a single model, but that may >>>>>>> well not be >>>>>>>>>>>>> the end of the world. Or does getFirstName() return a >>>>>>> CompoundModel >>>>>>>>>>>>> that is properly bound this this component? Intriguing >>>>>>>>>>>>> none >>>>>>> the less. >>>>>>>>>>>>> I hadn't considered this option, but I'm going to play >>>>>>>>>>>>> with >>>>>>> it a bit. >>>>>>>>>>>>> I rather like that direction. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 8, 2008 8:29 AM, Johan Compagner >>>>>>>>>>>>> <jcompagner@...> >>>>>>> wrote: >>>>>>>>>>>>>> i try to look at this this weekend, but i have a quick >>>>>>> question >>>>>>>>>>>>>> I find it a bit verbose can't it be a bit shorter like >>>>>>>>>>>>>> this >>>>>>> (just an >>>>>>>>>>>>>> example) >>>>>>>>>>>>>> >>>>>>>>>>>>>> SharedPropertyModel<Customer> model = new >>>>>>>>>>>>>> SharedPropertyModel<Customer>(customer); >>>>>>>>>>>>>> this.setModel(model); >>>>>>>>>>>>>> >>>>>>>>>>>>>> FormComponent firstName = new >>>>>>> CustomerNameField("firstName", >>>>>>>>>>>>>> model.getFirstName()).setRequired(true); >>>>>>>>>>>>>> add(firstName); >>>>>>>>>>>>>> >>>>>>>>>>>>>> where getFirstName() returns the model >>>>>>>>>>>>>> >>>>>>>>>>>>>> johan >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 6, 2008 6:57 PM, Scott Swank >>>>>>>>>>>>>> <scott.swank@...> >>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> One of our more clever developers created a >>>>>>> CompoundPropertyModel that >>>>>>>>>>>>>>> uses a cglib proxy to strongly bind the mutators to the >>>>>>> model. It >>>>>>>>>>>>>>> looks like this: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> SharedPropertyModel<Customer> model = new >>>>>>>>>>>>>>> SharedPropertyModel<Customer>(customer); >>>>>>>>>>>>>>> this.setModel(model); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> FormComponent firstName = new >>>>>>>>>>>>>>> CustomerNameField("firstName").setRequired(true); >>>>>>>>>>>>>>> model.bind(firstName).to().getFirstName >>>>>>>>>>>>>>> (); >>>>>>>>>>>>>>> add(firstName); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> FormComponent lastName = new >>>>>>>>>>>>>>> CustomerNameField("lastName").setRequired(true); >>>>>>>>>>>>>>> model.bind(lastName).to().getLastName(); >>>>>>>>>>>>>>> add(lastName); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> FormComponent addr1 = new >>>>>>>>>>>>>>> AddressField("address1").setRequired(true); >>>>>>>>>>>>>>> model.bind >>>>>>> (addr1).to().getAddress().getAddress1(); >>>>>>>>>>>>>>> add(addr1); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> FormComponent addr2 = new >>>>>>> AddressField("address2"); >>>>>>>>>>>>>>> model.bind >>>>>>> (addr2).to().getAddress().getAddress2(); >>>>>>>>>>>>>>> add(addr2); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> FormComponent city = new >>>>>>> CityField("city"); >>>>>>>>>>>>>>> model.bind >>>>>>> (city).to().getAddress().getCity(); >>>>>>>>>>>>>>> add(city); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We're happy to share if folk like this approach. N.B. >>>>>>> that the .to() >>>>>>>>>>>>>>> call is for readability rather than out of any >>>>>>>>>>>>>>> necessity. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> Scott >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Scott Swank >>>>>>>>>>>>>>> reformed mathematician >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>> ---------------------------------------------------------------- >>>>>>> ----- >>>>>>>>>>>>>>> To unsubscribe, e-mail: >>>>>>> users-unsubscribe@... >>>>>>>>>>>>>>> For additional commands, e-mail: >>>>>>> users-help@... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Scott Swank >>>>>>>>>>>>> reformed mathematician >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> ---------------------------------------------------------------- >>>>>>> ----- >>>>>>>>>>>>> To unsubscribe, e-mail: users- >>>>>>>>>>>>> unsubscribe@... >>>>>>>>>>>>> For additional commands, e-mail: users- >>>>>>>>>>>>> help@... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Resizable and reorderable grid components. >>>>>>> http://www.inmethod.com >>>>>>> >>>>>>> ---------------------------------------------------------------- >>>>>>> ----- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> ------------------------------------------------------------------- >>>> -- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>> >>> >>> -------------------------------------------------------------------- >>> - >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by Scott Swank
::
Rate this Message:
I'm working on a non-trivial app that uses this model (we submitted
it), and I like it. :) On Tue, Feb 26, 2008 at 11:00 AM, Sam Barnum <sam@...> wrote: > IntelliJ does a good job of locating String usages of property names > when you refactor a property name, which is nice. Not sure if > Eclipse/Netbeans do this also. > > If you use CompoundPropertyModels then wouldn't refactoring your > business objects will still silently break code? > > It seems that ideally you'd just reference a property by its name, > and continue using things like CompoundPropertyModel, > PropertyResolver, etc. which accept string representations of > properties. Using a code generation tool + generation gap pattern is > a good way to accomplish this for now, have the code generation > template generate String constants for all your property names in the > generated entity superclass java file. > > All that said, this is a pretty nifty trick. I wonder how much it > will actually benefit developers, though. > > -Sam --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by igor.vaynberg
::
Rate this Message:
looking at commons-proxy we just need an invoker proxy. if you can do
the caching behind the scenes for us that would be great. not sure what the code uses right now, cglib directly or something else. -igor On Tue, Feb 26, 2008 at 10:53 AM, James Carman <james@...> wrote: > Well, if you wait a bit until I do another release of Commons Proxy, > it'll have that feature built in. Also, you could use Javassist if > you wanted to very easily. > > > > On 2/26/08, Igor Vaynberg <igor.vaynberg@...> wrote: > > not really sure. but this is how it would work. > > > > proxies in cglib take handlers. so you would do: > > > > String key=modelclass.getname(); > > Class proxy=cache.get(key); > > if (proxy==null) { > > proxy=cglib.createproxy(modelclass); > > cache.put(key,proxy); > > } > > proxyhandler handler=new proxyhandler(this); > > Object instance=proxy.getconstructor(handler.class).newinstance(handler); > > > > so we reuse the generated proxy class for all instances of the given > > model class, and use a fresh handler to intercept all calls to proxy > > and build the expression. > > > > -igor > > > > > > > > On Tue, Feb 26, 2008 at 10:36 AM, James Carman > > > > <james@...> wrote: > > > So, you would cache the generated class (based on the type passed in) > > > and then have it generate a new object each time. Then, cast that > > > object to Factory and set its callbacks? > > > > > > > > > > > > On 2/26/08, Igor Vaynberg <igor.vaynberg@...> wrote: > > > > we can cache the created proxy class and simply give each instance a > > > > new handler... > > > > > > > > > > > > -igor > > > > > > > > > > > > > > > > On Tue, Feb 26, 2008 at 10:26 AM, James Carman > > > > <james@...> wrote: > > > > > Have you tried this out using load testing? You are creating a new > > > > > class every time you create a model. Have you run out of permgen > > > > > space? > > > > > > > > > > > > > > > > > > > > On 2/26/08, Sebastiaan van Erk <sebster@...> wrote: > > > > > > Well, there's a problem with normal PropertyModels (or > > > > > > CompoundPropertyModels). > > > > > > > > > > > > For example, if you have the following textfield: > > > > > > > > > > > > TextField tf = new TextField("name", new PropertyModel(customer, > > > > > > "customerName")); > > > > > > > > > > > > Then a refactor of the customerName property (and the getCustomerName() > > > > > > method) in an IDE such as Eclipse or NetBeans will *silently* break the > > > > > > above code, which you will discover only at runtime... > > > > > > > > > > > > The proxy based approach solves exactly this problem. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Sebastiaan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > atul singh wrote: > > > > > > > I feel this approach does NOT solve a problem.....Its just an alternative .. > > > > > > > > > > > > > > On Tue, Feb 26, 2008 at 4:48 PM, Matej Knopp <matej.knopp@...> wrote: > > > > > > > > > > > > > >> We've reworked the implementation a bit,it works like this: > > > > > > >> > > > > > > >> > > > > > > >> SafePropertyModel<Person> p = new SafePropertyModel<Person>(new Person()); > > > > > > >> TextField field = new TextField("name", p.bind(p.property > > > > > > >> ().getFirstName())); > > > > > > >> > > > > > > >> It's attached to the JIRA issue: > > > > > > >> https://issues.apache.org/jira/browse/WICKET-1327 > > > > > > >> > > > > > > >> -Matej > > > > > > >> > > > > > > >> > > > > > > >> On Tue, Feb 26, 2008 at 11:32 AM, Sebastiaan van Erk > > > > > > >> <sebster@...> wrote: > > > > > > >>> Matej Knopp wrote: > > > > > > >>> > Hi, > > > > > > >>> > > > > > > > >>> > On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk > > > > > > >>> > <sebster@...> wrote: > > > > > > >>> >> Matej Knopp wrote: > > > > > > >>> >> > model.getFirstName() can't really return IModel, if > > > > > > >>> >> > Customer.getFirstName() returns string. > > > > > > >>> >> > > > > > > > >>> >> > Anyway, I like the idea, but I don't like the syntax. instead of > > > > > > >> one > > > > > > >>> >> > line [add(new TextField("id", model).setRequred(true)) ] you have > > > > > > >> now > > > > > > >>> >> > three separate lines. > > > > > > >>> >> > > > > > > > >>> >> > So I was thinking of something more like > > > > > > >>> >> > > > > > > > >>> >> > SafePropertyModel<Customer> model = new > > > > > > >> SafePropertyModel<Customer>(customer); > > > > > > >>> >> > > > > > > > >>> >> > add(new TextField("tf", model.bind(model.proxy > > > > > > >> ().getCustomerName() > > > > > > >>> >> > )).setRequired(true)); > > > > > > >>> >> > > > > > > > >>> >> > This way you can have it one one line. > > > > > > >>> >> > > > > > > > >>> >> > -Matej > > > > > > >>> >> > > > > > > >>> >> So proxy() returns a Customer proxy? > > > > > > >>> >> > > > > > > >>> >> And model.bind() takes an Object argument (considering we don't > > > > > > >> know in > > > > > > >>> >> advance what type getCustomerName() returns)... What about > > > > > > >> primitive > > > > > > >>> >> types? Overload bind() for those as well? > > > > > > >>> > Well, the return object is not important at all. What is important is > > > > > > >>> > the getCustomerName() call. That marks somewhere in the model that > > > > > > >>> > last accessed property was called "customerName". and then > > > > > > >> immediately > > > > > > >>> > after this model.bind takes this information. > > > > > > >>> > > > > > > >>> OK, that's what I described. :-) And I was being stupid with respect to > > > > > > >>> the overloading. If bind takes an object as argument, then overloading > > > > > > >>> will not be necessary due to autoboxing. :-) > > > > > > >>> > > > > > > >>> > > > > > > >>> >> And the call to getCustomerName() has the side effect of setting a > > > > > > >> model > > > > > > >>> >> object somewhere (e.g., in an instance field of model) which > > > > > > >>> >> model.bind() can subsequently return? > > > > > > >>> > Model bind will return a model (variation of propertymodel probably). > > > > > > >>> > It will take the information that getCustomerName call on proxy > > > > > > >>> > provided. > > > > > > >>> > > > > > > >>> Ok, so the proxy remembers which getter was called last, and you use > > > > > > >>> that to construct the model in bind(). Of course. > > > > > > >>> > > > > > > >>> > > > > > > >>> >> Very interesting. I don't like the proxy() method name though. If > > > > > > >> you > > > > > > >>> >> call it something like property() it will look more like you're > > > > > > >> binding > > > > > > >>> >> to a property of Customer: > > > > > > >>> > Well, the naming can certainly be improved. I'm not sure about > > > > > > >>> > "property()" though. Well, we can discuss this more anyway. > > > > > > >>> >> model.bind(model.property().getCustomerName()) > > > > > > >>> > > > > > > >>> Neither am I. :-) For one, it's quite long. But on the other hand, you > > > > > > >>> do bind to a model property, and so it reads ok. I think that proxies > > > > > > >>> should be "invisible" for general users, so they shouldn't have to > > > > > > >>> understand the magic going on here, nor that proxies are involved. > > > > > > >>> > > > > > > >>> > > > > > > >>> >> VERY neat idea though... :-) > > > > > > >>> > Thanks. > > > > > > >>> > > > > > > >>> What I really like about this solution is that it can be implemented > > > > > > >>> completely separately from wicket-core, so you can just put it in it's > > > > > > >>> own project. :-) > > > > > > >>> > > > > > > >>> Regards, > > > > > > >>> Sebastiaan > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > -Matej > > > > > > >>> >> Regards, > > > > > > >>> >> Sebastiaan > > > > > > >>> >> > > > > > > >>> >> > > > > > > >>> >> > > > > > > >>> >> > > > > > > > >>> >> > On Fri, Feb 8, 2008 at 6:17 PM, Johan Compagner < > > > > > > >> jcompagner@...> wrote: > > > > > > >>> >> >> don't worry about creating the models > > > > > > >>> >> >> That will happen anyway in 1.3 (that needs to be done for > > > > > > >> example to get the > > > > > > >>> >> >> right object especially when we generify stuff) > > > > > > >>> >> >> > > > > > > >>> >> >> see CompoundPropertyModel.wrapOnInheritance() > > > > > > >>> >> >> > > > > > > >>> >> >> joan > > > > > > >>> >> >> > > > > > > >>> >> >> > > > > > > >>> >> >> > > > > > > >>> >> >> > > > > > > >>> >> >> > > > > > > >>> >> >> On Feb 8, 2008 5:41 PM, Scott Swank <scott.swank@...> > > > > > > >> wrote: > > > > > > >>> >> >> > > > > > > >>> >> >> > Interesting. So > > > > > > >>> >> >> > > > > > > > >>> >> >> > model.getFirstName() > > > > > > >>> >> >> > > > > > > > >>> >> >> > would return a PropetyModel based on the results of > > > > > > >> proxy.eval()? If > > > > > > >>> >> >> > I understand you correctly that creates many models (one per > > > > > > >>> >> >> > component) instead of reusing a single model, but that may > > > > > > >> well not be > > > > > > >>> >> >> > the end of the world. Or does getFirstName() return a > > > > > > >> CompoundModel > > > > > > >>> >> >> > that is properly bound this this component? Intriguing none > > > > > > >> the less. > > > > > > >>> >> >> > I hadn't considered this option, but I'm going to play with > > > > > > >> it a bit. > > > > > > >>> >> >> > I rather like that direction. > > > > > > >>> >> >> > > > > > > > >>> >> >> > > > > > > > >>> >> >> > On Feb 8, 2008 8:29 AM, Johan Compagner <jcompagner@...> > > > > > > >> wrote: > > > > > > >>> >> >> > > i try to look at this this weekend, but i have a quick > > > > > > >> question > > > > > > >>> >> >> > > I find it a bit verbose can't it be a bit shorter like this > > > > > > >> (just an > > > > > > >>> >> >> > > example) > > > > > > >>> >> >> > > > > > > > > >>> >> >> > > SharedPropertyModel<Customer> model = new > > > > > > >>> >> >> > > SharedPropertyModel<Customer>(customer); > > > > > > >>> >> >> > > this.setModel(model); > > > > > > >>> >> >> > > > > > > > > >>> >> >> > > FormComponent firstName = new > > > > > > >> CustomerNameField("firstName", > > > > > > >>> >> >> > > model.getFirstName()).setRequired(true); > > > > > > >>> >> >> > > add(firstName); > > > > > > >>> >> >> > > > > > > > > >>> >> >> > > where getFirstName() returns the model > > > > > > >>> >> >> > > > > > > > > >>> >> >> > > johan > > > > > > >>> >> >> > > > > > > > > >>> >> >> > > > > > > > > >>> >> >> > > > > > > > > >>> >> >> > > > > > > > > >>> >> >> > > > > > > > > >>> >> >> > > On Feb 6, 2008 6:57 PM, Scott Swank <scott.swank@...> > > > > > > >> wrote: > > > > > > >>> >> >> > > > > > > > > >>> >> >> > > > One of our more clever developers created a > > > > > > >> CompoundPropertyModel that > > > > > > >>> >> >> > > > uses a cglib proxy to strongly bind the mutators to the > > > > > > >> model. It > > > > > > >>> >> >> > > > looks like this: > > > > > > >>> >> >> > > > > > > > > > >>> >> >> > > > SharedPropertyModel<Customer> model = new > > > > > > >>> >> >> > > > SharedPropertyModel<Customer>(customer); > > > > > > >>> >> >> > > > this.setModel(model); > > > > > > >>> >> >> > > > > > > > > > >>> >> >> > > > FormComponent firstName = new > > > > > > >>> >> >> > > > CustomerNameField("firstName").setRequired(true); > > > > > > >>> >> >> > > > model.bind(firstName).to().getFirstName(); > > > > > > >>> >> >> > > > add(firstName); > > > > > > >>> >> >> > > > > > > > > > >>> >> >> > > > FormComponent lastName = new > > > > > > >>> >> >> > > > CustomerNameField("lastName").setRequired(true); > > > > > > >>> >> >> > > > model.bind(lastName).to().getLastName(); > > > > > > >>> >> >> > > > add(lastName); > > > > > > >>> >> >> > > > > > > > > > >>> >> >> > > > FormComponent addr1 = new > > > > > > >>> >> >> > > > AddressField("address1").setRequired(true); > > > > > > >>> >> >> > > > model.bind > > > > > > >> (addr1).to().getAddress().getAddress1(); > > > > > > >>> >> >> > > > add(addr1); > > > > > > >>> >> >> > > > > > > > > > >>> >> >> > > > FormComponent addr2 = new > > > > > > >> AddressField("address2"); > > > > > > >>> >> >> > > > model.bind > > > > > > >> (addr2).to().getAddress().getAddress2(); > > > > > > >>> >> >> > > > add(addr2); > > > > > > >>> >> >> > > > > > > > > > >>> >> >> > > > FormComponent city = new > > > > > > >> CityField("city"); > > > > > > >>> >> >> > > > model.bind > > > > > > >> (city).to().getAddress().getCity(); > > > > > > >>> >> >> > > > add(city); > > > > > > >>> >> >> > > > > > > > > > >>> >> >> > > > We're happy to share if folk like this approach. N.B. > > > > > > >> that the .to() > > > > > > >>> >> >> > > > call is for readability rather than out of any necessity. > > > > > > >>> >> >> > > > > > > > > > >>> >> >> > > > Cheers, > > > > > > >>> >> >> > > > Scott > > > > > > >>> >> >> > > > > > > > > > >>> >> >> > > > -- > > > > > > >>> >> >> > > > Scott Swank > > > > > > >>> >> >> > > > reformed mathematician > > > > > > >>> >> >> > > > > > > > > > >>> >> >> > > > > > > > > >>> >> >> > > > > > > > > > >> --------------------------------------------------------------------- > > > > > > >>> >> >> > > > To unsubscribe, e-mail: > > > > > > >> users-unsubscribe@... > > > > > > >>> >> >> > > > For additional commands, e-mail: > > > > > > >> users-help@... > > > > > > >>> >> >> > > > > > > > > > >>> >> >> > > > > > > > > > >>> >> >> > > > > > > > > >>> >> >> > > > > > > > >>> >> >> > > > > > > > >>> >> >> > > > > > > > >>> >> >> > -- > > > > > > >>> >> >> > Scott Swank > > > > > > >>> >> >> > reformed mathematician > > > > > > >>> >> >> > > > > > > > >>> >> >> > > > > > > > >> --------------------------------------------------------------------- > > > > > > >>> >> >> > To unsubscribe, e-mail: users-unsubscribe@... > > > > > > >>> >> >> > For additional commands, e-mail: users-help@... > > > > > > >>> >> >> > > > > > > > >>> >> >> > > > > > > > >>> >> >> > > > > > > >>> >> > > > > > > > >>> >> > > > > > > > >>> >> > > > > > > > >>> >> > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > >> > > > > > > >> > > > > > > >> -- > > > > > > >> Resizable and reorderable grid components. > > > > > > >> http://www.inmethod.com > > > > > > >> > > > > > > >> --------------------------------------------------------------------- > > > > > > >> To unsubscribe, e-mail: users-unsubscribe@... > > > > > > >> For additional commands, e-mail: users-help@... > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: users-unsubscribe@... > > > > > For additional commands, e-mail: users-help@... > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: users-unsubscribe@... > > > > For additional commands, e-mail: users-help@... > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscribe@... > > > For additional commands, e-mail: users-help@... > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscribe@... > > For additional commands, e-mail: users-help@... > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by jwcarman
::
Rate this Message:
On 2/26/08, Igor Vaynberg <igor.vaynberg@...> wrote:
> looking at commons-proxy we just need an invoker proxy. if you can do > the caching behind the scenes for us that would be great. not sure > what the code uses right now, cglib directly or something else. Commons Proxy allows you to swap out your implementation by coding to the ProxyFactory class. There are subclasses for CGLIB and Javassist right now. I'm implementing the changes now for CGLIB proxy class caching (all unit tests pass wonderfully yoo hoo). I was already doing it for Javassist. I didn't know how to do it before you said something about it just a minute ago. I wish I would have known before I cut the 1.0 release (just this past weekend). Oh well. And, yes, you would probably use an invoker to do what you want. > > -igor --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by Johan Compagner
::
Rate this Message:
Yes i would like to have something like commons proxy because i dont
want if possible a direct dependency on cglib. It would be coool that we have a default impl that is based on jdk itself (so only interface support). Then drop in cglib and you have support for also classes On 2/26/08, James Carman <james@...> wrote: > On 2/26/08, Igor Vaynberg <igor.vaynberg@...> wrote: > > looking at commons-proxy we just need an invoker proxy. if you can do > > the caching behind the scenes for us that would be great. not sure > > what the code uses right now, cglib directly or something else. > > Commons Proxy allows you to swap out your implementation by coding to > the ProxyFactory class. There are subclasses for CGLIB and Javassist > right now. I'm implementing the changes now for CGLIB proxy class > caching (all unit tests pass wonderfully yoo hoo). I was already > doing it for Javassist. I didn't know how to do it before you said > something about it just a minute ago. I wish I would have known > before I cut the 1.0 release (just this past weekend). Oh well. And, > yes, you would probably use an invoker to do what you want. > > > > > -igor > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by Johan Compagner
::
Rate this Message:
We dont serialize the expression builder see detach
On 2/26/08, Scott Swank <scott.swank@...> wrote: > I just added a relevant note about serialization (learned the hard > way...) to the jira. > > - Scott > > On Tue, Feb 26, 2008 at 3:18 AM, Matej Knopp <matej.knopp@...> wrote: > > We've reworked the implementation a bit,it works like this: > > > > > > SafePropertyModel<Person> p = new SafePropertyModel<Person>(new > Person()); > > TextField field = new TextField("name", > p.bind(p.property().getFirstName())); > > > > It's attached to the JIRA issue: > > > > https://issues.apache.org/jira/browse/WICKET-1327 > > > > -Matej > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by Gabor Szokoli
::
Rate this Message:
On 2/26/08, Sebastiaan van Erk <sebster@...> wrote:
> The proxy based approach solves exactly this problem. Wow, fancy! :-) Thanks for sharing it, we'll probably use it too. The rest is by no means ment to discredit your effort, more like the devils advocate grumbling in front of the TV about Java in general: Isn't the JavaBean as key-value datastructure the real problem? We were lucky to be able to use a Map at one place in our wicket code for a "reflective" model object instead: CompoundPropertyModel supports it uniformly. Do people ever use non trivial getters and setters in their JavaBeans? We don't. Type safety and JPA are nice though, so we use JavaBeans everywhere else :-) But I just can't help wondering how the complexity (and performance) of current reflection/bytecode generation efforts would compare to porting all the JavaBean based tools and utilities to some different datastructure convention? One designed for programmatic manipulation. Like a Map where the key contains the type of the value. Some EnumMap-like optimisation could be employed when the keys are known compile-time. Would cover 90% of the cases people use reflection for currently I expect. Just imagine, JAXB could be a utility class with 2 static methods: encode and decode :-) Gabor Szokoli --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by jwcarman
::
Rate this Message:
On 2/26/08, James Carman <james@...> wrote:
> Well, if you wait a bit until I do another release of Commons Proxy, > it'll have that feature built in. Also, you could use Javassist if > you wanted to very easily. Actually, after I played around a bit, it looks like CGLIB does this out of the box. So, it was caching your stuff already for you. Thus, Commons Proxy would be too. I had to create custom support for caching for Javassist, though. JDK proxy classes are cached automatically also by the java.lang.reflect.Proxy class. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by jwcarman
::
Rate this Message:
On 2/26/08, Johan Compagner <jcompagner@...> wrote:
> Yes i would like to have something like commons proxy because i dont > want if possible a direct dependency on cglib. It would be coool that > we have a default impl that is based on jdk itself (so only interface > support). Then drop in cglib and you have support for also classes > As soon as the mirrors pick up the release and it's available in the maven2 repository, I'll send out the 1.0 release announcement email. If you just can't wait, you can grab the distribution files from: http://www.apache.org/dist/commons/proxy/ The website has already been updated: http://commons.apache.org/proxy/ One thing that I think you'll be missing is serialization of the proxies. After I thought about it a bit, I don't think I made all proxies serializable. I'll put in a JIRA for that and get that out in a 1.1 release. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by Timo Rantalaiho
::
Rate this Message:
Hello,
On Tue, 26 Feb 2008, Sebastiaan van Erk wrote: > Then a refactor of the customerName property (and the getCustomerName() > method) in an IDE such as Eclipse or NetBeans will *silently* break the > above code, which you will discover only at runtime... > > The proxy based approach solves exactly this problem. We have found extensive developer tests (produced with TDD / BDD) to be a very effective solution to this problem. I prefer the current, terser syntax because of better readability, even though the string literals breaking in refactorings bother me too. It's a pity that Java in its current state seems to force one to produce a lot of clutter in the proxy-based approach, which is otherwise a very neat idea. For a Wicket UI, it's fairly easy to get 100 % branch coverage. And behavior-driving your code is more effective than "just writing it" anyway (produces better code faster), so it's a double win :) Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations Oy <URL: http://www.ri.fi/ > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by Johan Compagner
::
Rate this Message:
Serialization is not a problem for what we have build now because we
dont keep references to the proxies in the session. We just use them at construction time On 2/27/08, James Carman <james@...> wrote: > On 2/26/08, Johan Compagner <jcompagner@...> wrote: > > Yes i would like to have something like commons proxy because i dont > > want if possible a direct dependency on cglib. It would be coool that > > we have a default impl that is based on jdk itself (so only interface > > support). Then drop in cglib and you have support for also classes > > > > As soon as the mirrors pick up the release and it's available in the > maven2 repository, I'll send out the 1.0 release announcement email. > If you just can't wait, you can grab the distribution files from: > > http://www.apache.org/dist/commons/proxy/ > > The website has already been updated: > > http://commons.apache.org/proxy/ > > One thing that I think you'll be missing is serialization of the > proxies. After I thought about it a bit, I don't think I made all > proxies serializable. I'll put in a JIRA for that and get that out in > a 1.1 release. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by jwcarman
::
Rate this Message:
On 2/28/08, Johan Compagner <jcompagner@...> wrote:
> Serialization is not a problem for what we have build now because we > dont keep references to the proxies in the session. We just use them > at construction time > Well, it'll be built into v1.1 if you need it. :) I took care of that yesterday. It wasn't as easy as it might seem to make sure your proxies are serializable. CGLIB didn't want to play nice. They don't make their NoOp classes serializable for some reason. I had a little easier time with Javassist and JDK proxies. > > On 2/27/08, James Carman <james@...> wrote: > > On 2/26/08, Johan Compagner <jcompagner@...> wrote: > > > Yes i would like to have something like commons proxy because i dont > > > want if possible a direct dependency on cglib. It would be coool that > > > we have a default impl that is based on jdk itself (so only interface > > > support). Then drop in cglib and you have support for also classes > > > > > > > As soon as the mirrors pick up the release and it's available in the > > maven2 repository, I'll send out the 1.0 release announcement email. > > If you just can't wait, you can grab the distribution files from: > > > > http://www.apache.org/dist/commons/proxy/ > > > > The website has already been updated: > > > > http://commons.apache.org/proxy/ > > > > One thing that I think you'll be missing is serialization of the > > proxies. After I thought about it a bit, I don't think I made all > > proxies serializable. I'll put in a JIRA for that and get that out in > > a 1.1 release. > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscribe@... > > For additional commands, e-mail: users-help@... > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by Johan Compagner
::
Rate this Message:
>
> > > Well, it'll be built into v1.1 if you need it. :) I took care of that > yesterday. It wasn't as easy as it might seem to make sure your > proxies are serializable. CGLIB didn't want to play nice. They don't > make their NoOp classes serializable for some reason. I had a little > easier time with Javassist and JDK proxies. > I am playing now with the commons-proxy But i dont get what method to call to get the right ProxyFactory.. You dont say that i have to use at compile time one of the ProxyFactory implementations right? Because then the whole purpose of commons-proxy is gone. The thing is i want to be able to call something like this: ProxyFactory factory = ProxyFactory.getInstance() and then what ever instance i get back depends on configuration or classpath I like the SLF4J approache where you just drop you wanted implementation in the classpath and you are done. But the commons-logging also works for me where you set it in a property file which one to use. But that last one has classloading problems i think so maybe it is not a good idea to copy that... So to mimic the slf4j you should have: commons-proxy-api.jar commons-proxy-cglib.jar commons-proxy-javaassist.jar and then if you want to use cglib drop in the commons api and the commons cglib jar with the cglib jar itself. johan |
|
|
Re: CompoundModel based on proxies
by jwcarman
::
Rate this Message:
On 3/8/08, Johan Compagner <jcompagner@...> wrote:
> > > > > > > > Well, it'll be built into v1.1 if you need it. :) I took care of that > > yesterday. It wasn't as easy as it might seem to make sure your > > proxies are serializable. CGLIB didn't want to play nice. They don't > > make their NoOp classes serializable for some reason. I had a little > > easier time with Javassist and JDK proxies. > > > > > I am playing now with the commons-proxy > But i dont get what method to call to get the right ProxyFactory.. > > You dont say that i have to use at compile time one of the ProxyFactory > implementations right? > Because then the whole purpose of commons-proxy is gone. > > The thing is i want to be able to call something like this: > > ProxyFactory factory = ProxyFactory.getInstance() > > and then what ever instance i get back depends on configuration or classpath > > I like the SLF4J approache where you just drop you wanted implementation in > the classpath and you are done. > But the commons-logging also works for me where you set it in a property > file which one to use. > But that last one has classloading problems i think so maybe it is not a > good idea to copy that... > > So to mimic the slf4j you should have: > > commons-proxy-api.jar > commons-proxy-cglib.jar > commons-proxy-javaassist.jar > > and then if you want to use cglib drop in the commons api and the commons > cglib jar with the cglib jar itself. > Commons Proxy has no "discovery" built into it. It's not really designed for that. You just need to instantiate what you want. File a JIRA for adding slf4j-like discovery and I'll post a discussion to the rest of the dev list about it. > > johan > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by jwcarman
::
Rate this Message:
On 3/8/08, James Carman <james@...> wrote:
> On 3/8/08, Johan Compagner <jcompagner@...> wrote: > > > > > > > > > > > > Well, it'll be built into v1.1 if you need it. :) I took care of that > > > yesterday. It wasn't as easy as it might seem to make sure your > > > proxies are serializable. CGLIB didn't want to play nice. They don't > > > make their NoOp classes serializable for some reason. I had a little > > > easier time with Javassist and JDK proxies. > > > > > > > > > I am playing now with the commons-proxy > > But i dont get what method to call to get the right ProxyFactory.. > > > > You dont say that i have to use at compile time one of the ProxyFactory > > implementations right? > > Because then the whole purpose of commons-proxy is gone. > > > > The thing is i want to be able to call something like this: > > > > ProxyFactory factory = ProxyFactory.getInstance() > > > > and then what ever instance i get back depends on configuration or classpath > > > > I like the SLF4J approache where you just drop you wanted implementation in > > the classpath and you are done. > > But the commons-logging also works for me where you set it in a property > > file which one to use. > > But that last one has classloading problems i think so maybe it is not a > > good idea to copy that... > > > > So to mimic the slf4j you should have: > > > > commons-proxy-api.jar > > commons-proxy-cglib.jar > > commons-proxy-javaassist.jar > > > > and then if you want to use cglib drop in the commons api and the commons > > cglib jar with the cglib jar itself. > > > > > Commons Proxy has no "discovery" built into it. It's not really > designed for that. You just need to instantiate what you want. File > a JIRA for adding slf4j-like discovery and I'll post a discussion to > the rest of the dev list about it. That should have been "Please file a JIRA." :) > > > > > johan > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by Johan Compagner
::
Rate this Message:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in wicket which factory i use Then i can just as well directly compile against cglib. I cant make the api that way that the developer has to give that factory to use. That would be completely horrible, johan On Sat, Mar 8, 2008 at 1:15 PM, James Carman <james@...> wrote: > On 3/8/08, Johan Compagner <jcompagner@...> wrote: > > > > > > > > > > > > Well, it'll be built into v1.1 if you need it. :) I took care of > that > > > yesterday. It wasn't as easy as it might seem to make sure your > > > proxies are serializable. CGLIB didn't want to play nice. They > don't > > > make their NoOp classes serializable for some reason. I had a little > > > easier time with Javassist and JDK proxies. > > > > > > > > > I am playing now with the commons-proxy > > But i dont get what method to call to get the right ProxyFactory.. > > > > You dont say that i have to use at compile time one of the ProxyFactory > > implementations right? > > Because then the whole purpose of commons-proxy is gone. > > > > The thing is i want to be able to call something like this: > > > > ProxyFactory factory = ProxyFactory.getInstance() > > > > and then what ever instance i get back depends on configuration or > classpath > > > > I like the SLF4J approache where you just drop you wanted > implementation in > > the classpath and you are done. > > But the commons-logging also works for me where you set it in a > property > > file which one to use. > > But that last one has classloading problems i think so maybe it is not > a > > good idea to copy that... > > > > So to mimic the slf4j you should have: > > > > commons-proxy-api.jar > > commons-proxy-cglib.jar > > commons-proxy-javaassist.jar > > > > and then if you want to use cglib drop in the commons api and the > commons > > cglib jar with the cglib jar itself. > > > > Commons Proxy has no "discovery" built into it. It's not really > designed for that. You just need to instantiate what you want. File > a JIRA for adding slf4j-like discovery and I'll post a discussion to > the rest of the dev list about it. > > > > > johan > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > |
|
|
Re: CompoundModel based on proxies
by jwcarman
::
Rate this Message:
On 3/8/08, Johan Compagner <jcompagner@...> wrote:
> for wicket this is a feature it really should have > now it defeats the purpose i have to make a decission in wicket which > factory i use > Then i can just as well directly compile against cglib. > I cant make the api that way that the developer has to give that factory to > use. That would be completely horrible, > You could always implement your own brand of discovery for your project (perhaps by using the service discovery feature built into the jdk). I like the idea of splitting it (and doing it the slf4j way rather than the JCL way). I have actually suggested that we start an exploratory branch of JCL to make it work more like slf4j (we've been talking about this since 2005). Anyway, if you file a JIRA issue, I'll make sure we have a discussion with the other devs. For your immediate purposes, commons-discovery is available also. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by jwcarman
::
Rate this Message:
I see the JIRA, I'll go ahead and start the discussion on the dev list.
On 3/8/08, James Carman <james@...> wrote: > On 3/8/08, Johan Compagner <jcompagner@...> wrote: > > > for wicket this is a feature it really should have > > now it defeats the purpose i have to make a decission in wicket which > > factory i use > > Then i can just as well directly compile against cglib. > > I cant make the api that way that the developer has to give that factory to > > use. That would be completely horrible, > > > > > You could always implement your own brand of discovery for your > project (perhaps by using the service discovery feature built into the > jdk). > > I like the idea of splitting it (and doing it the slf4j way rather > than the JCL way). I have actually suggested that we start an > exploratory branch of JCL to make it work more like slf4j (we've been > talking about this since 2005). Anyway, if you file a JIRA issue, > I'll make sure we have a discussion with the other devs. For your > immediate purposes, commons-discovery is available also. > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by jwcarman
::
Rate this Message:
Couldn't you also do:
ProxyFactory pf = ...; new SharedPropertyModel<Customer>(pf, customer); So, the client tells you what proxy factory implementation to use. On 3/8/08, James Carman <james@...> wrote: > I see the JIRA, I'll go ahead and start the discussion on the dev list. > > > On 3/8/08, James Carman <james@...> wrote: > > On 3/8/08, Johan Compagner <jcompagner@...> wrote: > > > > > for wicket this is a feature it really should have > > > now it defeats the purpose i have to make a decission in wicket which > > > factory i use > > > Then i can just as well directly compile against cglib. > > > I cant make the api that way that the developer has to give that factory to > > > use. That would be completely horrible, > > > > > > > > > You could always implement your own brand of discovery for your > > project (perhaps by using the service discovery feature built into the > > jdk). > > > > I like the idea of splitting it (and doing it the slf4j way rather > > than the JCL way). I have actually suggested that we start an > > exploratory branch of JCL to make it work more like slf4j (we've been > > talking about this since 2005). Anyway, if you file a JIRA issue, > > I'll make sure we have a discussion with the other devs. For your > > immediate purposes, commons-discovery is available also. > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: CompoundModel based on proxies
by Johan Compagner
::
Rate this Message:
no i really dont like that
then everywhere there code they need to do that, that is not an option. and they have to program themselfs agains the proxy api. I dont want that developers also have the learn/do that This is something commons-proxy needs to do On Sat, Mar 8, 2008 at 3:29 PM, James Carman <james@...> wrote: > Couldn't you also do: > > ProxyFactory pf = ...; > new SharedPropertyModel<Customer>(pf, customer); > > So, the client tells you what proxy factory implementation to use. > > On 3/8/08, James Carman <james@...> wrote: > > I see the JIRA, I'll go ahead and start the discussion on the dev list. > > > > > > On 3/8/08, James Carman <james@...> wrote: > > > On 3/8/08, Johan Compagner <jcompagner@...> wrote: > > > > > > > for wicket this is a feature it really should have > > > > now it defeats the purpose i have to make a decission in wicket > which > > > > factory i use > > > > Then i can just as well directly compile against cglib. > > > > I cant make the api that way that the developer has to give that > factory to > > > > use. That would be completely horrible, > > > > > > > > > > > > > You could always implement your own brand of discovery for your > > > project (perhaps by using the service discovery feature built into > the > > > jdk). > > > > > > I like the idea of splitting it (and doing it the slf4j way rather > > > than the JCL way). I have actually suggested that we start an > > > exploratory branch of JCL to make it work more like slf4j (we've > been > > > talking about this since 2005). Anyway, if you file a JIRA issue, > > > I'll make sure we have a discussion with the other devs. For your > > > immediate purposes, commons-discovery is available also. > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > |
| < Prev | 1 - 2 - 3 - 4 - 5 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
