Re: 4.2 modeler change
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
> 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 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
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 wrote: > On Wed, Oct 2, 2019 at 11:10 AM Andrus Adamchik > 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
On Wed, Oct 2, 2019 at 11:10 AM Andrus Adamchik 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
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 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 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 > > 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 > 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 < > > and...@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 > > > >> 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 > > >
Re: 4.2 modeler change
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 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 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 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 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 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.varsc...@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.
Re: 4.2 modeler change
@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 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 > 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 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 < > and...@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 > > >> 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.varsc...@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 < > > >>>
Re: 4.2 modeler change
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 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 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 > >> 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 > >> 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.varsc...@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 < > >>> and...@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 > > >>> 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
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 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 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 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 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 < and...@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 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
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 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 > 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 > 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 > > > >> 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 < > > and...@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 > > 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
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 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 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 > >> 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 < > and...@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 > 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
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 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 >> 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 >>> 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 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
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 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 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 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
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 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 > 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 > > 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
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 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 > 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
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 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: >
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]
