Hi Olivier,
I think to engage the community you need to expose the code more than just
sharing a hosted server. Perhaps posting a repo on github might do the trick.
Either way, good luck with the initiative.
On Monday, May 04, 2020 18:02 +03, Olivier Heintz <holiv...@apache.org> wrote:
Hi Community,
Some news about the POC Vue.js,
since last mails (4 month ago), some works have been done, and compared to what
was planned as the next step, we have taken a step backwards, in order to
1. take into account the remarks of the community
2. make better progress after :-)
* First of all, the cleaning of the POCs (not yet finished), after the first
few months where we tried a few solutions, we worked to eliminate all the
non-validated tests or workaround solutions used.
At the JsonRenderer level we try to clearly show what is used and functional,
and which attributes / tags not yet implemented, The idea is to have
less but correctly tested.
* Some simplifications in screen "json representation", ex: field title
attributes are now in the field attribute, to be able to have a better
presentation (title integrated in field)
** all generic template use vuetify
** a more beautiful contactMech screenlet
* All can be done with "standard" screens, (without portal - portlet),
<container is used to define screen part that can be updated, (directly by
other widget or itself if a specific "watcher - content" change): a more clear
and logical screen update process
** we use grid style for <column-container and <column
* for Example and ExampleItem, all uri used are at the REST format and http
method is define.
The template use for uri is the same define for webtools
{ResourceName}/{cover}/{Pkvalue: .*}
For Example we have
| URI | method | Goal
| Example/find | get | find form to select options for list
| Example/list | get (via post)| Example list, +
=> with a get (so without parameters) all the examples +
=> with a post (parameters and _method="GET") examples selected by options
| Example/create | get | create form
| Example/edit/{exampleId} | get | edit form and data for the id sent
| Example/show/{exampleId} | get | show form and data for the id sent
| Example/summary/{exampleId} | get | summary form and data for the id sent
| Example/data/{exampleId} | get | just data for the id sent
| Example/change | post | create a example
| Example/change/{exampleId} | put (via post)| update example with exampleId
| Example/change/{exampleId} | delete | delete example with exampleId
each time a request need multiple parameters, a POST is used with the _method
param to which http method should used
* Compound file by Resource name, to have more modularity and reusability
(organize by functional Resource), all widget data are in the same file
controller / menu / form / widget
It's still a POC, so it's still a support to discuss about technical or GUI
point.
All current choices can be challenged to find the correct or strong solution
and quickly see the result on a user point of view.
To view/test, there are two testing environments :
* ofbiz-selenium[1] used by the continuous integration process and some debug
process, so vue.js application is build with dev option
With this env. it's possible to see a lot of information about data store and
component with browser vuejs tools, but application is more slow
* demo-vuejs[2], the standard POC demo build, more stable and build with prod
option.
on menu, "Examples management" is done with Screen et Rest-uri
and "Examples management (MgmtPageFrontJs)" is done with portal-portlet
[1]
https://ofbiz-selenium.ofbizextra.org/examplefjs/control/main#/screen/Example/mgmtPg
[2]
https://demo-vuejs.ofbizextra.org/examplefjs/control/main#/screen/Example/mgmtPg
We work on a agile mode, so most of the parts are prototype which should be
reviewed and/or optimize before finalized
For the next step: we're back on schedule (the POC-UI)
https://ofbizextra.org/ofbizextra_adocs/docs/asciidoc/developer-manual.html#_modular_and_generic_ui
