Hi Taher, Julien
I'm all for and looking forward for a generic solution.
I still believe (like Julien) it's better to hide, than remove or ignore, those
links in the meantime. They are there for already too long...
Jacques
Le 22/08/2018 à 18:52, Taher Alkhateeb a écrit :
Hi Julien,
Good ideas, and this is a good start to try and tackle the problem.
Whatever we do, we must not keep "ghosts" or things that are waiting
for specific outside plugins. The framework should _never_ know
anything about the outside. This is a fundamental architectural
concept in any layered software system.
I'm ready to help if needed, and I think there are many ways to fix
this problem. As you said one way is to extend webapps, another is
perhaps to optionally include freemarker templates that match a
certain pattern if they exist. In other words, you provide a generic
plugin-like mechanism for enhancing the system, but the direction is
_always_ from the outside to the inside, and not the other way around.
And that is what I mean with a root-cause analysis and solutions.
So I'm all for a generic solution, but not for hard-wiring any
component or any link that is specific to a certain component. That is
definitely a code smell and beats the entire purpose of splitting the
repositories in the first place.
On Wed, Aug 22, 2018 at 11:13 AM Julien NICOLAS
<[email protected]> wrote:
Hi all,
My opinion is to hide the link instead of delete it. I don't know if we
have other link in this case but it could be important to keep it in
source code. It could be convenient to have it for replacement by the
good solution
But in the same time, we need to think about inter-webapp connection.
How a menu from webapp A could be extended by webapp B without putting
code in webapp A.
It could be interesting to have a new tool bar in product to manage
ecommerce when ecommerce is installed. If we have this kind of feature,
it could work as well for OOTB webapp like product and stock, party and
order, etc.
Julien.
Le 21/08/2018 à 10:10, Jacques Le Roux a écrit :
OK, that your and Michael's opinions. So you prefer NPEs in code than
hiding them when necessary?
What others think?
Jacques
Le 21/08/2018 à 09:45, Taher Alkhateeb a écrit :
Again, hiding is not a solution and is correcting an error with another
error.
-1
On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux
<[email protected]>
wrote:
See my answer in the Jira, we can't tolerate NPEs, they are already
there
for too long
Being smart is cool, being smart and clean is better ;)
Jacques
Le 21/08/2018 à 08:57, Michael Brohl a écrit :
We should neither simply remove those links nor should we have
anything
hard coded.
Let's look for a smarter solution. No need to hurry, better take some
time to implement something sustainable.
Regards,
Michael Brohl
ecomify GmbH
www.ecomify.de
Am 21.08.18 um 07:00 schrieb Jacques Le Roux:
Of course, but I like to be able to get from the backend to the
frontend when it's possible.
I don't see any troubles keeping them once it's handled that way, but
theoretical ones .
Of course if the community prefers to remove them it's far easier and
was what I wanted to do initially before having this idea of hiding
links
Jacques
Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit :
Simple, don't put any logic that points outwards from the framework.
That
is sort of why we split repositories in the first place.
On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux <
[email protected]>
wrote:
Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :
Makes sense. However, i note reading in the JIRA that "we can
simply
hide
the button when the ecommerce component is not present". That
sounds
like
logic that points outwards which is a bad design IMHO.
I could not find a better way yet, I'm all ears for ideas.
Anyway, I think it is a reasonable step to take. +1
I attached a patch for today at OFBIZ-9241
Jacques
On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux <
[email protected]>
wrote:
Hi,
The proposition is in the title.
With the changes I'm introducing with OFBIZ-9241 there will few
differences in UI (and presence of js files) between the
framework
only
and
the
framework+plugins
I must add:
* since the old is often no longer supported and a
release of
it is
always available (today R13) for users. I think removing the old
demo is
maybe
not a big deal.
* I found several cases where people, new to OFBiz,
considered
OFBiz
as
what we call the framework, and were considering the plugins as
optional.
What do you think?
Jacques
