-
26 Dec 2012 9:37 AM #1
@Path annotation with arrays
@Path annotation with arrays
Hello
I'm creating a grid with a variable number of columns. I'm almost done but only one thing left... I cant access attribute Address (PersonProperties interface). I dont know how to write @Path properly. If anyone has any idea, Please give me advice.
JSON:
PropertyAccess Interface:Code:[ { "FirstName": "John", "LastName": "Doe", "Age": 23, "Details": [ { "Address": "Apt R113", "City": "Boston", "ZipCode": "30523" }, { "Address": "ABC 22", "City": "Paris", "ZipCode": "51112" } ] } ]
and here is my code:Code:public interface PersonProperties extends PropertyAccess<PersonDTO> { ModelKeyProvider<PersonDTO> key(); ValueProvider<PersonDTO, String> FirstName(); ValueProvider<PersonDTO, String> LastName(); ValueProvider<PersonDTO, Integer> Age(); @Path("Details???Address") ValueProvider<PersonDTO, String> Address(); }
Code:PersonDTO person = personList.get(0); for (int i = 0; i < person.getDetails().length(); i++) { DetailDTO detail = person.getDetails().get(i); ColumnConfig<PersonDTO, String> cc = new ColumnConfig<PersonDTO, String (personProperties.Address(), 50, detail.getCity()); l.add(cc); }
-
28 Dec 2012 11:15 AM #2
As discussed on your SO post, this isn't supported. AutoBeans are a GWT feature - the only thing that GXT brings to the table is XML support.
That XML support includes simple pathing because XML supports both attributes and sub-elements, and it is possible for a tag to have a child attribute and a child element that have the same node name - this allows for some disambiguation. Additionally, we support other simple paths using the DomQuery engine and language, because it is convinient to do so, not because we expect complex mappings to occur. Indeed, complex mappings will make it very difficult to map both XML to objects and those objects back to XML (using the XmlWriter), so we don't encourage it.
In general, AutoBeans are meant to be a simple interface-based window into the underlying data, not a full-on mapping system. This encourages developers to keep their models simple, as client code is usually running in the slowest environment (as browser JS VMs are often slower than any server technology). Other libraries exist that target this 'translation' style of object mapping instead of directly mapping properties and types - Piriti comes to mind, though I haven't worked directly with it before.


Reply With Quote