FAQ
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

Search Discussions

  • Andrus Adamchik at Oct 9, 2006 at 4:35 am
    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
  • Malcolm Edgar at Oct 9, 2006 at 4:52 am
    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 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
  • Andrus Adamchik at Oct 9, 2006 at 2:52 pm
    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 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
  • Adrian Wiesmann at Oct 10, 2006 at 6:54 pm
    Hello all

    On Mon, 9 Oct 2006 10:52:23 -0400
    Andrus Adamchik 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
  • Andrus Adamchik at Oct 10, 2006 at 7:25 pm

    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
  • Malcolm Edgar at Oct 10, 2006 at 7:51 pm
    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 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


  • Adrian Wiesmann at Oct 10, 2006 at 9:23 pm

    On Tue, 10 Oct 2006 15:25:21 -0400 Andrus Adamchik 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
  • Andrus Adamchik at Oct 10, 2006 at 9:35 pm

    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
  • Malcolm Edgar at Oct 16, 2006 at 1:57 am
    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 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
  • Ahmed Mohombe at Oct 16, 2006 at 9:14 am
    ... 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.
  • Ahmed Mohombe at Oct 16, 2006 at 9:15 am
    ... 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.
  • Andrus Adamchik at Oct 30, 2006 at 12:30 am
    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 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
  • Malcolm Edgar at Oct 30, 2006 at 12:32 am
    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 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 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
  • Adrian Wiesmann at Oct 30, 2006 at 4:18 pm
    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
  • Ahmed Mohombe at Nov 1, 2006 at 12:00 pm

    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.
  • Andrus Adamchik at Oct 9, 2006 at 5:07 am
    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
  • Malcolm Edgar at Oct 9, 2006 at 5:17 am
    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 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
  • Malcolm Edgar at Oct 9, 2006 at 9:09 am
    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 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 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
  • Andrus Adamchik at Oct 9, 2006 at 2:39 pm
    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 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 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
  • Ahmed Mohombe at Oct 9, 2006 at 9:35 am

    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.
  • Ahmed Mohombe at Oct 9, 2006 at 9:18 am

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedOct 9, '06 at 4:21a
activeNov 1, '06 at 12:00p
posts22
users4
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase