Re: Alternative to Wicket data binding
I agree. If you make the PropertyModel access private getter and setter I don't see any reason because it cannot access the attribute field directly (when the getter and setter are omitted) . - Paolo On 8/24/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Just to be pedantic they are not ignored: with public getXXX and private setXXX the property is read only with public getXXX and no setXXX the property is read only with no getXXX and public setXXX property is read and write I would say that if the field exists, it should always use that. I think we should improve it. WDYT? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative to Wicket data binding
Why couldn't it access the attribute field directly? -Matej On 8/25/07, Paolo Di Tommaso [EMAIL PROTECTED] wrote: I agree. If you make the PropertyModel access private getter and setter I don't see any reason because it cannot access the attribute field directly (when the getter and setter are omitted) . - Paolo On 8/24/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Just to be pedantic they are not ignored: with public getXXX and private setXXX the property is read only with public getXXX and no setXXX the property is read only with no getXXX and public setXXX property is read and write I would say that if the field exists, it should always use that. I think we should improve it. WDYT? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Palette component, how to populate right box?
Hi, Is it possible to populate both list boxes on Palette component? Or even only right one (Selected)? Usually I only want to change order, and in rare cases to remove some items. So populating only selected box would be preferable. Regards, Vatroslav -- View this message in context: http://www.nabble.com/Palette-component%2C-how-to-populate-right-box--tf4328675.html#a12328238 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Palette component, how to populate right box?
that box is populated from the selection model, so make sure the collection in that model has the selected items -igor On 8/25/07, Vatroslav [EMAIL PROTECTED] wrote: Hi, Is it possible to populate both list boxes on Palette component? Or even only right one (Selected)? Usually I only want to change order, and in rare cases to remove some items. So populating only selected box would be preferable. Regards, Vatroslav -- View this message in context: http://www.nabble.com/Palette-component%2C-how-to-populate-right-box--tf4328675.html#a12328238 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative to Wicket data binding
On 8/25/07, Matej Knopp [EMAIL PROTECTED] wrote: But the binding is as pluggable as possible. You can write any IModel implementation you want. Think of (Compound)PropertyModel as pure convenience implementation (that works for 99% usecases). With wicket, you don't think of mapping http requests to bean. But you have to think about mapping components to beans, because that's a fundamental thing in wicket (thus IModel). Anyway, I think if there is a public getter and private setter, we should honor the private setter and don't touch the field directly. I think that choice is completely arbitrary. Why honor encapsulation when a setter is private but not when there is no setter? Look, just about two months ago I discovered property models could work on private fields directly. I wasn't crazy about that, but Igor made a point and convinced me that it is ok to have when you work on private members of components. Even though I don't see any danger in providing such components with getters and setters, it's mostly bloat, so I can live without that. Normal beans however, I'm not so sure now about those... I hate the fact that we're inconsistent now with what people would typically expect. Like it or not, java beans using getters and setters is an established pattern. Maybe we could do something in between. If the target of a property model is a component, the model can work on the member directly (should first try *any* setter and if none is available, use the field), but if the target is not, it should only work via getters and setters. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative to Wicket data binding
On 8/25/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i think that is a foolish argument as you are assuming property model should
only work on _beans_
it is perfectly normal to do something like this:
class data { public String name; public int age; }
Yes, I hope you didn't really think that I would be against using
public fields directly were you?!
and wicket should work with this. if this data object is a private inner of
something and is only used there wth is the point of creating
getters/setters?
Because that confirms to the bean spec and to what probably 90% of
people would initially expect.
so our property model should work like this:
always try setter/getter first, if not fallback onto the field.
i dont really see a danger of propertymodel accessing private members
because you can do it yourself if you wanted - and in fact you ARE doing it
yourself by specifying that property path.
That is a ridiculous statement.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative to Wicket data binding
On Sat, 25 Aug 2007, Igor Vaynberg wrote: always try setter/getter first, if not fallback onto the field. +1 Direct field access works typically so I like to omit accessor bloat when possible, and if you need any special handling in the accessor just create the accessor method for it. If you want to conform better with the javabean way, maybe you could make falling back to direct field access a setting (default to true, please ;)). I (and surely many others) like field access anyway, and use it with Hibernate as well. - Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative to Wicket data binding
On 8/25/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
On 8/25/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 8/25/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i think that is a foolish argument as you are assuming property model
should
only work on _beans_
it is perfectly normal to do something like this:
class data { public String name; public int age; }
Yes, I hope you didn't really think that I would be against using
public fields directly were you
yeah, well, not everyone likes that spec. swt uses public fields and seems
to work just fine.
So I wasn't complete. In case you really though I am against directly
accessing public fields: I am not. Getters/ setters first and then
public fields is fine, preferably even.
so our property model should work like this:
always try setter/getter first, if not fallback onto the field.
i dont really see a danger of propertymodel accessing private members
because you can do it yourself if you wanted - and in fact you ARE doing
it
yourself by specifying that property path.
That is a ridiculous statement.
how do you mean? are you saying that propertymodel has some special jvm
magic that can access fields you otherwise could not? my point is...how do
you even know the path to the private field unless you already did some
poking around, or it is your own code.
I fail the see the logic in that, sorry. Why just not throw any scope
limiting away?
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative to Wicket data binding
I fail the see the logic in that, sorry. Why just not throw any scope limiting away? in this particular case: yes. dont forget that property model is entirely about convinience in the first place, and flattening scopes is just another part of that convenience :) So you write a class with a certain member, but as you don't want people to directly access that member, you don't provide an mutator method. Someone else takes a look at your class and decides to directly access the member using property model regardles. I know people can do it with introspection anyway, but it arguably breaches encapsulation. If you have a component/ page with members and in that component/ page you link a property model to it, I think it is fair to say you'd like to access the property as an implementation detail. But for regular domain objects, I don't see why normal rules of encapsulation wouldn't apply. Anyway, we built the damn thing so we know about it, though I - as a member of the dev team - didn't even know about this 'feature' until recently, neither did Martijn give this any special mention in his chapter on models so far. Also, this is the second time the topic comes up, so I don't think it is as obvious or intuitive as you are suggesting. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative to Wicket data binding
On 8/25/07, Eelco Hillenius [EMAIL PROTECTED] wrote: So you write a class with a certain member, but as you don't want people to directly access that member, you don't provide an mutator method. Someone else takes a look at your class and decides to directly access the member using property model regardles. I know people can do it with introspection anyway, but it arguably breaches encapsulation. my point is only that if people wanted to do this they could with or without the propertymodel. and if you really dont like it just go ahead and install a security manater. If you have a component/ page with members and in that component/ page you link a property model to it, I think it is fair to say you'd like to access the property as an implementation detail. But for regular domain objects, I don't see why normal rules of encapsulation wouldn't apply. what if i have a non-public top level class in my ui package sitting next to the component that uses it as a propertymodel object? all im saying is that narrowing it down to a direct property of a component is too narrow. in fact it just makes it more confusing when it does and does not work. Anyway, we built the damn thing so we know about it, though I - as a member of the dev team - didn't even know about this 'feature' until recently, neither did Martijn give this any special mention in his chapter on models so far. Also, this is the second time the topic comes up, so I don't think it is as obvious or intuitive as you are suggesting. yes it is the second time this topic comes up out of how many of thousands of users there are i dont know. i think this feature is very convenient. it is not something you can toggle on and off because 3rd party components might be written with this in mind. so i would say keep it, end of story. but that is just me. -igor Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative to Wicket data binding
I agree with Igor here. If you are really concerned about protecting private fields, your only option is running with a security manager. Otherwise there will always be a way around it. Being able to access private field is convenient and reduces code clutter. Even though it's not the cleanest way around, the practical benefits IMHO outweight the drawbacks. -Matej On 8/26/07, Igor Vaynberg [EMAIL PROTECTED] wrote: On 8/25/07, Eelco Hillenius [EMAIL PROTECTED] wrote: So you write a class with a certain member, but as you don't want people to directly access that member, you don't provide an mutator method. Someone else takes a look at your class and decides to directly access the member using property model regardles. I know people can do it with introspection anyway, but it arguably breaches encapsulation. my point is only that if people wanted to do this they could with or without the propertymodel. and if you really dont like it just go ahead and install a security manater. If you have a component/ page with members and in that component/ page you link a property model to it, I think it is fair to say you'd like to access the property as an implementation detail. But for regular domain objects, I don't see why normal rules of encapsulation wouldn't apply. what if i have a non-public top level class in my ui package sitting next to the component that uses it as a propertymodel object? all im saying is that narrowing it down to a direct property of a component is too narrow. in fact it just makes it more confusing when it does and does not work. Anyway, we built the damn thing so we know about it, though I - as a member of the dev team - didn't even know about this 'feature' until recently, neither did Martijn give this any special mention in his chapter on models so far. Also, this is the second time the topic comes up, so I don't think it is as obvious or intuitive as you are suggesting. yes it is the second time this topic comes up out of how many of thousands of users there are i dont know. i think this feature is very convenient. it is not something you can toggle on and off because 3rd party components might be written with this in mind. so i would say keep it, end of story. but that is just me. -igor Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative to Wicket data binding
yes it is the second time this topic comes up out of how many of thousands of users there are i dont know. i think this feature is very convenient. it is not something you can toggle on and off because 3rd party components might be written with this in mind. so i would say keep it, end of story. but that is just me. We've been there before though. Don't expect regular users to report any issue they find. How often do we bitch about things in Hibernate without ever doing it in public (mailing lists, issue trackers)? So, while I'm not saying this is an imminent problem just because we've had the topic brought up twice, I think we can say it is an issue that at least confuses some people, and that alone is imho enough reason to re-evaluate whether we made the best choices. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative to Wicket data binding
On 8/25/07, Eelco Hillenius [EMAIL PROTECTED] wrote: Finally, I'd like to hear a good argument why we shouldn't just say: if you want to access members directly, just make them public. If you want to avoid clutter (i.e. writing getters and setters) and you don't care about breaking encapsulation, why not do it the Java-way? Saying that you don't want to expose your members for normal Java programming, but do want to expose those members when using a property model strikes me as having a double standard. first of all the bean spec is _not_ the java way. it is just a spec, widely adopted though it is - just like jsf. second of all we _are_ doing it the java way. reflection has access to private fields and property model uses reflection, that is the java way. and third of all i think this _helps_ preserve encapsulation not break it. this whole argument started because someone _looked_ at the javadoc and said oh crap this can access private fields, oh no this is so anti java!, a purely theoretical concern, that will probably never have a sideeffect in real life while providing significant real life benefits. -igor My 2c, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Markup of type 'html' for component 'wicket.contrib.gmap.GMap2' not found
either the example is broken or your ide does not copy .html files from the src dir to the classes dir. -igor On 8/25/07, hhuynh [EMAIL PROTECTED] wrote: Hi all, I've tried out the examples of wicket-contrib-gmap2-examples and got this below error. I'm pretty new to Wicket so I'm not sure where to start debugging this error. Anybody has idea? Thank you, Hung- WicketMessage: Markup of type 'html' for component 'wicket.contrib.gmap.GMap2' not found. Enable debug messages for org.apache.wicket.util.resource to get a list of all filenames tried: [MarkupContainer [Component id = topPanel, page = wicket.contrib.examples.gmap.HomePage, path = 0:topPanel.GMap2, isVisible = true, isVersioned = true]] Root cause: org.apache.wicket.markup.MarkupNotFoundException: Markup not found. Component class: wicket.contrib.gmap.GMap2 Enable debug messages for org.apache.wicket.util.resource to get a list of all filenames tried at org.apache.wicket.markup.MarkupCache.getMarkupStream(MarkupCache.java:199) at org.apache.wicket.MarkupContainer.getAssociatedMarkupStream( MarkupContainer.java:331) at org.apache.wicket.MarkupContainer.renderAssociatedMarkup( MarkupContainer.java:601) at org.apache.wicket.markup.html.panel.Panel.onComponentTagBody(Panel.java :107) at org.apache.wicket.Component.renderComponent(Component.java:2114) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1294) at org.apache.wicket.Component.render(Component.java:1941) at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1179) at org.apache.wicket.MarkupContainer.renderComponentTagBody( MarkupContainer.java:1349) at org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java :1284) at org.apache.wicket.Component.renderComponent(Component.java:2114) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1294) at org.apache.wicket.Component.render(Component.java:1941) -- View this message in context: http://www.nabble.com/Markup-of-type-%27html%27-for-component-%27wicket.contrib.gmap.GMap2%27-not-found-tf4329975.html#a12331945 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Markup of type 'html' for component 'wicket.contrib.gmap.GMap2' not found
Thanks for tip. I added this to my pom and it works fine now. Eclipse doesn't copy non-java files over automatically. resources resource directorysrc/main/java/directory includes include**/include /includes excludes exclude**/*.java/exclude /excludes /resource /resources Hung- igor.vaynberg wrote: either the example is broken or your ide does not copy .html files from the src dir to the classes dir. -igor On 8/25/07, hhuynh [EMAIL PROTECTED] wrote: Hi all, I've tried out the examples of wicket-contrib-gmap2-examples and got this below error. I'm pretty new to Wicket so I'm not sure where to start debugging this error. Anybody has idea? Thank you, Hung- WicketMessage: Markup of type 'html' for component 'wicket.contrib.gmap.GMap2' not found. Enable debug messages for org.apache.wicket.util.resource to get a list of all filenames tried: [MarkupContainer [Component id = topPanel, page = wicket.contrib.examples.gmap.HomePage, path = 0:topPanel.GMap2, isVisible = true, isVersioned = true]] Root cause: org.apache.wicket.markup.MarkupNotFoundException: Markup not found. Component class: wicket.contrib.gmap.GMap2 Enable debug messages for org.apache.wicket.util.resource to get a list of all filenames tried at org.apache.wicket.markup.MarkupCache.getMarkupStream(MarkupCache.java:199) at org.apache.wicket.MarkupContainer.getAssociatedMarkupStream( MarkupContainer.java:331) at org.apache.wicket.MarkupContainer.renderAssociatedMarkup( MarkupContainer.java:601) at org.apache.wicket.markup.html.panel.Panel.onComponentTagBody(Panel.java :107) at org.apache.wicket.Component.renderComponent(Component.java:2114) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1294) at org.apache.wicket.Component.render(Component.java:1941) at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1179) at org.apache.wicket.MarkupContainer.renderComponentTagBody( MarkupContainer.java:1349) at org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java :1284) at org.apache.wicket.Component.renderComponent(Component.java:2114) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1294) at org.apache.wicket.Component.render(Component.java:1941) -- View this message in context: http://www.nabble.com/Markup-of-type-%27html%27-for-component-%27wicket.contrib.gmap.GMap2%27-not-found-tf4329975.html#a12331945 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Markup-of-type-%27html%27-for-component-%27wicket.contrib.gmap.GMap2%27-not-found-tf4329975.html#a12331989 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Markup of type 'html' for component 'wicket.contrib.gmap.GMap2' not found
there is a setting to make it do so, cant quiet remember where it is right now. -igot On 8/25/07, hhuynh [EMAIL PROTECTED] wrote: Thanks for tip. I added this to my pom and it works fine now. Eclipse doesn't copy non-java files over automatically. resources resource directorysrc/main/java/directory includes include**/include /includes excludes exclude**/*.java/exclude /excludes /resource /resources Hung- igor.vaynberg wrote: either the example is broken or your ide does not copy .html files from the src dir to the classes dir. -igor On 8/25/07, hhuynh [EMAIL PROTECTED] wrote: Hi all, I've tried out the examples of wicket-contrib-gmap2-examples and got this below error. I'm pretty new to Wicket so I'm not sure where to start debugging this error. Anybody has idea? Thank you, Hung- WicketMessage: Markup of type 'html' for component 'wicket.contrib.gmap.GMap2' not found. Enable debug messages for org.apache.wicket.util.resource to get a list of all filenames tried: [MarkupContainer [Component id = topPanel, page = wicket.contrib.examples.gmap.HomePage, path = 0:topPanel.GMap2, isVisible = true, isVersioned = true]] Root cause: org.apache.wicket.markup.MarkupNotFoundException: Markup not found. Component class: wicket.contrib.gmap.GMap2 Enable debug messages for org.apache.wicket.util.resource to get a list of all filenames tried at org.apache.wicket.markup.MarkupCache.getMarkupStream(MarkupCache.java :199) at org.apache.wicket.MarkupContainer.getAssociatedMarkupStream( MarkupContainer.java:331) at org.apache.wicket.MarkupContainer.renderAssociatedMarkup( MarkupContainer.java:601) at org.apache.wicket.markup.html.panel.Panel.onComponentTagBody(Panel.java :107) at org.apache.wicket.Component.renderComponent(Component.java:2114) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java :1294) at org.apache.wicket.Component.render(Component.java:1941) at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1179) at org.apache.wicket.MarkupContainer.renderComponentTagBody( MarkupContainer.java:1349) at org.apache.wicket.MarkupContainer.onComponentTagBody( MarkupContainer.java :1284) at org.apache.wicket.Component.renderComponent(Component.java:2114) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java :1294) at org.apache.wicket.Component.render(Component.java:1941) -- View this message in context: http://www.nabble.com/Markup-of-type-%27html%27-for-component-%27wicket.contrib.gmap.GMap2%27-not-found-tf4329975.html#a12331945 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Markup-of-type-%27html%27-for-component-%27wicket.contrib.gmap.GMap2%27-not-found-tf4329975.html#a12331989 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
