Re: What is OFBiz public API?
There will always be a tension between guaranteeing backward compatibility for the existing user base and the efforts to maintain our codebase, enhance/refactor/innovate it. Considering the peculiar nature of OFBiz, I don't think that trying to define the areas that are part of the "public API" and then guarantee backward compatibility only for them, will resolve this tension. In fact there may be cases in which the "public API" should change in a non-backward compatible way such as: * the cost of maintaining a backward compatible feature is too high for our community (or there is not enough interest in the active community in maintaining it) * the change is required to fix a flaw or a security vulnerability * some fundamental (and important to the community) architectural change may not be backward compatible * etc... Apart from this, even the definition of "public API" for OFBiz is troublesome considering for example that potentially any OFBiz service can be used by "client" code and as a consequence in theory our community should never change the behavior (or remove) a service. In an ideal World, our community would have infinite resources and would be able to innovate and maintain our codebase while at the same time guaranteeing backward compatibility for all the users... in our reality we have to take the best decisions case by case. Potentially any change will impact someone and we should accept this; our community is also here to support and provide advices to users facing issues during migrations. I don't think it is possible or even meaningful to ask that any change/innovation must be backward compatible. This doesn't mean that we should not care at all about backward compatibility because there are changes that may have a large impact while not being so relevant for the innovation. There are cases (like the one that triggered this conversation) that may involve some community discussion because it is difficult to figure out if the cost (in terms of pains for our users) is worth the gain (in terms of better/cleaner code): sometimes these discussions can be frustrating but if we all try to stay open (to the other point of view), positive, flexible, patient I am sure we will cope with them. Just my 2 cents Jacopo
Re: What is OFBiz public API?
Le 05/01/2020 à 18:32, Mathieu Lirzin a écrit :
Hello,
The arguments provided by Michael are very general and go beyond the
specific question of “component-load.xml” so I am opening a general
discussion about how to make OFBiz evolve smoothly by precising the
extent of its public API.
I urge other contributors to join this discussion which is crucial to
define our capability to work together as a community and my willing to
continue to participate.
Michael Brohl writes:
This project is not only about tech, it has a user base with serious
business running on base of OFBiz. This has always to be considered as
serious as good technical solutions should be considered. So we cannot
simply change things because single contributors like other technical
solutions better. We have to remain downwards compatible and manage
deprecation of features carefully.
First to clarify things, making evolutions in the framework is not about
developers changing arbitrary stuff, it is about structuring internals
in an understandeable way to enable correctness and the inclusion of new
features that satisfies evolving requirements.
Backwards compability only makes sense when something has a public API
otherwise every evolution is a breaking change. In OFBiz we lack a
proper specification of what is a feature provided by the framework
subject to backward compatibility and what is an implementation detail
that can evolve/disappear between version silently. We rely on an
informal consensus to distinguish between the two.
The fact that some mechanism appears to be used in production is a valid
argument against its removal only if that mechanism is part of the
public API, otherwise it is up to the client code to adapt.
My broad understanding of what is part of OFBiz public API is:
- the plugin mechanism
- the data model and data access (Entity Engine)
- The ability to call existing services and implement new ones (Service
Engine)
- the HTTP routing mechanism (Event Handler)
- the various configuration files location in “{component}/config”
directories.
[...]
If you read carefully what I previously wrote, there are several uses
for the applications component-load.xml:
* deactivation of unused component(s) by commenting out the
load-component entry (why load marketing resources if you don't use
the component at the moment)
* addition of components (yes, I've seen projects where this was not
done through the hot-deploy mechanism)
* ordering these components in the right load order
While you can argument that these might be "wrong" approaches, they
are technically valid and used in customer projects. Therefore we
cannot simply switch the mechanisms without a proper deprecation
period.
The general problem here is not to know if things are wrong or
technically valid, it is to know if something is part of the public API
or is an implementation detail. This determines how to handle an
evolution on that part. Something wrong but part of the public API like
using XML for code should be handled with care (deprecation, migration
guides), but something technically valid but inappropriate like patching
framework Java source code from a plugin should be ignored.
In the case of ordering/enabling core components I consider it as an
implementation detail. If a component inside framework/applications is
effectively optional (like the marketing example you brought) it should
eventually be moved in the official plugins if we actually want to
provides the capability for users to disable it. However users should
not be entitled to think that they can freely desactivate/reorder/add
new components inside the framework/applications directory and that such
modifications will continue to work in a future release.
The larger question is about knowing if the internal organisation of the
files inside the "framework/applications" directories with the exception
of the “config” directories is considered part of OFBiz public API or
not? What do people think?
For the record, Without the ability to safely refactor a large subset of
the codebase that have the status of “implementation details”, I will
simply stop contributing to OFBiz because I don't have time for endless
discussions with people blaming my community work because their
extensions happen to rely on unspecified behavior.
Hi All,
Following Mathieu's question about "OFBiz public API" and the points he already
mentioned I decided to create a new thread.
I don't know what will happen with the other tread (mostly about
removing/replacing component-load.xml). That's not the subject here.
Mathieu wrote:
<>
I tend to agree with this list. From the top of my head, I'd add (maybe not a
the same level and maybe we need to define level/s)
1. Obviously, the Java API !
2. All things (why not?) supported by XSD files.
It includes Entity and Services Engines, not all feature are
documented/supported by XSD files though.
It also includes component-loader.xsd
Re: What is OFBiz public API?
Hi Michael, I purposely created a new thread because then there were no answers and I wanted to create a new thread not inserted in the initial thread. But because I got issue with my temporary IP address (due to my Internet provider) it was sent later. OK, copying there... Jacques Le 08/01/2020 à 08:32, Michael Brohl a écrit : Hi Jacques, you've created another mail thread with exactly the same title. The first thread already has answers which would get lost if your new thread would be answered. I propose that you simply answer the first thread directly. Thanks, Michael Am 08.01.20 um 05:38 schrieb Jacques Le Roux: Hi All, Following Mathieu's question about "OFBiz public API" and the points he already mentioned I decided to create a new thread. I don't know what will happen with the other tread (mostly about removing/replacing component-load.xml). That's not the subject here. Mathieu wrote: <> I tend to agree with this list. From the top of my head, I'd add (maybe not a the same level and maybe we need to define level/s) 1. Obviously, the Java API ! 2. All things (why not?) supported by XSD files. It includes Entity and Services Engines, not all feature are documented/supported by XSD files though. It also includes component-loader.xsd and ofbiz-component.xsd which are somehow parts of the subject of the other thread 3. OFBiz Gradle tasks I don't know what to say about Groovy scripts which are replacing simple-method services. What else? Jacques
Re: [DISCUSSION] Make Back-Office screens dynamic
Hi Olivier Quick question: Are you using NodeJs & NPM in your POC? And if so are you integrating with Gradle? Cheers Gavin On Mon, Dec 23, 2019 at 6:33 PM Olivier Heintz wrote: > > > Le 17/12/2019 à 15:12, Gil Portenseigne a écrit : > > Hello Taher, > > > > The proposition you saw with your first glance is > . > > > > > In that vision implementing a theme for SPA application should be > > possible, but in our opinion a gigantic task to support the screen > > engine. We think that for back office application, we should stay with > > the classic way to implement screens, and improve it to get more > > efficient. > > > > The implementation of a theme for a SPA application is a big task and > should be studied from an agile perspective. > POC-VueJs was initiated and realized in this perspective. > The POC should allow to : > * to be able to test a simple conversion from macro.ftl to the vuejs > component (or other SPA framework) > * be able to test the advanced functionalities of the SPA framework from > the point of view of an ERP back office application > * to be able to test new uses of the graphical interface linked to the > SPA concept > > I think this is only possible if there are enough screens / components > available in the POC. > We chose Party because it will be possible to derive it to HR / CRM B2C / > eCommerce Profile pages / CRM B2B / facilities workers. > Currently, only the main screens of Party are working, it is possible to > play with them at > https://ofbiz-selenium.ofbizextra.org/partymgrfjs/control/main (vuejs is > in dev mode so it is possible to view components and store areas) > https://demo-vuejs.ofbizextra.org/partymgrfjs/control/main (vuejs is in > prod mode) > > POC-VueJs is not a theme but there are already very similar points and we > should work in this direction too. > Even if some modifications should be made on a component before using this > "kind of theme", we should consider rendering it - component VueJs as a > theme. > > POC will have several steps before it is possible to choose and validate > the right solutions. > During POC we store the "migration time" per component / screens to be > able to have an evaluation of the migration ofbiz applications in the > future. > >
Re: [DISCUSSION] Make Back-Office screens dynamic
very quick answer (inline) Best Regards Le 08/01/2020 à 17:39, Gavin Mabie a écrit : > Hi Olivier > > Quick question: Are you using NodeJs & NPM in your POC? yes And if so are you > integrating with Gradle? Not yet > > Cheers > > Gavin >
Re: PortalPage / Portlet / parameters : SGBD versus XML file
Thank you Mathieu and Nicolas for your remarks They help me identify the highest priority tasks... some comments in line Le 30/12/2019 à 17:43, Nicolas Malin a écrit : > Hello, > > Ten yearsagoI would've leaned over on a solution to improve on this way, but > now with practical field experience I understood that it was a chimera on > business production site. > > All is currently present on screen-widget.xsd to define easily a screen > structure. > > The scenario “ProductOwner/keyUser/endUser” is already supported, I didn't > hear at Néréide for functional developer that they are some difficulties to > translate businessspecificationsfromany of theserolesthrough screen > definition. Currently, without portal-portlet, it's necessary to have a functional developer with its development environment to change some screen parameters, or page organization. Parameters available are not easily readable. With current PortalPage tools, I have already seen some ProductOwner/keyUsers test some solutions alone before choosing the right one (for them), it's very efficient for functional consultant. > > Rather than concentrating on adding model layers, we willwin not to let the > code grow too much and identify what is really missing on screensand rely > on portal page only for caseswhere the end user can edit his own > configuration page. You are totally right, and clearly my next priority will be to check if I find a Portal-Portlet configuration feature that I can't easily achieve with "classical" screen / decorator. If I find one, I will ask you how to solve the issue, because I already assume it will be possible. ;-) > > I'm more in favor to put away all current portal page out of the framework, > keep only one plugin as example and convert them with good practice to > help other developersand functional developersto extend the framework. > > In this way I found the Mathieu'sbelowidea: fun :) > > Nicolas > > On 29/12/2019 11:36, Mathieu Lirzin wrote: >> Hello Olivier,[...] >> >> One idea would be to have a specific webtools screen taking the form of >> a client-side Javascript program allowing users to compose a screen >> graphically and to export it as XML. This would fit the scenario you >> describe without the need of adding a general screen configuration >> mechanism inside the database. >> >> What do you think? That's a part of my proposal, and your implementation proposition give me a better idea of how to present it.. Well, first of all. I will re-uses portalPage, column, portlet, attribute entities to be able to design a short POC. I'm not sure to generate the xml directly, but something similar; the goal being a ready-to-use XML In the second stage This will involve identifying the screens that can be used as a "component" (in a GUI point of view) >>
Re: What is OFBiz public API?
Hi, everybody, It is not easy to add something in the discussion among the different arguments! (and on the different topics) I will, however, try to give some summary of my position on the various subjects discussed. 1) As Jacques recall "Community over code" so : 1.1 : It is important to trust all the members of the community in their will to improve OFBiz 1.2 : the discussion cannot take place in 2 or 3 days, it is rather in a week or a month that it will take place. (I don't have 2 or 3 hours to read (and answer) the mail every day, but I can find them during a week.. This is an advantage of mailing list discussions over chat discussions. 2) Deprecated (with documentation) before removing is a very good solution, in a release migration process, when something has disappears (not yet move to the new solution), it's more easy to retrieve file when it was deprecated to read associated documentation and know how to migrate. the rule is the same even it's simple util java method ;-) 3) I clearly not understand all implications/advantages/constrains ... or whatever about depend-on or component-load what I only can be say is : In a functional consultant point of view which want to configure an ofbiz with a lot of plugins (between 20 and 40) it's more easy to have a depend-on on each plugin to be sure the loading order will be correct. 4) implementation detail or core choice, often, it's depend of point of view you use On ERP development / implementation there are multiple type of people working on it with each one, specifics knowledge, usage, practice and point of view. When someone says, it's a big change, start by trusting him and find out which process is affected to propose a solution; he doesn't want to block something, he wants to help you come up with a better solution that solves more cases. 5) patching is wrong : very often there are patch because hook or extend mechanism not exist so When a plugin contains a patch, framework expert should explain or how to use existing extensibility mechanism to avoid the patch or how to improve the framework to provide a extensibility mechanism for this case this point is also an example about previous point ;-) 6) what is OFBiz, - not only a public API ;-) - not only a framework - currently not a OOTB ERP but I hope what, in future, there will contain some OOTB applications In my long term view Apache OFBiz could be like linux, a core/kernel as small as possible with multiple components (the plugins) and so with some distributions. So, clearly, for me it is not possible to define the boundary between what is public (with backward compatibility) and what is only implementation. Even on data model I can give some examples where not everyone will agree on what is in kernel and what is in components just my 6 cents Olivier Le 06/01/2020 à 10:29, Samuel Trégouët a écrit : > > I also hope others contributors will eventually join (many thanks to > Jacques for joining!) since this discussion seems to me to be larger > than a particular feature (component-load.xml): it is about the process > of contributing to OFBiz. > >
