Yes I agree too. As I said in
https://issues.apache.org/jira/browse/OFBIZ-2172?focusedCommentId=12673674#action_12673674
<<ProductStore is bloated and some slimming can't hurt. >>
But David explained that much more better than me ;o)
Jacques
From: "Bruno Busco" <[email protected]>
David,
its great to hear what you are going to do.
Thank you.
Bruno
2009/2/15 David E Jones <[email protected]>:
I agree this is not a good pattern to follow as it's a hack and waters down
the definition of a ProductStore. Such things typically lead to more and
more hacks until there are big problems that require lots of effort to
resolve. Yes, I know that is a generality, but IMO this is a principle that
when violated brings a lot more pain than following it even if it seems like
it will require more effort. In this case I don't think it will require much
more effort, or I should say wouldn't have before you put the effort into
this direction, now it is duplicate effort.
You don't have to go through ProductStore to send a notification email. All
you're getting from it is the use of the ProductStoreEmailSetting entity.
That entity has 9 fields (including the productStoreId), and if something
more generic is needed (which I think has been discussed before) then we
should create something more generic. Otherwise over time we'll have to call
more and more things a "ProductStore", and what it means to be a
ProductStore (with 95% of the settings not used) will be difficult to define
and confusing to use.
Even more important than this case is that we all understand and follow this
principle. It is well worth the effort to keep such things well defined and
as clean and literal as possible, because of all the issues that come up in
large systems the biggest ones are those that cause confusion and make it
difficult to apply business requirements to the software. Things like this
that aren't as literal (ie named using terms that are clear and applicable)
and clean as possible end up costing a lot of time and money later on. To
put things in perspective, code that has bugs but is well designed is cheap
and easy to fix compare to code that is poorly designed and needs to be
redesigned and rewritten before it is useful. It also seems that with
community driven open source like OFBiz there are plenty who are willing to
contribute fixes and small enhancements to good designs, but if people end
up designing and building their own solution very few in the community will
contribute it, so we end up with a bunch of variations out in "the wild" and
the feature in OFBiz stagnates for the most part once the original
contributor loses interest in it or need of it.
Sorry for the digression, getting back to the point.... This is somewhat
related to the framework independence effort. One thing that has bugged me
for a while is that the email services are in the content component which is
in applications. I'm moving those services to the framework/common
component, and adding a new service called "EmailTemplateSetting" and a
service to go with it to send emails based on these template settings so
that creating email templates (screen-based) and sending email from them
will be easier going forward.
I'll try to get this in soon, and maybe it will be an easier and cleaner way
to send the MyPortal emails without depending on the ProductStore (which
will help a lot when we start moving MyPortal into the framework).
BTW, this will also help with the forgot password email and similar security
and other things which we have started moving into the framework and using
more consistently in the apps.
-David
On Feb 15, 2009, at 2:46 AM, Hans Bakker wrote:
we need to have the productstore in myportal to be able to store
notification email messages.....
On Sun, 2009-02-15 at 10:19 +0100, Bruno Busco wrote:
Hi,
if you go to https://localhost:8443/catalog/control/FindProductStore
MyPortal is listed as a ProductStore.
I think this is an error.
Thank you,
Bruno
--
Antwebsystems.com: Quality OFBiz services for competitive prices
