The old joke:
Why is it more important for women to be beautiful than smart?
Because men see better than they think!
If you need any help, let me know.
Ron
On 24/11/2015 10:37 AM, Jacques Le Roux wrote:
We know you like visual graphics ;) And it's a good idea!
Jacques
Le 24/11/2015 15:40, Ron Wheeler a écrit :
Would it be possible create a graphic in the docs identifying what
overrides what as you find this out?
A description would be great but at least a visual summary would help
the next person.
Ron
On 24/11/2015 8:31 AM, Jacques Le Roux wrote:
Yes I see, as suggested by Nicolas. But it seems not obvious for a
non technical person, and they are often those who assess the
product by simply running the fasted and easiest ways (I do that
also with other software, who don't? ;))
Like "Start" section at http://ofbiz.apache.org/download.html and
others alike in wiki. Unfortunately you can only make 1 1st
impression. Of course, we possibly could give them an UI for that
but we should at least change (all) our documentation.
And even if we agree on this, the main part of the work remains:
some components should not be "commented out".
1. AFAIK example and exampleext does not override anything and they
are useful (at least to me), notably in official demo.
2. Obviously, as it was in R13.07, ecommerce. But not sure the
ecommerce component does not override applications...
3. The POS is not concerned: not used in official demos, does not
override anything.
4. I wonder about the WepPos, does it overrides something, I don't
think so but not sure
5. Several persons spoke about the project manager, not sure it
overrides applications.
So the 1st step should be to clearly identify which components are
concerned.
Jacopo said <<the default demo of OFBiz will only showcase the more
specialized behaviors>> We could have all released demos not using
some specialpurpose components but trunk with all? It's bleeding
edge after all.
Jacques
Le 21/11/2015 13:07, slidingfilame...@gmail.com a écrit :
Hi Jacques,
what about a parameter using -D for the build script. we can also
do something programmatic in the ./tools directory.
Regards,
--
Taher Alkhateeb
On Nov 21, 2015, at 12:53 PM, Jacques Le
Roux<jacques.le.r...@les7arts.com> wrote:
I'd veto something which would blindly applies to all
specialpurpose components, see my last post about that
Jacques
Le 21/11/2015 09:22, Jacopo Cappellato a écrit :
Taher,
I like your proposal; in fact this feature would be useful not
only for
automated deployments/tests but also to end users to easily
enable the
components they like.
Jacopo
On Sat, Nov 21, 2015 at 8:53 AM,<slidingfilame...@gmail.com>
wrote:
Hi Jacopo,
I would make a distinction between two things: a) preserve what
exists and
b) prepare for the future.
Doubtless what you are saying below makes perfect sense as a design
decision to allow for better future developments. I am concerned
however
with what currently exists in specialpurpose. Specifically, I
worry about
unit tests and Java Source code for framework integration.
Changes we make
to the framework now needs to be followed up closely and we need to
manually enable, test and re-disable the specialpurpose
components to
ensure continuous compatibility with trunk. Can we at least have a
modification in build.xml to enable / disable specialpurpose so
that the
buildbot would continually test against specialpurpose?
If you agree then I can try to write something to that effect in
build.xml
at least to keep the code live in specialpurpose.
Regards,
--
Taher Alkhateeb
On Nov 19, 2015, at 4:36 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:
I was actually thinking to Birt as an example of this behavior:
but in
the
future we may add other special purpose applications that need to
override
applications screens (in fact overriding screens and other
artifacts to
specialize them is a best practice in OFBiz) and the problem
will happen
again if we keep them all enabled.
Jacopo
On Thu, Nov 19, 2015 at 11:45 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Could we list, apart the well known Birt issue, special
components which
are overriding main applications?
Then depending on cases we could be more surgical...
Jacques
Le 19/11/2015 09:46, Jacopo Cappellato a écrit :
I agree with Taher when he says that we should strive to move
small
steps
in the direction of having a lean lightweight framework with
pluggable
components.
But I think that Nicolas' proposal is actually one of these
steps.
The fact that currently some of our specialized components are
overriding
the more generic behavior of other components (e.g. the ones
under
"applications") is a problem that we have to fix asap.
Otherwise the default demo of OFBiz will only showcase the more
specialized
behaviors; for example, if tomorrow we will add a new special
purpose
component for a niche industry, that will override the
application
screens
with industry specific ones from that day on all OFBiz users
that will
download and run OFBiz will have the impression that OFBiz
was designed
for
one specific industry only.
Nicolas' proposal addresses this issue and still leaves the
ability to
the
interested users to manually enable the components they need.
Jacopo
On Thu, Nov 19, 2015 at 8:22 AM, Taher Alkhateeb <
slidingfilame...@gmail.com
wrote:
Hi Nicolas,
I think If your finger hurts you don't cut it off. The
project has too
many
pages, documentations, email threads and time dedicated to
the special
purpose components. They existed for a long, long time in
the history
of
OFBiz.
Some attempts were made in the past to reduce the size of the
framework
and
release 13.07 is a prime example of these attempts which
failed IMHO.
This
is a reason why, for example, a rewrite of the framework is
being
discussed
in the community.
I would suggest to you that to get really lean and clean, we
need to
work
on the root of the problem which is the design of the
framework and
its
architecture. We need a _plugin_ implementation that
achieves _loose
coupling_ of the components in a way that sustains the
quality of the
code
while at the same time allowing a small framework core to
thrive.
Take a
look at this thread <
http://ofbiz.markmail.org/thread/7bipnq3ffoteliff>
in
which we discussed this issue and suggested one of several
strategies.
There are other threads which I cannot recall at the moment.
For the record, I totally agree with keeping a small core
and a lean
framework, It's how we get there that I'm worried about and
I would
suggest
to you that we do this in a well thought out and gradual
process.
My 2 cents
Taher Alkhateeb
On Wed, Nov 18, 2015 at 11:22 PM, Nicolas Malin <
nicolas.ma...@nereide.fr>
wrote:
Le 10/11/2015 05:54,slidingfilame...@gmail.com a écrit :
This topic was heavily discussed in the past and I think a
solution
like
turning off the components is very quick indeed but not
ideal.
Completely, I'm sure a better ideal exist but difficult to
reach.
A second step, easy to reach would be enable a specialpurpose
directly
by
an ant target :
$ ant load-component -D"component=ecommerce" load-demo start
or
$ ant load-component -D"components=ecommerce projectmgr
myportal"
load-demo start
This help beginner through easy command line to copy/past from
documentation or expert by scripting to configure ofbiz.
Nicolas
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102