Re: Allow definition of external style sheet in multi-block html template

[James Yong]

Hi all,

I have created OFBIZ-11819 for this.

Regards,
James

On 2020/06/06 12:05:33, James Yong  wrote: 
> Hi all,
> 
> Some external style sheets defined in layoutSettings.styleSheets are 
> page-specific.
> E.g. jquery.jgrowl-1.4.6.min.css, select2-4.0.6.css
> 
> Propose new function to set the external style sheet in multi-block html 
> template.
> 
> Regards,
> James
> 

Re: REST implementation

[Jacques Le Roux]

Hi Al,

Welcome back :)

Your message has been moderated, else it would not have reached this Mailing 
List.

Please subscribe to the dev ML.

Thanks

Jacques

Le 10/06/2020 à 18:07, Al Byers a écrit :

I am curious as to whether or not you have looked at what Moqui has done?
I'm not up to speed on it enough to comment on how it stacks up against
your list, but it seems logical to look at it since OFBiz and Moqui share a
lot of DNA.

Al Byers

On Wed, Jun 10, 2020 at 9:43 AM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:


Hi All

I am again bringing up this discussion on having a REST implementation for
OFBiz. I know we have had discussions before and I was looking at some of
the past discussions about this topic and seems we are not there quite yet
(correct me if I am wrong).

I had developed a POC plug-in based on Jersey (that I am currently
enhancing) and recently started evaluating Apache Juneau as well. I wanted
to bring everybody on the same page as far as REST implementation is
concerned so I had initiated a discussion on slack today. I am listing down
a few points below that can be perceived as comment/question/understanding
based on my general understanding of the matter and today's slack
discussion.

- Anything we start on can be part of a plug-in for the start and later
can become part of the framework (as separate plug-in) once it is
developed. A dedicated API application will allow it to be lightweight
in
terms of request processing. Should have separate auth mechanism
bypassing
ControlerServlet/ContextFiler/ControlFilter. I opine we do not need the
API
request to go through these three. Please correct me.
- We want to have mechanism to expose services (export=true) to be
available as a REST resources. Possibly extending existing service
definition by a new attribute verb="get|post". Also, if we also want to
expose out REST interface as an OpenApi specification, then it will
possibly help if we show in the spec an example of request for a
specific
service. In that case, the service definition can be expanded to allow
for
defining a JSON example (in a CDATA element)?
-  Any service that declares one of the verbs and not called with
declared verb will result in 405(Method not found) or 404(Resource does
not
exist) error.
   - GET /api/services/{serviceName}?inParams={JSON}
   - POST /api/services/{serviceName} (Request Body will contain in
   params as JSON)
   - GET /api/services : We list all services(export=true) along with
   HATEOS Links (self link describing where the specific service can be
   located)
- Do we want to have a similar resource for entities?. I think entities
should not be exposed directly as a REST resource even though they are a
good example of being a resource.
- We can take one day at a time approach here and just start with
exposing services as REST.
- Auth : I had provided JWT based auth for the plug-in I had developed.
This can further be expanded and allow for Digest auth as well? Can have
separate API endpoint to generate JWT token.

Please share your thoughts on this and apologies for long email.

Best Regards,
Girish

Re: REST implementation

[Pierre Smits]

Hi Al,

Great to see you still present.


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Wed, Jun 10, 2020 at 6:19 PM Al Byers  wrote:

> I am curious as to whether or not you have looked at what Moqui has done?
> I'm not up to speed on it enough to comment on how it stacks up against
> your list, but it seems logical to look at it since OFBiz and Moqui share a
> lot of DNA.
>
> Al Byers
>
> On Wed, Jun 10, 2020 at 9:43 AM Girish Vasmatkar <
> girish.vasmat...@hotwaxsystems.com> wrote:
>
> > Hi All
> >
> > I am again bringing up this discussion on having a REST implementation
> for
> > OFBiz. I know we have had discussions before and I was looking at some of
> > the past discussions about this topic and seems we are not there quite
> yet
> > (correct me if I am wrong).
> >
> > I had developed a POC plug-in based on Jersey (that I am currently
> > enhancing) and recently started evaluating Apache Juneau as well. I
> wanted
> > to bring everybody on the same page as far as REST implementation is
> > concerned so I had initiated a discussion on slack today. I am listing
> down
> > a few points below that can be perceived as
> comment/question/understanding
> > based on my general understanding of the matter and today's slack
> > discussion.
> >
> >- Anything we start on can be part of a plug-in for the start and
> later
> >can become part of the framework (as separate plug-in) once it is
> >developed. A dedicated API application will allow it to be lightweight
> > in
> >terms of request processing. Should have separate auth mechanism
> > bypassing
> >ControlerServlet/ContextFiler/ControlFilter. I opine we do not need
> the
> > API
> >request to go through these three. Please correct me.
> >- We want to have mechanism to expose services (export=true) to be
> >available as a REST resources. Possibly extending existing service
> >definition by a new attribute verb="get|post". Also, if we also want
> to
> >expose out REST interface as an OpenApi specification, then it will
> >possibly help if we show in the spec an example of request for a
> > specific
> >service. In that case, the service definition can be expanded to allow
> > for
> >defining a JSON example (in a CDATA element)?
> >-  Any service that declares one of the verbs and not called with
> >declared verb will result in 405(Method not found) or 404(Resource
> does
> > not
> >exist) error.
> >   - GET /api/services/{serviceName}?inParams={JSON}
> >   - POST /api/services/{serviceName} (Request Body will contain in
> >   params as JSON)
> >   - GET /api/services : We list all services(export=true) along with
> >   HATEOS Links (self link describing where the specific service can
> be
> >   located)
> >- Do we want to have a similar resource for entities?. I think
> entities
> >should not be exposed directly as a REST resource even though they
> are a
> >good example of being a resource.
> >- We can take one day at a time approach here and just start with
> >exposing services as REST.
> >- Auth : I had provided JWT based auth for the plug-in I had
> developed.
> >This can further be expanded and allow for Digest auth as well? Can
> have
> >separate API endpoint to generate JWT token.
> >
> > Please share your thoughts on this and apologies for long email.
> >
> > Best Regards,
> > Girish
> >
>

Re: REST implementation

[Al Byers]

I am curious as to whether or not you have looked at what Moqui has done?
I'm not up to speed on it enough to comment on how it stacks up against
your list, but it seems logical to look at it since OFBiz and Moqui share a
lot of DNA.

Al Byers

On Wed, Jun 10, 2020 at 9:43 AM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:

> Hi All
>
> I am again bringing up this discussion on having a REST implementation for
> OFBiz. I know we have had discussions before and I was looking at some of
> the past discussions about this topic and seems we are not there quite yet
> (correct me if I am wrong).
>
> I had developed a POC plug-in based on Jersey (that I am currently
> enhancing) and recently started evaluating Apache Juneau as well. I wanted
> to bring everybody on the same page as far as REST implementation is
> concerned so I had initiated a discussion on slack today. I am listing down
> a few points below that can be perceived as comment/question/understanding
> based on my general understanding of the matter and today's slack
> discussion.
>
>- Anything we start on can be part of a plug-in for the start and later
>can become part of the framework (as separate plug-in) once it is
>developed. A dedicated API application will allow it to be lightweight
> in
>terms of request processing. Should have separate auth mechanism
> bypassing
>ControlerServlet/ContextFiler/ControlFilter. I opine we do not need the
> API
>request to go through these three. Please correct me.
>- We want to have mechanism to expose services (export=true) to be
>available as a REST resources. Possibly extending existing service
>definition by a new attribute verb="get|post". Also, if we also want to
>expose out REST interface as an OpenApi specification, then it will
>possibly help if we show in the spec an example of request for a
> specific
>service. In that case, the service definition can be expanded to allow
> for
>defining a JSON example (in a CDATA element)?
>-  Any service that declares one of the verbs and not called with
>declared verb will result in 405(Method not found) or 404(Resource does
> not
>exist) error.
>   - GET /api/services/{serviceName}?inParams={JSON}
>   - POST /api/services/{serviceName} (Request Body will contain in
>   params as JSON)
>   - GET /api/services : We list all services(export=true) along with
>   HATEOS Links (self link describing where the specific service can be
>   located)
>- Do we want to have a similar resource for entities?. I think entities
>should not be exposed directly as a REST resource even though they are a
>good example of being a resource.
>- We can take one day at a time approach here and just start with
>exposing services as REST.
>- Auth : I had provided JWT based auth for the plug-in I had developed.
>This can further be expanded and allow for Digest auth as well? Can have
>separate API endpoint to generate JWT token.
>
> Please share your thoughts on this and apologies for long email.
>
> Best Regards,
> Girish
>

REST implementation

[Girish Vasmatkar]

Hi All

I am again bringing up this discussion on having a REST implementation for
OFBiz. I know we have had discussions before and I was looking at some of
the past discussions about this topic and seems we are not there quite yet
(correct me if I am wrong).

I had developed a POC plug-in based on Jersey (that I am currently
enhancing) and recently started evaluating Apache Juneau as well. I wanted
to bring everybody on the same page as far as REST implementation is
concerned so I had initiated a discussion on slack today. I am listing down
a few points below that can be perceived as comment/question/understanding
based on my general understanding of the matter and today's slack
discussion.

   - Anything we start on can be part of a plug-in for the start and later
   can become part of the framework (as separate plug-in) once it is
   developed. A dedicated API application will allow it to be lightweight in
   terms of request processing. Should have separate auth mechanism bypassing
   ControlerServlet/ContextFiler/ControlFilter. I opine we do not need the API
   request to go through these three. Please correct me.
   - We want to have mechanism to expose services (export=true) to be
   available as a REST resources. Possibly extending existing service
   definition by a new attribute verb="get|post". Also, if we also want to
   expose out REST interface as an OpenApi specification, then it will
   possibly help if we show in the spec an example of request for a specific
   service. In that case, the service definition can be expanded to allow for
   defining a JSON example (in a CDATA element)?
   -  Any service that declares one of the verbs and not called with
   declared verb will result in 405(Method not found) or 404(Resource does not
   exist) error.
  - GET /api/services/{serviceName}?inParams={JSON}
  - POST /api/services/{serviceName} (Request Body will contain in
  params as JSON)
  - GET /api/services : We list all services(export=true) along with
  HATEOS Links (self link describing where the specific service can be
  located)
   - Do we want to have a similar resource for entities?. I think entities
   should not be exposed directly as a REST resource even though they are a
   good example of being a resource.
   - We can take one day at a time approach here and just start with
   exposing services as REST.
   - Auth : I had provided JWT based auth for the plug-in I had developed.
   This can further be expanded and allow for Digest auth as well? Can have
   separate API endpoint to generate JWT token.

Please share your thoughts on this and apologies for long email.

Best Regards,
Girish