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 <andru..bjectstyle.org> 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 <andru..bjectstyle.org> 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
> >>
> >>
> >
>
>
This archive was generated by hypermail 2.0.0 : Sun Oct 29 2006 - 19:32:48 EST