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 >> > >
