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:30:08 EST