On Fri, Oct 3, 2008 at 12:30 PM, Ian Petersen <[EMAIL PROTECTED]> wrote:
> public interface PersonForm extends Form<Person> {
>
> Field<Person, String> getFirstName();
>
> Field<Person, String> getLastName();
>
> @Calculate("${firstName} + \" \" + ${lastName}")
> Formula<Person, String> getFullName();
> }
What is the second type parameter and why is it needed? I get that
the first parameter probably allows the generator to go introspect the
Person type and find an identically named method getFirstName(), is
the second parameter supposed to represent the return type of the
Person.getFirstName() method?
> // in widget code:
> PersonForm form = GWT.create(PersonForm.class);
>
> Person me = new Person("Ian", "Petersen");
>
> BoundForm<Person> boundForm = form.bindTo(me);
>
> BoundField<Person, String> firstName = boundForm.bind(form.getFirstName());
> BoundField<Person, String> lastName = boundForm.bind(form.getLastName());
> BoundFormula<Person, String> fullName = boundForm.bind(form.getFullName());
>
Is there any way we can make the actual binding declarations more
succinct? This seems awfully verbose and repetitive.
> The exciting bit (for me) is that the Viewer created
> for the last cell will automatically update itself as the user changes
> the values in the text boxes. The magic mostly happens in a generator
> and @Calculate can accept just about any Java expression that you can
> cram between a return and a ;.
This can be tricky. In order to make this work correctly, you're
going to have to implement a master-dependency graph and evaluate
@Calculates according to topological sort order. This is how it's done
in spreadsheets and in XForms. If not, and if @Calculate expressions
reference other formulas, you can end up with inconsistent results.
You can also detect infinite loops as well (A = B + 1, B = A + 1) and
warn people about them.
All in all, I think it looks good, but I'm not totally happy with the
generic type verbosity required. I give you props for avoiding dynamic
runtime introspection, and you proposal should allow for very
efficient binding expressions to be generated by the compiler while
minimally impacting pruning and type tightening.
I'm somewhat confused about how data fields magically turn into
Widgets. How do I say something is a Radio button, or a
CreditCardEntryWidget?
-Ray
>
> Ian
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
