Question re developing an add-on for a UI component with two different alternative implementations

Add-ons
#1

Ok, maybe the title is a bit confusing, but I couldn’t come up with a better one :wink:

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)
  • I want to give the ability to swap this component with an alternative one, based on another JS library (see this idea: TWProject Gantt Component - CUBA.Platform

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:
    <component>
        <name>nexGantt</name>
        <componentLoader>it.nexbit.cuba.tltvgantt.web.gui.xml.layout.loaders.TltvGanttLoader</componentLoader>
        <class>it.nexbit.cuba.tltvgantt.web.gui.components.WebTltvGantt</class>
    </component>

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:

    <component>
        <name>nexGantt</name>
        <componentLoader>it.nexbit.cuba.twgantt.web.gui.xml.layout.loaders.TwGanttLoader</componentLoader>
        <class>it.nexbit.cuba.twgantt.web.gui.components.WebTwGantt</class>
    </component>

Doing this way (in theory) a host application could swap one add-on with another, without changing neither the XML of the screens, nor the underlying controller code.

Is it a viable option (I know, a bit hacky), or do you see any major drawbacks?

Thanks
Paolo

1 Like
#2

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.

#3

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.

P.

#4

Yes, it could work.

From my practice, this approach simply does not work in case of complex UI components. Usually, UI component is very concrete thing, not abstract.

#5

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 :wink:

#6

Just expect a lot of tedious work and be brave!

#7

hi @pfurini
How is your Gantt Chart project going with TWprojects?

#8

Hi, unfortunately now I’m going in a different direction, that is I’m integrating a commercial component for a closed source project.

But I’m not going to forget the public marketplace, I just need to re-consider the options after completing the commercial project.

I’ll post here as soon as I have news.

P.

#9

@pfurini
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!

#10

Hi @mortozakhan
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)

Bye
P.

#11

Hi @pfurini
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.