Hi Andrus, I need to pitch it to a client to fund further development. This will probably happen at the end of November.
regards Malcolm On 10/30/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
Malcolm, Looks very impressive. Do you plan to submit the patches against the 3.0 trunk? I will definitely vote for resurrecting DVModeler on the trunk (from 2.0 branch) if you will help us to merge your changes. Andrus On Oct 15, 2006, at 9:57 PM, Malcolm Edgar wrote: > Hi All, > > I have been spending some time getting familiar with the DataView / > DVmodeller code base from the Cayenne 1.2.1 build. This code is > definitely a work in progress, compared with the rest of the Cayenne > code base but I think there is a lot of great work in there. > > Things I have been doing is: > > * Making DVModeller more productive, auto populating fields, saving > prefs, etc. > > * Removed the jdom dependency for the DataView package, to enable the > DataView core to run on WebSphere without patching jdom. > > * Added ThreadLocal access pattern, as is done with DataContext, to > support server side usage. > > * refactored out dependent code Swing into a dataview.swing package > > * Unit tests and Javadoc > > I think the DataView concept is very useful, and has benefits over an > Java 1.5 annotation based meta data approach. When building > applications you often have the use case where on form where some > fields are not required (or visible), but latter on in the process > they become mandatory (in the database these fields are not > mandatory). > > With DV you can have different views across the same object entities > to support these different requirements. With a straight annotation > based approach I can't see how it would support these scenarios. > > From a conceptual point of view I think associating UI and validation > meta data for objects and their fields, is a better approach than 1.5 > annotations. I think annotations are used in JSF for this purpose. > > Extra fields which could be added the the ObjFieldView include: > * sortable - UI hint for columns > * tooltip - for field help > * width - UI field / column width hint > > Validation meta data will be more complex, and possibly should be > represented in another class. Information I would like to see would > include: > * required > * max length > * min length > * min value (for numeric values) > * max value (for numeric values) > > The existing edit format combined with the JavaClass can be used for > additional validation. > > I haven't figured out how a list of values (for a select / ComboBox) > is represented in the DV design. > > Anyway just some random thoughts. > > regards Malcolm Edgar > > On 10/11/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote: >> >> On Oct 10, 2006, at 5:22 PM, Adrian Wiesmann wrote: >> >> > Unfortunately the SOBF tool has no full time developer and does not >> > bring >> > in any money and therefore I can make no commitment. But I am >> > willing to >> > supply the "cayenne core team" with patches and diffs. Although >> > this would >> > require somebody from the core team willing and interested to go >> > through >> > my/our stuff and work that into the official source. >> >> That'll work, but will depend on the quality of patches submitted via >> Jira. As long the patches are well-organized, split into manageable >> chunks and documented via Jira comments, I personally have no problem >> committing them. >> >> >> > And of course I would welcome if I would not be the only one >> > volunteering :) >> >> Quite possibly this won't be the case. >> >> >> >> I like your website :-) >> > >> > How come? >> >> This wasn't an ironic comment. For an open source project the design >> is clean and professional. >> >> Andrus >> >> >
