> DataViews technology was contributed by the one time Cayenne committer
> who is no longer active in the community. We support it in its current
> state, but there is no ongoing development. Post 1.2, I think we should
> move it out of the core to an extension package or something.
:(.
> I personally use a different methodology revolving around JStaple ideas:
> http://objectstyle.org/jstaple/
> http://www.theserverside.com/articles/article.tss?l=JavaGUIDev
Sounds interesting, but I have the impression that it's somehow more Swing dependent.
> I'd also love to have a good integrated Swing framework, just don't
> have any time left to work on this. So as far as UI goes, I have to
> start almost from scratch every time I begin a new Swing project.
>
> I wish we could somehow merge DV into JStaple and develop JStaple
> itself into a usable technology (maybe borrow some Click ideas - I have
> a feeling those will translate pretty well into the Swing space).
> Unfortunately all this is still wishful thinking...
Well my idea was in a little other direction:
1. Integrate DVModeler into Cayenne Modeler (one modeler should be enough IMHO) and simpler to maintain.
2. Separate from DataViews the Swing classes/implementation (only a few of them are Swing specific)
3. Move those Swing specific classes to a subpackage.
4. Add other DataViews (so like the Swing part but for other frameworks) e.g. Click DataViews :),
or other Web Specific Data Views. Depending on the framework this might be a combination of
reflection and/or generation(with the help of Modeler).
5. Extend the DVModeler part(of the modeler) to be able to support those new frameworks, but mostly
the required functions are framework independent.
This would make the Modeler a real modeler, cause it would allow to 'model' Views/(Edits) too.
I had the impression that such an approach would be very efficient for CRUD/(dataView) like
applications in all domains. In most cases, this is of course not a complete application but it can
be a big part of it.
Also all the available CRUD approaches(for web frameworks) have the problem that if one
generates/reflects the CRUD, it's not flexible(customizable enough), but with DVModeler one could
customize in a very easy way.
Well, just ideas seeing DataViews and DVModeler for Swing in Action, and wondering how fast it would
be for Click (and maybe Tapestry or other frameworks) to have the same tool :).
Does my approach makes sense, or do I oversee something?
Thanks in advance,
Ahmed.
This archive was generated by hypermail 2.0.0 : Tue Nov 15 2005 - 17:40:13 EST