Return-Path: Delivered-To: apmail-pivot-user-archive@www.apache.org Received: (qmail 16767 invoked from network); 23 Mar 2010 13:35:12 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 23 Mar 2010 13:35:12 -0000 Received: (qmail 68598 invoked by uid 500); 23 Mar 2010 13:35:12 -0000 Delivered-To: apmail-pivot-user-archive@pivot.apache.org Received: (qmail 68579 invoked by uid 500); 23 Mar 2010 13:35:12 -0000 Mailing-List: contact user-help@pivot.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@pivot.apache.org Delivered-To: mailing list user@pivot.apache.org Received: (qmail 68571 invoked by uid 99); 23 Mar 2010 13:35:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Mar 2010 13:35:12 +0000 X-ASF-Spam-Status: No, hits=-0.9 required=10.0 tests=AWL,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gkbrown@mac.com designates 17.148.16.101 as permitted sender) Received: from [17.148.16.101] (HELO asmtpout026.mac.com) (17.148.16.101) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Mar 2010 13:35:05 +0000 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_q4n0RynjP5JTa+J3vtxmxA)" Received: from [192.168.1.10] (pool-173-76-183-203.bstnma.fios.verizon.net [173.76.183.203]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KZQ0090SLPN2VA0@asmtp026.mac.com> for user@pivot.apache.org; Tue, 23 Mar 2010 06:34:38 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003230094 From: Greg Brown Subject: Re: Evaluating Pivot Date: Tue, 23 Mar 2010 09:34:35 -0400 In-reply-to: <68dcbc7a1003230630u1634e18dl7d9651b53524388f@mail.gmail.com> To: user@pivot.apache.org References: <36fe576b1003220503n3b4cff86p8fe28306553fd6a6@mail.gmail.com> <168ef9ac1003230458l10c460cdp724f87f080fe6c94@mail.gmail.com> <6BC52395-A475-4CE3-B1A2-CFD7FF3AD269@mac.com> <68dcbc7a1003230555o12e4916j5774a5175f20b0a3@mail.gmail.com> <68dcbc7a1003230630u1634e18dl7d9651b53524388f@mail.gmail.com> Message-id: <7110A47D-AB9D-4CCE-BC57-878C6A2F739C@mac.com> X-Mailer: Apple Mail (2.1077) --Boundary_(ID_q4n0RynjP5JTa+J3vtxmxA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT So are you are simply using application-specific XML as a data interchange format? If so, this is also a good option. An instance of org.apache.pivot.xml.Element can be used to back a list view or table view and can also serve as a tree data model, which JSON can't. On Mar 23, 2010, at 9:30 AM, Robert Piotrowski wrote: > 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 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 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 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 >>> >> >> > > --Boundary_(ID_q4n0RynjP5JTa+J3vtxmxA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT So are you are simply using application-specific XML as a data interchange format? If so, this is also a good option. An instance of org.apache.pivot.xml.Element can be used to back a list view or table view and can also serve as a tree data model, which JSON can't.


On Mar 23, 2010, at 9:30 AM, Robert Piotrowski wrote:

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 <gkbrown@mac.com> 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 <gkbrown@mac.com> 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 <sbhatti@peak6.com> 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






--Boundary_(ID_q4n0RynjP5JTa+J3vtxmxA)--