Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
Received-SPF: pass (athena.apache.org: domain of
 gcjcd-cayenne-devel-890-moved1@m.gmane.org designates 80.91.229.2 as
 permitted sender)
To: dev@cayenne.apache.org
From: Ahmed Mohombe <amohombe@yahoo.com>
Subject: Re: DataViews - Proposal - move to sourceforge!
Date: Sun, 04 Nov 2007 14:30:41 +0100
Lines: 42
Message-ID: <fgkhi2$nue$1@ger.gmane.org>
References: <13564433.post@talk.nabble.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
In-Reply-To: <13564433.post@talk.nabble.com>
Sender: news <news@ger.gmane.org>

> Since the Cayenne team is not very interested in DataViews, but many users
> are, the most simple solution to me looks to move DataViews to a place where
> users can contribute much easier.
> 
> Because of it's "patch" based contribution restriction, and especially of
> the long list of incompatible "licenses", I'm not sure if Apache.org is the
> best place to get help from users with as few as possible "barriers".
Sourceforge is a good place for this however the issue tracking, the forums and the wiki are 
horrible (but one can use them from somewhere else).

> Also an important step would be to switch the license from Apache to LGPL.
> It seems that the Apache license is not too GUI friendly: just looks how few
> projects on Apache.org have GUI's and how many good GUI oriented libraries
> or tools are LGPL.
I don't think this is required. As Aristedes mentioned too, the incompatibility
between Apache license and LGPL is in the "distribution" by Apache.org.
On SF there are no such restrictions - there are many projects there that have
Apache license but have dependencies on (L)GPL code.

> Any other ideas on what could be done to re-invigorate DataViews?
1. Improve Dataviews
1.1. IMHO extending the purpose of the project would be a great idea, i.e. making
DataViews independent from Swing (or not just Swing only).

This way DataViews could be only a DSL (domain specific language) for Rich Data oriented UIs,
with several implementations:
- the actual one with Swing UIs
- several web based implementations (rich data oriented UIs are required there too).
(I have an older proof of concept based on Struts 1.1) and would gladly submit
a Click Framework (http://click.sourceforge.net/) based one (it's based on a very
old Click version but I could update that too).

1.2. Extend the Swing implementation to support JGoodies Binding and Validation.

2. Improving DVModeler would be even more important. What makes Cayenne great is CM (the
productivity gained with it and the low level entry barrier) - this should be true for any
other technology.

IMHO with 1.1 more users would be attracted to DataViews since there are many web frameworks, and 2. 
  would convince users (with the help of a small video/screencast) to give DataViews a try.

Ahmed.