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
> 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
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
>
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
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
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
@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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo
