Thanks indeed Gavin for all the details,
I guess others have also implemented solutions with SPA frameworks. It would be
interesting to compare the implementations...
Thanks
Jacques
Le 17/12/2019 à 21:11, Gil Portenseigne a écrit :
Thanks Gavin for sharing, i have a clearer view now :).
Le
Hello,
@Michael: I would like to know if you intend to provide an explanation
regarding why it matters in production environments to be able to patch
“framework/component-load.xml” and “applications/component-load.xml” ?
This would help determining what should be done regarding [1] (meaning
Thanks Gavin for sharing, i have a clearer view now :).
Le 17:05 - mardi 17 déc., Gavin Mabie a écrit :
> Hi Gil
>
> I used a type=groovy service to resolve the form location eg.
> /*
> *@paramater formLocaction (where the form resides in the system)
> *@parameter formName (passed as request
Example Angular-Ofbiz formField Service:
import { Injectable } from '@angular/core';
import { HttpClient, HttpHeaders } from '@angular/common/http';
import { of as observableOf,Observable } from 'rxjs';
import { OfbizForm, OfbizFormFieldsBase, OfbizTexboxField,
OfbizDisplayField,
Example of Angular-Ofbiz formField Service
import { Injectable } from '@angular/core';
import { HttpClient, HttpHeaders } from '@angular/common/http';
import { of as observableOf,Observable } from 'rxjs';
import { OfbizForm, OfbizFormFieldsBase, OfbizTexboxField,
OfbizDisplayField,
Here's a more complete snippet to get a form - in Groovy.
if(formLocation) {
String delegatorName = delegator.getDelegatorName();
if (delegatorName.contains("default#")) {
delegatorName = "default";
}
DispatchContext dispatchContext = dispatcher.getDispatchContext();
ModelReader
Hi Gil
I used a type=groovy service to resolve the form location eg.
/*
*@paramater formLocaction (where the form resides in the system)
*@parameter formName (passed as request parameter)
* returns an Ofbiz form entity with all the normal functionalties
associated with ModelForm
* this is
Hello Gavin,
Thanks for four feedback, that's very interesting !
Could you elaborate about the OFBiz forms usage you did in your angular
implementation ?
You just used view-map with simple screen/form ?
Cheers !
Gil
Le 12:26 - mardi 17 déc., Gavin Mabie a écrit :
> Hi Taher
>
> I've been
Hello Taher,
The proposition you saw with your first glance is about :
* Intent : describing into a link/menu definition, the way that the
dynamically rendered form will refresh the screen upon submission
success
* Implementation : adding a tag that will generate a refreshment event
Hi Oliver
I think separating the GUI completely from the application layer could be
an option worthy of exploring. That would mean api requests and with
standard responses in JSON or XML. What the end user does with the
response is entirely up to him/her. In this scenario the responses and
Hi Taher
I've been using Angular for custom apps over the past year. This is my
approach:
1. Ofbiz deployed as an AppServer:
1.1 Ofbiz controller resolves API request calls;
1.2 Ofbiz Service Engine executes Services;
1.3 Entity Engine for persistence;
1.4 Returns JSON object - including Ofbiz
Hello Taher,
> Do you want an SPA framework now or in the future,
is a very important question but
which road to use to go is important too.
As with the current gui renderer architecture, it's possible to have multiple
rendrer engine for the "same" screen/menu/form xml files,
one question is :
Le 13/12/2019 à 23:58, Nicolas Malin a écrit :
> Hello, inline,
>
> On 13/12/2019 12:47, Olivier Heintz wrote:
>> Hello Community,
>>
>> [...]
>> 1. homogeneous in each component and between components
> This is the way started with the common-theme creation. Move all
> structural and
Hello Gil, (and Néréide Team)
Thank you for sharing research and formal process to be concentrated on concept
first.
just short remarks inline
Le 13/12/2019 à 16:52, Gil Portenseigne a écrit :
> Chapter One: How to manage the updating area
>
> Hello,
>
> After different discussions already
14 matches
Mail list logo
