You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Lon Varscsak <lo...@gmail.com> on 2019/09/25 22:08:43 UTC
4.2 modeler change
Hey all,
It looks like when adding a db-relationship in the Modeler (4.2.M1-SNAPSHOT
from today) the potential target entities is not sorted (which is only
mildly annoying), but doesn't contain any target entities outside of the
current data map (blocker). Am i missing something?
Thanks!
-Lon
Here's a screenshot for reference:
[image: Screen Shot 2019-09-25 at 3.07.42 PM.jpg]
Re: 4.2 modeler change
Posted by Andrus Adamchik <an...@objectstyle.org>.
While I like the idea of having something visual and DB-centric that people can use for various purposes, I still can't wrap my head around of how to do modeling away from access to the real DB and my Java projects. To me the main value of the Modeler (since 4.1 anyways) is "cdbimport" and "cgen". (Meaning most of the actual modeling happening in SQL migration scripts).
Andrus
> On Oct 3, 2019, at 1:05 PM, Michael Gentry <bl...@gmail.com> wrote:
>
> Hi Ari,
>
> I thought a bit about a web-based version of CM, too. I kind of liked the
> idea (especially for your point #5 -- a Google Docs type of collaborative
> editing), but ultimately decided it would introduce security/deployment
> concerns I'd rather not focus on. I'd be happy to discuss the idea again,
> though. Maybe others have some fresh thoughts, plus the technology
> landscape has changed over the years.
>
> mrg
>
>
> On Wed, Oct 2, 2019 at 7:00 PM Aristedes Maniatis <ar...@maniatis.org> wrote:
>
>> One advantage of an html/js frontend would be to offer a service on our
>> website into which a user could paste their DDL as SQL, and get back:
>>
>> 1. a Cayenne map xml
>>
>> 2. a visual representation of their schema [1]
>>
>> 3. an editor which allows them to make changes
>>
>> 4. The ability to export an updated DDL
>>
>> 5. Some sort of sharing link so they can share and discuss with co-workers
>>
>>
>> Here's a company I just found doing something similar.
>> https://www.dbdesigner.net/
>>
>>
>> The main advantage of this approach is to give Cayenne greater exposure.
>> People come for the tool and walk away with a whole ORM.
>>
>> I'm ccing this to the dev@ list where it makes more sense.
>>
>>
>> Ari
>>
>>
>> [1] Like this
>>
>> https://www.mysql.com/common/images/products/MySQL_Workbench_Visual_Design_Mac.png
>>
>>
Re: 4.2 modeler change
Posted by Michael Gentry <bl...@gmail.com>.
Hi Ari,
I thought a bit about a web-based version of CM, too. I kind of liked the
idea (especially for your point #5 -- a Google Docs type of collaborative
editing), but ultimately decided it would introduce security/deployment
concerns I'd rather not focus on. I'd be happy to discuss the idea again,
though. Maybe others have some fresh thoughts, plus the technology
landscape has changed over the years.
mrg
On Wed, Oct 2, 2019 at 7:00 PM Aristedes Maniatis <ar...@maniatis.org> wrote:
> One advantage of an html/js frontend would be to offer a service on our
> website into which a user could paste their DDL as SQL, and get back:
>
> 1. a Cayenne map xml
>
> 2. a visual representation of their schema [1]
>
> 3. an editor which allows them to make changes
>
> 4. The ability to export an updated DDL
>
> 5. Some sort of sharing link so they can share and discuss with co-workers
>
>
> Here's a company I just found doing something similar.
> https://www.dbdesigner.net/
>
>
> The main advantage of this approach is to give Cayenne greater exposure.
> People come for the tool and walk away with a whole ORM.
>
> I'm ccing this to the dev@ list where it makes more sense.
>
>
> Ari
>
>
> [1] Like this
>
> https://www.mysql.com/common/images/products/MySQL_Workbench_Visual_Design_Mac.png
>
>
Re: 4.2 modeler change
Posted by Aristedes Maniatis <ar...@maniatis.org>.
One advantage of an html/js frontend would be to offer a service on our
website into which a user could paste their DDL as SQL, and get back:
1. a Cayenne map xml
2. a visual representation of their schema [1]
3. an editor which allows them to make changes
4. The ability to export an updated DDL
5. Some sort of sharing link so they can share and discuss with co-workers
Here's a company I just found doing something similar.
https://www.dbdesigner.net/
The main advantage of this approach is to give Cayenne greater exposure.
People come for the tool and walk away with a whole ORM.
I'm ccing this to the dev@ list where it makes more sense.
Ari
[1] Like this
https://www.mysql.com/common/images/products/MySQL_Workbench_Visual_Design_Mac.png
On 3/10/19 3:20am, Andrus Adamchik wrote:
> But thanks for all the replies. That's sort of where I was going with this as well.
Re: 4.2 modeler change
Posted by Aristedes Maniatis <ar...@maniatis.org>.
One advantage of an html/js frontend would be to offer a service on our
website into which a user could paste their DDL as SQL, and get back:
1. a Cayenne map xml
2. a visual representation of their schema [1]
3. an editor which allows them to make changes
4. The ability to export an updated DDL
5. Some sort of sharing link so they can share and discuss with co-workers
Here's a company I just found doing something similar.
https://www.dbdesigner.net/
The main advantage of this approach is to give Cayenne greater exposure.
People come for the tool and walk away with a whole ORM.
I'm ccing this to the dev@ list where it makes more sense.
Ari
[1] Like this
https://www.mysql.com/common/images/products/MySQL_Workbench_Visual_Design_Mac.png
On 3/10/19 3:20am, Andrus Adamchik wrote:
> But thanks for all the replies. That's sort of where I was going with this as well.
Re: 4.2 modeler change
Posted by Andrus Adamchik <an...@objectstyle.org>.
> As for the JS backend,
Sorry, a typo: s/backend/frontend/ :)
But thanks for all the replies. That's sort of where I was going with this as well.
Andrus
> On Oct 2, 2019, at 6:09 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> As for the JS backend, the concern (at least from me) was that our community is mostly Java developers, so it may be hard to support if a primary author becomes unavailable. FWIW, it is less of a concern for me these days, as JS world had matured significantly since the last time we had this discussion.
Re: 4.2 modeler change
Posted by Lon Varscsak <lo...@gmail.com>.
I concur with the idea that a Java-served web app (hosted inside an
Electron app) would be best.
@Emmerson - I don't know if there were JIRAs created, I didn't create them
personally.
On Wed, Oct 2, 2019 at 8:20 AM Michael Gentry <bl...@gmail.com> wrote:
> On Wed, Oct 2, 2019 at 11:10 AM Andrus Adamchik <an...@objectstyle.org>
> wrote:
>
> > As for the JS backend, the concern (at least from me) was that our
> > community is mostly Java developers, so it may be hard to support if a
> > primary author becomes unavailable. FWIW, it is less of a concern for me
> > these days, as JS world had matured significantly since the last time we
> > had this discussion.
> >
>
> I wouldn't do the backend in Node/JS with an Electron application if I
> could avoid it. I'd bundle a Java-based microservice that the Electron UI
> starts up and uses to read/write Cayenne models, communicate with DBs via
> JDBC, etc. With JavaFX I was just using the Cayenne JARs natively (no
> client/server architecture).
>
Re: 4.2 modeler change
Posted by Michael Gentry <bl...@gmail.com>.
On Wed, Oct 2, 2019 at 11:10 AM Andrus Adamchik <an...@objectstyle.org>
wrote:
> As for the JS backend, the concern (at least from me) was that our
> community is mostly Java developers, so it may be hard to support if a
> primary author becomes unavailable. FWIW, it is less of a concern for me
> these days, as JS world had matured significantly since the last time we
> had this discussion.
>
I wouldn't do the backend in Node/JS with an Electron application if I
could avoid it. I'd bundle a Java-based microservice that the Electron UI
starts up and uses to read/write Cayenne models, communicate with DBs via
JDBC, etc. With JavaFX I was just using the Cayenne JARs natively (no
client/server architecture).
Re: 4.2 modeler change
Posted by Andrus Adamchik <an...@objectstyle.org>.
And there were people who wanted to join JavaFX effort, but this was too big of a jump to do it all at once.
So the current approach is to convert backend to Bootique, and write a common service layer that can be reused between JavaFX and Swing frontends (something that wasn't done too cleanly in the original Swing app). There's been progress down that path. IIRC it is either already in 4.2 or is coming there soon.
As for the JS backend, the concern (at least from me) was that our community is mostly Java developers, so it may be hard to support if a primary author becomes unavailable. FWIW, it is less of a concern for me these days, as JS world had matured significantly since the last time we had this discussion.
In any event if/when Mike or anyone else is planning to restart or join the new Modeler effort, please let's start a thread on dev@ to make sure we are all working together towards the same goal.
Andrus
> On Oct 2, 2019, at 2:31 PM, Michael Gentry <bl...@gmail.com> wrote:
>
> I started a JavaFX prototype, but got bogged down (with other things) and
> haven't picked it back up again. Kind of hoping to do that again within
> the coming year...
>
> As to Ari's HTML/JS/CSS comment, if we went that route, it would likely be
> an Electron-based application, I think, with HTML/JS/CSS for the UI and a
> Java backend.
>
>
> On Tue, Oct 1, 2019 at 7:34 PM Aristedes Maniatis <ar...@maniatis.org> wrote:
>
>> JavaFX would be a huge amount of work since almost the entire app would
>> be rewritten from scratch. And if there was a reason to do it, that
>> reason would probably point toward an html/js front end. There are just
>> so many more html/js widgets for object graphs, table views, etc than
>> any other UI kit.
>>
>> And then we'd have Cayenne modeler SaaS! \s
>>
>> Back in reality, Swing is going to be here a long time. If you are able
>> to submit a PR to run even a basic set of tests on the UI that would be
>> great and provide a guide on how to add more over time.
>>
>>
>> Ari
>>
>> On 2/10/19 5:36am, Emerson Castañeda wrote:
>>> Last year a got some progresses testing Swing UI using
>> assertj-swing-junit
>>> dependency
>>>
>>> Also, I got to run TravisCI successfully, by including xvfb In order to
>>> run the tests that require a GUI.
>>>
>>> Finally, it required 2 additional changes:
>>>
>>> 1. Modifying Main class on modeler to expose Injector object
>>> 2. Include some modifications to the CayenneModelerFrame to set names for
>>> the GUI components to test, since assertj cannot test anonymous
>> instances.
>>>
>>> If Swing still being an option, I can open a PR with a full functional
>> use
>>> case of GUI testing using the mentioned stack..
>>>
>>> Other way, what would be the desires/goals for diving into JavaFX? so we
>>> could think about at GUI testing strategy covering that path.
>>>
>>> Thanks
>>>
>>> EmeCas
>>>
>>>
>>>
>>>
>>> On Tue, Oct 1, 2019 at 2:51 PM John Huss <jo...@gmail.com> wrote:
>>>
>>>> The way to handle testing for the UI is to write the app in an MVP
>> style,
>>>> sort of like this:
>>>>
>> https://stackoverflow.com/questions/11367250/concrete-code-example-of-mvp
>>>>
>>>> The gist is to define an interface contract for the view so that you can
>>>> replace the actual Swing UI View with a mock while testing.
>>>> But that doesn't help much with an existing application that wasn't
>> written
>>>> in that style.
>>>>
>>>>
>>>> On Tue, Oct 1, 2019 at 1:00 AM Andrus Adamchik <an...@objectstyle.org>
>>>> wrote:
>>>>
>>>>> Yeah, I was thinking how do we even approach testing of Java UI. Any
>>>>> suggestions are welcome.
>>>>>
>>>>> And to complicate things we've been postponing a dive into JavaFX,
>> while
>>>>> the Swing app keeps adding functionality. So investing effort in a test
>>>>> framework should take this pending decision into account.
>>>>>
>>>>> Andrus
>>>>>
>>>>>> On Oct 1, 2019, at 7:11 AM, Aristedes Maniatis <ar...@maniatis.org>
>>>> wrote:
>>>>>> I've been down that path before, trying to test Swing and JavaFX. Its
>>>>> not easy to do. The best tool I found (and that was about 8 years ago)
>>>> was
>>>>> https://www.froglogic.com/squish/editions/automated-java-gui-testing/
>>>> but
>>>>> I don't know if they have any licensing available for open source
>>>> projects.
>>>>>> Emerson, if you have any experience with this, let us know what has
>>>>> worked for you.
>>>>>>
>>>>>> Ari
>>>>>>
>>>>>>
>>>>>> On 30/9/19 12:21am, Emerson Castañeda wrote:
>>>>>>> Wonder if these bugs would be into the kind of things that a good GUI
>>>>> test
>>>>>>> suite for the modeler could prevent.
>>>>>>>
>>>>>>> EmeCas
>>>>>>>
>>>>>>> On Thu, Sep 26, 2019 at 12:08 PM Lon Varscsak <
>> lon.varscsak@gmail.com
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Okay, cool. Another bug (I just found) is on the add relationship
>>>>> dialog
>>>>>>>> (on object entity) is that it seems to ignore the "delete" rule and
>>>>> just is
>>>>>>>> always the default. Easily worked around by just editing the added
>>>>>>>> relationship after the fact.
>>>>>>>>
>>>>>>>> On Thu, Sep 26, 2019 at 12:22 AM Andrus Adamchik <
>>>>> andrus@objectstyle.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Screenshots are stripped by the list management software, but the
>>>>>>>>> description is pretty clear. I am not using 4.2 myself, but we do
>>>>> need to
>>>>>>>>> fix it before we release 4.2.M1.
>>>>>>>>>
>>>>>>>>> Andrus
>>>>>>>>>
>>>>>>>>>> On Sep 26, 2019, at 1:08 AM, Lon Varscsak <lon.varscsak@gmail.com
>>>
>>>>>>>>> wrote:
>>>>>>>>>> Hey all,
>>>>>>>>>>
>>>>>>>>>> It looks like when adding a db-relationship in the Modeler
>>>>>>>>> (4.2.M1-SNAPSHOT from today) the potential target entities is not
>>>>> sorted
>>>>>>>>> (which is only mildly annoying), but doesn't contain any target
>>>>> entities
>>>>>>>>> outside of the current data map (blocker). Am i missing something?
>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>> -Lon
>>>>>>>>>>
>>>>>>>>>> Here's a screenshot for reference:
>>>>>>>>>>
>>>>>
>>
Re: 4.2 modeler change
Posted by Michael Gentry <bl...@gmail.com>.
Hi Emerson,
The reason I started playing around with JavaFX instead of Electron is
because I could re-use some of the Cayenne JARs. An advantage of Electron,
though, is I feel it has more momentum than JavaFX, but you'd have to
duplicate data structures and end up with a more complex client/server
architecture. Both approaches would produce a cross-platform "native"
solution for the 3 major OSes, which is a win.
On Wed, Oct 2, 2019 at 11:01 AM Emerson Castañeda <em...@gmail.com> wrote:
> @Ari, Completely agree with you, and since we're still on Swing's parallel
> reality :) I will be working on that PR and any UI testing in general for
> the modeler. For some reason, that I don't know yet, my builds are failing
> in a totally different module (cayenne-rop-server).
>
>
> @Michael I don't have any experience with Electron, but any approach for a
> web-modeler will be interesting to discuss.
>
>
> @John maybe we can start introducing that MVC pattern in order to uncouple
> the modeler's layers. Actually that is one of the keys factors for a
> testable app.
>
> @Lon do you have a specific JIRA ticket(s) were you are following the new
> bugs?
>
> Thanks
>
> EmeCas
>
>
>
>
> On Wed, Oct 2, 2019 at 7:42 AM Michael Gentry <bl...@gmail.com> wrote:
>
> > I started a JavaFX prototype, but got bogged down (with other things) and
> > haven't picked it back up again. Kind of hoping to do that again within
> > the coming year...
> >
> > As to Ari's HTML/JS/CSS comment, if we went that route, it would likely
> be
> > an Electron-based application, I think, with HTML/JS/CSS for the UI and a
> > Java backend.
> >
> >
> > On Tue, Oct 1, 2019 at 7:34 PM Aristedes Maniatis <ar...@maniatis.org>
> > wrote:
> >
> > > JavaFX would be a huge amount of work since almost the entire app would
> > > be rewritten from scratch. And if there was a reason to do it, that
> > > reason would probably point toward an html/js front end. There are just
> > > so many more html/js widgets for object graphs, table views, etc than
> > > any other UI kit.
> > >
> > > And then we'd have Cayenne modeler SaaS! \s
> > >
> > > Back in reality, Swing is going to be here a long time. If you are able
> > > to submit a PR to run even a basic set of tests on the UI that would be
> > > great and provide a guide on how to add more over time.
> > >
> > >
> > > Ari
> > >
> > > On 2/10/19 5:36am, Emerson Castañeda wrote:
> > > > Last year a got some progresses testing Swing UI using
> > > assertj-swing-junit
> > > > dependency
> > > >
> > > > Also, I got to run TravisCI successfully, by including xvfb In order
> > to
> > > > run the tests that require a GUI.
> > > >
> > > > Finally, it required 2 additional changes:
> > > >
> > > > 1. Modifying Main class on modeler to expose Injector object
> > > > 2. Include some modifications to the CayenneModelerFrame to set names
> > for
> > > > the GUI components to test, since assertj cannot test anonymous
> > > instances.
> > > >
> > > > If Swing still being an option, I can open a PR with a full
> functional
> > > use
> > > > case of GUI testing using the mentioned stack..
> > > >
> > > > Other way, what would be the desires/goals for diving into JavaFX? so
> > we
> > > > could think about at GUI testing strategy covering that path.
> > > >
> > > > Thanks
> > > >
> > > > EmeCas
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Oct 1, 2019 at 2:51 PM John Huss <jo...@gmail.com>
> wrote:
> > > >
> > > >> The way to handle testing for the UI is to write the app in an MVP
> > > style,
> > > >> sort of like this:
> > > >>
> > >
> >
> https://stackoverflow.com/questions/11367250/concrete-code-example-of-mvp
> > > >>
> > > >> The gist is to define an interface contract for the view so that you
> > can
> > > >> replace the actual Swing UI View with a mock while testing.
> > > >> But that doesn't help much with an existing application that wasn't
> > > written
> > > >> in that style.
> > > >>
> > > >>
> > > >> On Tue, Oct 1, 2019 at 1:00 AM Andrus Adamchik <
> > andrus@objectstyle.org>
> > > >> wrote:
> > > >>
> > > >>> Yeah, I was thinking how do we even approach testing of Java UI.
> Any
> > > >>> suggestions are welcome.
> > > >>>
> > > >>> And to complicate things we've been postponing a dive into JavaFX,
> > > while
> > > >>> the Swing app keeps adding functionality. So investing effort in a
> > test
> > > >>> framework should take this pending decision into account.
> > > >>>
> > > >>> Andrus
> > > >>>
> > > >>>> On Oct 1, 2019, at 7:11 AM, Aristedes Maniatis <ar...@maniatis.org>
> > > >> wrote:
> > > >>>> I've been down that path before, trying to test Swing and JavaFX.
> > Its
> > > >>> not easy to do. The best tool I found (and that was about 8 years
> > ago)
> > > >> was
> > > >>>
> > https://www.froglogic.com/squish/editions/automated-java-gui-testing/
> > > >> but
> > > >>> I don't know if they have any licensing available for open source
> > > >> projects.
> > > >>>> Emerson, if you have any experience with this, let us know what
> has
> > > >>> worked for you.
> > > >>>>
> > > >>>> Ari
> > > >>>>
> > > >>>>
> > > >>>> On 30/9/19 12:21am, Emerson Castañeda wrote:
> > > >>>>> Wonder if these bugs would be into the kind of things that a good
> > GUI
> > > >>> test
> > > >>>>> suite for the modeler could prevent.
> > > >>>>>
> > > >>>>> EmeCas
> > > >>>>>
> > > >>>>> On Thu, Sep 26, 2019 at 12:08 PM Lon Varscsak <
> > > lon.varscsak@gmail.com
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> Okay, cool. Another bug (I just found) is on the add
> relationship
> > > >>> dialog
> > > >>>>>> (on object entity) is that it seems to ignore the "delete" rule
> > and
> > > >>> just is
> > > >>>>>> always the default. Easily worked around by just editing the
> > added
> > > >>>>>> relationship after the fact.
> > > >>>>>>
> > > >>>>>> On Thu, Sep 26, 2019 at 12:22 AM Andrus Adamchik <
> > > >>> andrus@objectstyle.org>
> > > >>>>>> wrote:
> > > >>>>>>
> > > >>>>>>> Screenshots are stripped by the list management software, but
> the
> > > >>>>>>> description is pretty clear. I am not using 4.2 myself, but we
> do
> > > >>> need to
> > > >>>>>>> fix it before we release 4.2.M1.
> > > >>>>>>>
> > > >>>>>>> Andrus
> > > >>>>>>>
> > > >>>>>>>> On Sep 26, 2019, at 1:08 AM, Lon Varscsak <
> > lon.varscsak@gmail.com
> > > >
> > > >>>>>>> wrote:
> > > >>>>>>>> Hey all,
> > > >>>>>>>>
> > > >>>>>>>> It looks like when adding a db-relationship in the Modeler
> > > >>>>>>> (4.2.M1-SNAPSHOT from today) the potential target entities is
> not
> > > >>> sorted
> > > >>>>>>> (which is only mildly annoying), but doesn't contain any target
> > > >>> entities
> > > >>>>>>> outside of the current data map (blocker). Am i missing
> > something?
> > > >>>>>>>> Thanks!
> > > >>>>>>>>
> > > >>>>>>>> -Lon
> > > >>>>>>>>
> > > >>>>>>>> Here's a screenshot for reference:
> > > >>>>>>>>
> > > >>>
> > >
> >
>
Re: 4.2 modeler change
Posted by Emerson Castañeda <em...@gmail.com>.
@Ari, Completely agree with you, and since we're still on Swing's parallel
reality :) I will be working on that PR and any UI testing in general for
the modeler. For some reason, that I don't know yet, my builds are failing
in a totally different module (cayenne-rop-server).
@Michael I don't have any experience with Electron, but any approach for a
web-modeler will be interesting to discuss.
@John maybe we can start introducing that MVC pattern in order to uncouple
the modeler's layers. Actually that is one of the keys factors for a
testable app.
@Lon do you have a specific JIRA ticket(s) were you are following the new
bugs?
Thanks
EmeCas
On Wed, Oct 2, 2019 at 7:42 AM Michael Gentry <bl...@gmail.com> wrote:
> I started a JavaFX prototype, but got bogged down (with other things) and
> haven't picked it back up again. Kind of hoping to do that again within
> the coming year...
>
> As to Ari's HTML/JS/CSS comment, if we went that route, it would likely be
> an Electron-based application, I think, with HTML/JS/CSS for the UI and a
> Java backend.
>
>
> On Tue, Oct 1, 2019 at 7:34 PM Aristedes Maniatis <ar...@maniatis.org>
> wrote:
>
> > JavaFX would be a huge amount of work since almost the entire app would
> > be rewritten from scratch. And if there was a reason to do it, that
> > reason would probably point toward an html/js front end. There are just
> > so many more html/js widgets for object graphs, table views, etc than
> > any other UI kit.
> >
> > And then we'd have Cayenne modeler SaaS! \s
> >
> > Back in reality, Swing is going to be here a long time. If you are able
> > to submit a PR to run even a basic set of tests on the UI that would be
> > great and provide a guide on how to add more over time.
> >
> >
> > Ari
> >
> > On 2/10/19 5:36am, Emerson Castañeda wrote:
> > > Last year a got some progresses testing Swing UI using
> > assertj-swing-junit
> > > dependency
> > >
> > > Also, I got to run TravisCI successfully, by including xvfb In order
> to
> > > run the tests that require a GUI.
> > >
> > > Finally, it required 2 additional changes:
> > >
> > > 1. Modifying Main class on modeler to expose Injector object
> > > 2. Include some modifications to the CayenneModelerFrame to set names
> for
> > > the GUI components to test, since assertj cannot test anonymous
> > instances.
> > >
> > > If Swing still being an option, I can open a PR with a full functional
> > use
> > > case of GUI testing using the mentioned stack..
> > >
> > > Other way, what would be the desires/goals for diving into JavaFX? so
> we
> > > could think about at GUI testing strategy covering that path.
> > >
> > > Thanks
> > >
> > > EmeCas
> > >
> > >
> > >
> > >
> > > On Tue, Oct 1, 2019 at 2:51 PM John Huss <jo...@gmail.com> wrote:
> > >
> > >> The way to handle testing for the UI is to write the app in an MVP
> > style,
> > >> sort of like this:
> > >>
> >
> https://stackoverflow.com/questions/11367250/concrete-code-example-of-mvp
> > >>
> > >> The gist is to define an interface contract for the view so that you
> can
> > >> replace the actual Swing UI View with a mock while testing.
> > >> But that doesn't help much with an existing application that wasn't
> > written
> > >> in that style.
> > >>
> > >>
> > >> On Tue, Oct 1, 2019 at 1:00 AM Andrus Adamchik <
> andrus@objectstyle.org>
> > >> wrote:
> > >>
> > >>> Yeah, I was thinking how do we even approach testing of Java UI. Any
> > >>> suggestions are welcome.
> > >>>
> > >>> And to complicate things we've been postponing a dive into JavaFX,
> > while
> > >>> the Swing app keeps adding functionality. So investing effort in a
> test
> > >>> framework should take this pending decision into account.
> > >>>
> > >>> Andrus
> > >>>
> > >>>> On Oct 1, 2019, at 7:11 AM, Aristedes Maniatis <ar...@maniatis.org>
> > >> wrote:
> > >>>> I've been down that path before, trying to test Swing and JavaFX.
> Its
> > >>> not easy to do. The best tool I found (and that was about 8 years
> ago)
> > >> was
> > >>>
> https://www.froglogic.com/squish/editions/automated-java-gui-testing/
> > >> but
> > >>> I don't know if they have any licensing available for open source
> > >> projects.
> > >>>> Emerson, if you have any experience with this, let us know what has
> > >>> worked for you.
> > >>>>
> > >>>> Ari
> > >>>>
> > >>>>
> > >>>> On 30/9/19 12:21am, Emerson Castañeda wrote:
> > >>>>> Wonder if these bugs would be into the kind of things that a good
> GUI
> > >>> test
> > >>>>> suite for the modeler could prevent.
> > >>>>>
> > >>>>> EmeCas
> > >>>>>
> > >>>>> On Thu, Sep 26, 2019 at 12:08 PM Lon Varscsak <
> > lon.varscsak@gmail.com
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Okay, cool. Another bug (I just found) is on the add relationship
> > >>> dialog
> > >>>>>> (on object entity) is that it seems to ignore the "delete" rule
> and
> > >>> just is
> > >>>>>> always the default. Easily worked around by just editing the
> added
> > >>>>>> relationship after the fact.
> > >>>>>>
> > >>>>>> On Thu, Sep 26, 2019 at 12:22 AM Andrus Adamchik <
> > >>> andrus@objectstyle.org>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> Screenshots are stripped by the list management software, but the
> > >>>>>>> description is pretty clear. I am not using 4.2 myself, but we do
> > >>> need to
> > >>>>>>> fix it before we release 4.2.M1.
> > >>>>>>>
> > >>>>>>> Andrus
> > >>>>>>>
> > >>>>>>>> On Sep 26, 2019, at 1:08 AM, Lon Varscsak <
> lon.varscsak@gmail.com
> > >
> > >>>>>>> wrote:
> > >>>>>>>> Hey all,
> > >>>>>>>>
> > >>>>>>>> It looks like when adding a db-relationship in the Modeler
> > >>>>>>> (4.2.M1-SNAPSHOT from today) the potential target entities is not
> > >>> sorted
> > >>>>>>> (which is only mildly annoying), but doesn't contain any target
> > >>> entities
> > >>>>>>> outside of the current data map (blocker). Am i missing
> something?
> > >>>>>>>> Thanks!
> > >>>>>>>>
> > >>>>>>>> -Lon
> > >>>>>>>>
> > >>>>>>>> Here's a screenshot for reference:
> > >>>>>>>>
> > >>>
> >
>
Re: 4.2 modeler change
Posted by Michael Gentry <bl...@gmail.com>.
I started a JavaFX prototype, but got bogged down (with other things) and
haven't picked it back up again. Kind of hoping to do that again within
the coming year...
As to Ari's HTML/JS/CSS comment, if we went that route, it would likely be
an Electron-based application, I think, with HTML/JS/CSS for the UI and a
Java backend.
On Tue, Oct 1, 2019 at 7:34 PM Aristedes Maniatis <ar...@maniatis.org> wrote:
> JavaFX would be a huge amount of work since almost the entire app would
> be rewritten from scratch. And if there was a reason to do it, that
> reason would probably point toward an html/js front end. There are just
> so many more html/js widgets for object graphs, table views, etc than
> any other UI kit.
>
> And then we'd have Cayenne modeler SaaS! \s
>
> Back in reality, Swing is going to be here a long time. If you are able
> to submit a PR to run even a basic set of tests on the UI that would be
> great and provide a guide on how to add more over time.
>
>
> Ari
>
> On 2/10/19 5:36am, Emerson Castañeda wrote:
> > Last year a got some progresses testing Swing UI using
> assertj-swing-junit
> > dependency
> >
> > Also, I got to run TravisCI successfully, by including xvfb In order to
> > run the tests that require a GUI.
> >
> > Finally, it required 2 additional changes:
> >
> > 1. Modifying Main class on modeler to expose Injector object
> > 2. Include some modifications to the CayenneModelerFrame to set names for
> > the GUI components to test, since assertj cannot test anonymous
> instances.
> >
> > If Swing still being an option, I can open a PR with a full functional
> use
> > case of GUI testing using the mentioned stack..
> >
> > Other way, what would be the desires/goals for diving into JavaFX? so we
> > could think about at GUI testing strategy covering that path.
> >
> > Thanks
> >
> > EmeCas
> >
> >
> >
> >
> > On Tue, Oct 1, 2019 at 2:51 PM John Huss <jo...@gmail.com> wrote:
> >
> >> The way to handle testing for the UI is to write the app in an MVP
> style,
> >> sort of like this:
> >>
> https://stackoverflow.com/questions/11367250/concrete-code-example-of-mvp
> >>
> >> The gist is to define an interface contract for the view so that you can
> >> replace the actual Swing UI View with a mock while testing.
> >> But that doesn't help much with an existing application that wasn't
> written
> >> in that style.
> >>
> >>
> >> On Tue, Oct 1, 2019 at 1:00 AM Andrus Adamchik <an...@objectstyle.org>
> >> wrote:
> >>
> >>> Yeah, I was thinking how do we even approach testing of Java UI. Any
> >>> suggestions are welcome.
> >>>
> >>> And to complicate things we've been postponing a dive into JavaFX,
> while
> >>> the Swing app keeps adding functionality. So investing effort in a test
> >>> framework should take this pending decision into account.
> >>>
> >>> Andrus
> >>>
> >>>> On Oct 1, 2019, at 7:11 AM, Aristedes Maniatis <ar...@maniatis.org>
> >> wrote:
> >>>> I've been down that path before, trying to test Swing and JavaFX. Its
> >>> not easy to do. The best tool I found (and that was about 8 years ago)
> >> was
> >>> https://www.froglogic.com/squish/editions/automated-java-gui-testing/
> >> but
> >>> I don't know if they have any licensing available for open source
> >> projects.
> >>>> Emerson, if you have any experience with this, let us know what has
> >>> worked for you.
> >>>>
> >>>> Ari
> >>>>
> >>>>
> >>>> On 30/9/19 12:21am, Emerson Castañeda wrote:
> >>>>> Wonder if these bugs would be into the kind of things that a good GUI
> >>> test
> >>>>> suite for the modeler could prevent.
> >>>>>
> >>>>> EmeCas
> >>>>>
> >>>>> On Thu, Sep 26, 2019 at 12:08 PM Lon Varscsak <
> lon.varscsak@gmail.com
> >>>>> wrote:
> >>>>>
> >>>>>> Okay, cool. Another bug (I just found) is on the add relationship
> >>> dialog
> >>>>>> (on object entity) is that it seems to ignore the "delete" rule and
> >>> just is
> >>>>>> always the default. Easily worked around by just editing the added
> >>>>>> relationship after the fact.
> >>>>>>
> >>>>>> On Thu, Sep 26, 2019 at 12:22 AM Andrus Adamchik <
> >>> andrus@objectstyle.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Screenshots are stripped by the list management software, but the
> >>>>>>> description is pretty clear. I am not using 4.2 myself, but we do
> >>> need to
> >>>>>>> fix it before we release 4.2.M1.
> >>>>>>>
> >>>>>>> Andrus
> >>>>>>>
> >>>>>>>> On Sep 26, 2019, at 1:08 AM, Lon Varscsak <lon.varscsak@gmail.com
> >
> >>>>>>> wrote:
> >>>>>>>> Hey all,
> >>>>>>>>
> >>>>>>>> It looks like when adding a db-relationship in the Modeler
> >>>>>>> (4.2.M1-SNAPSHOT from today) the potential target entities is not
> >>> sorted
> >>>>>>> (which is only mildly annoying), but doesn't contain any target
> >>> entities
> >>>>>>> outside of the current data map (blocker). Am i missing something?
> >>>>>>>> Thanks!
> >>>>>>>>
> >>>>>>>> -Lon
> >>>>>>>>
> >>>>>>>> Here's a screenshot for reference:
> >>>>>>>>
> >>>
>
Re: 4.2 modeler change
Posted by Aristedes Maniatis <ar...@maniatis.org>.
JavaFX would be a huge amount of work since almost the entire app would
be rewritten from scratch. And if there was a reason to do it, that
reason would probably point toward an html/js front end. There are just
so many more html/js widgets for object graphs, table views, etc than
any other UI kit.
And then we'd have Cayenne modeler SaaS! \s
Back in reality, Swing is going to be here a long time. If you are able
to submit a PR to run even a basic set of tests on the UI that would be
great and provide a guide on how to add more over time.
Ari
On 2/10/19 5:36am, Emerson Castañeda wrote:
> Last year a got some progresses testing Swing UI using assertj-swing-junit
> dependency
>
> Also, I got to run TravisCI successfully, by including xvfb In order to
> run the tests that require a GUI.
>
> Finally, it required 2 additional changes:
>
> 1. Modifying Main class on modeler to expose Injector object
> 2. Include some modifications to the CayenneModelerFrame to set names for
> the GUI components to test, since assertj cannot test anonymous instances.
>
> If Swing still being an option, I can open a PR with a full functional use
> case of GUI testing using the mentioned stack..
>
> Other way, what would be the desires/goals for diving into JavaFX? so we
> could think about at GUI testing strategy covering that path.
>
> Thanks
>
> EmeCas
>
>
>
>
> On Tue, Oct 1, 2019 at 2:51 PM John Huss <jo...@gmail.com> wrote:
>
>> The way to handle testing for the UI is to write the app in an MVP style,
>> sort of like this:
>> https://stackoverflow.com/questions/11367250/concrete-code-example-of-mvp
>>
>> The gist is to define an interface contract for the view so that you can
>> replace the actual Swing UI View with a mock while testing.
>> But that doesn't help much with an existing application that wasn't written
>> in that style.
>>
>>
>> On Tue, Oct 1, 2019 at 1:00 AM Andrus Adamchik <an...@objectstyle.org>
>> wrote:
>>
>>> Yeah, I was thinking how do we even approach testing of Java UI. Any
>>> suggestions are welcome.
>>>
>>> And to complicate things we've been postponing a dive into JavaFX, while
>>> the Swing app keeps adding functionality. So investing effort in a test
>>> framework should take this pending decision into account.
>>>
>>> Andrus
>>>
>>>> On Oct 1, 2019, at 7:11 AM, Aristedes Maniatis <ar...@maniatis.org>
>> wrote:
>>>> I've been down that path before, trying to test Swing and JavaFX. Its
>>> not easy to do. The best tool I found (and that was about 8 years ago)
>> was
>>> https://www.froglogic.com/squish/editions/automated-java-gui-testing/
>> but
>>> I don't know if they have any licensing available for open source
>> projects.
>>>> Emerson, if you have any experience with this, let us know what has
>>> worked for you.
>>>>
>>>> Ari
>>>>
>>>>
>>>> On 30/9/19 12:21am, Emerson Castañeda wrote:
>>>>> Wonder if these bugs would be into the kind of things that a good GUI
>>> test
>>>>> suite for the modeler could prevent.
>>>>>
>>>>> EmeCas
>>>>>
>>>>> On Thu, Sep 26, 2019 at 12:08 PM Lon Varscsak <lon.varscsak@gmail.com
>>>>> wrote:
>>>>>
>>>>>> Okay, cool. Another bug (I just found) is on the add relationship
>>> dialog
>>>>>> (on object entity) is that it seems to ignore the "delete" rule and
>>> just is
>>>>>> always the default. Easily worked around by just editing the added
>>>>>> relationship after the fact.
>>>>>>
>>>>>> On Thu, Sep 26, 2019 at 12:22 AM Andrus Adamchik <
>>> andrus@objectstyle.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Screenshots are stripped by the list management software, but the
>>>>>>> description is pretty clear. I am not using 4.2 myself, but we do
>>> need to
>>>>>>> fix it before we release 4.2.M1.
>>>>>>>
>>>>>>> Andrus
>>>>>>>
>>>>>>>> On Sep 26, 2019, at 1:08 AM, Lon Varscsak <lo...@gmail.com>
>>>>>>> wrote:
>>>>>>>> Hey all,
>>>>>>>>
>>>>>>>> It looks like when adding a db-relationship in the Modeler
>>>>>>> (4.2.M1-SNAPSHOT from today) the potential target entities is not
>>> sorted
>>>>>>> (which is only mildly annoying), but doesn't contain any target
>>> entities
>>>>>>> outside of the current data map (blocker). Am i missing something?
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> -Lon
>>>>>>>>
>>>>>>>> Here's a screenshot for reference:
>>>>>>>>
>>>
Re: 4.2 modeler change
Posted by Emerson Castañeda <em...@gmail.com>.
Last year a got some progresses testing Swing UI using assertj-swing-junit
dependency
Also, I got to run TravisCI successfully, by including xvfb In order to
run the tests that require a GUI.
Finally, it required 2 additional changes:
1. Modifying Main class on modeler to expose Injector object
2. Include some modifications to the CayenneModelerFrame to set names for
the GUI components to test, since assertj cannot test anonymous instances.
If Swing still being an option, I can open a PR with a full functional use
case of GUI testing using the mentioned stack..
Other way, what would be the desires/goals for diving into JavaFX? so we
could think about at GUI testing strategy covering that path.
Thanks
EmeCas
On Tue, Oct 1, 2019 at 2:51 PM John Huss <jo...@gmail.com> wrote:
> The way to handle testing for the UI is to write the app in an MVP style,
> sort of like this:
> https://stackoverflow.com/questions/11367250/concrete-code-example-of-mvp
>
> The gist is to define an interface contract for the view so that you can
> replace the actual Swing UI View with a mock while testing.
> But that doesn't help much with an existing application that wasn't written
> in that style.
>
>
> On Tue, Oct 1, 2019 at 1:00 AM Andrus Adamchik <an...@objectstyle.org>
> wrote:
>
> > Yeah, I was thinking how do we even approach testing of Java UI. Any
> > suggestions are welcome.
> >
> > And to complicate things we've been postponing a dive into JavaFX, while
> > the Swing app keeps adding functionality. So investing effort in a test
> > framework should take this pending decision into account.
> >
> > Andrus
> >
> > > On Oct 1, 2019, at 7:11 AM, Aristedes Maniatis <ar...@maniatis.org>
> wrote:
> > >
> > > I've been down that path before, trying to test Swing and JavaFX. Its
> > not easy to do. The best tool I found (and that was about 8 years ago)
> was
> > https://www.froglogic.com/squish/editions/automated-java-gui-testing/
> but
> > I don't know if they have any licensing available for open source
> projects.
> > >
> > > Emerson, if you have any experience with this, let us know what has
> > worked for you.
> > >
> > >
> > > Ari
> > >
> > >
> > > On 30/9/19 12:21am, Emerson Castañeda wrote:
> > >> Wonder if these bugs would be into the kind of things that a good GUI
> > test
> > >> suite for the modeler could prevent.
> > >>
> > >> EmeCas
> > >>
> > >> On Thu, Sep 26, 2019 at 12:08 PM Lon Varscsak <lon.varscsak@gmail.com
> >
> > >> wrote:
> > >>
> > >>> Okay, cool. Another bug (I just found) is on the add relationship
> > dialog
> > >>> (on object entity) is that it seems to ignore the "delete" rule and
> > just is
> > >>> always the default. Easily worked around by just editing the added
> > >>> relationship after the fact.
> > >>>
> > >>> On Thu, Sep 26, 2019 at 12:22 AM Andrus Adamchik <
> > andrus@objectstyle.org>
> > >>> wrote:
> > >>>
> > >>>> Screenshots are stripped by the list management software, but the
> > >>>> description is pretty clear. I am not using 4.2 myself, but we do
> > need to
> > >>>> fix it before we release 4.2.M1.
> > >>>>
> > >>>> Andrus
> > >>>>
> > >>>>> On Sep 26, 2019, at 1:08 AM, Lon Varscsak <lo...@gmail.com>
> > >>>> wrote:
> > >>>>> Hey all,
> > >>>>>
> > >>>>> It looks like when adding a db-relationship in the Modeler
> > >>>> (4.2.M1-SNAPSHOT from today) the potential target entities is not
> > sorted
> > >>>> (which is only mildly annoying), but doesn't contain any target
> > entities
> > >>>> outside of the current data map (blocker). Am i missing something?
> > >>>>> Thanks!
> > >>>>>
> > >>>>> -Lon
> > >>>>>
> > >>>>> Here's a screenshot for reference:
> > >>>>>
> > >>>>
> >
> >
>
Re: 4.2 modeler change
Posted by John Huss <jo...@gmail.com>.
The way to handle testing for the UI is to write the app in an MVP style,
sort of like this:
https://stackoverflow.com/questions/11367250/concrete-code-example-of-mvp
The gist is to define an interface contract for the view so that you can
replace the actual Swing UI View with a mock while testing.
But that doesn't help much with an existing application that wasn't written
in that style.
On Tue, Oct 1, 2019 at 1:00 AM Andrus Adamchik <an...@objectstyle.org>
wrote:
> Yeah, I was thinking how do we even approach testing of Java UI. Any
> suggestions are welcome.
>
> And to complicate things we've been postponing a dive into JavaFX, while
> the Swing app keeps adding functionality. So investing effort in a test
> framework should take this pending decision into account.
>
> Andrus
>
> > On Oct 1, 2019, at 7:11 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
> >
> > I've been down that path before, trying to test Swing and JavaFX. Its
> not easy to do. The best tool I found (and that was about 8 years ago) was
> https://www.froglogic.com/squish/editions/automated-java-gui-testing/ but
> I don't know if they have any licensing available for open source projects.
> >
> > Emerson, if you have any experience with this, let us know what has
> worked for you.
> >
> >
> > Ari
> >
> >
> > On 30/9/19 12:21am, Emerson Castañeda wrote:
> >> Wonder if these bugs would be into the kind of things that a good GUI
> test
> >> suite for the modeler could prevent.
> >>
> >> EmeCas
> >>
> >> On Thu, Sep 26, 2019 at 12:08 PM Lon Varscsak <lo...@gmail.com>
> >> wrote:
> >>
> >>> Okay, cool. Another bug (I just found) is on the add relationship
> dialog
> >>> (on object entity) is that it seems to ignore the "delete" rule and
> just is
> >>> always the default. Easily worked around by just editing the added
> >>> relationship after the fact.
> >>>
> >>> On Thu, Sep 26, 2019 at 12:22 AM Andrus Adamchik <
> andrus@objectstyle.org>
> >>> wrote:
> >>>
> >>>> Screenshots are stripped by the list management software, but the
> >>>> description is pretty clear. I am not using 4.2 myself, but we do
> need to
> >>>> fix it before we release 4.2.M1.
> >>>>
> >>>> Andrus
> >>>>
> >>>>> On Sep 26, 2019, at 1:08 AM, Lon Varscsak <lo...@gmail.com>
> >>>> wrote:
> >>>>> Hey all,
> >>>>>
> >>>>> It looks like when adding a db-relationship in the Modeler
> >>>> (4.2.M1-SNAPSHOT from today) the potential target entities is not
> sorted
> >>>> (which is only mildly annoying), but doesn't contain any target
> entities
> >>>> outside of the current data map (blocker). Am i missing something?
> >>>>> Thanks!
> >>>>>
> >>>>> -Lon
> >>>>>
> >>>>> Here's a screenshot for reference:
> >>>>>
> >>>>
>
>
Re: 4.2 modeler change
Posted by Andrus Adamchik <an...@objectstyle.org>.
Yeah, I was thinking how do we even approach testing of Java UI. Any suggestions are welcome.
And to complicate things we've been postponing a dive into JavaFX, while the Swing app keeps adding functionality. So investing effort in a test framework should take this pending decision into account.
Andrus
> On Oct 1, 2019, at 7:11 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
> I've been down that path before, trying to test Swing and JavaFX. Its not easy to do. The best tool I found (and that was about 8 years ago) was https://www.froglogic.com/squish/editions/automated-java-gui-testing/ but I don't know if they have any licensing available for open source projects.
>
> Emerson, if you have any experience with this, let us know what has worked for you.
>
>
> Ari
>
>
> On 30/9/19 12:21am, Emerson Castañeda wrote:
>> Wonder if these bugs would be into the kind of things that a good GUI test
>> suite for the modeler could prevent.
>>
>> EmeCas
>>
>> On Thu, Sep 26, 2019 at 12:08 PM Lon Varscsak <lo...@gmail.com>
>> wrote:
>>
>>> Okay, cool. Another bug (I just found) is on the add relationship dialog
>>> (on object entity) is that it seems to ignore the "delete" rule and just is
>>> always the default. Easily worked around by just editing the added
>>> relationship after the fact.
>>>
>>> On Thu, Sep 26, 2019 at 12:22 AM Andrus Adamchik <an...@objectstyle.org>
>>> wrote:
>>>
>>>> Screenshots are stripped by the list management software, but the
>>>> description is pretty clear. I am not using 4.2 myself, but we do need to
>>>> fix it before we release 4.2.M1.
>>>>
>>>> Andrus
>>>>
>>>>> On Sep 26, 2019, at 1:08 AM, Lon Varscsak <lo...@gmail.com>
>>>> wrote:
>>>>> Hey all,
>>>>>
>>>>> It looks like when adding a db-relationship in the Modeler
>>>> (4.2.M1-SNAPSHOT from today) the potential target entities is not sorted
>>>> (which is only mildly annoying), but doesn't contain any target entities
>>>> outside of the current data map (blocker). Am i missing something?
>>>>> Thanks!
>>>>>
>>>>> -Lon
>>>>>
>>>>> Here's a screenshot for reference:
>>>>>
>>>>
Re: 4.2 modeler change
Posted by Aristedes Maniatis <ar...@maniatis.org>.
I've been down that path before, trying to test Swing and JavaFX. Its
not easy to do. The best tool I found (and that was about 8 years ago)
was
https://www.froglogic.com/squish/editions/automated-java-gui-testing/
but I don't know if they have any licensing available for open source
projects.
Emerson, if you have any experience with this, let us know what has
worked for you.
Ari
On 30/9/19 12:21am, Emerson Castañeda wrote:
> Wonder if these bugs would be into the kind of things that a good GUI test
> suite for the modeler could prevent.
>
> EmeCas
>
> On Thu, Sep 26, 2019 at 12:08 PM Lon Varscsak <lo...@gmail.com>
> wrote:
>
>> Okay, cool. Another bug (I just found) is on the add relationship dialog
>> (on object entity) is that it seems to ignore the "delete" rule and just is
>> always the default. Easily worked around by just editing the added
>> relationship after the fact.
>>
>> On Thu, Sep 26, 2019 at 12:22 AM Andrus Adamchik <an...@objectstyle.org>
>> wrote:
>>
>>> Screenshots are stripped by the list management software, but the
>>> description is pretty clear. I am not using 4.2 myself, but we do need to
>>> fix it before we release 4.2.M1.
>>>
>>> Andrus
>>>
>>>> On Sep 26, 2019, at 1:08 AM, Lon Varscsak <lo...@gmail.com>
>>> wrote:
>>>> Hey all,
>>>>
>>>> It looks like when adding a db-relationship in the Modeler
>>> (4.2.M1-SNAPSHOT from today) the potential target entities is not sorted
>>> (which is only mildly annoying), but doesn't contain any target entities
>>> outside of the current data map (blocker). Am i missing something?
>>>> Thanks!
>>>>
>>>> -Lon
>>>>
>>>> Here's a screenshot for reference:
>>>>
>>>
Re: 4.2 modeler change
Posted by Emerson Castañeda <em...@gmail.com>.
Wonder if these bugs would be into the kind of things that a good GUI test
suite for the modeler could prevent.
EmeCas
On Thu, Sep 26, 2019 at 12:08 PM Lon Varscsak <lo...@gmail.com>
wrote:
> Okay, cool. Another bug (I just found) is on the add relationship dialog
> (on object entity) is that it seems to ignore the "delete" rule and just is
> always the default. Easily worked around by just editing the added
> relationship after the fact.
>
> On Thu, Sep 26, 2019 at 12:22 AM Andrus Adamchik <an...@objectstyle.org>
> wrote:
>
> > Screenshots are stripped by the list management software, but the
> > description is pretty clear. I am not using 4.2 myself, but we do need to
> > fix it before we release 4.2.M1.
> >
> > Andrus
> >
> > > On Sep 26, 2019, at 1:08 AM, Lon Varscsak <lo...@gmail.com>
> > wrote:
> > >
> > > Hey all,
> > >
> > > It looks like when adding a db-relationship in the Modeler
> > (4.2.M1-SNAPSHOT from today) the potential target entities is not sorted
> > (which is only mildly annoying), but doesn't contain any target entities
> > outside of the current data map (blocker). Am i missing something?
> > >
> > > Thanks!
> > >
> > > -Lon
> > >
> > > Here's a screenshot for reference:
> > >
> >
> >
>
Re: 4.2 modeler change
Posted by Lon Varscsak <lo...@gmail.com>.
Okay, cool. Another bug (I just found) is on the add relationship dialog
(on object entity) is that it seems to ignore the "delete" rule and just is
always the default. Easily worked around by just editing the added
relationship after the fact.
On Thu, Sep 26, 2019 at 12:22 AM Andrus Adamchik <an...@objectstyle.org>
wrote:
> Screenshots are stripped by the list management software, but the
> description is pretty clear. I am not using 4.2 myself, but we do need to
> fix it before we release 4.2.M1.
>
> Andrus
>
> > On Sep 26, 2019, at 1:08 AM, Lon Varscsak <lo...@gmail.com>
> wrote:
> >
> > Hey all,
> >
> > It looks like when adding a db-relationship in the Modeler
> (4.2.M1-SNAPSHOT from today) the potential target entities is not sorted
> (which is only mildly annoying), but doesn't contain any target entities
> outside of the current data map (blocker). Am i missing something?
> >
> > Thanks!
> >
> > -Lon
> >
> > Here's a screenshot for reference:
> >
>
>
Re: 4.2 modeler change
Posted by Andrus Adamchik <an...@objectstyle.org>.
Screenshots are stripped by the list management software, but the description is pretty clear. I am not using 4.2 myself, but we do need to fix it before we release 4.2.M1.
Andrus
> On Sep 26, 2019, at 1:08 AM, Lon Varscsak <lo...@gmail.com> wrote:
>
> Hey all,
>
> It looks like when adding a db-relationship in the Modeler (4.2.M1-SNAPSHOT from today) the potential target entities is not sorted (which is only mildly annoying), but doesn't contain any target entities outside of the current data map (blocker). Am i missing something?
>
> Thanks!
>
> -Lon
>
> Here's a screenshot for reference:
>