FWIW, another advantage to using web services is that they allow your data to be consumed by a wider range of clients. Using WTKX as a serialization format ensures that your data can only be consumed by a Pivot application. G
On Mar 23, 2010, at 9:04 AM, Greg Brown 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 >>> >> >> >
