> You could still do your work in your own svn > repository until you were ready to merge it if that was easiest for you.
I guess this is the best way. We copy the current status of DataViews into our own project and feed changes back to Cayenne. There are still some technical questions concerning how we should integrate the DataView part of Cayenne into our own project, but the goal is it to keep things as they are and to stay as "compliant" as possible so that we can feed back our changes into Cayenne. > Although I haven't looked > deeply into DataViews, they appear to offer some of the same promise > as this approach - in fact to me they look slightly like a GUI for > creating SQLtemplates. I see them as an easy way to "paint" a list/table form or edit form during design time which is interpreted at runtime by the application. So I don't have to look after the data binding, after basic validation checks, paging, adding new records etc. The layout is defined by the dataview and is then interpreted by whatever renderer I prefer. > If you add GPL/LGPL code to an existing Apache licensed code base, > then anything you release will be usable only under the more > restrictive GPL/LGPL license. This means it cannot be merged back > into Cayenne. If possible, I think the prospect of merging your > improvements back to Cayenne would be a useful one. My problem is less in dual licencing our changes than in integrating the DataViews (which is Apache licence) into our own tool (which is GPL). But as far as I see nobody from Cayenne has a problem with us doing so and therefor I suggest that we integrate the DataView code into our own project (because this is easier for us to work on them) and when merging our changes with Cayenne we licence our changes under the Apache licence. We will probably have to change some namespaces, but that can be scripted and is IMHO no big problem when merging back. > What would be interesting is if you could clarify what your goals are > for DataViews. Is it just to get them working against against Cayenne > 3.0 or do you have some specific features you want to add? DataViews run without any changes on 3.0. At least in the snapshot I got. Our problem is that DataViews lack some functionality (no complete list and we currently don't need everything from here): - Edit form renderer (single record) instead of a list (table model). I want to design a DataView and then have a renderer create a form for me. Much in the way that I can add a DataView to a TableModel. - Foreign key relation editing. I need a mechanism in which a user can select a foreign record from a list to set as a foreign key on the current row. - Code field resolution. I need comboboxes with some human readable representations of codes so that I can present those comboboxes to the user instead of him having to enter a number or some cryptic value. - Dynamic fields. Sometimes there is the need to have a field which can only be used on one specific view. Probably some calculation which is never stored on the database and therefor has no representation on the DataObject. - Foreign relations with a filter. Sometimes a list should show a field from a foreign key relation. But there are multiple records via the relation. It must then be possible to add a filter to a relation. - Theoretically DataViews could be used for web development as well and I wonder why this was not adopted before. A page could define which DataView to use with what kind of DataSet and a renderer could then render this specific webpage. We already added some of those features to our snapshot of Cayenne. But there is still much to be done and I am not sure if everybody would agree with our changes. And we would like to regularly switch to a new build of Cayenne 3.0 so that we stay current. Which means that we either have to go completely proprietory with our changes or integrate the DataViews and feed our changes back. I think everybody here agrees that the last procedure is OK with Cayenne. So let's start :) Regards, Adrian
