I forgot to reply :), after sharing with my coworkers, It's would b
interesting for us to works on this parts.
So I will start a POC just to see if we go on a good way.
Nicolas
On 25/08/2018 13:35, Nicolas Malin wrote:
On 24/08/2018 09:16, Taher Alkhateeb wrote:
Furthermore, I'm not sure we
On 24/08/2018 09:16, Taher Alkhateeb wrote:
Furthermore, I'm not sure we need another superman initiative in the widget
system? The price to pay for this does not seem to be worth the added
value, I would hardly call it a value but maybe I'm wrong?
I'm the feeling that it's not a mountain (less
I have just reviewed the links again, and the example provided by Jacques
is to access the ecommerce product page from the product component as a
menu item.
Honestly, I think for this example it should simply be deleted. It serves
no substantial value to me:
- I most likely will not use the
Hi Nicolas,
With your proposal, I'm afraid that we can't simply add a new menu in an
application from a plugin. Maybe it's another subject but it could be
interesting to manage it in the same times.
Technically I understand your proposal but it's difficult for me to
understand the impact ^^
Not sure why my 1st post didn't get through. So reposting again..
Hi all,
Good discussion so far.
I am in favour of having a proper solution from start rather than a stopgap.
Propose something similar to what Nicolas mentioned but making use of a
fragment-type plugin framework like
Hello
This thread about a "simple" problem highlights the difficulty for a
plugin to extend the framework on different elements. Since many years I
search different solution to how surcharge correctly the framework and
it was not easy :)
in line
On 22/08/2018 18:52, Taher Alkhateeb wrote:
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
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
Hi Michael,
My proposition is to replace old by framework only, not to remove
framework+plugins.
Jacques
Le 21/08/2018 à 08:54, Michael Brohl a écrit :
Hi Jacques,
for my comments on
https://issues.apache.org/jira/projects/OFBIZ/issues/OFBIZ-9241 see Jira.
For the proposal, I think we
Hi Michael,
OK, no problems
Jacques
Le 22/08/2018 à 15:51, Michael Brohl a écrit :
Jacques,
just 2 days are not much for discussion in an open source community. Please have in mind that people might not have the time to think about and
answer to the discussion in such a short timeframe.
Jacques,
just 2 days are not much for discussion in an open source community.
Please have in mind that people might not have the time to think about
and answer to the discussion in such a short timeframe. Most of us are
working full time.
I see no need to hurry and propose to put down the
Thanks Julien,
At this stage, after 2 days, we already have diverse answers and it's hard to
see a clear answer/consensus from that.
So after this [PROPOSITION] I'll start 2 [VOTE]s, for:
1. Demos: replace old by trunk framework only?
2. Hide, remove or let as is UI links in framework
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
Le 21/08/2018 à 11:10, Gil Portenseigne a écrit :
I've not analysed the issue in details, but an in-middle solution should
be to remove the problematic links from trunk,
That's what I thought initially, and created OFBIZ-9241 for that. Then I thought we could simply hide them when the ecommerce
I've not analysed the issue in details, but an in-middle solution should
be to remove the problematic links from trunk, and fill a new Jira for
implementing it in the better way :).
Gil
Le mardi 21 août 2018 à 10:10:03 (+0200), Jacques Le Roux a écrit :
> OK, that your and Michael's opinions. So
I did not say I prefer NPEs, don't put words in my mouth.
On Tue, Aug 21, 2018, 11:09 AM Jacques Le Roux
wrote:
> 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
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
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
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 ;)
>
>
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
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
Hi Jacques,
for my comments on
https://issues.apache.org/jira/projects/OFBIZ/issues/OFBIZ-9241 see Jira.
For the proposal, I think we should provide the demo with the framwork +
plugins. It shows the portential of the whole ecosystem and I see no
reason why we should not make it available?
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
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
wrote:
> Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :
> > Makes sense. However, i note reading in the JIRA that
I agree. +1
On 20/08/2018 19:01, Jacques Le Roux 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
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
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.
Anyway, I think it is a reasonable step to take. +1
On Mon, Aug 20, 2018, 5:31 PM Jacques Le
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
27 matches
Mail list logo
