I’ve a question for experts. I’ve an application core with standard functions, then come a customer that want custom functions. I can develop extending functions components only for this customer, but this require to rebuild main application. Right ?
How can I do it without build main app, ? Something to load dynamic component (like a plugin Idea)
thanks
Hi,
no this is not necessarly true. This obviously heavily depends on what you actually want to change for this customer. But generally you can create the core-app as an application component. Then you create another cuba app for this customer, which uses the core app component and then add the customer specific additions / changes.
The dynamic part is not really necessary in this case. You could also do something more dynamic like I did in this application: GitHub - mariodavid/testery: Efficient exploratory testing with as much automation as possible
There the user can add groovy scripts that the core application does not know about. The scripts are specific to the customer’s usage of the application.
Generally other dynamic plugin architectures are also possible (like putting additional jar’s in the conf directory etc.) in CUBA - but it depends on your requirements,
Bye
Mario
Hi,
It is possible without rebuilding the original project. Take a look at this sample project: GitHub - cuba-platform/sample-extensions: Extending entities and screens It can be done the same way you can extend functionality from the platform.
Thanks David and Yuriy for the answer. Assuming that I do not want to use groovy but I will create a component, I followed this example:
https://doc.cuba-platform.com/manual-6.9/app_components_sample.html
requires that the core core app, (in this sample sales app), knows that there is another component of the application client in the Extend Studio window. As a result I do not think it is the right solution. Is there a way to use components and dynamically load them from the core application?
You cannot load app components dynamically meaning without server restart. You have to put component JARs to the server, specify the component name in web.xml and restart the server.
The rest depends on your application logic, i.e. what components provide and how users should invoke the optional functionality. In the simplest case, a component just provides its screens in separate main menu items - then the application doesn’t have to know anything about the component and doesn’t have to be rebuilt or prepared for the addition of the component after deployment.
Hi,
i think this is possible, but it will not be CUBA’s application components. You would need to have to introduce some kind of runtime plugin mechanism (as in jenkins e.g.). The groovy scripts are just a simplistic example of this. It could also be a proper java library where you would have to fulfil a certain interface which is defined in the app-core.
But as I said - this really relies on what you actually want to “plugin”…
Bye
Yes this is my case, generally I will invoke a standard public method entry point for all my “plugins”, and will be external screens not integrated with existing core app screen.
thanks
and what do you actually want to do with this kind of screens? These kind of “plugins” i described (where I actually not be 100% sure how they could be deployed) would have some limitations. One of it is that you cannot change or create entities in those (at least of what I could imagine of). Instead it will be just a bunch of java classes and or XML screen descriptors. Also it might be necessary to restart the application (also not 100% sure about).
So, as you see I haven’t done this before and i’m not really sure what is possible. But most of the time app components also do the trick. From your explanations i don’t see why you could not solve what you described with app components.
Still, just out of curiosity - @knstvk do you guys have done anything like a runtime-plugin mechanism before internally, or do you have an ideas around that topic?
Bye
Mario
Hi David I explain better my case,
generally are customizations where is not required to change main interface applicaton, but simply we implement new screens with new business logic code, and we implement the entry point call code from a contest menu enabled from some grid browse table. So will be necessary a some configuration step from a section of my application where I say that there is an external customization. When a user do this, a standard function into external library is called, to return all functions available for each context (browse screen grid) where is possible call custom function, in this case the main app, will add a context menu into grid of context where is required.
At the moment we do all this using VB6 and call custom function of external dll, using CallByName function (using a string to call external code). I’d like implement same mecanism on CUBA.
Hypothesis to be able also customize interface and extending the acutal entity, is sure an interesting case, but we’ll use this case few time . Our problems is that we have about 1000 customers, and much of these have customizations, so I can’t think to rebuild the main application for each customer for each update.
So the solution of Konstantin could be the way, but if there is a mode also to extend screen and entities dynamically mode simply adding an external library even better
No, the closest thing to the topic is our hot-deploy mechanism, but it works only on class level.
When started to design Studio, we tested OSGI but decided that it brings more complexities than valuable things in case of a development tool.
I think, for an enterprise application, such ability to apply plugins at runtime can be really useful if it is about a single installation and many small optional plugins, like in Atlassian Confluence. But if we are talking about separate installations for different customers, each with its own set of add-ons, the regular CUBA app components added with server restart should be enough.