Not the GUI components, just the data structures for the components (lists, hashmaps, etc). It makes binding super easy.
Bob On Tue, Mar 23, 2010 at 8:04 AM, Greg Brown <[email protected]> wrote: > IMO, XML and JSON both have their places. But are you suggesting that an > application generate WTKX representing the application's UI and send that > back to the client, much like HTML is generated on the server today? If so, > this is viable, but it may not be advisable in all cases since it tightly > couples the client and server. One of the main advantages to web services > (whether REST, SOAP, or otherwise) is that they allow the client and server > to be loosely coupled and can vary much more independently. > > > On Mar 23, 2010, at 8:55 AM, Robert Piotrowski wrote: > > Just my 2 cents, but if you bring back XML from a server that is already > styled to match the data structure of your component, it's just a matter of > using the WTKX serializer to get a handle on the data and dropping it onto > your component. It works great with tables, trees, etc. The data might be > a little more verbose, but it really doesn't matter when we're running > decent desktops. > > To me, XML is much more readable and a better data exchange than JSON. You > can always restyle another source so that it will become WTKX. > > Again, just my opinion. > > Bob > > > On Tue, Mar 23, 2010 at 7:13 AM, Greg Brown <[email protected]> wrote: > >> This list is similar to what I would have suggested, though I might >> re-word #5 as "Take advantage of data binding". Using JSON as a data >> transfer format helps facilitate this, though there are other ways (you can >> also use data binding to bind to Java beans, for example). >> >> I might also re-word #7 as "Take advantage of web queries". They still >> offer a lot of value to your app even if you don't control both client and >> server. If you do, then you can also use QueryServlet on the back end as >> Todd mentioned. >> >> Finally, I would add the following: >> >> 8) Use Resources to manage the localizable aspects of your app. This >> suggestion isn't necessarily unique to Pivot, but I find that it is >> generally easiest to design for localization up front rather than trying to >> retrofit it later. >> >> G >> >> On Mar 23, 2010, at 7:58 AM, Todd Volkert wrote: >> >> Hi Shahzad, >> >> Pivot certainly meets all those key requirements. There have been at >> least three complex enterprise-level applications built using the Pivot >> platform (that I know of), though as far as I know, none of them are open >> source. However, their authors (one of them being me) are all on this user >> list, so you'd presumably have the benefit of their experience. >> >> As far as best practices go, that's somewhat specific to the requirements >> of the application, but I can share some high-level insights that I've >> gained in writing my Pivot apps: >> >> 1) Separate your behaviors into Action classes that live in the global >> action map. This allows you to wire up the actions to your buttons and menu >> items easily in WTKX and provides logical separation in code. >> >> 2) Author your UI in WTKX. Some people are against UI construction in >> XML, but I find that it's a nice fit. >> >> 3) Use the @WTKX annotation. It helps remove boilerplate clutter from >> your code. Note, however, that this will require you to either (a) sign >> your JAR files, or (b) make your @WTKX fields public. >> >> 4) As of Pivot 1.5 (to be released in the next ~2 months), use the >> Bindable interface. I wrote my big Pivot apps against Pivot 1.4 (before >> Bindable existed), and I went with a "manager" concept -- where each WTKX >> file had a corresponding manager class that populated the UI with data and >> wired up event handlers. That model worked fairly well, but from what I >> hear, the Bindable interface is an alternative approach that yields even >> cleaner code. The gist is that you subclass the root component of your WTKX >> file and implement Bindable, and that subclass performs the work that would >> have otherwise been done by the manager. >> >> 5) Try to deal in raw JSON data (maps, lists, numbers, strings, etc.) >> only. Avoid having to load data from the server and then translate it into >> app-specific data model classes, and instead, write custom renderers to >> render the raw data correctly into your buttons, tables, lists, etc. This >> allows you to use data binding to directly move the data from the server to >> the UI. As of Pivot 1.5, the new bind mapping facilities make this even >> easier (it is possible in Pivot 1.4, but you have to jump through more >> hoops). >> >> 6) To reiterate the last point, don't be afraid to write custom data >> renderers! They're not tough to write (you can typically subclass a >> component to get the desired behavior), and they allow you to render data in >> any form straight to the UI. >> >> 7) If you control both the client and the server, using QueryServlet as >> the server endpoint provides nice parity with using web queries (GetQuery, >> PostQuery, etc.) on the client. >> >> I'm sure there are more, but those are the ones that come to me right now >> :-) >> >> Hope that helps, >> -T >> >> On Mon, Mar 22, 2010 at 8:15 PM, Shahzad Bhatti <[email protected]>wrote: >> >>> I am evaluating Apache Pivot as possible platform for building a trading >>> application. The key requirements for our application are snappy UI, support >>> for multiple windows, charts, real time updates to quotes and other >>> financial data. I would like to know if there are any complex applications >>> that have been built with Apache Pivot especially any open source. I am also >>> interested in best practices behind this platform for building highly >>> interactive applications. Thanks in advance. >>> >>> ______________________________________________ >>> >>> See http://www.peak6.com/email_disclaimer.php >>> for terms and conditions related to this email >>> >> >> >> > >
