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
