<< Back to previous view

[DOL-161] Refactor DolphinServlet for extension Created: 22/Mar/16  Updated: 23/Mar/16

Status: Open
Project: Dolphin
Component/s: infrastructure
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Improvement Priority: Major
Reporter: Andres Almiray Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The `org.opendolphin.server.adapter.DolphinServlet` is a good starting point for setting up Dolphin on a Servlet environment, sadly it does not allow many customizations to be applied as the important `ServerDolphin? creation method is private.
It would be better if this class was refactored using the template method pattern to allow proper extension points, for example
@Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        preProcessRequest(request);
        DefaultServerDolphin serverDolphin = resolveServerDolphin(request);
        StringBuilder input = readInput(request);
        List<Command> commands = decodeInput(serverDolphin, input);
        List<Command> results = handleCommands(serverDolphin, commands);
        String output = encodeOutput(serverDolphin, results);
        writeOutput(response, output);
        postProcessResponse(response);
    }

where the `resolveServerDolphin` method might be implemented as follows

protected DefaultServerDolphin resolveServerDolphin(HttpServletRequest request) {
        HttpSession session = request.getSession();
        DefaultServerDolphin serverDolphin = (DefaultServerDolphin) session.getAttribute(SERVER_DOLPHIN_ATTRIBUTE_ID);

        if (serverDolphin == null) {
            serverDolphin = createServerDolphin();
            configureServerDolphin(serverDolphin);
            session.setAttribute(SERVER_DOLPHIN_ATTRIBUTE_ID, serverDolphin);
        }

        return serverDolphin;
    }

This allows subclasses to customize the whole reuqest/response handling mechanism, as well as the creation/configuration of a `ServerDolphin` instance.



 Comments   
Comment by Andres Almiray [ 23/Mar/16 11:43 AM ]
PR https://github.com/canoo/open-dolphin/pull/41




[DOL-135] Let Codec handle other inputs such as Reader and InputStream Created: 21/Jan/15  Updated: 23/Mar/16

Status: Open
Project: Dolphin
Component/s: Communication-Level
Affects Version/s: 0.11
Fix Version/s: None
Security Level: public

Type: Improvement Priority: Minor
Reporter: Andres Almiray Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The current org.opendolphin.core.comm.Codec interface defines a single decode() method that takes a String as input. It would be better for integration with Java based codebases if the Codec could handle java.io.Reader and java.io.InputStream too.

 Comments   
Comment by Dierk Koenig [ 22/Jan/15 04:28 PM ]
I see the principle value but inside OpenDolphin, the codec is never used other than for a String nor is it apparent that it will ever do so.

I'd say we can defer the effort (and the effort of testing it) until we need such a feature.

Comment by Andres Almiray [ 23/Mar/16 09:46 AM ]
I can see OpenDolphin being used in environments where HTTP and JSON are not the transfer protocol nor the encoding mechanism. Other transport options may be Netty, Aeron. Additional encoding mechanism may be Kryo, Messagepack, Simple Binary Encoder. These options provide a better throughput and/or data transfer rates. Some of them do not work with Javascript but that's beside the point. This issue was created to open the possibility to write such codecs targeting Java only applications.

PS: it's possible to use Messagepack as encoding mechanism for JS too.





[DOL-163] Allow JsonCodec to handle Integer/Long/BigInteger types Created: 22/Mar/16  Updated: 23/Mar/16

Status: Open
Project: Dolphin
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Improvement Priority: Major
Reporter: Andres Almiray Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Reference
is related to DOL-146 DoubleProperty bindings behavior Closed

 Description   
The current implementation can handle BigDecimal, Float, Number, and Date (using the ISO8601 format) but fails to distinct Integer, Long and BigInteger.
It's important to handle these types too, specially when applications may need to encode domain ids (typically typed with Long).
The current behavior is that a Long will get demoted to an Integer, leading up to ClassCastException somewhere down the road.

 Comments   
Comment by Dierk Koenig [ 20/Apr/16 09:59 PM ]
fixed with commit 5ca3b2b




[DOL-168] Update copyright statements to 2016 Created: 23/Mar/16  Updated: 23/Mar/16

Status: Open
Project: Dolphin
Component/s: infrastructure
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Task Priority: Major
Reporter: Andres Almiray Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Andres Almiray [ 23/Mar/16 09:26 AM ]
PR https://github.com/canoo/open-dolphin/pull/40




[DOL-167] Outdated Groovydoc links Created: 23/Mar/16  Updated: 23/Mar/16

Status: Open
Project: Dolphin
Component/s: infrastructure
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Task Priority: Major
Reporter: Andres Almiray Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The `groovydoc` task points to outdated links
link("http://download.oracle.com/javase/7/docs/api", "java.", "javax.")
link("http://docs.oracle.com/javafx/2/api/", "javafx.")
link("http://groovy.codehaus.org/api", "groovy.", "org.codehaus.groovy.")

The Codehaus server was shutdown in April 2015.
It would be better to point JavaFX docs to version 8 instead of 2.






[DOL-166] Review and update build & project dependencies Created: 22/Mar/16  Updated: 22/Mar/16

Status: Open
Project: Dolphin
Component/s: infrastructure
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Improvement Priority: Major
Reporter: Andres Almiray Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The following report was obtained by running `gradle dependencyUpdates` at the root level
The following dependencies are using the latest milestone version:
 - com.github.ben-manes:gradle-versions-plugin:0.12.0
 - com.github.jruby-gradle:jruby-gradle-plugin:1.2.1
 - com.jfrog.bintray.gradle:gradle-bintray-plugin:1.6
 - commons-lang:commons-lang:2.6
 - javax.inject:javax.inject:1
 - org.asciidoctor:asciidoctor-gradle-plugin:1.5.3
 - org.asciidoctor:asciidoctorj-pdf:1.5.0-alpha.11
 - org.codehaus.gpars:gpars:1.2.1
 - org.codehaus.groovyfx:groovyfx:0.4.0
 - org.jruby:jruby-complete:9.0.5.0
 - org.kt3k.gradle.plugin:coveralls-gradle-plugin:2.6.3
 - org.spockframework:spock-core:1.0-groovy-2.4
 - org.springframework.build.gradle:propdeps-plugin:0.0.7
 - org.xhtmlrenderer:core-renderer:R8
 - radeox:radeox:1.0-b2

The following dependencies exceed the version found at the milestone revision level:
 - de.richsource.gradle.plugins:typescript-gradle-plugin [1.7.1 <- 1.7]

The following dependencies have later milestone versions:
 - com.lowagie:itext [2.0.8 -> 4.2.2]
 - com.moowork.gradle:gradle-node-plugin [0.6 -> 0.12]
 - com.xlson.groovycsv:groovycsv [1.0 -> 1.1]
 - commons-logging:commons-logging [1.1.1 -> 1.2]
 - javax.servlet:servlet-api [2.5 -> 3.0-alpha-1]
 - org.apache.httpcomponents:httpclient [4.2.1 -> 4.5.2]
 - org.codehaus.groovy:groovy [2.4.4 -> 2.4.6]
 - org.codehaus.groovy:groovy-all [2.3.4 -> 2.4.6]
 - org.codehaus.groovy:groovy-ant [2.4.4 -> 2.4.6]
 - org.codehaus.groovy:groovy-json [2.4.4 -> 2.4.6]
 - org.codehaus.groovy:groovy-swing [2.4.4 -> 2.4.6]
 - org.codehaus.groovy:groovy-test [2.4.4 -> 2.4.6]
 - org.grails:grails-docs [2.4.1 -> 3.1.4]
 - org.jfxtras:jfxtras-labs [2.2-r4 -> 8.0-r4]
 - org.yaml:snakeyaml [1.9 -> 1.17]


 Comments   
Comment by Andres Almiray [ 22/Mar/16 11:22 PM ]
PR https://github.com/canoo/open-dolphin/pull/39




[DOL-165] Add project metadata to JAR manifests Created: 22/Mar/16  Updated: 22/Mar/16

Status: Open
Project: Dolphin
Component/s: infrastructure
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Improvement Priority: Major
Reporter: Andres Almiray Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
It's always a good idea to add metadata to JAR manifests that can be used by tools or even applications, for example
Manifest-Version: 1.0
Built-By: aalmiray
Created-By: 1.8.0_74 (Oracle Corporation 25.74-b02)
Build-Date: 2016-03-22
Build-Time: 22:34:37.600+0100
Build-Revision: 98ff9b011e9bc0e056f6d7088ab6924dcb20a9e2
Specification-Title: dolphin-client
Specification-Version: 1.0-RC3
Specification-Vendor: open-dolphin.org
Implementation-Title: dolphin-client
Implementation-Version: 1.0-RC3
Implementation-Vendor: open-dolphin.org


 Comments   
Comment by Andres Almiray [ 22/Mar/16 10:38 PM ]
PR https://github.com/canoo/open-dolphin/pull/38




[DOL-149] Switch to Slf4j as a logging framework Created: 09/Jul/15  Updated: 22/Mar/16

Status: Open
Project: Dolphin
Component/s: infrastructure
Affects Version/s: 0.11
Fix Version/s: None
Security Level: public

Type: Improvement Priority: Major
Reporter: Andres Almiray Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates DOL-79 Use slf4j for logging Open

 Description   
Consider using SLF4J as logging framework. The choice of a logging framework can lead into an endless discussion, just the same over which editor is better: VIM or Emacs (it's VIM of course
However, of all the terrible options we have at our disposal (all Java logging frameworks have severe deficiencies) SLF4J is the one that allows for better centralized configuration and provides bridges with other logging frameworks.

Currently it's possible to route java.util.logging through SLF4J using the jul-to-sl4j bridge, but as the documentation states, this results in severe performance hits (see http://www.slf4j.org/legacy.html#jul-to-slf4j)

Choosing SLF4J as logging provider entails:

  • an additional dependency (slf4j-api)
  • update all java.util.logging references to SLF4J's API

consumers of opendolphin would now have to

  • choose a suitable SLF4J implementation
  • optionally register additional bridges (such as apache commons-logging)





[DOL-79] Use slf4j for logging Created: 16/Jul/13  Updated: 22/Mar/16

Status: Open
Project: Dolphin
Component/s: Communication-Level
Affects Version/s: None
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Major
Reporter: Neil Galarneau Assignee: Dierk Koenig
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by DOL-149 Switch to Slf4j as a logging framework Open

 Description   
Currently, Dolphin uses java.util.logging directly.

When the application that uses Dolphin uses a different logging package (such as logback or log4j) then it is confusing & the 2 logging systems can be out of sync.

SLF4J is a logging facade that can be directed to whatever logging system the hosting application is already using.

Thank you!






[DOL-164] Apply @CompileStatic and @Cannonical to all command classes Created: 22/Mar/16  Updated: 22/Mar/16

Status: Open
Project: Dolphin
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Improvement Priority: Major
Reporter: Andres Almiray Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Command classes are used many times over during transmission. Their code should react fast to updates (no need for Groovy's MOP) and must be well behaved POJOs (equals & hashcode)




[DOL-162] ServerDolphin should expose it's Serverconnector and ServerModelStore collaborators Created: 22/Mar/16  Updated: 22/Mar/16

Status: Open
Project: Dolphin
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Improvement Priority: Major
Reporter: Andres Almiray Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
The `org.opendolphin.core.server.ServerDolphin` interface defines the basic contract fot the server side Dolphin facade. But it omits the relationships it has with `org.opendolphin.core.server.ServerModelStore` and `org.opendolphin.core.server.ServerConnector`. This forces downstream implementations to rely on `org.opendolphin.core.server.DefaultServerDolphin` which does expose getters.




[DOL-150] Split methods of OnFinishedHandler into separate classes Created: 10/Jul/15  Updated: 15/Feb/16

Status: Open
Project: Dolphin
Component/s: Communication-Level
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Improvement Priority: Major
Reporter: Franz-Josef Wiszniewsky Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
ClientDolphin allows to send commands to the server. An OnFinishedHandler can be provided as second parameter as a callback.
When this approach is used then almost always the developer uses the OnFinishedHandlerAdapter, a default implementation of the OnFinishedHandler interface and overwrites only the onFinished() method.
Because the OnFinishedHandler interface contains two methods no inlined lamdba expression can be used here.

Therefore the OnFinishedHandler interface shall be split up. The onFinished() method shall remain. The onFinishedData() method shall be moved to another interface, named for example OnFinishedDataHandler.

Next to the send method another method named sendData shall be provided which allows an instance of the new handler as a callback.

This is the proposed solution:

class ClientDolphin {
  ...

   send(String command, OnFinishedHandler onFinishedHandler) {
     ...
  }

 sendData(String command, OnFinishedDataHandler onFinishedDataHandler) {
     ...
  }

 ...
}

interface OnFinishedHandler {
   void onFinished(List<ClientPresentationModel> presentationModels);
}

interface OnFinishedDataHandler {
   void onFinishedData(List<Map> data);
}


 Comments   
Comment by Sibylle Peter [ 15/Feb/16 05:08 PM ]
According to Franz-Josef this issue is a duplicate to DOL-140




[DOL-158] PushListener needs to slow down, if it fails Created: 05/Jan/16  Updated: 06/Jan/16

Status: Open
Project: Dolphin
Component/s: Communication-Level
Affects Version/s: 0.11
Fix Version/s: 1.0
Security Level: public

Type: Feature Request Priority: Minor
Reporter: Michael Heinrichs Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
At present, if sending the push-listening command fails, OpenDolphin immediately sends a new PushListening command. As nothing was really done to resolve the issue, it is very likely to fail again. In our case this results in dozens of unsuccessful attempts per second which renders the logs unusable.

It would be better, if this functionality slows down after a number of failed attempts automatically. Another solution would be to leave this to the application, which requires some hooks to become notified of issues and some mechanisms to control how often the pushListening command is sent.



 Comments   
Comment by Dierk Koenig [ 05/Jan/16 06:00 PM ]
If the default way for push listening needs to be customized for a given application, the programmer can fully roll his own logic.
The PushView example shows an approach that allows putting in any kind of custom logic:
https://github.com/canoo/open-dolphin/blob/3fc94b4bae95eaa2333e3fc6b8c4317d4a036d5c/subprojects/demo-javafx/client/src/main/groovy/org/opendolphin/demo/PushView.groovy#L42-L43

Of course, one could also provide a feature on the standard start-/stopPushListening that allows some kind of "unavailable strategy" to be configured.
Other options would be to set specialized ResponseHandler in the HttpClientConnector or setting a suitable onException logic in the ClientConnector.

Comment by Andres Almiray [ 06/Jan/16 09:15 AM ]
This issue is somehow related to the ongoing discussion of proper resource cleanup currently missing in version 1.0-RC1




[DOL-157] Provide opendolphin.d.ts Created: 18/Nov/15  Updated: 18/Nov/15

Status: Open
Project: Dolphin
Component/s: dolphin.js
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Feature Request Priority: Major
Reporter: Michael Heinrichs Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Please provide the TypeScript-interface definition of the JavaScript client (opendolphin.d.ts) as part of the bower package. This would make it easier to integrate the OpenDolphin client into a TypeScript project.

Another option that would work for me is to push the definition to DefinitelyTyped (https://github.com/DefinitelyTyped/DefinitelyTyped).






[DOL-155] Order of pushListening and release command is not deterministic Created: 02/Nov/15  Updated: 03/Nov/15

Status: Open
Project: Dolphin
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Bug Priority: Major
Reporter: Michael Heinrichs Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
We use different instances of XMLHttpRequest for the PushListening and the Release command. Unfortunately the order in which messages arrive at the server, which were sent through different instances, does not seem to be defined. If we send a PushListening command and right after that a Release command, it is possible that the Release command reaches the server first. Subsequently the PushListening Command will not be released.

As we cannot guarantee the order on transport level, we need to ensure it on a higher level. I believe we do not really need to order all messages, but we just need to make sure that older PushListening commands are dropped if a newer Release command has been processed already.



 Comments   
Comment by Dierk Koenig [ 02/Nov/15 08:14 PM ]
Is that JavaScript only?
Comment by Michael Heinrichs [ 03/Nov/15 11:01 AM ]
I do not know. So far we use the EventBus only in one of our JavaScript clients.




[DOL-156] PushAction Commands (long poll) should only be send, if no other command is in the queue Created: 02/Nov/15  Updated: 02/Nov/15

Status: Open
Project: Dolphin
Component/s: dolphin.js
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Bug Priority: Major
Reporter: Michael Heinrichs Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Fix: https://github.com/canoo/open-dolphin/pull/21

 Description   
I encountered problems with the current implementation when many commands were sent. It was possible that regular commands were enqueued in the CommandQueue after a PushAction Command. These commands were effectively blocked until either the long poll returned regularly or was released by a new command.




[DOL-147] Work over the sequence of notifications on add/remove: local first or remote first? Created: 26/Apr/15  Updated: 26/Apr/15

Status: Open
Project: Dolphin
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Task Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Finding by Michael when a MSL on remove add the PM again, the sequence of remote notifications is odd.
On the other hand, remote notifications must only be sent if all local actions were ok.




[DOL-145] Support java.time.LocalDateTime and java.time.LocalDate Created: 25/Mar/15  Updated: 25/Mar/15

Status: Open
Project: Dolphin
Component/s: None
Affects Version/s: 0.11
Fix Version/s: None
Security Level: public

Type: Improvement Priority: Major
Reporter: Franz-Josef Wiszniewsky Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Fix: Add java.time.LocalDateTime.class and java.time.LocalDate.class to the supported values array.

 Description   
The class BaseAttribute provides a static list of supported value types named SUPPORTED_VALUE_TYPES containing classes like java.lang.String or java.util.Date.
In order to support Java 8, I recommend that also at least java.time.LocalDateTime and java.time.LocalDate from the new java.time package are supported.




[DOL-144] make sure the solution for deprecation warnings are easy to access from any kind of code Created: 27/Jan/15  Updated: 27/Jan/15

Status: Open
Project: Dolphin
Component/s: Documentation
Affects Version/s: 0.11
Fix Version/s: 1.0
Security Level: public

Type: Task Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
from the mailing list:

would it be possible to add/generate some javadoc from groovy classes?
Groovy sources are not included in the src jar, which makes it much harder to determine proper api usage for groovy bases code compared to the java based code.

example:
JFXBinder.bind(World.PROP_ONLINE).of(world).to("visible").of(statusOfflineImage, (Converter<Boolean,Boolean>) (Boolean value) -> !value);

shows a deprecation warning for of.
of is a method of BindPojoTargetOfAble which has no javadoc and attached source shows:

@Deprecated
public void of(Object target, Converter converter) { compiled code }

The actual source is located at subprojects/shared/src/main/groovy/org/opendolphin/binding/Binder.groovy opposed to exptected BindPojoTargetOfAble.groovy
which can make it a bit hard to locate:

@Deprecated // TODO (DOL-93) remove legacy code
void of(Object target, Converter converter) {
if (log.isLoggable(Level.WARNING)) { log.warning("bind(<property>).of(<source>).to(<property>).of(<target>, <converter>) is deprecated! Please use: bind(<property>).of(<source>).using(<converter>).to(<property>).of(<target>)"); }

At which point I can conclude I should have used .using method instead.

Cheers,
Timon






[DOL-143] ServerDolphin.registerDefaultActions() should be called automatically Created: 23/Jan/15  Updated: 23/Jan/15

Status: Open
Project: Dolphin
Component/s: Facade-Level
Affects Version/s: None
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Major
Reporter: Hendrik Ebbers Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Fix: The ServerDolphinFactory should call this method.

 Description   
Currently the method registerDefaultActions() must be called for each server dolphin.




[DOL-142] High Level Bindings for JavaFX Created: 23/Jan/15  Updated: 23/Jan/15

Status: Open
Project: Dolphin
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Feature Priority: Major
Reporter: Hendrik Ebbers Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: JavaFX


 Description   
Currently the binding API is generic and works for any UI Toolkit. JavaFX provides a property and binding API that can be used in the JavaFX client.




[DOL-141] explain how to write tests against PMs Created: 22/Jan/15  Updated: 22/Jan/15

Status: Open
Project: Dolphin
Component/s: Documentation
Affects Version/s: 0.11
Fix Version/s: 1.0
Security Level: public

Type: Task Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
  • extract the structure from FunctionalPresentatioModelTests
  • add tests to the demos
  • include a description in the user guide





[DOL-140] [Breaking?] make the 0nFinishedHandler a functional interface (put the onData somewhere else) Created: 22/Jan/15  Updated: 22/Jan/15

Status: Open
Project: Dolphin
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Task Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[DOL-139] remove the Closure type from all public APIs and replace with a functional interface Created: 22/Jan/15  Updated: 22/Jan/15

Status: Open
Project: Dolphin
Component/s: infrastructure
Affects Version/s: 0.11
Fix Version/s: 1.0
Security Level: public

Type: Task Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
this should make no difference to the Groovy callers as Closures can be used where functional interfaces are expected.

It makes the API more plain-Java friendly while keeping it functional for the Groovy users.






[DOL-138] upgrade to Groovy 2.3.5 or above to go around GROOVY-6852 Created: 22/Jan/15  Updated: 22/Jan/15

Status: Open
Project: Dolphin
Component/s: infrastructure
Affects Version/s: 0.11
Fix Version/s: 1.0
Security Level: public

Type: Task Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[DOL-134] provide the options to add an application-specific onException Handler to the ServerDolphin to generally handle exceptions that arise e.g. from server side property change listeners Created: 10/Dec/14  Updated: 10/Dec/14

Status: Open
Project: Dolphin
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Feature Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[DOL-132] force value change when ServerAttribute.setValue() is called even when the new value equals the old value Created: 09/Nov/14  Updated: 09/Nov/14

Status: Open
Project: Dolphin
Component/s: Communication-Level
Affects Version/s: 0.10
Fix Version/s: 1.0
Security Level: public

Type: Feature Request Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
ATM, when the old value and the new value are equivalent,
  • no value change command (VCC) is sent to the client
  • no server-side listeners are notified.

While this looked ok at first, it can actually happen that a
client attribute has already changed its value and the according change notification is
under way (sits in the client queue or comes later in the server command list).
In this case the VCC should be sent.
We cannot detect this situation, therefore we must always force the value change command.
However, since from the server perspective, the value did not change, we will not notify any listeners.

Shortcutting endless update circles (hysterese) can therefore be done on the client side only .






[DOL-129] rename findAllPresentationModelByType to findAllPresentationModelsByType (proper plural-s) Created: 07/Nov/14  Updated: 08/Nov/14

Status: Open
Project: Dolphin
Component/s: dolphin.js
Affects Version/s: 0.10
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
this is a breaking change for the JS users.
Maybe keep the old version around for some time.




[DOL-131] make a CleanModelStore command Created: 08/Nov/14  Updated: 08/Nov/14

Status: Open
Project: Dolphin
Component/s: Communication-Level
Affects Version/s: 0.10
Fix Version/s: 1.0
Security Level: public

Type: Feature Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
make a command that cleans the model store.

This can be used e.g. when running the first "initial" command in a session to make sure that we work on a clean slate.
The usage of "invalidate" and the respective Servlet can than be deprecated - and there is no longer a workflow dependency to HTTP.






[DOL-128] consider dropping back notifications or making them optional Created: 20/Aug/14  Updated: 20/Aug/14

Status: Open
Project: Dolphin
Component/s: Communication-Level
Affects Version/s: 0.10
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
With commands knowing whether the sender has already changed his state according to the command
and receivers processing commands with regard to that information, we could make sending back notifications
optional (and default would be "off").

E.g.

client             server
                       pm.value = 1    // VCC sent to client
 pm.value = 1                          // no back notification sent since server is already in the correct state
client             server
 pm.value = 1                          // VCC sent to server
                       pm.value = 1    // no back notification sent since server is already in the correct state





[DOL-125] OpenDolphin.JS's onloadend is not invoked in PhoneGap/Cordova environment. Created: 21/Jul/14  Updated: 28/Jul/14

Status: Reopened
Project: Dolphin
Component/s: dolphin.js
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Bug Priority: Major
Reporter: Janak Mulani Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: PhoneGap/Cordova


 Comments   
Comment by Janak Mulani [ 21/Jul/14 07:13 AM ]
While trying to convert an OpenDolphin.JS based app to Android mobile app using PhoneGap/Cordova it was found that onloadend is not invoked after the XMLHttpRequest. It seems that onreadystatechange has to be used instead.
Comment by Kunal Singh [ 25/Jul/14 12:52 PM ]
Fixed with GIT commit: 6bf5516370aec9667fc80351cbe5b59fc84c797b
Changed in HttpTransmitter- onloadend reaplaced with onreadystatechanged
this.http.onreadystatechange= (evt:ProgressEvent) => {
                if (this.http.readyState==4 && this.http.status==200)
                {
                    var responseText = this.http.responseText;
                    var responseCommands = this.codec.decode(responseText);
                    onDone(responseCommands);
                }
            }
Comment by Dierk Koenig [ 25/Jul/14 01:05 PM ]
We should not use magic literals (4 and 200) but meaningful constants.

Checking for status==OK may be too restrictive.
Is anything below 300 or even below 400 ok?

The onError logic must be called when the state has changed to 4 but the status is not ok.

Please add git commit hash to jira comment when closing an issue.

Comment by Kunal Singh [ 28/Jul/14 08:24 AM ]
Fixed with commit f855492ec0405d693d48e03c4f2cc97f04866081
For HttpStatus we can create constants like-
HttpCodes = {
            finished: 4,
            success : 200
 }

and we can check

this.http.onreadystatechange= (evt:ProgressEvent) => {
                if (this.http.readyState == this.HttpCodes.finished){

                    if(this.http.status == this.HttpCodes.success)
                    {
                        var responseText = this.http.responseText;
                        var responseCommands = this.codec.decode(responseText);
                        onDone(responseCommands);
                    }else{
                         //onerror should be called-- how to pass ErrorEvent here
                    }
                }

How to get ErrorEvent in else part of onreadystatechange? Or we can directly give an alert there?

Do we need to concern about other than 200 status? I have no idea what to do with other codes below 300 or 400.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html





[DOL-120] AngularJS integration - spezialized directive to bind a PresentationModel to a view Created: 14/Jul/14  Updated: 14/Jul/14

Status: Open
Project: Dolphin
Component/s: dolphin.js
Affects Version/s: 0.10
Fix Version/s: None
Security Level: public

Type: Feature Priority: Minor
Reporter: Martin Jungbauer Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Create an Angular directive, which allows one to directly bind a Presentation Model to a View




[DOL-119] Build failure with Gradle 2.0 Created: 04/Jul/14  Updated: 05/Jul/14

Status: Open
Project: Dolphin
Component/s: infrastructure
Affects Version/s: 0.10
Fix Version/s: None
Security Level: public

Type: Bug Priority: Minor
Reporter: Andres Almiray Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: ------------------------------------------------------------
Gradle 2.0
------------------------------------------------------------

Build time: 2014-07-01 07:45:34 UTC
Build number: none
Revision: b6ead6fa452dfdadec484059191eb641d817226c

Groovy: 2.3.3
Ant: Apache Ant(TM) version 1.9.3 compiled on December 23 2013
JVM: 1.8.0_05 (Oracle Corporation 25.5-b02)
OS: Mac OS X 10.9.3 x86_64


How-To-Repeat: $ gvm use gradle 2.0
$ gradle build

 Description   
The build fails with Gradle versions greater than 1.10.
It would be great if the build was upgraded to be compatible with Gradle 2.0.
The following error appears when attempting to build with Gradle > 1.10
* Where:
Script '/Users/aalmiray/Projects/canoo/open-dolphin/buildSrc/scripts/docsDependencies.gradle' line: 20

* What went wrong:
A problem occurred evaluating script.
> Cannot get property 'grailsDocs' on extra properties extension as it does not exist

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED


 Comments   
Comment by Dierk Koenig [ 05/Jul/14 08:40 PM ]
+1

I guess it would be a good strategy to resolve the pre-2.0 warnings and then do the upgrade, which should then go smoothly.

cheers
Dierk





[DOL-118] investigate whether we should introduce a RejectedCommand to inform the server about rejected value changes and maybe provide a respective listener Created: 02/May/14  Updated: 02/May/14

Status: Open
Project: Dolphin
Component/s: None
Affects Version/s: 0.9
Fix Version/s: 1.0
Security Level: public

Type: Task Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[DOL-68] serverDolphin.apply() to create a SwitchPresentationModelCommand Created: 19/Mar/13  Updated: 15/Apr/14

Status: Open
Project: Dolphin
Component/s: None
Affects Version/s: 0.7
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Dierk Koenig [ 15/Apr/14 06:15 PM ]
the pm.syncWith(source) is already there.
The question is whether the fluent API should also change the server-side state or not.




[DOL-55] add "tag" factory method to server dolphin analogous to the client dolphin but implementation sends the appropriate command Created: 14/Feb/13  Updated: 15/Apr/14

Status: Open
Project: Dolphin
Component/s: Facade-Level
Affects Version/s: 0.4
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Dierk Koenig [ 15/Apr/14 06:13 PM ]
there are two use cases
  • sending only the command
  • tagging on the server side and sending the command




[DOL-104] PresentationModel.copy() Created: 26/Dec/13  Updated: 13/Apr/14

Status: In Progress
Project: Dolphin
Component/s: Communication-Level
Affects Version/s: 0.8
Fix Version/s: 1.0
Security Level: public

Type: Feature Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Especially in master-detail views, it happens that there is a "no selection" state, i.e. at startup time, after deselection, removal of the selected element, when master is empty, etc.
In such a case, the detail view should represent the "no selection" state.
One suggestion was to allow something like apply(null) but null bears not enough information of how to reset values, e.g. to "", 0, false, null, or whatever the default should be.
Instead, do a copy of the initial presentation model state, keep it around as a reference (e.g. "blank") and use apply(blank) on deselection.
For this to work, we need a copy constructor for presentation models and their attributes.

The copy must not copy any IDs, but everything else (values, types, tags, and qualifiers). It could be isClientSideOnly=true by default as this information is only used on the client side for "how to visualize a non-selection".

The copy should not be automatically added to the model store.
If such a behavior is needed later, it can be added in a Dolphin.copy(pm) method.

If the server wants to set the detail view back to the "no-selection" state, it does so by setting back the selection itself ("what" to select? "Nothing").



 Comments   
Comment by Dierk Koenig [ 27/Dec/13 10:07 PM ]
first cut with commit 61c0a366dd49128045ec722b730dd091d4258a8b which covers the js part of the story.
The Java/Groovy part is still to do (preferably with a demo).
Comment by Dierk Koenig [ 13/Apr/14 08:36 PM ]
with 37d5e97543d30d6f91b504e5aa1a4c15814eb674
we have a client-side Java variant.
Still to do: the server-side Java variant.

Decisions for the Java version:

  • copy the client-side only flag from the source
  • put the functionality on the dolphin (not on the pm)
  • auto-add the new pm to the modelstore




[DOL-112] allow onFinished handler with only one method to implement - Java 8 friendly Created: 15/Mar/14  Updated: 15/Mar/14

Status: Open
Project: Dolphin
Component/s: Facade-Level
Affects Version/s: 0.9
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Minor
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
we have onFinished and onFinishedData. It would be better to only have one to implement - especially given that data requests are rarely used.




[DOL-110] evaluate the thread-consumption effect of many actions listening on the event bus Created: 05/Mar/14  Updated: 05/Mar/14

Status: Open
Project: Dolphin
Component/s: Communication-Level
Affects Version/s: 0.8
Fix Version/s: 1.0
Security Level: public

Type: Task Priority: Minor
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[DOL-109] disallow manual sending of release signals Created: 28/Feb/14  Updated: 28/Feb/14

Status: Open
Project: Dolphin
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: public

Type: Improvement Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
make the sending of signals non-public such that only the infrastructure can send them.
This is to avoid any misconceptions by the application programmer




[DOL-108] allow null for release Action in startPushListening for clients that need no release because they are read-only Created: 28/Feb/14  Updated: 28/Feb/14

Status: Open
Project: Dolphin
Component/s: Communication-Level
Affects Version/s: 0.8
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: both Java and JavaScript client





[DOL-91] [REFACTORING] Create a command service layer on client dolphin Created: 08/Aug/13  Updated: 24/Feb/14

Status: Open
Project: Dolphin
Component/s: Facade-Level
Affects Version/s: 0.8
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Minor
Reporter: Johannes Porzelt Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
you should not call ClientConnector.send directly to keep checks like for client-side-only consistent in one place




[DOL-75] REF: makeFrom in CreatePresentationModelCommand could go to specialized Client Ctor Created: 15/Apr/13  Updated: 24/Feb/14

Status: Open
Project: Dolphin
Component/s: Communication-Level
Affects Version/s: 0.8
Fix Version/s: 1.0
Security Level: public

Type: Task Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[DOL-93] Cleanup: remove legacy syntax for binding using converters Created: 26/Aug/13  Updated: 24/Feb/14

Status: Open
Project: Dolphin
Component/s: Facade-Level
Affects Version/s: 0.8
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Major
Reporter: Christoph Lipp Assignee: Christoph Lipp
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
With DOL-80 a new syntax has been introduced for binding using converters.
For compatibility reasons the old syntax still works but it is marked as deprecated and logs a warning message during runtime.

This legacy code should be removed in a future version



 Comments   
Comment by Christoph Lipp [ 26/Aug/13 12:00 PM ]
See also code marked with "TODO (DOL-93)"




[DOL-103] provide a method analogous to sync{} that does not actually send a command Created: 26/Dec/13  Updated: 26/Dec/13

Status: Open
Project: Dolphin
Component/s: Communication-Level
Affects Version/s: 0.8
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
in many sync{} cases there is no need for actually sending the EmptyCommand to the server (only when there is an action registered for it on the server side).
We can spare one roundtrip time by not actually sending that command but only executing the callback at the appropriate time (after all previous command callbacks have been executed).
Note that we must still flush the command batcher.




[DOL-99] update to Groovy 2.2 and make use of automatic closure coercion, esp. to PCL Created: 20/Nov/13  Updated: 14/Dec/13

Status: In Progress
Project: Dolphin
Component/s: Demo-Level
Affects Version/s: 0.8
Fix Version/s: 1.0
Security Level: public

Type: Task Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Dierk Koenig [ 20/Nov/13 03:34 PM ]
update done with commit 2016e97fd7d942ff2393a0b76e1123069428b1ae
more cleanup in the demos to do.




[DOL-47] make a clickable, self-starting demo Created: 18/Jan/13  Updated: 27/Jul/13

Status: Open
Project: Dolphin
Component/s: None
Affects Version/s: 0.4
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
thx to Andres for the suggestion




[DOL-48] provide a self-evident place for where to put actions Created: 18/Jan/13  Updated: 27/Jul/13

Status: Open
Project: Dolphin
Component/s: Demo-Level
Affects Version/s: 0.4
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
... possibly a Controller abstraction
Thx to Dieter Holz for the suggestion




[DOL-73] Explain more benefits of the generic approach of dolphin Created: 15/Apr/13  Updated: 15/Apr/13

Status: Open
Project: Dolphin
Component/s: Documentation
Affects Version/s: None
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
  • no versioning of transport artifacts
  • very little versioning of shared artifacts
  • support for non-java clients





[DOL-70] make Groovy dependencies as small as possible Created: 19/Mar/13  Updated: 19/Mar/13

Status: Open
Project: Dolphin
Component/s: infrastructure
Affects Version/s: 0.7
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Major
Reporter: Dierk Koenig Assignee: Andres Almiray
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[DOL-54] complete the documentation Created: 14/Feb/13  Updated: 14/Feb/13

Status: Open
Project: Dolphin
Component/s: infrastructure
Affects Version/s: 0.4
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
fill the demos and the reference part, include the step-by-step tutorial




[DOL-9] scan *ModelStore and *Connector for methods that should be in the *Dolphin facade Created: 23/Oct/12  Updated: 14/Feb/13

Status: Open
Project: Dolphin
Component/s: Facade-Level
Affects Version/s: 0.4
Fix Version/s: 1.0
Security Level: public

Type: Improvement Priority: Major
Reporter: Dierk Koenig Assignee: Dierk Koenig
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





Generated at Tue Oct 23 06:54:38 CEST 2018 using JIRA Enterprise Edition, Version: 3.13.5-#360.