After the two main first agile steps, a lot of try-error have been done and the first solution found to solve a technical point was’nt the good one all the time.
After one month of usage by the user (on a tiny functional perimeter), it was time to clean work before next step

With Material Design, in single form, find or edit, title is included in the field, in our component it was difficult to use all the vuetify-field functionalities, because title was send at the same level than field ( FieldRowTitleCell and FieldRowWidgetCell ).

FrontJsFormRenderer has been modified to have the Title properties in Field properties, so json send is more simple and field rendering by vuetify is nice.

Currently we have choose to not manage all text-field attributes, only those for which we have a use case and which seem necessary, for example: size attribute seem to not be be necessary with vuetify.

ContactMech is our first specifics component to demonstrate how to manage ftl replacement in a Vue.Js environment.

With the users, a lot of little details have been enhance or corrected to have a nice and compact presentation.

ContactMech can be used in multiple context, so most party related name have been managed by parameters.
Params are managed in the <screen>, in the <action> section, and if this screen should be included in an other screen it’s possible to overload these parameters.

Currently there are 3 types of parameters :

There are still some enhancements or functionnalities to add to this component, but now, it’s really usable for the POC about Modular and generic UI

Start a document which will be reference all portlets, and there documentation associated.
Currently use existing docbook doc migrate to asccidoc for party-portlet and example.

Include in ofbizextra website a menu entry for this screenlet reference list

Short review / update for some simple older things (like specialpurpose versus plugin ;-)

Currently there are, for most of them, a edit_param form defined. With current POC situation, there is no ways to use them, but when attributes are define in database, they are used by showPortlet.

Simple modification have been done to easily migrate screen to the POC, first step has been done with the classical Find - List screen.

The "main" (on controller point of view) partymgr screen is migrated but at minimal, just a part of find works and list with link to Recap Portal Page

Currently there is a strange problem with npm buil-prod, it’s necessary to run it twice, because first one failed and not second one !
The problem not exist with build-dev.

Currently on continuous integration process (demo-selenium.ofbizextra.org), we used build-dev to facilitate debug or study how vuejs application is organized.

A portletType screenlet screen has been created to facilitate migration. Should be used by copy - paste for each portlet.

A short documentation have been started for help migration operations. It’s really a V0, it will be enhance after more migration.

Review all screen to be sure to use ${parameters.mainDecoratorLocation} for the main and uilabel decorator every time it’s possible.

In exampleFjs, correction of all screenlet title to be, now, with uiLabel.

Decorator have been created for find-list, similar to lookup to facilitate screen migration and put in a dedicated file.

To have better reactivity, we have modified the VueLink to be able to generate an internal vuejs-app call when link target is a showPortal.
With this modification, and a ofbiz component with all user interface done with portal-page, we are in a One Page application.

On a user experience point of view, it’s really a plus, because, when coming back to an already open portal-page, user retrieve it with data already load.

VuejsRouter is now used when click is done on internal link, it will be useful to have a correct back button in browser usage.

In the same time, first "standard ofbiz screen" has been used with the FrontjsRenderer and vuejs generics component.
So future migration will be more easier.

For the first screen test, we have used a dedicated FindListDecorator, to have only the List area which is update when search is done.

For fjs component, we currently force to use flatgreyfjs theme and no application menu.

A new uri for sending applicationMenu at json format with frontjsviewhandler has been done, so vuejs call it when started and update it when it’s necesary

Now, all common files for the fjs component (examplefjs, partymgrfjs, …​) are in vuejsPortal

We have started by PartyContactMgmt, to develop a vuejs-component from sratch, not trying to re-use html in ftl as template in vuejs.

To easily design this gui and to have a "modern" look, we choose to use the vuetify lib.
It’s not an original choice in vuejs environment !

Currently portlet is developed like it’s uses alone, all ofbiz css are desactivated !

In the current infra we are using docker and kubernetess for most of virtual environment.
After using these tools, for a simgle configuration like ours, during 3 years, time consuming to manage tools is more than time saving in deployment or configuration.
So we have decided to simplify configuration, one VM by ofbiz environment for example, and install - configuration is done by the jenkins job.
In current server it was not more possible to add multiple VM, most of resources are full. ;-)

We hope, it will be more easy to integrate new Apache Release environement and new project in the futur.

From a more general standpoint, we hope having more flexibility on infrastructure technics evolutions, for example :

ERP applications need more and more modularity, which is one of the major priorities of the Apache OFBiz community.

This presentation will explain why user interface modularity and its associated unit testing methods can help create full process flow integration testing that helps enable and maintain application quality.

A key success factor to delivering good automated tests is the need to have various people (e.g. Business Analysts, Developers, Product Owners) all working and collaborating together.
This ensures that the application, its tests and also the automated test deployment is as efficient as possible.
Team for test should be the same than team for developping / deploying ERP project.

After some definition about test type (gui unit test versus scenario gui test) and their own rules and goals.

We will demonstrate, how Selenium-Webdriver UI testing is being used with Apache OFBiz on a current project, and how it helps to automatically provide enough documentation to help Business analyst and to create beginner’s tutorial for the application.

Apache OFBiz is a ERP and also a technical and functional framework.
It allows to build strong and adapted solution for managing Company.

Currently there are a lot of Junit test for internal business process but there are no test for user interface, because most of time standard GUI is modified in customer project implementation.

This presentation will show how to realize GUI unit test with selenium and webdriver to test Portal page with portlet, and how to integrate test in a continuous integration environment Jenkins(ex Hudson).

With standardized tests like these, it’s possible, in a customer project to deploy a complete test coverage to guaranty quality and scalability.

This presentation cover 3 main points :

How doing in the same time the developments related to customer projects and contributions to the community project.
This is the goal of the addon system for Apache-OFBiz.
How does it works?

The Apache-OFBiz addon system is developed to:

We will see what exactly is an addon, how the adm-manager manages its, how addons could be synchronized with Apache-OFBiz evolution and how to use its on a Customer production site.

We will end with the advantages and disadvantages of such a solution and what can we hope for the future.

This conference will explain, for people who know how to insert a functionality (technical or business) in ofbiz,

There will be 3 or more ofbizextra addons repository.
What is the goals and constrains of each?
What is the process to have a good visibility for its own addon.

ofbizextra addons repository should help developers to contribute to Apache-OFBiz project.

There will be :

Mulitple repository for facilitate contribution and having a good quality, so ofbizextra-addons-dev is open for all people who want to contribute and ofbizextra-addons is only for addons with all quality points review.

This track will

This track present what is planned, but all can be discuss and change, so this track will help to defined the definitive rules.

OFBiz with a set of addons which customize user interface is a OOTB CRM application.
Details on howto install, and used

all functionality for a CRM exist in OFBiz, most of the time user interface is not user friendly, but some addons exist which customize user interface by created a large set of portlet in place of existing screen.

This track will present