Ok, maybe the title is a bit confusing, but I couldn’t come up with a better one
Let me explain my goals:
I want to create a Gantt component to use in web projects
For a quick start, I want to base this first UI component on this vaadin addon: Vaadin Add-on Directory (to be precise, I have integrated the source code in the add-on itself, and applied some minor fixes to it, but it doesn’t change the final result)
Regarding the last point, if the host application didn’t unwrap the underlying component’s concrete class, it should be able to swap the existing vaadin-based add-on with the new one based on another client library (like the TWProject js library), without changing anything in the existing code.
So I’m implementing the component using this approach:
The component’s interface is placed in a common package and it has a common name, for example: it.nexbit.cuba.gantt.web.gui.components.NexGantt
The add-on using the vaadin component defines a concrete implementation it.nexbit.cuba.tltvgantt.web.gui.components.WebTltvGantt, and a corresponding loader class
The cuba-ui-component.xml defines a generic nexGantt component as follows:
Now, another (future) add-on based on TWProject gantt could implement the SAME NexGantt interface from the same package as the above component, and it will define a GUI component with the same element name, like:
It is viable idea but I believe it will require too much efforts because you have to provide API with two implementations. These two Gantt charts have different APIs and I’m not sure that you can implement the same features based on these implementations.
Yeah, I know it’s not straightforward, but I’ll try to implement base features that are common between the two, then I’ll see how it will go…
For example, the vaadin component supports task resolution in days, hours and maybe also in minutes, while TWProject only in days.
So I’ll start supporting only days, and a minimum set of common functionality. I’m going to experiment on this internally, if I’ll succeed with this path, I’ll polish it for publishing.
Obviously the main goal is not to force the two components appear and behave exactly the same, but only to ease the adoption of the new component by existing applications.
I know what you mean, and I agree. This is an “experiment” to see if I can build a viable abstraction, like you did with the desktop/web modules, but in a different context. Maybe it will be usable, maybe I’ll trash it and forget about it
I hope you have done with your commercial project by now. I am considering to work on one of the Gantt components for my project but if you already have done something, even if it is commercial, would like to know!
I have tried DHTMLX gantt in a project, but it was not perfectly aligned with the requirements, so it has been replaced by a Cuba gantt chart (amcharts) with some hacks to add more interactivity, and in the near future I’ll probably integrate another JS component (a resource scheduler, that’s somewhat similar to a gantt, but with different semantics).
Integrating such a complex component (like DHTMLX gantt or other JS components with complex state) it’s not trivial. I’ve been successful enough to be usable, but now it’s not complete (several things do not work, simply because I left them unimplemented).
If you have previous experience with Vaadin custom components development, go ahead and give it a try, otherwise I suggest you to try the Gantt component in the vaadin directory. Maybe it’s not the best gantt implementation in the world, but I tried it and it does its job.
Another thing you must consider is the time you need to invest to analyse third party JS components, and determine if and how they can be integrated with vaadin. Unfortunately, as you may know, there is no such a thing like “standard data binding” in JS world, so that some approaches taken by some complex JS components cannot fit well with the RPC style calls that vaadin expect. For example, I spent a good amount of time to find some workable way to pass data updates back and forth the DHTMLX gantt component, and I’ve not yet tested the more complex cases (I left the component too early). But this approach is unique to that component, and probably more than 80% of the work must be redone for a different one (even if it is a “gantt” too)…
TBH I don’t find the DHTMLX gantt so appealing (but I must admit it works pretty well and it’s stable), so I don’t know if I’ll ever complete the add-on implementation. But there’s a high probability that I’ll integrate another dual licensed component that is similar but somewhat more powerful (the resource scheduler I mentioned in the beginning of my post).
I’ll post an update on the forum ASAP (probably around the last week of november)
Thanks for the detail update and difficulties you went through trying different options. The resource scheduler you are going to work on sounds it is in the area where I am looking for to use. That is, resource planning in production plan. Looking forward for more updates.