Re[2]: Alternative to Wicket data binding
Hi Igor and Eelco, Sorry, for interventing in your discussion :) May java annotations can help us? Say [EMAIL PROTECTED]/Write or [EMAIL PROTECTED] or ever to protect all bean. It would protect the field from accidently access in Wicket models without any assumption on set/get functions. How it lead to additional lag on processing the model, i can't estimate. Cheers, Oleg >> all i asked johan to do was to tweak property resolver to allow access to >> private stuff. i was under the impression that the property resolver always >> tries to access the getter/setter first, then the field. >> half of this thread you are arguing that we shouldnt allow access to private >> fields/methods and half of it you are arguing that we should but try the >> getter first, so im pretty confused. > No, again, I'm arguing to *either* allowing access to all private, or > don't allow it at all. I am not against private member access per se, > just want it to be consistent. > Eelco > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- С уважением, Oleg mailto:[EMAIL PROTECTED] - 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. > > > > src/main/java > > ** > > > **/*.java > > > > > 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
Thanks for tip. I added this to my pom and it works fine now. Eclipse doesn't copy non-java files over automatically. src/main/java ** **/*.java 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
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] > >
Markup of type 'html' for component 'wicket.contrib.gmap.GMap2' not found
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: Alternative to Wicket data binding
> all i asked johan to do was to tweak property resolver to allow access to > private stuff. i was under the impression that the property resolver always > tries to access the getter/setter first, then the field. > > half of this thread you are arguing that we shouldnt allow access to private > fields/methods and half of it you are arguing that we should but try the > getter first, so im pretty confused. No, again, I'm arguing to *either* allowing access to all private, or don't allow it at all. I am not against private member access per se, just want it to be consistent. 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: > > > i completely agree with you. my point is that its been brought up, but > do > > you see anyone else jumping in on this conversation and voicing their > > opinion? you are basically championing this thread because you are a > core > > dev. there are other users on this list, if they were just as concerned > > about this im sure they would voice it once the thread got started. > > Ok, let's get back to two other occasions: setting the response page > in the constructor and setting feedback messages in the constructor. > Both occasions were similar threads like these: a user reports > something, I'm fighting half of the development team against the > status quo, get accused of championing something that is just > theoretical, etc. those were both _practical_ problems. someone _tried_ to call those methods in their code and it _didnt work as expected_. so it was fixed. this is purely theoretical. Why can't we just argue to just 'get it right'? To > my knowledge - and that might be my sloppy memory - we never actually > had a proper discussion about this. Maybe you and Johan and Matej had, > but I don't remember OK-ing the fact that having a private setter > would block, while having no setter would open it up again. I can't > imagine I would agree with that tbh. And that's all fine, we can have > that discussion now. The only thing I want to get clear from this > thread is whether we all think what we have now is good. I think it > isn't. all i asked johan to do was to tweak property resolver to allow access to private stuff. i was under the impression that the property resolver always tries to access the getter/setter first, then the field. half of this thread you are arguing that we shouldnt allow access to private fields/methods and half of it you are arguing that we should but try the getter first, so im pretty confused. -igor For the sake of clarity, I think this: > > with "public getXXX" and "private setXXX" the property is read only > with "public getXXX" and "no setXXX" the property is read only > > is not the way to go. > > I'm arguing for either using that private setter even though it is > private (since we access the private member as well), or not allowing > any private access and just tell people to use public members instead > (and I still haven't heard a convincing argument against that). > > > Eelco > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Alternative to Wicket data binding
> i completely agree with you. my point is that its been brought up, but do > you see anyone else jumping in on this conversation and voicing their > opinion? you are basically championing this thread because you are a core > dev. there are other users on this list, if they were just as concerned > about this im sure they would voice it once the thread got started. Ok, let's get back to two other occasions: setting the response page in the constructor and setting feedback messages in the constructor. Both occasions were similar threads like these: a user reports something, I'm fighting half of the development team against the status quo, get accused of championing something that is just theoretical, etc. Why can't we just argue to just 'get it right'? To my knowledge - and that might be my sloppy memory - we never actually had a proper discussion about this. Maybe you and Johan and Matej had, but I don't remember OK-ing the fact that having a private setter would block, while having no setter would open it up again. I can't imagine I would agree with that tbh. And that's all fine, we can have that discussion now. The only thing I want to get clear from this thread is whether we all think what we have now is good. I think it isn't. For the sake of clarity, I think this: with "public getXXX" and "private setXXX" the property is read only with "public getXXX" and "no setXXX" the property is read only is not the way to go. I'm arguing for either using that private setter even though it is private (since we access the private member as well), or not allowing any private access and just tell people to use public members instead (and I still haven't heard a convincing argument against that). Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative to Wicket data binding
> first of all the bean spec is _not_ the java way. it is just a spec, widely > adopted though it is - just like jsf. Comparing JavaBeans with JSF is plain bs. JavaBeans has been put forward as a standard patten by SUN from the very first versions of Java, and it is part of any beginners Java book you can get. I consider it an integral part of Java. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WicketSessionFilter
I want to have a separate servlet to go along with my wicket application that can serve streaming files. However, it needs to have access to the wicket session to know what to stream. I was thinking about using a WicketSessionFilter to help me do this. I am using wicket as a filter, and it seems to save the wicket session as wicket:MyWicketApplication:session. There is an init-param to the WicketSessionFilter to specify the middle part of that key, however, it prepends a '/' to the beginning of the string provided - hence trying to find a session call wicket:/MyWicketApplication:session and not finding anything. Is there a better way I should be doing this? Is this a bug in WicketSessionFilter? Regards, Nick. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.484 / Virus Database: 269.12.4/969 - Release Date: 23/08/2007 16:04
Re: Alternative to Wicket data binding
On 8/25/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > 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. i completely agree with you. my point is that its been brought up, but do you see anyone else jumping in on this conversation and voicing their opinion? you are basically championing this thread because you are a core dev. there are other users on this list, if they were just as concerned about this im sure they would voice it once the thread got started. -igor 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] > >
modal window as pop up on non wicket site.
I am try to see if modal window can be used to pop up a dialog box onto a page that has been written in php. I essentially want to have a html link on the older site - that would launch a pop up dialog to my application. want to avoid first coming to my app and then offering the users a form. just want to see if this can be done with the 1.2 extensions. Would appreciate some direction here.thanks,ed _ Messenger Café — open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline
Re: Alternative to Wicket data binding
On 8/25/07, Matej Knopp <[EMAIL PROTECTED]> wrote: > 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. Well, yeah. I know there are ways around it, but actively facilitating it is something else imho. > 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. I am personally not *that* concerned about encapsulation for my personal needs, but I *am* concerned about predictable behavior. Let's get back to the start of this thread. I think this: with "public getXXX" and "private setXXX" the property is read only with "public getXXX" and "no setXXX" the property is read only is very counter intuitive. I very much disagree with that if there is a private setter it is read only, but if there is just a private field, it is accessible. If we decide to keep supporting setting private members, we should support going through the private setter first. Otherwise it is just very inconsistent to me. 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. My 2c, 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
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
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 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: > > > 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 :) -igor 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:
> 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
On 8/25/07, Timo Rantalaiho <[EMAIL PROTECTED]> wrote: > 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. It is convenient, sure. Hibernate has a better reason for it than we have though. There can definitively be cases where you want to hide members for direct outside access, but want to persist them. What we are discussing here though is quite a different case. If it is no problem that people access members directly, and you think getters and setters are too much bloat, why don't you just make them public then? I'm not against directly accessing that, and I think this is something that is supported by most if not all EL out there. But having private members without getters and setters but saying they should be easily accessible by the outside world is kind of a double standard. So, public getters/ setters first, public fields as a fallback. Private fields as a fallback, well maybe if there is a setting for it and/ or when they are fields of components. Or if we have a hard time agreeing to each other, maybe just not. Like Igor and Matej pointed out, anyone can easily write their own implementations, so we can stick to something that is predictable though maybe not as convenient. 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:
>
> 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?!
well, this is what you said:
"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."
> 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.
yeah, well, not everyone likes that spec. swt uses public fields and seems
to work just fine.
> 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.
-igor
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 Oyhttp://www.ri.fi/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Palette component, how to populate right box?
Sorry, you are right, I was thinking on Collection, not a String. :( However, I found where was the problem: while creating Pallete component, I put the same model as parameters, both for model and choices model. My mistake, it is 11:30 PM at my place and I'm realy tired. :) thanks for help, vatroslav igor.vaynberg wrote: > > are you sure you get an empty string? i dont think that is possible, it > should at least be an empty collection. > > -igor > > > On 8/25/07, Vatroslav <[EMAIL PROTECTED]> wrote: >> >> >> I've tried that, and in that case items are displayed as I want. >> But on submit event, palette.getModelObject() returns empty string, >> although all items are in the right listbox?!? >> >> vatroslav >> >> >> 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#a12329569 >> 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/Palette-component%2C-how-to-populate-right-box--tf4328675.html#a12329736 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, 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
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; }
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?
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.
-igor
On 8/25/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> 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: Newbie questions
On 8/24/07, Alex Shneyderman <[EMAIL PROTECTED]> wrote: > I have been reading and re-reading the > getting started manual, unfortunately it is an extremely incomplete > document, so it is of a very limited use, although I appreciate the > intention. Wicket In Action is available through MEAP now, and chapter 2 (available since yesterday) explains how the different concepts in Wicket work together. On top of that, Martijn wrote a separate chapter solely on models which will be available in a few weeks. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Palette component, how to populate right box?
are you sure you get an empty string? i dont think that is possible, it should at least be an empty collection. -igor On 8/25/07, Vatroslav <[EMAIL PROTECTED]> wrote: > > > I've tried that, and in that case items are displayed as I want. > But on submit event, palette.getModelObject() returns empty string, > although all items are in the right listbox?!? > > vatroslav > > > 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#a12329569 > 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: Palette component, how to populate right box?
I've tried that, and in that case items are displayed as I want. But on submit event, palette.getModelObject() returns empty string, although all items are in the right listbox?!? vatroslav 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#a12329569 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] > >
Saving another page into session from ajax request
Hi all, how should i save a page -that I'm modifying from an ajax request originated at another page- into the session, if possible? The target page is an iframe nested inside the source one. For the record, I'm doing this trick not for the pleasure it brings but because of the need to upload files without submitting the entire form within which the upload iframe is contained. Btw I've posted a number of InlineFrame related issues (886, 887 and 888) with suggested quick fixes (hopefuly). Thank you in advance. Best regards, Carlos
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: Alternative to Wicket data binding
Sorry yes. I agree Wicket has a very elegant solution to giving developers
choice of how to get data between components and model.
Matej Knopp-2 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.
>
> -Matej
>
> On 8/25/07, Sam Hough <[EMAIL PROTECTED]> wrote:
>>
>>
>> From a newbie perspective, for what it is worth, say I had a class:
>> private Object secret;
>> private String temp;
>> public getSecret() {return temp;}
>> private setSecret(Object p) {secret = p;}
>> So I think I have a read only property secret that comes from temp it is
>> going to get confusing when Wicket goes in directly and sets/gets Object
>> secret.
>>
>> I know it has been very well discussed and thought out but disregarding
>> encapsulation is a bit of a turn off for us newbies.
>>
>> Pushing my luck but possible to make the model binding more pluggable?
>> Any
>> of the Swing etc systems work well? One of the things I was looking
>> forward
>> to moving from struts hell was to not have to think about HTTPRequest to
>> Bean mapping.
>>
>>
>> Matej Knopp-2 wrote:
>> >
>> > 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]
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Alternative-to-Wicket-data-binding-tf4322899.html#a12324979
>> 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/Alternative-to-Wicket-data-binding-tf4322899.html#a12325312
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
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.
-Matej
On 8/25/07, Sam Hough <[EMAIL PROTECTED]> wrote:
>
>
> From a newbie perspective, for what it is worth, say I had a class:
> private Object secret;
> private String temp;
> public getSecret() {return temp;}
> private setSecret(Object p) {secret = p;}
> So I think I have a read only property secret that comes from temp it is
> going to get confusing when Wicket goes in directly and sets/gets Object
> secret.
>
> I know it has been very well discussed and thought out but disregarding
> encapsulation is a bit of a turn off for us newbies.
>
> Pushing my luck but possible to make the model binding more pluggable? Any
> of the Swing etc systems work well? One of the things I was looking
> forward
> to moving from struts hell was to not have to think about HTTPRequest to
> Bean mapping.
>
>
> Matej Knopp-2 wrote:
> >
> > 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]
> >> >
> >> >
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Alternative-to-Wicket-data-binding-tf4322899.html#a12324979
> 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
>From a newbie perspective, for what it is worth, say I had a class:
private Object secret;
private String temp;
public getSecret() {return temp;}
private setSecret(Object p) {secret = p;}
So I think I have a read only property secret that comes from temp it is
going to get confusing when Wicket goes in directly and sets/gets Object
secret.
I know it has been very well discussed and thought out but disregarding
encapsulation is a bit of a turn off for us newbies.
Pushing my luck but possible to make the model binding more pluggable? Any
of the Swing etc systems work well? One of the things I was looking forward
to moving from struts hell was to not have to think about HTTPRequest to
Bean mapping.
Matej Knopp-2 wrote:
>
> 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]
>> >
>> >
>>
>
>
--
View this message in context:
http://www.nabble.com/Alternative-to-Wicket-data-binding-tf4322899.html#a12324979
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
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] > > > > >
