You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Malcolm Edgar <ma...@gmail.com> on 2006/10/09 04:40:45 UTC
DataView status
Hi All,
I wanted to enquire about the status of the Cayenne DataView modeller.
The reason being we are looking at defining related UI metadata for
applications.
regards Malcolm Edgar
Re: DataView status
Posted by Ahmed Mohombe <am...@yahoo.com>.
> I wanted to enquire about the status of the Cayenne DataView modeller.
>
> The reason being we are looking at defining related UI metadata for
> applications.
The XML saved by DataView Modeler can be very easily read with XStream and
converted to a Click Form/Page (or for any other web framework - for those
who are page/control oriented is the simplest).
http://article.gmane.org/gmane.comp.web.click.devel/819
Ahmed.
Re: DataView status
Posted by Andrus Adamchik <an...@objectstyle.org>.
DataViews or CAY-400?
In any event, in 3.0 we have no intention to deprecate current
Cayenne mapping format. And if we do in the future releases, IMO we
should preserve all Cayenne extras (whether DV falls in the "extras"
category depends on whether we still support it in the core by then).
JPA allows that via mapped properties, in a way similar to CAY-400.
Andrus
On Oct 9, 2006, at 5:09 AM, Malcolm Edgar wrote:
> Is the DataView design compatible with the JPA direction of Cayenne,
> i.e. will the *.map.xml file become obsolete?
>
> regards Malcolm
>
> On 10/9/06, Malcolm Edgar <ma...@gmail.com> wrote:
>> Yes CAY-400 would be very useful, especially if we can take it
>> down to
>> a field level. Examples could include:
>> * database table and field comments
>> * field metadata, e.g. minvalue="5", label="Customer No."
>>
>> I will take this up dicussion further on the JIRA
>>
>> regards Malcolm
>>
>> On 10/9/06, Andrus Adamchik <an...@objectstyle.org> wrote:
>> > Actually if all you need is to attach arbitrary properties to the
>> > mapping objects, I suggest that we work on this Jira issue:
>> >
>> > http://issues.apache.org/cayenne/browse/CAY-400
>> >
>> > adding this functionality to the Modeler itself. It is fairly
>> > straightforward and is long overdue - it was promised to the users
>> > quite some time ago.
>> >
>> > Andrus
>> >
>> >
>> > On Oct 9, 2006, at 12:26 AM, Andrus Adamchik wrote:
>> >
>> > > Hi Malcolm,
>> > >
>> > > DVModeler is available up to and including 2.0.x release.
>> > >
>> > > We removed it from the trunk recently, because there are no
>> > > volunteers to support it, and it hasn't been updated for many
>> years
>> > > now, becoming a liability. We can always resurrect it if somebody
>> > > steps in and dedicates enough time to this piece of technology.
>> > >
>> > > Andrus
>> > >
>> > >
>> > > On Oct 8, 2006, at 10:40 PM, Malcolm Edgar wrote:
>> > >> Hi All,
>> > >>
>> > >> I wanted to enquire about the status of the Cayenne DataView
>> > >> modeller.
>> > >>
>> > >> The reason being we are looking at defining related UI
>> metadata for
>> > >> applications.
>> > >>
>> > >> regards Malcolm Edgar
>
Re: DataView status
Posted by Malcolm Edgar <ma...@gmail.com>.
Is the DataView design compatible with the JPA direction of Cayenne,
i.e. will the *.map.xml file become obsolete?
regards Malcolm
On 10/9/06, Malcolm Edgar <ma...@gmail.com> wrote:
> Yes CAY-400 would be very useful, especially if we can take it down to
> a field level. Examples could include:
> * database table and field comments
> * field metadata, e.g. minvalue="5", label="Customer No."
>
> I will take this up dicussion further on the JIRA
>
> regards Malcolm
>
> On 10/9/06, Andrus Adamchik <an...@objectstyle.org> wrote:
> > Actually if all you need is to attach arbitrary properties to the
> > mapping objects, I suggest that we work on this Jira issue:
> >
> > http://issues.apache.org/cayenne/browse/CAY-400
> >
> > adding this functionality to the Modeler itself. It is fairly
> > straightforward and is long overdue - it was promised to the users
> > quite some time ago.
> >
> > Andrus
> >
> >
> > On Oct 9, 2006, at 12:26 AM, Andrus Adamchik wrote:
> >
> > > Hi Malcolm,
> > >
> > > DVModeler is available up to and including 2.0.x release.
> > >
> > > We removed it from the trunk recently, because there are no
> > > volunteers to support it, and it hasn't been updated for many years
> > > now, becoming a liability. We can always resurrect it if somebody
> > > steps in and dedicates enough time to this piece of technology.
> > >
> > > Andrus
> > >
> > >
> > > On Oct 8, 2006, at 10:40 PM, Malcolm Edgar wrote:
> > >> Hi All,
> > >>
> > >> I wanted to enquire about the status of the Cayenne DataView
> > >> modeller.
> > >>
> > >> The reason being we are looking at defining related UI metadata for
> > >> applications.
> > >>
> > >> regards Malcolm Edgar
> > >>
> > >
> > >
> >
> >
>
Re: DataView status
Posted by Malcolm Edgar <ma...@gmail.com>.
Yes CAY-400 would be very useful, especially if we can take it down to
a field level. Examples could include:
* database table and field comments
* field metadata, e.g. minvalue="5", label="Customer No."
I will take this up dicussion further on the JIRA
regards Malcolm
On 10/9/06, Andrus Adamchik <an...@objectstyle.org> wrote:
> Actually if all you need is to attach arbitrary properties to the
> mapping objects, I suggest that we work on this Jira issue:
>
> http://issues.apache.org/cayenne/browse/CAY-400
>
> adding this functionality to the Modeler itself. It is fairly
> straightforward and is long overdue - it was promised to the users
> quite some time ago.
>
> Andrus
>
>
> On Oct 9, 2006, at 12:26 AM, Andrus Adamchik wrote:
>
> > Hi Malcolm,
> >
> > DVModeler is available up to and including 2.0.x release.
> >
> > We removed it from the trunk recently, because there are no
> > volunteers to support it, and it hasn't been updated for many years
> > now, becoming a liability. We can always resurrect it if somebody
> > steps in and dedicates enough time to this piece of technology.
> >
> > Andrus
> >
> >
> > On Oct 8, 2006, at 10:40 PM, Malcolm Edgar wrote:
> >> Hi All,
> >>
> >> I wanted to enquire about the status of the Cayenne DataView
> >> modeller.
> >>
> >> The reason being we are looking at defining related UI metadata for
> >> applications.
> >>
> >> regards Malcolm Edgar
> >>
> >
> >
>
>
Re: DataView status
Posted by Andrus Adamchik <an...@objectstyle.org>.
Actually if all you need is to attach arbitrary properties to the
mapping objects, I suggest that we work on this Jira issue:
http://issues.apache.org/cayenne/browse/CAY-400
adding this functionality to the Modeler itself. It is fairly
straightforward and is long overdue - it was promised to the users
quite some time ago.
Andrus
On Oct 9, 2006, at 12:26 AM, Andrus Adamchik wrote:
> Hi Malcolm,
>
> DVModeler is available up to and including 2.0.x release.
>
> We removed it from the trunk recently, because there are no
> volunteers to support it, and it hasn't been updated for many years
> now, becoming a liability. We can always resurrect it if somebody
> steps in and dedicates enough time to this piece of technology.
>
> Andrus
>
>
> On Oct 8, 2006, at 10:40 PM, Malcolm Edgar wrote:
>> Hi All,
>>
>> I wanted to enquire about the status of the Cayenne DataView
>> modeller.
>>
>> The reason being we are looking at defining related UI metadata for
>> applications.
>>
>> regards Malcolm Edgar
>>
>
>
Re: DataView status
Posted by Ahmed Mohombe <am...@yahoo.com>.
> ... but I think there is a lot of great work in there.
Me too. The concept is jut too nice to be thrown away.
IMHO this DataView "language" is the closest to the most practical and efficient
Form/UI Domain Specific "Language", I've seen so far.
> * refactored out dependent code Swing into a dataview.swing package
This is fantastic. IMHO exactly what's needed. Based on the generic
remaining part one could than implement:
dataview.click package
dataview.tapestry package, etc.
> 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)
Would be useful to have these too:
- "pattern" for pattern oriented fields
- "rows" and "cols" for (J)TextAreas or other rich text areas (JEditorPane, etc.)
The validation (for the Swing implementation of DataView), could be better served IMHO by this
framework:
https://validation.dev.java.net/
http://www.jgoodies.com/freeware/validationdemo/index.html
(instead of an "own" implementation)
> I haven't figured out how a list of values (for a select / ComboBox)
> is represented in the DV design.
RadioGroup is in the same situation.
> Anyway just some random thoughts.
Also there could be support for I18N since this is done easily with Swing and also with most
of the webframeowrks.
Ahmed.
Re: DataView status
Posted by Ahmed Mohombe <am...@yahoo.com>.
> ... but I think there is a lot of great work in there.
Me too. The concept is jut too nice to be thrown away.
IMHO this DataView "language" is the closest to the most practical and efficient
Form/UI Domain Specific "Language", I've seen so far.
> * refactored out dependent code Swing into a dataview.swing package
This is fantastic. IMHO exactly what's needed. Based on the generic
remaining part one could than implement:
dataview.click package
dataview.tapestry package, etc.
> 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)
Would be useful to have these too:
- "pattern" for pattern oriented fields
- "rows" and "cols" for (J)TextAreas or other rich text areas (JEditorPane, etc.)
The validation (for the Swing implementation of DataView), could be better served IMHO by this
framework:
https://validation.dev.java.net/
http://www.jgoodies.com/freeware/validationdemo/index.html
(instead of an "own" implementation)
> I haven't figured out how a list of values (for a select / ComboBox)
> is represented in the DV design.
RadioGroup is in the same situation.
> Anyway just some random thoughts.
Also there could be support for I18N since this is done easily with Swing and also with most
of the webframeowrks.
Ahmed.
Re: DataView status
Posted by Ahmed Mohombe <am...@yahoo.com>.
> I will definitely vote for resurrecting DVModeler on the trunk
> (from 2.0 branch) if you will help us to merge your changes.
Please resurrect it. I also have some small usability improvements for the DVModeler.
Also please revive the DataView based example. This doesn't seems to be migrated
to Apache.
Thanks in advance,
Ahmed.
Re: DataView status
Posted by Adrian Wiesmann <aw...@somap.org>.
Hi Malcolm
> 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.
There is another scenario. List and detail views where you use the same
DataContext to render a list of DataObjects and to render one single
DataObject which can then be edited. In the list you normally show
different fields (or not the same group or something) like in the detail
view. The detail view mostly contains more fields than the list view.
> Extra fields which could be added the the ObjFieldView include:
> * sortable - UI hint for columns
> * width - UI field / column width hint
Good ideas.
Foreignkey reference information is something which we also miss. I would
like to be able to add the name of a DataView to the foreign key
reference: When showing a list of DataObjects and one of the fields is a
reference to another type of DataObjects, we currently have the
functionality that we add a button besides the corresponding field in the
UI. Clicking the button will open up a modal search dialog. While it is
clear what type of DataObject we want to search for, we need another
DataView to render a list of DataObjects.
> * tooltip - for field help
Good idea (we already do have the captions there). But there should be
some multi language support. Or some hook to where you could hook up some
piece of code which does the translation.
Adding a help hook would be another idea.
Yet another idea would be to define the edit states. Which means: Can the
user edit data within this DataView or is it for read only?
> I haven't figured out how a list of values (for a select / ComboBox)
> is represented in the DV design.
This looked a little bit tricky to me. Afaik the list renders a combobox.
But that is not a good solution. Especially when these foreignkey
constraints can contain huge lists of records. We solve this with modal
searches, see above for details.
Perhaps we should elaborate on the different usage strategies/techniques
of DV.
Regards,
Adrian
Re: DataView status
Posted by Malcolm Edgar <ma...@gmail.com>.
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 <an...@objectstyle.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 <an...@objectstyle.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
> >>
> >>
> >
>
>
Re: DataView status
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <an...@objectstyle.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
>>
>>
>
Re: DataView status
Posted by Malcolm Edgar <ma...@gmail.com>.
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 <an...@objectstyle.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
>
>
Re: DataView status
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
Re: DataView status
Posted by Adrian Wiesmann <aw...@somap.org>.
On Tue, 10 Oct 2006 15:25:21 -0400
Andrus Adamchik <an...@objectstyle.org> wrote:
> This sounds like a reasonable strategy. I guess we can promise that
> much. But again, I appreciate if all interested parties could
> actually help us with DV maintenance. You probably know much more
> about DV than myself or any of the current committers anyways :-)
I have no problem in helping out with some DV maintenance (or testing).
Now that I worked with the DataViews for quite some while I think I know
what these views are and what is missing.
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.
> It would be cool if we could find one or more dedicated developers
> with a vision in this area to lead the Swing effort. But I'll keep
> dreaming...
As I said earlier, I am interested to supply the cayenne project with
enhancements and stuff we do for the SOBF tool. But it has to be clear
that this will always be a "side effect" and no full committment. And of
course I would welcome if I would not be the only one volunteering :)
> I like your website :-)
How come?
Adrian
Re: DataView status
Posted by Malcolm Edgar <ma...@gmail.com>.
I may be able to contribute to the DV module, but this depends upon
whether a client project firms up (has to pay the bills). I will keep
you posted.
regards Malcolm Edgar
On 10/11/06, Andrus Adamchik <an...@objectstyle.org> wrote:
> On Oct 10, 2006, at 2:54 PM, Adrian Wiesmann wrote:
> >> * If we (cayenne dev community) are to continue the development, as a
> >> first step I suggest making Cayenne core independent of DV runtime.
> >
> > I would suggest to move DV "out of the way" so that it is not
> > hurting the
> > normal Cayenne development. But please keep DataViews supported. I am
> > currently in the process to switch to Cayenne 3.x because I absolutely
> > need the Lifecycle Callbacks (generating uuid formated key when
> > creating a
> > new object and updating the last_updated field before committing
> > changes).
> >
> > Because the SOBF tool is that much depending on DataViews I would very
> > much like to see them at least not removed. I would hate to have to
> > redo
> > everything I already programmed only because of DataViews being
> > removed
> > from Cayenne.
>
> This sounds like a reasonable strategy. I guess we can promise that
> much. But again, I appreciate if all interested parties could
> actually help us with DV maintenance. You probably know much more
> about DV than myself or any of the current committers anyways :-)
>
> As the history shows (DV, JStaple and Rowan projects), there is lots
> of interest in Swing-related technologies in our community, but not
> nearly as much commitment. I suspect it is because Swing is not
> paying anyone's bills consistently (e.g. I may have a 2-month Swing
> project and then switch back to webapps, I believe that's the case
> with others too).
>
> It would be cool if we could find one or more dedicated developers
> with a vision in this area to lead the Swing effort. But I'll keep
> dreaming...
>
> > The SOBF tool (Security Officers Best Friend, Open Source tool for
> > assessing information security risk)
>
> I like your website :-)
>
> Andrus
>
>
>
>
Re: DataView status
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Oct 10, 2006, at 2:54 PM, Adrian Wiesmann wrote:
>> * If we (cayenne dev community) are to continue the development, as a
>> first step I suggest making Cayenne core independent of DV runtime.
>
> I would suggest to move DV "out of the way" so that it is not
> hurting the
> normal Cayenne development. But please keep DataViews supported. I am
> currently in the process to switch to Cayenne 3.x because I absolutely
> need the Lifecycle Callbacks (generating uuid formated key when
> creating a
> new object and updating the last_updated field before committing
> changes).
>
> Because the SOBF tool is that much depending on DataViews I would very
> much like to see them at least not removed. I would hate to have to
> redo
> everything I already programmed only because of DataViews being
> removed
> from Cayenne.
This sounds like a reasonable strategy. I guess we can promise that
much. But again, I appreciate if all interested parties could
actually help us with DV maintenance. You probably know much more
about DV than myself or any of the current committers anyways :-)
As the history shows (DV, JStaple and Rowan projects), there is lots
of interest in Swing-related technologies in our community, but not
nearly as much commitment. I suspect it is because Swing is not
paying anyone's bills consistently (e.g. I may have a 2-month Swing
project and then switch back to webapps, I believe that's the case
with others too).
It would be cool if we could find one or more dedicated developers
with a vision in this area to lead the Swing effort. But I'll keep
dreaming...
> The SOBF tool (Security Officers Best Friend, Open Source tool for
> assessing information security risk)
I like your website :-)
Andrus
Re: DataView status
Posted by Adrian Wiesmann <aw...@somap.org>.
Hello all
On Mon, 9 Oct 2006 10:52:23 -0400
Andrus Adamchik <an...@objectstyle.org> wrote:
> * I have no experience using it on a project, so I can't comment on
> the usefulness of this particular implementation, but the idea looks
> good.
The SOBF tool (Security Officers Best Friend, Open Source tool for
assessing information security risk) is heavily based on DataViews and the
DataViews saved me many hours of headaches and work.
Basically it is the idea to create DataViews for DataObjects. Taking
these view definitions it is possible to program a databound JList in a
few minutes. For the SOBF tool we currently work on creating a renderer
based on DataViews which can generate detail edit frames and which can
create JasperReports XML formatted files. This would allow us to create
new edit/view forms and printable representations of these in no time.
The idea is this: When the data model changes (at least when talking about
simple foreign key constraints and table changes) we will need no
progamming. We will just update the respective DataView and the renderer
does the rest.
> * If we (cayenne dev community) are to continue the development, as a
> first step I suggest making Cayenne core independent of DV runtime.
I would suggest to move DV "out of the way" so that it is not hurting the
normal Cayenne development. But please keep DataViews supported. I am
currently in the process to switch to Cayenne 3.x because I absolutely
need the Lifecycle Callbacks (generating uuid formated key when creating a
new object and updating the last_updated field before committing changes).
Because the SOBF tool is that much depending on DataViews I would very
much like to see them at least not removed. I would hate to have to redo
everything I already programmed only beause of DataViews being removed
from Cayenne.
Regards,
Adrian
Re: DataView status
Posted by Andrus Adamchik <an...@objectstyle.org>.
More on the DataViews...
* I have no experience using it on a project, so I can't comment on
the usefulness of this particular implementation, but the idea looks
good.
* DV runtime and DVModeler went through Apache IP clearance process
with the rest of Cayenne, so any new development can and should
proceed at ASF.
* If we (cayenne dev community) are to continue the development, as a
first step I suggest making Cayenne core independent of DV runtime.
Right now cayenne.xml and Configuration class have direct dependency
on DV. This is bad IMO - DV is just one of the possible extensions
and should be treated as an extension. So I guess all DV code needs
to be extracted in a separate Maven module, and use either a property
mechanism (CAY-400) or its own descriptor to bootstrap itself.
Andrus
On Oct 9, 2006, at 12:45 AM, Malcolm Edgar wrote:
> Hi Andrus,
>
> What was your experience with using DataViews, did you get much
> development productivity / maintenance benefit from this approach?
>
> If I was to take this up, would this be hosted under ObjectStyle or
> Apache ?
>
> regards Malcolm Edgar
>
> On 10/9/06, Andrus Adamchik <an...@objectstyle.org> wrote:
>> Hi Malcolm,
>>
>> DVModeler is available up to and including 2.0.x release.
>>
>> We removed it from the trunk recently, because there are no
>> volunteers to support it, and it hasn't been updated for many years
>> now, becoming a liability. We can always resurrect it if somebody
>> steps in and dedicates enough time to this piece of technology.
>>
>> Andrus
>>
>>
>> On Oct 8, 2006, at 10:40 PM, Malcolm Edgar wrote:
>> > Hi All,
>> >
>> > I wanted to enquire about the status of the Cayenne DataView
>> modeller.
>> >
>> > The reason being we are looking at defining related UI metadata for
>> > applications.
>> >
>> > regards Malcolm Edgar
>> >
>>
>>
>
Re: DataView status
Posted by Malcolm Edgar <ma...@gmail.com>.
Hi Andrus,
What was your experience with using DataViews, did you get much
development productivity / maintenance benefit from this approach?
If I was to take this up, would this be hosted under ObjectStyle or Apache ?
regards Malcolm Edgar
On 10/9/06, Andrus Adamchik <an...@objectstyle.org> wrote:
> Hi Malcolm,
>
> DVModeler is available up to and including 2.0.x release.
>
> We removed it from the trunk recently, because there are no
> volunteers to support it, and it hasn't been updated for many years
> now, becoming a liability. We can always resurrect it if somebody
> steps in and dedicates enough time to this piece of technology.
>
> Andrus
>
>
> On Oct 8, 2006, at 10:40 PM, Malcolm Edgar wrote:
> > Hi All,
> >
> > I wanted to enquire about the status of the Cayenne DataView modeller.
> >
> > The reason being we are looking at defining related UI metadata for
> > applications.
> >
> > regards Malcolm Edgar
> >
>
>
Re: DataView status
Posted by Ahmed Mohombe <am...@yahoo.com>.
> DVModeler is available up to and including 2.0.x release.
>
> We removed it from the trunk recently, because there are no volunteers
> to support it, and it hasn't been updated for many years now, becoming a
> liability.
IMHO despite the missing volunteers, the DVModeler should be still included
in the trunk since the DataView packages are also there:
cayenne\main\core\cayenne-jdk1.4\src\main\java\org\apache\cayenne\dataview\*
Ahmed.
Re: DataView status
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Malcolm,
DVModeler is available up to and including 2.0.x release.
We removed it from the trunk recently, because there are no
volunteers to support it, and it hasn't been updated for many years
now, becoming a liability. We can always resurrect it if somebody
steps in and dedicates enough time to this piece of technology.
Andrus
On Oct 8, 2006, at 10:40 PM, Malcolm Edgar wrote:
> Hi All,
>
> I wanted to enquire about the status of the Cayenne DataView modeller.
>
> The reason being we are looking at defining related UI metadata for
> applications.
>
> regards Malcolm Edgar
>