Just a bit of history on binding. In Click 1.4 binding was introduced because people wanted a shortcut for binding and converting input params. This was in the Java 1.4 days, pre annotation. So public fields was used as binding. With Java 1.5 Bindable was introduced but backward compatibility was kept in place. (If you want to use public fields in your pages that should not be bound, you can set autobinding="annotation" and public fields won't be touched.)
So the intention wasn't to support both public fields and @Bindable. It was for preserving backwards compatibility. I understand the argument of splitting @Bindable into two behaviors -> @InputParameter (which sets and coerce the value vs @AddToModel which adds the value to the model. The Bindable design also raised these issues: https://cwiki.apache.org/confluence/display/CLICK/Java+5+Support but this work was never completed. Kind regards Bob On 21/11/2010 01:49, Lorenzo Simionato wrote: > On Nov 20, 2010, at 14:35 , Bob Schellink wrote: > > Here what i meant is that if you declare a field as @Bindable you are clearly > aware that it can be set in some way by the user. > If you have a public field (ok, it's rare) this is not that obvious. > > Here the XSS was just an example. The fact that one can set a value that i > intended only for output is disturbing. > As a couple of other examples: > -suppose the welcomeMessage is the title of the page. It's not nice that one > can put an arbitrary title on the page, even if it is escaped properly. > > -suppose one modifies the RequestTypeConverter as explained in the > documentation to dynamically load customers from the db. > In a page one would like to do something with a customer object and then > print the details, so we could have something like: > MyPage.class > public class MyPage extends Page { > @Bindable protected Customer customer = loadCustomer(3); > > pubic void action() { > customer.set.....(); > } > > MyPage.html > $customer.name > > a different customer can be loaded with a request like mypage.htm?customer=56 > (this example is a little weird but is just to get the idea) > > > These are just examples and maybe if all is handled very carefully by the > programmer there would not be any problems. > However, they demonstrate that it is easy to make something that does not > work as intended. > As a last example consider SQL Injections: if you escape the input properly > you do not have the problem. On the other hand, > to prevent the problem even if you are not that careful PHP has introduced > magic quotes and in Java we have preparedStatements (yes i'm simplifying a > lot the things here!). The concept is that this double role of public field > and ones annotated with @Bindable (as parameters and variables added to the > page) it does not seem a good idea to me. > > -- > Lorenzo
