blob: 6de8df8da6fe342290ad483323e34510f99212ce [file] [log] [blame]
Title: Swing Applications
<P>Those who have experience of Swing GUI development knows how much time it takes to work out all the minutest details of formatting, in-place input validation, handling the interactive data modification, enforcing naming, order, and formatting consistensy, etc. Whenever the domain or requirements change (e.g. new attributes are added to an ObjEntity, formats or captions of data are modified, or relationships change their meaning) developers are faced with the necessity to go through the number of Swing data models, panels, various helpers fishing out the bits of code to be corrected.</P>
<P>Another problem is the need for quick and easy prototyping of data aware GUIs. Those who, at one time or another, worked with Borland VCL for C++ or Delphi or DataExpress/dbSwing for Java and similar frameworks can recall how painless it was to create a rough prototype of the GUI working with the relational database and bind it to the actual data. That was possible due to the layer of easily configured data aware classes and components. And once the working prototype had been ready, refinining it used to be a very simple task.</P>
<P>Cayenne DataViews solve these problems. Data Views act as a bridge between the domain defined in terms of Cayenne DataObjects and a presentation layer built with Swing. Potentially they can be used in the Web environment as well, but Swing integration is the main direction. Conceptually, Data Views are close to the application facades described, for instance, by <A href="http://www.martinfowler.com/apsupp/appfacades.pdf" class="external-link" rel="nofollow">Martin Fowler</A>. The following figure shows the area where Data Views can be applied.<BR>
<SPAN class="image-wrap" style=""><IMG src="swing-applications.data/dataview-usecases.gif" style="border: 0px solid black"></SPAN></P>
<DIV class="panelMacro"><TABLE class="infoMacro"><COLGROUP><COL width="24"><COL></COLGROUP><TR><TD valign="top"><IMG src="http://cayenne.apache.org/docs/1.2/images/icons/emoticons/information.gif" width="16" height="16" align="absmiddle" alt="" border="0"></TD><TD><B>Validation</B><BR>The validation rules mentioned in the Use Cases are meant to be &quot;lightweght&quot;, i.e. it is generally agreed the validation related code to enforce the business rules should be located in the domain area but, still, there are various checks one could prefer to perform right in the presentation layer like inclusion in a predefined range of values, correct input format, sometimes, even preliminary credit card number validity check with the well known Luhn algorithm, the other kinds of sanity checks. Presently the validation is on the list of the features to be added.</TD></TR></TABLE></DIV>