date:20161130

So when you speak of

a super-structure that will be used in place of currently conventions which
are not always respected

how do you envision that with that new 'super-structure' conventions will
be respected?

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Nov 30, 2016 at 9:00 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Julien
>
> Inline ...
>
> Le 30/11/2016 à 10:02, Julien NICOLAS a écrit :
>
>> Hi Jacques,
>>
>>
>> On 30/11/2016 08:51, Jacques Le Roux wrote:
>>
>>>  - Each screen must be linked to a screen structure.
>>>
>>> What would be this screen structure? You don't need to develop much at
>>> this stage, just that I can't vision what it would be.
>>>
>> This structure is to follow the a UI standard that can be managed by the
>> theme. For example, the find screen can be define as :
>>  - A research field area
>>  - A result area
>>
>
> Ah, I see, we have already this concept in screen widget.
>
>
>> If all the find screen could be linked to this structure, it will be
>> easier for theme to manage it's own template of search screen.
>>
>
> You mean that it would be a super-structure that will be used in place of
> currently conventions which are not always respected, I see.
>
> It will be included in the main decorator that will also linked to a
>> structure, so theme can manage to change the template. And when you change
>> the theme, it could be a completely different look and feel :)
>> I hope I explain well my thought.
>>
>
> Got it, thanks :)
>
>
>>>
 Why we need a new component to test new theme ?

 When I start working with OFBiz, I was so surprised that the UI is too
 heavy. Then I was thinking that I have to improve the UI to provide a best
 one. After several try I understand that the actual UI is not a final user
 interface. It is a developer one. It's a developer UI because it contain
 all the features developed. But definitively, we can't provide this kind of
 UI to final users, we have to simplify it. In the same times, we can't
 delete the current UI because developers need to improve it with new
 features that will help us to deploy new features to our final users.

 For this new component, we can implement an existing component but
 simplified and ready for the new theme(s).

>>>
>>> You mean we could take and existing component, say example for instance,
>>> and would simply it at the UI level. I picked example because it's already
>>> rather simple and contains demonstration of features.
>>>
>> No, I mean to define a component (party, product, facility, etc.) that we
>> start to re-implement (using the existing services) but in a more simple
>> way (without all the features, selecting only the main ones).
>>
>
> I see
>
>
>>>
 In conclusion, if the new component dedicated for test a new theme
 match to the community needs, Taher think to a super simplified developer
 user interface that facilitate developers to improve the software. A new
 interface without any constraint that allow developers to develop easily
 new features.


>>> Another thing I can't vision at this stage, no hurry, I guess I'll later
>>> :)
>>>
>> Yes, too many thing to explain, I have to add details about this point,
>> I'll do it soon ^^
>>
>
> I did not get a chance to look yet at the POC Nicolas, Gil and you are
> working on. I guess I'd get the ideas from there then?
>
> Thanks
>
> Jacques
>

Re: [DISCUSSION] Improving the OFBiz User Interface

Julien

Inline ...

Le 30/11/2016 à 10:02, Julien NICOLAS a écrit :

Hi Jacques,

On 30/11/2016 08:51, Jacques Le Roux wrote:

- Each screen must be linked to a screen structure.

What would be this screen structure? You don't need to develop much at this
stage, just that I can't vision what it would be.

This structure is to follow the a UI standard that can be managed by the theme.
For example, the find screen can be define as :
- A research field area
- A result area

Ah, I see, we have already this concept in screen widget.

If all the find screen could be linked to this structure, it will be easier for
theme to manage it's own template of search screen.

You mean that it would be a super-structure that will be used in place of
currently conventions which are not always respected, I see.

It will be included in the main decorator that will also linked to a structure, so theme can manage to change the template. And when you change the
theme, it could be a completely different look and feel :)

I hope I explain well my thought.

Got it, thanks :)

Why we need a new component to test new theme ?

When I start working with OFBiz, I was so surprised that the UI is too heavy. Then I was thinking that I have to improve the UI to provide a best
one. After several try I understand that the actual UI is not a final user interface. It is a developer one. It's a developer UI because it
contain all the features developed. But definitively, we can't provide this kind of UI to final users, we have to simplify it. In the same times,
we can't delete the current UI because developers need to improve it with new features that will help us to deploy new features to our final users.

For this new component, we can implement an existing component but simplified
and ready for the new theme(s).

You mean we could take and existing component, say example for instance, and would simply it at the UI level. I picked example because it's already
rather simple and contains demonstration of features.
No, I mean to define a component (party, product, facility, etc.) that we start to re-implement (using the existing services) but in a more simple
way (without all the features, selecting only the main ones).

I see

In conclusion, if the new component dedicated for test a new theme match to the community needs, Taher think to a super simplified developer user
interface that facilitate developers to improve the software. A new interface without any constraint that allow developers to develop easily new
features.

Another thing I can't vision at this stage, no hurry, I guess I'll later :)

Yes, too many thing to explain, I have to add details about this point, I'll do
it soon ^^

I did not get a chance to look yet at the POC Nicolas, Gil and you are working
on. I guess I'd get the ideas from there then?

Thanks

Jacques

Re: [DISCUSSION] Improving the OFBiz User Interface

Ahh. Thanks.

That (https://oem.ofbizci.net/oci-2) uses a different theme and customer
facing component. The theme is based on the ZURB Foundation front-end
framework.

Best regards,



Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Nov 30, 2016 at 8:51 PM, Gaurav Saini 
wrote:

> https://oem.ofbizci.net/oci-2/products/oem-promotions/p_orrtiz-oshop
>
> On Thu, Dec 1, 2016 at 1:20 AM, Pierre Smits 
> wrote:
>
> > Which demo page are you referring to, Gaurav?
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Wed, Nov 30, 2016 at 8:46 PM, Gaurav Saini 
> > wrote:
> >
> > > Right, looks like it doesn't have entire features covered from the demo
> > > page I saw.
> > > But yes on similar tracks we can build something really good to go.
> > >
> > > Thanks
> > > Gaurav
> > >
> > > On Thu, Dec 1, 2016 at 1:08 AM, Pierre Smits 
> > > wrote:
> > >
> > > > You talking about something like
> > > >
> > > >- [1], which is bootstrap based and intended for customer facing
> > apps
> > > >(e.g. cmssite and ecommerce variants),
> > > >- [2], which is current default ecommerce theme elements
> > disentangled
> > > >from the framework stack
> > > >
> > > > ?
> > > >
> > > > [1] https://github.com/ORRTIZ/ecbootstrap
> > > > [2] https://github.com/ORRTIZ/ecdefault
> > > >
> > > > Best regards,
> > > >
> > > > Pierre Smits
> > > >
> > > > ORRTIZ.COM 
> > > > OFBiz based solutions & services
> > > >
> > > > OFBiz Extensions Marketplace
> > > > http://oem.ofbizci.net/oci-2/
> > > >
> > > > On Wed, Nov 30, 2016 at 8:06 PM, Gaurav Saini <
> gauravsain...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hello Everyone,
> > > > >
> > > > > Looks like I am jumping a bit late here. But as Julien said I am
> > really
> > > > > interested on working on the UI side of the project. I am still
> > looking
> > > > > deep into the ofbiz structure and understand how Julien is
> proposing
> > to
> > > > do
> > > > > UI customisation so I can help and make OFBiz look good :)
> > > > >
> > > > > For starting what I am able to understand and quickly start is
> > prepare
> > > a
> > > > > theme for the e-commerce component that is responsive in nature and
> > > with
> > > > > good UI/UX components. So, anyone starting with ofbiz can directly
> > use
> > > > the
> > > > > theme with minor changes according to need.
> > > > >
> > > > > Just to mention, I have updated my angular code to github which i
> > > > presented
> > > > > in presentation at ApacheCON. I have already posting link on
> hipchat,
> > > if
> > > > > somebody interested can look into it. I was interested in using
> > angular
> > > > as
> > > > > all together different single page app outside ofbiz because it
> > helped
> > > me
> > > > > do good amount of UI customisation and on the other hand for small
> > > > modules
> > > > > or some specific requirement it was really light-weight to use at
> > > > client's
> > > > > end.
> > > > > https://github.com/gauravsaini03/ofbiz-angular
> > > > >
> > > > > Thanks
> > > > > Gaurav
> > > > >
> > > > >
> > > > > On Wed, Nov 30, 2016 at 6:54 PM, Julien NICOLAS <
> > > > julien.nico...@nereide.fr
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Yes, I agree, let's make it simple for the POC.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 30/11/2016 11:07, Jacopo Cappellato wrote:
> > > > > >
> > > > > >> Amazing discussion and initiative.
> > > > > >> My only recommendation at the moment is to try to plan very
> short
> > > (in
> > > > > >> scope and in time) development cycles (requirements gathering
> and
> > > > > >> discussion, design, implementation, review) so that each cycle
> > could
> > > > > focus
> > > > > >> on a specific experiment/proposal (e.g. a given ui technology)
> and
> > > > could
> > > > > >> deliver a proof of concept to the community (e.g. as a new
> > > component)
> > > > > for
> > > > > >> further discussion and work.
> > > > > >>
> > > > > >> In this way we will be able to quickly implement and compare
> > > different
> > > > > >> solutions/technologies and will have a chance to take a more
> > > informed
> > > > > >> decision.
> > > > > >>
> > > > > >> Jacopo
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > > *Gaurav Saini*
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Regards,
> > > *Gaurav Saini*
> > >
> >
>
>
>
> --
> Regards,
> *Gaurav Saini*
>

Re: [DISCUSSION] Improving the OFBiz User Interface

https://oem.ofbizci.net/oci-2/products/oem-promotions/p_orrtiz-oshop

On Thu, Dec 1, 2016 at 1:20 AM, Pierre Smits  wrote:

> Which demo page are you referring to, Gaurav?
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Wed, Nov 30, 2016 at 8:46 PM, Gaurav Saini 
> wrote:
>
> > Right, looks like it doesn't have entire features covered from the demo
> > page I saw.
> > But yes on similar tracks we can build something really good to go.
> >
> > Thanks
> > Gaurav
> >
> > On Thu, Dec 1, 2016 at 1:08 AM, Pierre Smits 
> > wrote:
> >
> > > You talking about something like
> > >
> > >- [1], which is bootstrap based and intended for customer facing
> apps
> > >(e.g. cmssite and ecommerce variants),
> > >- [2], which is current default ecommerce theme elements
> disentangled
> > >from the framework stack
> > >
> > > ?
> > >
> > > [1] https://github.com/ORRTIZ/ecbootstrap
> > > [2] https://github.com/ORRTIZ/ecdefault
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM 
> > > OFBiz based solutions & services
> > >
> > > OFBiz Extensions Marketplace
> > > http://oem.ofbizci.net/oci-2/
> > >
> > > On Wed, Nov 30, 2016 at 8:06 PM, Gaurav Saini  >
> > > wrote:
> > >
> > > > Hello Everyone,
> > > >
> > > > Looks like I am jumping a bit late here. But as Julien said I am
> really
> > > > interested on working on the UI side of the project. I am still
> looking
> > > > deep into the ofbiz structure and understand how Julien is proposing
> to
> > > do
> > > > UI customisation so I can help and make OFBiz look good :)
> > > >
> > > > For starting what I am able to understand and quickly start is
> prepare
> > a
> > > > theme for the e-commerce component that is responsive in nature and
> > with
> > > > good UI/UX components. So, anyone starting with ofbiz can directly
> use
> > > the
> > > > theme with minor changes according to need.
> > > >
> > > > Just to mention, I have updated my angular code to github which i
> > > presented
> > > > in presentation at ApacheCON. I have already posting link on hipchat,
> > if
> > > > somebody interested can look into it. I was interested in using
> angular
> > > as
> > > > all together different single page app outside ofbiz because it
> helped
> > me
> > > > do good amount of UI customisation and on the other hand for small
> > > modules
> > > > or some specific requirement it was really light-weight to use at
> > > client's
> > > > end.
> > > > https://github.com/gauravsaini03/ofbiz-angular
> > > >
> > > > Thanks
> > > > Gaurav
> > > >
> > > >
> > > > On Wed, Nov 30, 2016 at 6:54 PM, Julien NICOLAS <
> > > julien.nico...@nereide.fr
> > > > >
> > > > wrote:
> > > >
> > > > > Yes, I agree, let's make it simple for the POC.
> > > > >
> > > > >
> > > > >
> > > > > On 30/11/2016 11:07, Jacopo Cappellato wrote:
> > > > >
> > > > >> Amazing discussion and initiative.
> > > > >> My only recommendation at the moment is to try to plan very short
> > (in
> > > > >> scope and in time) development cycles (requirements gathering and
> > > > >> discussion, design, implementation, review) so that each cycle
> could
> > > > focus
> > > > >> on a specific experiment/proposal (e.g. a given ui technology) and
> > > could
> > > > >> deliver a proof of concept to the community (e.g. as a new
> > component)
> > > > for
> > > > >> further discussion and work.
> > > > >>
> > > > >> In this way we will be able to quickly implement and compare
> > different
> > > > >> solutions/technologies and will have a chance to take a more
> > informed
> > > > >> decision.
> > > > >>
> > > > >> Jacopo
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > *Gaurav Saini*
> > > >
> > >
> >
> >
> >
> > --
> > Regards,
> > *Gaurav Saini*
> >
>



-- 
Regards,
*Gaurav Saini*

Re: [DISCUSSION] Improving the OFBiz User Interface

Which demo page are you referring to, Gaurav?

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Nov 30, 2016 at 8:46 PM, Gaurav Saini 
wrote:

> Right, looks like it doesn't have entire features covered from the demo
> page I saw.
> But yes on similar tracks we can build something really good to go.
>
> Thanks
> Gaurav
>
> On Thu, Dec 1, 2016 at 1:08 AM, Pierre Smits 
> wrote:
>
> > You talking about something like
> >
> >- [1], which is bootstrap based and intended for customer facing apps
> >(e.g. cmssite and ecommerce variants),
> >- [2], which is current default ecommerce theme elements disentangled
> >from the framework stack
> >
> > ?
> >
> > [1] https://github.com/ORRTIZ/ecbootstrap
> > [2] https://github.com/ORRTIZ/ecdefault
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Wed, Nov 30, 2016 at 8:06 PM, Gaurav Saini 
> > wrote:
> >
> > > Hello Everyone,
> > >
> > > Looks like I am jumping a bit late here. But as Julien said I am really
> > > interested on working on the UI side of the project. I am still looking
> > > deep into the ofbiz structure and understand how Julien is proposing to
> > do
> > > UI customisation so I can help and make OFBiz look good :)
> > >
> > > For starting what I am able to understand and quickly start is prepare
> a
> > > theme for the e-commerce component that is responsive in nature and
> with
> > > good UI/UX components. So, anyone starting with ofbiz can directly use
> > the
> > > theme with minor changes according to need.
> > >
> > > Just to mention, I have updated my angular code to github which i
> > presented
> > > in presentation at ApacheCON. I have already posting link on hipchat,
> if
> > > somebody interested can look into it. I was interested in using angular
> > as
> > > all together different single page app outside ofbiz because it helped
> me
> > > do good amount of UI customisation and on the other hand for small
> > modules
> > > or some specific requirement it was really light-weight to use at
> > client's
> > > end.
> > > https://github.com/gauravsaini03/ofbiz-angular
> > >
> > > Thanks
> > > Gaurav
> > >
> > >
> > > On Wed, Nov 30, 2016 at 6:54 PM, Julien NICOLAS <
> > julien.nico...@nereide.fr
> > > >
> > > wrote:
> > >
> > > > Yes, I agree, let's make it simple for the POC.
> > > >
> > > >
> > > >
> > > > On 30/11/2016 11:07, Jacopo Cappellato wrote:
> > > >
> > > >> Amazing discussion and initiative.
> > > >> My only recommendation at the moment is to try to plan very short
> (in
> > > >> scope and in time) development cycles (requirements gathering and
> > > >> discussion, design, implementation, review) so that each cycle could
> > > focus
> > > >> on a specific experiment/proposal (e.g. a given ui technology) and
> > could
> > > >> deliver a proof of concept to the community (e.g. as a new
> component)
> > > for
> > > >> further discussion and work.
> > > >>
> > > >> In this way we will be able to quickly implement and compare
> different
> > > >> solutions/technologies and will have a chance to take a more
> informed
> > > >> decision.
> > > >>
> > > >> Jacopo
> > > >>
> > > >>
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > *Gaurav Saini*
> > >
> >
>
>
>
> --
> Regards,
> *Gaurav Saini*
>

Re: [DISCUSSION] Improving the OFBiz User Interface

Right, looks like it doesn't have entire features covered from the demo
page I saw.
But yes on similar tracks we can build something really good to go.

Thanks
Gaurav

On Thu, Dec 1, 2016 at 1:08 AM, Pierre Smits  wrote:

> You talking about something like
>
>- [1], which is bootstrap based and intended for customer facing apps
>(e.g. cmssite and ecommerce variants),
>- [2], which is current default ecommerce theme elements disentangled
>from the framework stack
>
> ?
>
> [1] https://github.com/ORRTIZ/ecbootstrap
> [2] https://github.com/ORRTIZ/ecdefault
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Wed, Nov 30, 2016 at 8:06 PM, Gaurav Saini 
> wrote:
>
> > Hello Everyone,
> >
> > Looks like I am jumping a bit late here. But as Julien said I am really
> > interested on working on the UI side of the project. I am still looking
> > deep into the ofbiz structure and understand how Julien is proposing to
> do
> > UI customisation so I can help and make OFBiz look good :)
> >
> > For starting what I am able to understand and quickly start is prepare a
> > theme for the e-commerce component that is responsive in nature and with
> > good UI/UX components. So, anyone starting with ofbiz can directly use
> the
> > theme with minor changes according to need.
> >
> > Just to mention, I have updated my angular code to github which i
> presented
> > in presentation at ApacheCON. I have already posting link on hipchat, if
> > somebody interested can look into it. I was interested in using angular
> as
> > all together different single page app outside ofbiz because it helped me
> > do good amount of UI customisation and on the other hand for small
> modules
> > or some specific requirement it was really light-weight to use at
> client's
> > end.
> > https://github.com/gauravsaini03/ofbiz-angular
> >
> > Thanks
> > Gaurav
> >
> >
> > On Wed, Nov 30, 2016 at 6:54 PM, Julien NICOLAS <
> julien.nico...@nereide.fr
> > >
> > wrote:
> >
> > > Yes, I agree, let's make it simple for the POC.
> > >
> > >
> > >
> > > On 30/11/2016 11:07, Jacopo Cappellato wrote:
> > >
> > >> Amazing discussion and initiative.
> > >> My only recommendation at the moment is to try to plan very short (in
> > >> scope and in time) development cycles (requirements gathering and
> > >> discussion, design, implementation, review) so that each cycle could
> > focus
> > >> on a specific experiment/proposal (e.g. a given ui technology) and
> could
> > >> deliver a proof of concept to the community (e.g. as a new component)
> > for
> > >> further discussion and work.
> > >>
> > >> In this way we will be able to quickly implement and compare different
> > >> solutions/technologies and will have a chance to take a more informed
> > >> decision.
> > >>
> > >> Jacopo
> > >>
> > >>
> > >
> >
> >
> > --
> > Regards,
> > *Gaurav Saini*
> >
>



-- 
Regards,
*Gaurav Saini*

Re: [DISCUSSION] Defining an OFBiz Project Strategy

HI Gaurav,

See [1] for connecting Magento to OFBiz.

[1] https://oem.ofbizci.net/oci-2/products/ecommerce/p_ofbiz-connect

It has links to the product page and code repository of the 3rd party
special purpose component.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Nov 30, 2016 at 8:40 PM, Gaurav Saini 
wrote:

> Hello Sharan,
>
> I was going through old archives from mailing list and saw some discussion
> regarding comparing ofbiz with magento. As, I have also heard from people
> using magento as its quick to install and multiple themes support.
>
> Going back to UI again, if we can make the e-commerce UI look good then we
> can surely attract people towards ofbiz adoption for an e-commerce stores.
> Another good enhancement that can be a factor getting people towards OFBiz
> is integrating some real time recommendation system using machine learning.
> As, after basic e-commerce part is there, now next necessity to have
> recommendation and analytics available to grow further.
>
> Thanks
> Gaurav
>
> On Mon, Nov 28, 2016 at 4:05 PM, Sharan Foga  wrote:
>
> > There was a bit that I missed - and this is a common thing that keeps
> > coming back up when we get together and talk:
> >
> > OFBiz could deliver more than one product. We could have more than one
> > product active at the same time e.g
> >
> >- Framework with applications
> >- Advanced UI but without all features
> >- Advanced features but with the poor UI
> >
> > This is also something that we could think about for the high level
> > strategy.
> >
> > Thanks
> > Sharan
> >
> > On 2016-11-28 11:08 (+0100), "Sharan Foga" wrote:
> > > Hi Everyone
> > >
> > > One of the topics that came up during the brainstorming in Seville was
> > that the project desperately needs a clear strategy and roadmap.
> > >
> > > Benefits:
> > > - A strategy will provide a clear path for people to follow
> > > - A strategy will allow us to set goals / milestones and metrics about
> > progress
> > >
> > > In past maybe we have tried to do too much (tried to do it all at once
> -
> > which is why we find it h ard to focus).
> > >
> > > - One suggestion was to set a maximum of 3 goals and then work only on
> > these. To define these goals we need to look at what is the most
> important
> > thing that we want to achieve - and base them on that.
> > > - Another suggestion was that the most important thing for the project
> > is driving adoption. If this is true then what are the key blockers that
> > stop user adoption of OFBiz? (the UI!)
> > > - Suggestion to organise / setup teams from the community that focus on
> > specific areas (e.g. workgroups) - this could really help progress
> > >
> > > So to get the discussion started:
> > >
> > > 1. Do people agree that the project needs to focus on driving adoption?
> > > 2. Do people think that the UI is one of the key things that stops this
> > ? (If, not then please include what do you think is)
> > > 3. What goals could we set?
> > > 4. Are people interested in working in workgroups, to focus on specific
> > areas (or goals)?
> > >
> > > (I know there are some ideas/work around the UI going on, but I will
> > post the Seville details and notes about that in separate discussion
> > thread.)
> > >
> > > Thanks
> > > Sharan
> > >
> > >
> >
>
>
>
> --
> Regards,
> *Gaurav Saini*
>

Re: [DISCUSSION] Defining an OFBiz Project Strategy

Hello Sharan,

I was going through old archives from mailing list and saw some discussion
regarding comparing ofbiz with magento. As, I have also heard from people
using magento as its quick to install and multiple themes support.

Going back to UI again, if we can make the e-commerce UI look good then we
can surely attract people towards ofbiz adoption for an e-commerce stores.
Another good enhancement that can be a factor getting people towards OFBiz
is integrating some real time recommendation system using machine learning.
As, after basic e-commerce part is there, now next necessity to have
recommendation and analytics available to grow further.

Thanks
Gaurav

On Mon, Nov 28, 2016 at 4:05 PM, Sharan Foga  wrote:

> There was a bit that I missed - and this is a common thing that keeps
> coming back up when we get together and talk:
>
> OFBiz could deliver more than one product. We could have more than one
> product active at the same time e.g
>
>- Framework with applications
>- Advanced UI but without all features
>- Advanced features but with the poor UI
>
> This is also something that we could think about for the high level
> strategy.
>
> Thanks
> Sharan
>
> On 2016-11-28 11:08 (+0100), "Sharan Foga" wrote:
> > Hi Everyone
> >
> > One of the topics that came up during the brainstorming in Seville was
> that the project desperately needs a clear strategy and roadmap.
> >
> > Benefits:
> > - A strategy will provide a clear path for people to follow
> > - A strategy will allow us to set goals / milestones and metrics about
> progress
> >
> > In past maybe we have tried to do too much (tried to do it all at once -
> which is why we find it h ard to focus).
> >
> > - One suggestion was to set a maximum of 3 goals and then work only on
> these. To define these goals we need to look at what is the most important
> thing that we want to achieve - and base them on that.
> > - Another suggestion was that the most important thing for the project
> is driving adoption. If this is true then what are the key blockers that
> stop user adoption of OFBiz? (the UI!)
> > - Suggestion to organise / setup teams from the community that focus on
> specific areas (e.g. workgroups) - this could really help progress
> >
> > So to get the discussion started:
> >
> > 1. Do people agree that the project needs to focus on driving adoption?
> > 2. Do people think that the UI is one of the key things that stops this
> ? (If, not then please include what do you think is)
> > 3. What goals could we set?
> > 4. Are people interested in working in workgroups, to focus on specific
> areas (or goals)?
> >
> > (I know there are some ideas/work around the UI going on, but I will
> post the Seville details and notes about that in separate discussion
> thread.)
> >
> > Thanks
> > Sharan
> >
> >
>



-- 
Regards,
*Gaurav Saini*

Re: [DISCUSSION] Improving the OFBiz User Interface

You talking about something like

   - [1], which is bootstrap based and intended for customer facing apps
   (e.g. cmssite and ecommerce variants),
   - [2], which is current default ecommerce theme elements disentangled
   from the framework stack

?

[1] https://github.com/ORRTIZ/ecbootstrap
[2] https://github.com/ORRTIZ/ecdefault

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Nov 30, 2016 at 8:06 PM, Gaurav Saini 
wrote:

> Hello Everyone,
>
> Looks like I am jumping a bit late here. But as Julien said I am really
> interested on working on the UI side of the project. I am still looking
> deep into the ofbiz structure and understand how Julien is proposing to do
> UI customisation so I can help and make OFBiz look good :)
>
> For starting what I am able to understand and quickly start is prepare a
> theme for the e-commerce component that is responsive in nature and with
> good UI/UX components. So, anyone starting with ofbiz can directly use the
> theme with minor changes according to need.
>
> Just to mention, I have updated my angular code to github which i presented
> in presentation at ApacheCON. I have already posting link on hipchat, if
> somebody interested can look into it. I was interested in using angular as
> all together different single page app outside ofbiz because it helped me
> do good amount of UI customisation and on the other hand for small modules
> or some specific requirement it was really light-weight to use at client's
> end.
> https://github.com/gauravsaini03/ofbiz-angular
>
> Thanks
> Gaurav
>
>
> On Wed, Nov 30, 2016 at 6:54 PM, Julien NICOLAS  >
> wrote:
>
> > Yes, I agree, let's make it simple for the POC.
> >
> >
> >
> > On 30/11/2016 11:07, Jacopo Cappellato wrote:
> >
> >> Amazing discussion and initiative.
> >> My only recommendation at the moment is to try to plan very short (in
> >> scope and in time) development cycles (requirements gathering and
> >> discussion, design, implementation, review) so that each cycle could
> focus
> >> on a specific experiment/proposal (e.g. a given ui technology) and could
> >> deliver a proof of concept to the community (e.g. as a new component)
> for
> >> further discussion and work.
> >>
> >> In this way we will be able to quickly implement and compare different
> >> solutions/technologies and will have a chance to take a more informed
> >> decision.
> >>
> >> Jacopo
> >>
> >>
> >
>
>
> --
> Regards,
> *Gaurav Saini*
>

Re: [DISCUSSION] Improving the OFBiz User Interface

Hello Everyone,

Looks like I am jumping a bit late here. But as Julien said I am really
interested on working on the UI side of the project. I am still looking
deep into the ofbiz structure and understand how Julien is proposing to do
UI customisation so I can help and make OFBiz look good :)

For starting what I am able to understand and quickly start is prepare a
theme for the e-commerce component that is responsive in nature and with
good UI/UX components. So, anyone starting with ofbiz can directly use the
theme with minor changes according to need.

Just to mention, I have updated my angular code to github which i presented
in presentation at ApacheCON. I have already posting link on hipchat, if
somebody interested can look into it. I was interested in using angular as
all together different single page app outside ofbiz because it helped me
do good amount of UI customisation and on the other hand for small modules
or some specific requirement it was really light-weight to use at client's
end.
https://github.com/gauravsaini03/ofbiz-angular

Thanks
Gaurav

On Wed, Nov 30, 2016 at 6:54 PM, Julien NICOLAS 
wrote:

> Yes, I agree, let's make it simple for the POC.
>
>
>
> On 30/11/2016 11:07, Jacopo Cappellato wrote:
>
>> Amazing discussion and initiative.
>> My only recommendation at the moment is to try to plan very short (in
>> scope and in time) development cycles (requirements gathering and
>> discussion, design, implementation, review) so that each cycle could focus
>> on a specific experiment/proposal (e.g. a given ui technology) and could
>> deliver a proof of concept to the community (e.g. as a new component) for
>> further discussion and work.
>>
>> In this way we will be able to quickly implement and compare different
>> solutions/technologies and will have a chance to take a more informed
>> decision.
>>
>> Jacopo
>>
>>
>

-- 
Regards,
*Gaurav Saini*

Re: [DISCUSSION] Defining an OFBiz Project Strategy

2016-11-30 Thread Olivier Heintz



Le 29/11/2016 à 22:12, Nicolas Malin a écrit :
> 
> Le 29/11/2016 à 20:21, Olivier Heintz a écrit :
>> Le 28/11/2016 à 22:43, Taher Alkhateeb a écrit :
 Hi Sharan,

 Thank you for starting this important topic. OFBiz definitely needs

 

model.
 - A DSL that hides and abstracts away the complexity of everything 
 (services, entities, widgets, routing, etc...)
and makes it easy for adopters to provide value quickly.
>>- A plugin system AND a plugin strong organization
> I'm agree to the plugin system but not on plugin strong organization.
> 
> Offer good tools to realize some plugin is different that offer a 
> plateform to deploy and manage a plugin store
> We need to concentrate the effort on the core, have some official plugin 
> for example, special case and define best pratice.
> 
> We are to few to maintain the ofbiz core so for me manage a plugin store 
> is more for integrator company or another dedicate community with 
> different rules.

my formulation was too short and so not clear, << plugin strong organization >>
would have of the being something like
<< plugin metadata and some rules to be able to have efficient documentation to 
find easily what plugin install for the choosing function >>
and nothing about repository management, I apologize for the misunderstanding.

But I immediately add the remark done by sharan, taher, ... It's not a current 
discussion subject for today.
We should have first have some plugin available. (I'm currently testing the 
webdriver-tools addon migrated as a plugin)



> 
> Cheers,
> Nicolas
>

Re: [DISCUSSION] Defining an OFBiz Project Strategy

2016-11-30 Thread Nicolas Malin


Hello,
Le 30/11/2016 à 13:44, Jacopo Cappellato a écrit :

On Wed, Nov 30, 2016 at 11:52 AM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:


[...]
Instead of firing up an entire maven repository we can just create source
branches for the plugins, and publish to JCenter with an OFBiz account.
This is a simpler faster way moving forward. [...]

[...]

In my opinion the following points should be considered:
* each plugin created by the OFBiz project is actually a "product" and
should be treated as a product
* as an ASF project/community we can only distribute products that we
create and publish/release with a formal vote; the OFBiz project cannot
distribute code that is not formally approved/released
* the primary distribution channel for the products published by the OFBiz
project must be owned/managed by the ASF Infra; it is ok to distribute the
OFBiz project's products using different alternative channels (like the
mirrors release network leveraged by all the ASF projects) provided that
the primary channel is owned by the ASF.

All the above doesn't apply to third party plugins: for them there are no
restrictions as they are not distributed by the OFBiz project. Users can
download them, possibly using the OFBiz plugin API, and third party
companies can create them and upload to public/private repositories as they
like.
As an ASF project we will not endorse, promote, approve, distribute or
release third-party plugins; but as a project we could facilitate and
encourage third party companies to create/publish/promote their plugins by
improving the tools (e.g. the plugin API) that enable end users to install
them in their OFBiz instance.

Jacopo


:) you resume my mind Jacopo, it's exaclty what I think !

Nicolas

Re: [DISCUSSION] Defining an OFBiz Project Strategy

I am looking forward to seeing a strategy in place, before any *new* code
will be added to the code base.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Nov 30, 2016 at 1:56 PM, Taher Alkhateeb  wrote:

> Hi jacopo,
>
> I see, all good points on tbe compliance side of things with ASF
> guidelines. I was actually replying to a suggestion by Jacques to create a
> new maven repository in a VM or something like that which sounded like too
> much work to me. So your suggestion of just using an existing ASF
> infrastructure seems like a good middle solution.
>
> Cheers,
>
> Taher Alkhateeb
>
> On Nov 30, 2016 3:44 PM, "Jacopo Cappellato" <
> jacopo.cappell...@hotwaxsystems.com> wrote:
>
> On Wed, Nov 30, 2016 at 11:52 AM, Taher Alkhateeb <
> slidingfilame...@gmail.com> wrote:
>
> > [...]
> > Instead of firing up an entire maven repository we can just create source
> > branches for the plugins, and publish to JCenter with an OFBiz account.
> > This is a simpler faster way moving forward. [...]
>
>
> Hi Taher,
>
> I am not sure I understand what you mean with "firing up a maven repo" but
> my proposal was not that: instead I was proposing to explore the
> possibility to use the existing official repo offered by the ASF to
> distribute Maven plugins.
> Sharan and Jacques had a quick chat today with some Infra guys to explore
> the options available (I will let them add more info if I am missing
> something).
>
> In my opinion the following points should be considered:
> * each plugin created by the OFBiz project is actually a "product" and
> should be treated as a product
> * as an ASF project/community we can only distribute products that we
> create and publish/release with a formal vote; the OFBiz project cannot
> distribute code that is not formally approved/released
> * the primary distribution channel for the products published by the OFBiz
> project must be owned/managed by the ASF Infra; it is ok to distribute the
> OFBiz project's products using different alternative channels (like the
> mirrors release network leveraged by all the ASF projects) provided that
> the primary channel is owned by the ASF.
>
> All the above doesn't apply to third party plugins: for them there are no
> restrictions as they are not distributed by the OFBiz project. Users can
> download them, possibly using the OFBiz plugin API, and third party
> companies can create them and upload to public/private repositories as they
> like.
> As an ASF project we will not endorse, promote, approve, distribute or
> release third-party plugins; but as a project we could facilitate and
> encourage third party companies to create/publish/promote their plugins by
> improving the tools (e.g. the plugin API) that enable end users to install
> them in their OFBiz instance.
>
> Jacopo
>

Re: svn commit: r1771995 - /ofbiz/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/jdbc/Da tabaseUtil.java


Le 30/11/2016 à 09:41, Nicolas Malin a écrit :

Hello Paul

Le 30/11/2016 à 07:42, paulfoxwor...@apache.org a écrit :

@@ -1014,7 +1014,8 @@ public class DatabaseUtil {
  // NOTE: this may need a toUpperCase in some cases, keep 
an eye on it, okay for now just do a compare with equalsIgnoreCase
  String tableType = tableSet.getString("TABLE_TYPE");
  // only allow certain table types
-if (tableType != null && !"TABLE".equalsIgnoreCase(tableType) && !"VIEW".equalsIgnoreCase(tableType) && 
!"ALIAS".equalsIgnoreCase(tableType) && !"SYNONYM".equalsIgnoreCase(tableType)) {

+if (tableType != null && !"TABLE".equalsIgnoreCase(tableType) && 
!"VIEW".equalsIgnoreCase(tableType)
+&& !"ALIAS".equalsIgnoreCase(tableType) && !"SYNONYM".equalsIgnoreCase(tableType) && !"BASE 
TABLE".equalsIgnoreCase(tableType)) {

  continue;
  }


Maybe we can change the if condition by something like that :

if (tableType != null && Arrays.asList(types).contains(tableType.toUpperCase()))

Nicolas



We could even use the Martin Fowler's "Decompose Conditional" refactoring 
pattern http://www.refactoring.com/catalog/decomposeConditional.html

I mean not only specifically here but all around OFBiz when necessary

While seeing Taher doing a lot of refactoring in the base component I decided 
it was time for me to read more about it.
I knew about refactoring from Eclipse tools, but that was it. So I bought http://www.martinfowler.com/books/refactoring.html and I'm now reading it 
for few weeks.

I recommend it to everyone who have not the chance to read it yet.

Jacques

Re: [DISCUSSION] Improving the OFBiz User Interface

2016-11-30 Thread Julien NICOLAS


Yes, I agree, let's make it simple for the POC.


On 30/11/2016 11:07, Jacopo Cappellato wrote:

Amazing discussion and initiative.
My only recommendation at the moment is to try to plan very short (in
scope and in time) development cycles (requirements gathering and
discussion, design, implementation, review) so that each cycle could focus
on a specific experiment/proposal (e.g. a given ui technology) and could
deliver a proof of concept to the community (e.g. as a new component) for
further discussion and work.

In this way we will be able to quickly implement and compare different
solutions/technologies and will have a chance to take a more informed
decision.

Jacopo

Re: [DISCUSSION] Defining an OFBiz Project Strategy

2016-11-30 Thread Taher Alkhateeb

Hi jacopo,

I see, all good points on tbe compliance side of things with ASF
guidelines. I was actually replying to a suggestion by Jacques to create a
new maven repository in a VM or something like that which sounded like too
much work to me. So your suggestion of just using an existing ASF
infrastructure seems like a good middle solution.

Cheers,

Taher Alkhateeb

On Nov 30, 2016 3:44 PM, "Jacopo Cappellato" <
jacopo.cappell...@hotwaxsystems.com> wrote:

On Wed, Nov 30, 2016 at 11:52 AM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:

> [...]
> Instead of firing up an entire maven repository we can just create source
> branches for the plugins, and publish to JCenter with an OFBiz account.
> This is a simpler faster way moving forward. [...]

Hi Taher,

I am not sure I understand what you mean with "firing up a maven repo" but
my proposal was not that: instead I was proposing to explore the
possibility to use the existing official repo offered by the ASF to
distribute Maven plugins.
Sharan and Jacques had a quick chat today with some Infra guys to explore
the options available (I will let them add more info if I am missing
something).

In my opinion the following points should be considered:
* each plugin created by the OFBiz project is actually a "product" and
should be treated as a product
* as an ASF project/community we can only distribute products that we
create and publish/release with a formal vote; the OFBiz project cannot
distribute code that is not formally approved/released
* the primary distribution channel for the products published by the OFBiz
project must be owned/managed by the ASF Infra; it is ok to distribute the
OFBiz project's products using different alternative channels (like the
mirrors release network leveraged by all the ASF projects) provided that
the primary channel is owned by the ASF.

All the above doesn't apply to third party plugins: for them there are no
restrictions as they are not distributed by the OFBiz project. Users can
download them, possibly using the OFBiz plugin API, and third party
companies can create them and upload to public/private repositories as they
like.
As an ASF project we will not endorse, promote, approve, distribute or
release third-party plugins; but as a project we could facilitate and
encourage third party companies to create/publish/promote their plugins by
improving the tools (e.g. the plugin API) that enable end users to install
them in their OFBiz instance.

Jacopo

Re: [DISCUSSION] Defining an OFBiz Project Strategy

On Wed, Nov 30, 2016 at 11:52 AM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:

> [...]
> Instead of firing up an entire maven repository we can just create source
> branches for the plugins, and publish to JCenter with an OFBiz account.
> This is a simpler faster way moving forward. [...]

Hi Taher,

I am not sure I understand what you mean with "firing up a maven repo" but
my proposal was not that: instead I was proposing to explore the
possibility to use the existing official repo offered by the ASF to
distribute Maven plugins.
Sharan and Jacques had a quick chat today with some Infra guys to explore
the options available (I will let them add more info if I am missing
something).

In my opinion the following points should be considered:
* each plugin created by the OFBiz project is actually a "product" and
should be treated as a product
* as an ASF project/community we can only distribute products that we
create and publish/release with a formal vote; the OFBiz project cannot
distribute code that is not formally approved/released
* the primary distribution channel for the products published by the OFBiz
project must be owned/managed by the ASF Infra; it is ok to distribute the
OFBiz project's products using different alternative channels (like the
mirrors release network leveraged by all the ASF projects) provided that
the primary channel is owned by the ASF.

All the above doesn't apply to third party plugins: for them there are no
restrictions as they are not distributed by the OFBiz project. Users can
download them, possibly using the OFBiz plugin API, and third party
companies can create them and upload to public/private repositories as they
like.
As an ASF project we will not endorse, promote, approve, distribute or
release third-party plugins; but as a project we could facilitate and
encourage third party companies to create/publish/promote their plugins by
improving the tools (e.g. the plugin API) that enable end users to install
them in their OFBiz instance.

Jacopo

Re: [DISCUSSION] Improving the OFBiz User Interface

2016-11-30 Thread Taher Alkhateeb

Good point Jacopo. We need a place to collaborate and get down to business.
I would prefer an interactive HipChat session to get rolling and decide
what to do next, then maybe create a wiki page or something like that based
on the initial plan.

On Wed, Nov 30, 2016 at 1:07 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> Amazing discussion and initiative.
> My only recommendation at the moment is to try to plan very short (in
> scope and in time) development cycles (requirements gathering and
> discussion, design, implementation, review) so that each cycle could focus
> on a specific experiment/proposal (e.g. a given ui technology) and could
> deliver a proof of concept to the community (e.g. as a new component) for
> further discussion and work.
>
> In this way we will be able to quickly implement and compare different
> solutions/technologies and will have a chance to take a more informed
> decision.
>
> Jacopo
>

Re: [DISCUSSION] Defining an OFBiz Project Strategy

2016-11-30 Thread Taher Alkhateeb

Folks, I need to note that the plugins issue is simple and does not need
that much effort.

Instead of firing up an entire maven repository we can just create source
branches for the plugins, and publish to JCenter with an OFBiz account.
This is a simpler faster way moving forward. Firing up an entire maven
repository just for a few packages does not seem necessary to me at this
time. This step might be necessary in the future if we get a huge volume of
plugins or something like that.

So a simple naming convention for the plugin versions combined with hosting
the source code in branches is enough to get us started.

For example:

- For trunk: We can create a task called ./gradlew pullOfficialPlugin
-PpluginId=Whatever. This task will pull the source code from subversion or
whatever and just put it in /specialpurpose
- For releases 16.11: ./gradlew pullPlugin
-PdependencyId='org.apache.ofbiz.plugin.release16.11:myplugin:1.0.0'

So I'm rooting for simplicity, I suggest not to over-engineer too quickly
before testing all aspects of the plugin system. In the end, the OFBiz
plugin of a certain version in a certain release is really just a tag in
subversion or something like that. It's not a big deal to publish it to
JCenter or similar repository providers because we will always have that
exact copy available in our source code system.

Cheers,

Taher Alkhateeb

On Wed, Nov 30, 2016 at 1:37 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> On Wed, Nov 30, 2016 at 11:26 AM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > If I understand well, this Maven repo is only for ASF internal use,
> right?
> > (though I see http://repo.maven.apache.org/maven2/external/atlassian/
> but
> > I guess it's a matter of agreement with infra and maybe Maven teams?)
> > If it's the case, that's quite an idea Jacopo, less work for us :)
> > Will you ask?
> >
> > Jacques
> >
>
> I am not sure it is only for ASF projects, probably not.
> But, since one of the requirements by the ASF for distributing official
> releases (and afaik each plugin will be technically a release) is that the
> release packages must be available from ASF owned infra, the above should
> do the trick.
> I would prefer to wait before asking any question until we have a better
> knowledge of our intentions, requirements and architecture; in the meantime
> we can explore more in this and other directions.
>
> Jacopo
>

Re: [DISCUSSION] Defining an OFBiz Project Strategy

On Wed, Nov 30, 2016 at 11:26 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> If I understand well, this Maven repo is only for ASF internal use, right?
> (though I see http://repo.maven.apache.org/maven2/external/atlassian/ but
> I guess it's a matter of agreement with infra and maybe Maven teams?)
> If it's the case, that's quite an idea Jacopo, less work for us :)
> Will you ask?
>
> Jacques
>

I am not sure it is only for ASF projects, probably not.
But, since one of the requirements by the ASF for distributing official
releases (and afaik each plugin will be technically a release) is that the
release packages must be available from ASF owned infra, the above should
do the trick.
I would prefer to wait before asking any question until we have a better
knowledge of our intentions, requirements and architecture; in the meantime
we can explore more in this and other directions.

Jacopo

Re: [DISCUSSION] Defining an OFBiz Project Strategy


Le 30/11/2016 à 10:54, Jacopo Cappellato a écrit :

On Wed, Nov 30, 2016 at 10:40 AM, Sharan Foga  wrote:


[...] I wouldn't be happy for the community to have to rely on service
providers to provide what should be standard functions / components or
plug-ins.

So I would be in favour of something like Jacques is proposing that we
have an official project repo for plug-ins.


We could look at the feasibility (from an infra and a legal perspective) of
publishing our plugins to:
http://repo.maven.apache.org/maven2

Jacopo

If I understand well, this Maven repo is only for ASF internal use, right? (though I see http://repo.maven.apache.org/maven2/external/atlassian/ but I 
guess it's a matter of agreement with infra and maybe Maven teams?)

If it's the case, that's quite an idea Jacopo, less work for us :)
Will you ask?

Jacques

Re: buildbot failure in on ofbiz-trunk


Yes I also checked tests locally just after the commit, I confirm and Builbot 
continued OK later

Thanks to care Deepak

Jacques


Le 30/11/2016 à 08:50, Deepak Dixit a écrit :

I think its an false report, as  testIntegration return success on local
box.

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

On Tue, Nov 29, 2016 at 11:47 PM,  wrote:


The Buildbot has detected a new failure on builder ofbiz-trunk while
building . Full details are available at:
 https://ci.apache.org/builders/ofbiz-trunk/builds/1765

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz-commit'
triggered this build
Build Source Stamp: [branch ofbiz/trunk] 1771935
Blamelist: deepak

BUILD FAILED: failed shell_1

Sincerely,
  -The Buildbot

Re: [DISCUSSION] Defining an OFBiz Project Strategy

2016-11-30 Thread Shi Jinghai

+1 to use repo.maven.apache.org if possible.

-邮件原件-
发件人: Jacopo Cappellato [mailto:jacopo.cappell...@hotwaxsystems.com] 
发送时间: 2016年11月30日 17:54
收件人: dev@ofbiz.apache.org
主题: Re: [DISCUSSION] Defining an OFBiz Project Strategy

On Wed, Nov 30, 2016 at 10:40 AM, Sharan Foga  wrote:

> [...] I wouldn't be happy for the community to have to rely on service 
> providers to provide what should be standard functions / components or 
> plug-ins.
>
> So I would be in favour of something like Jacques is proposing that we 
> have an official project repo for plug-ins.
>

We could look at the feasibility (from an infra and a legal perspective) of 
publishing our plugins to:
http://repo.maven.apache.org/maven2

Jacopo

Re: [DISCUSSION] Improving the OFBiz User Interface

Amazing discussion and initiative.
My only recommendation at the moment is to try to plan very short (in
scope and in time) development cycles (requirements gathering and
discussion, design, implementation, review) so that each cycle could focus
on a specific experiment/proposal (e.g. a given ui technology) and could
deliver a proof of concept to the community (e.g. as a new component) for
further discussion and work.

In this way we will be able to quickly implement and compare different
solutions/technologies and will have a chance to take a more informed
decision.

Jacopo

Re: [DISCUSSION] Defining an OFBiz Project Strategy

On Wed, Nov 30, 2016 at 10:40 AM, Sharan Foga  wrote:

> [...] I wouldn't be happy for the community to have to rely on service
> providers to provide what should be standard functions / components or
> plug-ins.
>
> So I would be in favour of something like Jacques is proposing that we
> have an official project repo for plug-ins.
>

We could look at the feasibility (from an infra and a legal perspective) of
publishing our plugins to:
http://repo.maven.apache.org/maven2

Jacopo

Re: [DISCUSSION] Defining an OFBiz Project Strategy

2016-11-30 Thread Sharan Foga

I've added a comment inline

On 30/11/16 10:27, Jacques Le Roux wrote:

Le 29/11/2016 à 22:12, Nicolas Malin a écrit :

Le 29/11/2016 à 20:21, Olivier Heintz a écrit :

Le 28/11/2016 à 22:43, Taher Alkhateeb a écrit :

>Hi Sharan,
>
>Thank you for starting this important topic. OFBiz definitely needs
>strategic objectives and a sense of direction. To try to formulate a
>strategy, I would suggest perhaps we highlight where I think OFBiz 
delivers
>value and where it does not, and based on that provide a few 
suggestions on

>moving forward.
>
>OFBiz main value proposition
>---
>- A very robust domain model based on the data model resource book.
>- A library of services to control and manipulate the data model.
>- A DSL that hides and abstracts away the complexity of everything 
(services, entities, widgets, routing, etc...)

>and makes it easy for adopters to provide value quickly.

   - A plugin system AND a plugin strong organization

I'm agree to the plugin system but not on plugin strong organization.

Offer good tools to realize some plugin is different that offer a 
plateform to deploy and manage a plugin store
We need to concentrate the effort on the core, have some official 
plugin for example, special case and define best pratice.

We are to few to maintain the ofbiz core so for me manage a plugin 
store is more for integrator company or another dedicate community 
with different rules.

As I suggested elsewhere, as delivered by the community, this could be 
as simple as a Maven repository on our demo server and a wiki page to 
reference plugins. New plugins would be asked to be put in the Maven 
repo by creating Jira issues.
Anyway the 1st step is technical: we need to complete the plugins 
mechanisms to install from a Maven repo not on localhost. I must say I 
did not test the current feature yet nor looked at what enhancing it 
entails...

Jacques

If I remember correctly ,when we asked the question to the community 
regarding addons/plug-ins, the consensus was that they wanted to project 
itself manage official approved plug-ins (so to setup an official 
repository for those) Looking at the discussions we are having now, some 
of our standard components may technically become plug-ins (and we've 
already said that the specialpurpose ones will be). I wouldn't be happy 
for the community to have to rely on service providers to provide what 
should be standard functions / components or plug-ins.

So I would be in favour of something like Jacques is proposing that we 
have an official project repo for plug-ins.

Thanks
Sharan

Cheers,
Nicolas

Re: [DISCUSSION] Defining an OFBiz Project Strategy




Le 29/11/2016 à 22:12, Nicolas Malin a écrit :


Le 29/11/2016 à 20:21, Olivier Heintz a écrit :

Le 28/11/2016 à 22:43, Taher Alkhateeb a écrit :

>Hi Sharan,
>
>Thank you for starting this important topic. OFBiz definitely needs
>strategic objectives and a sense of direction. To try to formulate a
>strategy, I would suggest perhaps we highlight where I think OFBiz delivers
>value and where it does not, and based on that provide a few suggestions on
>moving forward.
>
>OFBiz main value proposition
>---
>- A very robust domain model based on the data model resource book.
>- A library of services to control and manipulate the data model.
>- A DSL that hides and abstracts away the complexity of everything (services, 
entities, widgets, routing, etc...)
>and makes it easy for adopters to provide value quickly.

   - A plugin system AND a plugin strong organization

I'm agree to the plugin system but not on plugin strong organization.

Offer good tools to realize some plugin is different that offer a plateform to 
deploy and manage a plugin store
We need to concentrate the effort on the core, have some official plugin for 
example, special case and define best pratice.

We are to few to maintain the ofbiz core so for me manage a plugin store is more for integrator company or another dedicate community with different 
rules.


As I suggested elsewhere, as delivered by the community, this could be as simple as a Maven repository on our demo server and a wiki page to reference 
plugins. New plugins would be asked to be put in the Maven repo by creating Jira issues.
Anyway the 1st step is technical: we need to complete the plugins mechanisms to install from a Maven repo not on localhost. I must say I did not test 
the current feature yet nor looked at what enhancing it entails...


Jacques



Cheers,
Nicolas

Re: OFBiz security issues


+1 for tags

Tthere are only few OFBIZ-1525 subtasks which are related to a CVE. I can add 
the CVE tags in them and in future we can just create tasks with the CVE tag

Agreed?

Jacques


Le 30/11/2016 à 00:02, Paul Foxworthy a écrit :

Hi all,

Using JIRA is a good idea, and we need to be able to find them. But a
security issue is not a subtask and not a component. I think a tag will
work fine.

Thanks

Paul


On 30 November 2016 at 00:42, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:


Tags or components are fine to me (you can specify more than one component
to each ticket); I agree that a tag may be more appropriate for this use
case. My preference is just to not use subtasks.

Jacopo

On Tue, Nov 29, 2016 at 2:13 PM, Pierre Smits 
wrote:


Well...

CVEs can occur on any component (even though past issues have been

related

for most to framework components. So having a particular component just

for

CVE reference purposes would complicate matters as much as converting

JIRA

issues into sub-tasks.

Applying a tag to the issue (e.g. CVE) and using a persisted filter in

JIRA

would be sufficient to link to from the download page (and elsewhere e.g.
the 'keeping OFBiz secure' cwiki page.

Best regards,




Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Nov 29, 2016 at 2:04 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:


Rather than using subtasks I think it would be better to use a

component

(named CVE or similar).

Il 29 Nov 2016 1:50 PM, "Jacques Le Roux" <

jacques.le.r...@les7arts.com>

ha
scritto:


Also it would be better if we can group all security issues in Jira.

For

that I created OFBIZ-1525, please if you create Jira security issues

create

(or convert) them as subtasks of OFBIZ-1525

Thanks

Jacques


Le 29/11/2016 à 11:05, Pierre Smits a écrit :


Of course, I implied this policy to be in line with
http://www.apache.org/security/

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Nov 29, 2016 at 10:59 AM, Nicolas Malin <

nicolas.ma...@nereide.fr

wrote:

Yes I agree with Jacopo, when can create the issue only when they

are

corrected

Nicolas



Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit :

We can definitely create one Jira ticket for each CVE number with

all

the

details we want and link them from the "security" section of the

OFBiz

download page.
This was probably implied in Pierre's proposal, but I prefer to
explicitly
state here: these tickets will be created only after the CVE are
publicly
disclosed (i.e. the tickets will be created and resolved at the

same

time).
The good news is that we can create now all the tickets for the

CVE

processed so far in the history of OFBiz, in order to implement

what

Pierre
has proposed here.

Jacopo

On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits <

pierre.sm...@gmail.com>

wrote:

Hi all,


Recently we have seen some security issues fixed in the code base
(CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated

in

identifying, analysing and fixing these OFBiz security threats.

When I look at how we communicate to our adopters that there are
threats
and how they can be mitigated [1] I believe we could and we

should

do a

little bit more. There we merely put a reference to the CVE [2]

issue

(see
[3] for example) there and and advice to upgrade. But on that

page

we

leave
out any particulars on how the issue affected OFBiz and what was

done

to
it. Rightly so as it is just a list of notifications.

The details about the effect of the issue and the mitigation is

in

commits.
But there is no apparent relation between the notification on [1]

and

the
actual commit that mitigated. Also reporting the CVE in JIRA

issues

not

optimal. This leads to the fact that details don't appear in

release

notes
very well.

I believe we could and should do better. We should *always* have

a

JIRA

issue explaining the CVE issue and its effect on the OFBiz

product,

have
it
enhanced with the proper tags or labels (e.g. CVE/Security), and

-

like

any
other JIRA issue - have it showing with which commit(s) it has

been

resolved and on which branch it has been implemented.

With a proper filter definition on JIRA we can then shorten the
vulnerability section in [1] and have that link to that JIRA

filter

definition.

What do you think?

References:

  - [1] http://ofbiz.apache.org/download.html
  - [2] CVE: Common Vulnerability and Exposure
  - [3] http://cve.mitre.org/cgi-bin/

cvename.cgi?name=CVE-2016-6800


Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

Re: [DISCUSSION] Improving the OFBiz User Interface

2016-11-30 Thread Julien NICOLAS


Hi Jacques,


On 30/11/2016 08:51, Jacques Le Roux wrote:

Hi Julien,

Just few questions inline


Le 29/11/2016 à 23:35, Julien NICOLAS a écrit :

Hi Sharan, everyone,

It was idea like seed that start to grow up in my mind since I start 
with OFBiz. Today, after several try on the project I think the 
community is very closed to find the best way to improve the UI.


The first sharing was with Gil and Nicolas, then we decide to submit 
a talk about that. The big surprise was that Taher have the quite 
same ideas than us !!!


There are many things that must be done to have a good UI.

 - All the UI could be managed by the theme without modifying the 
framework.


 - Each screen must be linked to a screen structure.


What would be this screen structure? You don't need to develop much at 
this stage, just that I can't vision what it would be.
This structure is to follow the a UI standard that can be managed by the 
theme. For example, the find screen can be define as :

 - A research field area
 - A result area

If all the find screen could be linked to this structure, it will be 
easier for theme to manage it's own template of search screen.
It will be included in the main decorator that will also linked to a 
structure, so theme can manage to change the template. And when you 
change the theme, it could be a completely different look and feel :)

I hope I explain well my thought.




 - We need a UI standard that the developer need to follow for screen 
creation.


 - We must have a common theme (remove all theming stuff from the 
framework)


 - It could be interesting to have a new component to improve / test 
a new theme


 - We have to create at least a new theme without limits ! Be crazy !

It's a long term project, but it must be our concern, all the people 
that want a beautiful and UX UI must be involved \o/ I remember when 
I start bootstrap topics, that we were many ;)


This project is more ambitious, a long term one that will improve the 
theming automatism to provide to the webdesigner an unlimited tool 
and, in the same time, an easy to maintain framework for us ;)



Why we need a new component to test new theme ?

When I start working with OFBiz, I was so surprised that the UI is 
too heavy. Then I was thinking that I have to improve the UI to 
provide a best one. After several try I understand that the actual UI 
is not a final user interface. It is a developer one. It's a 
developer UI because it contain all the features developed. But 
definitively, we can't provide this kind of UI to final users, we 
have to simplify it. In the same times, we can't delete the current 
UI because developers need to improve it with new features that will 
help us to deploy new features to our final users.


For this new component, we can implement an existing component but 
simplified and ready for the new theme(s).


You mean we could take and existing component, say example for 
instance, and would simply it at the UI level. I picked example 
because it's already rather simple and contains demonstration of 
features.
No, I mean to define a component (party, product, facility, etc.) that 
we start to re-implement (using the existing services) but in a more 
simple way (without all the features, selecting only the main ones).




In conclusion, if the new component dedicated for test a new theme 
match to the community needs, Taher think to a super simplified 
developer user interface that facilitate developers to improve the 
software. A new interface without any constraint that allow 
developers to develop easily new features.




Another thing I can't vision at this stage, no hurry, I guess I'll 
later :)
Yes, too many thing to explain, I have to add details about this point, 
I'll do it soon ^^


All the rest is OK with me, or at least I think I did grab the ideas

Thanks!

Jacques



What about the new theme ?

A new theme, maybe more than one theme. It could be crazy but if we 
need to be sure that we can do anything we want and that the screen 
structure allow webdesigner to do whatever we want, we can imagine 2 
new themes exactly different in structure :)


I have at least an idea, just for the look and feel. I can share it 
and we can improve it all together (or just scrap it and start with a 
new idea ^^). In the same times, at the Apache Con we meet Victoria 
Bondarchuk 
 
(work in UX project management) that want to help us in this task, 
and Darshan Kumar (work also in UX) who want to join the OFBiz 
project starting on that task.



How to start ?

I propose to start by creating a main Jira about Improve the UI 
(maybe this one already exist since a long long time ago ^^) and then 
link all the subtasks to this main one. Maybe we can start a topic by 
subtask to share with the community.



Before creating anything it could be interesting to have opinion of 
all people who want UI changes. All the community I

Re: svn commit: r1771995 - /ofbiz/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/jdbc/DatabaseUtil.java

2016-11-30 Thread Nicolas Malin


Hello Paul

Le 30/11/2016 à 07:42, paulfoxwor...@apache.org a écrit :

@@ -1014,7 +1014,8 @@ public class DatabaseUtil {
  // NOTE: this may need a toUpperCase in some cases, keep 
an eye on it, okay for now just do a compare with equalsIgnoreCase
  String tableType = tableSet.getString("TABLE_TYPE");
  // only allow certain table types
-if (tableType != null && !"TABLE".equalsIgnoreCase(tableType) && 
!"VIEW".equalsIgnoreCase(tableType) && !"ALIAS".equalsIgnoreCase(tableType) && 
!"SYNONYM".equalsIgnoreCase(tableType)) {
+if (tableType != null && !"TABLE".equalsIgnoreCase(tableType) && 
!"VIEW".equalsIgnoreCase(tableType)
+&& !"ALIAS".equalsIgnoreCase(tableType) && 
!"SYNONYM".equalsIgnoreCase(tableType) && !"BASE TABLE".equalsIgnoreCase(tableType)) {
  continue;
  }
  


Maybe we can change the if condition by something like that :

if (tableType != null && 
Arrays.asList(types).contains(tableType.toUpperCase()))


Nicolas

[ANNOUNCE] Plugin components for OFBiz and OFBizBase