MyPortal - ProductStore

[Bruno Busco]

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

[hans_bakker]

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

[David E Jones-3]

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
>

[Bruno Busco]

David,
its great to hear what you are going to do.
Thank you.
Bruno

2009/2/15 David E Jones <[hidden email]>:

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

[Jacques Le Roux]

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" <[hidden email]>

> David,
> its great to hear what you are going to do.
> Thank you.
> Bruno
>
> 2009/2/15 David E Jones <[hidden email]>:
>>
>> 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
>>>
>>
>>
>

[David E Jones-3]

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