You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Bruno Busco <br...@gmail.com> on 2009/02/15 10:19:30 UTC
MyPortal - ProductStore
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
Re: MyPortal - ProductStore
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <br...@gmail.com>
> David,
> its great to hear what you are going to do.
> Thank you.
> Bruno
>
> 2009/2/15 David E Jones <da...@hotwaxmedia.com>:
>>
>> 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
>>>
>>
>>
>
Re: MyPortal - ProductStore
Posted by Bruno Busco <br...@gmail.com>.
David,
its great to hear what you are going to do.
Thank you.
Bruno
2009/2/15 David E Jones <da...@hotwaxmedia.com>:
>
> 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
>>
>
>
Re: MyPortal - ProductStore
Posted by David E Jones <da...@hotwaxmedia.com>.
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
>>
>
Re: MyPortal - ProductStore
Posted by David E Jones <da...@hotwaxmedia.com>.
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
>
Re: MyPortal - ProductStore
Posted by Hans Bakker <ma...@antwebsystems.com>.
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