Okay, the moving around is done and so is a first pass of this more
generic email settings entity and a service to send email using it.
-David
On Feb 15, 2009, at 11:22 AM, David E Jones wrote:
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
