Dev - CommEventOrder, CommEventProduct, and CommEventContentAssoc
Locked
 
|
Al,
I saw your commits r 7089 and r 7090. What are the purposes of CommEventOrder and CommEventProduct? When are they to be used? Is CommEventContentAssoc for associating attachments to a CommEvent? Si _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
|
|
Si Chen wrote:
>Al, > >I saw your commits r 7089 and r 7090. What are the purposes of >CommEventOrder and CommEventProduct? When are they to be used? > > Si, I have a contract in which the client wants to be able to associate comm events with Orders and Products - David's advice about associating them with CustRequest notwithstanding. I realize that one client's needs do not necessarily make for a valid reason for including in the project, but I tried to get feedback without a definitive yes or no. I put them in with the reasoning that there are many entities and services in OFBiz that are not used that much, but the fact that they are there just means that some others who would also like to use them won't have to duplicate them. I have no strong feelings about this - I just felt that it was a shame to exclude functionality that may be of use to someone. I realize that this could lead to excess bloat and would be glad to move them if the concensus is that they should not be there. >Is CommEventContentAssoc for associating attachments to a CommEvent? > > Yes it is. Do you have any thoughts on that. Unlike the above entities, I don't think that there is much question about the need for this entity, though its composition may require some tweaking. I appreciate the review. -Al >Si > > >_______________________________________________ >Dev mailing list >[hidden email] >http://lists.ofbiz.org/mailman/listinfo/dev > > > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
|
|
Let's see what David says about CommEventOrder and CommEventProduct. I do have some more questions about CommEventContentAssoc: 1. How should we store the type of Content? Should we use Content.mimeTypeId to store if it is a PDF, JPG, DOC, etc.? What about what kind of an association it is? Do we only assume that the association is an attachment, or could there be other associations which require a separate Type field? 2. How do we create, say, a JPG attachment to a CommunicationEvent? Should we create a DataResource and store the JPG into it, then associate the DataResource with a Content, and the Content with a CommEventContentAssoc? How would we retrieve the information? (Sorry, I guess this reflects my general lack of knowledge with the content manager.) Si Al Byers wrote: Si Chen wrote: _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
|
|
Si Chen wrote:
> Al, > > Let's see what David says about CommEventOrder and CommEventProduct. > I do have some more questions about CommEventContentAssoc: > > 1. How should we store the type of Content? Should we use > Content.mimeTypeId to store if it is a PDF, JPG, DOC, etc.? What > about what kind of an association it is? Do we only assume that the > association is an attachment, or could there be other associations > which require a separate Type field? The mime type of the content is actually contained in the DataResource.mimeTypeId field. I am not terribly clear on how the Content.mimeTypeId field should be used, except to show a need for a conversion from its DataResource type to a Content display mime type. I had a contentAssocTypeId field in CommEventContentAssoc at one time, but then decided, per David's advice, to take out everything for which I could not see an immediate use. If it turns out that there is a need for more than one sort of association, we can put it back. > > 2. How do we create, say, a JPG attachment to a CommunicationEvent? > Should we create a DataResource and store the JPG into it, then > associate the DataResource with a Content, and the Content with a > CommEventContentAssoc? How would we retrieve the information? There is a service, persistContentAndAssoc that consolidates all the activities for working with Content, DataResource, ElectronicText, etc. Last night, I committed services for working with CommEventContentAssoc (create/updateCommEventContentAssoc) and some UI under partymgr->Communication->Content for adding content to CommunicationEvent entities. Not quite finished with it, but it should give you some ideas on how to do all this. These services will be used in attaching content to comm events that come from auto-processed emails - which I hope to get to today. The client wants this documented, so things should be clearer after this week. -Al > > (Sorry, I guess this reflects my general lack of knowledge with the > content manager.) > > Si > > Al Byers wrote: > >>Si Chen wrote: >> >> >> >>>Al, >>> >>>I saw your commits r 7089 and r 7090. What are the purposes of >>>CommEventOrder and CommEventProduct? When are they to be used? >>> >>> >>> >>> >>Si, >> >>I have a contract in which the client wants to be able to associate comm >>events with Orders and Products - David's advice about associating them >>with CustRequest notwithstanding. I realize that one client's needs do >>not necessarily make for a valid reason for including in the project, >>but I tried to get feedback without a definitive yes or no. I put them >>in with the reasoning that there are many entities and services in OFBiz >>that are not used that much, but the fact that they are there just means >>that some others who would also like to use them won't have to duplicate >>them. I have no strong feelings about this - I just felt that it was a >>shame to exclude functionality that may be of use to someone. I realize >>that this could lead to excess bloat and would be glad to move them if >>the concensus is that they should not be there. >> >> >> >>>Is CommEventContentAssoc for associating attachments to a CommEvent? >>> >>> >>> >>> >>Yes it is. Do you have any thoughts on that. Unlike the above entities, >>I don't think that there is much question about the need for this >>entity, though its composition may require some tweaking. >> >>I appreciate the review. >> >>-Al >> >> >> >>>Si >>> >>> >>>_______________________________________________ >>>Dev mailing list >>>[hidden email] >>>http://lists.ofbiz.org/mailman/listinfo/dev >>> >>> >>> >>> >>> >> >> >>_______________________________________________ >>Dev mailing list >>[hidden email] >>http://lists.ofbiz.org/mailman/listinfo/dev >> >> >> >> >------------------------------------------------------------------------ > > >_______________________________________________ >Dev mailing list >[hidden email] >http://lists.ofbiz.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - CommEventOrder, CommEventProduct, and CommEventContentAssoc
|
|
First thanks AL. I generally agree with the concept, and Hope to add my
contribution to the Jira. some thoughts on the actual storage of the mime data. Like to keep it in a none object format like the base64 (BLOB), then let the particular mime service create the object when it is to be rendered. Al Byers sent the following on 3/29/06 7:51 AM: > Si Chen wrote: > > >>Al, >> >>Let's see what David says about CommEventOrder and CommEventProduct. >>I do have some more questions about CommEventContentAssoc: >> >>1. How should we store the type of Content? Should we use >>Content.mimeTypeId to store if it is a PDF, JPG, DOC, etc.? What >>about what kind of an association it is? Do we only assume that the >>association is an attachment, or could there be other associations >>which require a separate Type field? > > > The mime type of the content is actually contained in the > DataResource.mimeTypeId field. I am not terribly clear on how the > Content.mimeTypeId field should be used, except to show a need for a > conversion from its DataResource type to a Content display mime type. > > I had a contentAssocTypeId field in CommEventContentAssoc at one time, > but then decided, per David's advice, to take out everything for which I > could not see an immediate use. If it turns out that there is a need for > more than one sort of association, we can put it back. > > >>2. How do we create, say, a JPG attachment to a CommunicationEvent? >>Should we create a DataResource and store the JPG into it, then >>associate the DataResource with a Content, and the Content with a >>CommEventContentAssoc? How would we retrieve the information? > > > There is a service, persistContentAndAssoc that consolidates all the > activities for working with Content, DataResource, ElectronicText, etc. > Last night, I committed services for working with CommEventContentAssoc > (create/updateCommEventContentAssoc) and some UI under > partymgr->Communication->Content for adding content to > CommunicationEvent entities. Not quite finished with it, but it should > give you some ideas on how to do all this. > > These services will be used in attaching content to comm events that > come from auto-processed emails - which I hope to get to today. The > client wants this documented, so things should be clearer after this week. > > -Al > > >>(Sorry, I guess this reflects my general lack of knowledge with the >>content manager.) >> >>Si >> >>Al Byers wrote: >> >> >>>Si Chen wrote: >>> >>> >>> >>> >>>>Al, >>>> >>>>I saw your commits r 7089 and r 7090. What are the purposes of >>>>CommEventOrder and CommEventProduct? When are they to be used? >>>> >>>> >>>> >>>> >>> >>>Si, >>> >>>I have a contract in which the client wants to be able to associate comm >>>events with Orders and Products - David's advice about associating them >>>with CustRequest notwithstanding. I realize that one client's needs do >>>not necessarily make for a valid reason for including in the project, >>>but I tried to get feedback without a definitive yes or no. I put them >>>in with the reasoning that there are many entities and services in OFBiz >>>that are not used that much, but the fact that they are there just means >>>that some others who would also like to use them won't have to duplicate >>>them. I have no strong feelings about this - I just felt that it was a >>>shame to exclude functionality that may be of use to someone. I realize >>>that this could lead to excess bloat and would be glad to move them if >>>the concensus is that they should not be there. >>> >>> >>> >>> >>>>Is CommEventContentAssoc for associating attachments to a CommEvent? >>>> >>>> >>>> >>>> >>> >>>Yes it is. Do you have any thoughts on that. Unlike the above entities, >>>I don't think that there is much question about the need for this >>>entity, though its composition may require some tweaking. >>> >>>I appreciate the review. >>> >>>-Al >>> >>> >>> >>> >>>>Si >>>> >>>> >>>>_______________________________________________ >>>>Dev mailing list >>>>[hidden email] >>>>http://lists.ofbiz.org/mailman/listinfo/dev >>>> >>>> >>>> >>>> >>>> >>> >>> >>>_______________________________________________ >>>Dev mailing list >>>[hidden email] >>>http://lists.ofbiz.org/mailman/listinfo/dev >>> >>> >>> >>> >> >>------------------------------------------------------------------------ >> >> >>_______________________________________________ >>Dev mailing list >>[hidden email] >>http://lists.ofbiz.org/mailman/listinfo/dev >> > > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - CommEventOrder, CommEventProduct, and CommEventContentAssoc
|
|
In reply to this post by byersa
Just a quick note: my comment on simplification was mainly a response to the initial approach of starting with the ContentAssoc entity and adapting it for this purpose. Having a type in this case I think makes good sense. Any time you can list out a number of different types of content when looking at the concept in general it is probably a good idea. In this case I don't think the type field needs to be part of the primary key, unless someone can think of a scenario where a single Content record would be associated with a single CommunicationEvent with more than one type. Some types I can imagine for this might be: For email CommEvents: - attachment - message in plain text - message in HTML For others (face to face, fax, phone, paper mail, etc): - document sent from customer - document sent to customer ...and so on. -David Al Byers wrote: > Si Chen wrote: > >> Al, >> >> Let's see what David says about CommEventOrder and CommEventProduct. >> I do have some more questions about CommEventContentAssoc: >> >> 1. How should we store the type of Content? Should we use >> Content.mimeTypeId to store if it is a PDF, JPG, DOC, etc.? What >> about what kind of an association it is? Do we only assume that the >> association is an attachment, or could there be other associations >> which require a separate Type field? > > The mime type of the content is actually contained in the > DataResource.mimeTypeId field. I am not terribly clear on how the > Content.mimeTypeId field should be used, except to show a need for a > conversion from its DataResource type to a Content display mime type. > > I had a contentAssocTypeId field in CommEventContentAssoc at one time, > but then decided, per David's advice, to take out everything for which I > could not see an immediate use. If it turns out that there is a need for > more than one sort of association, we can put it back. > >> 2. How do we create, say, a JPG attachment to a CommunicationEvent? >> Should we create a DataResource and store the JPG into it, then >> associate the DataResource with a Content, and the Content with a >> CommEventContentAssoc? How would we retrieve the information? > > There is a service, persistContentAndAssoc that consolidates all the > activities for working with Content, DataResource, ElectronicText, etc. > Last night, I committed services for working with CommEventContentAssoc > (create/updateCommEventContentAssoc) and some UI under > partymgr->Communication->Content for adding content to > CommunicationEvent entities. Not quite finished with it, but it should > give you some ideas on how to do all this. > > These services will be used in attaching content to comm events that > come from auto-processed emails - which I hope to get to today. The > client wants this documented, so things should be clearer after this week. > > -Al > >> (Sorry, I guess this reflects my general lack of knowledge with the >> content manager.) >> >> Si >> >> Al Byers wrote: >> >>> Si Chen wrote: >>> >>> >>> >>>> Al, >>>> >>>> I saw your commits r 7089 and r 7090. What are the purposes of >>>> CommEventOrder and CommEventProduct? When are they to be used? >>>> >>>> >>>> >>>> >>> Si, >>> >>> I have a contract in which the client wants to be able to associate comm >>> events with Orders and Products - David's advice about associating them >>> with CustRequest notwithstanding. I realize that one client's needs do >>> not necessarily make for a valid reason for including in the project, >>> but I tried to get feedback without a definitive yes or no. I put them >>> in with the reasoning that there are many entities and services in OFBiz >>> that are not used that much, but the fact that they are there just means >>> that some others who would also like to use them won't have to duplicate >>> them. I have no strong feelings about this - I just felt that it was a >>> shame to exclude functionality that may be of use to someone. I realize >>> that this could lead to excess bloat and would be glad to move them if >>> the concensus is that they should not be there. >>> >>> >>> >>>> Is CommEventContentAssoc for associating attachments to a CommEvent? >>>> >>>> >>>> >>>> >>> Yes it is. Do you have any thoughts on that. Unlike the above entities, >>> I don't think that there is much question about the need for this >>> entity, though its composition may require some tweaking. >>> >>> I appreciate the review. >>> >>> -Al >>> >>> >>> >>>> Si >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [hidden email] >>>> http://lists.ofbiz.org/mailman/listinfo/dev >>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [hidden email] >>> http://lists.ofbiz.org/mailman/listinfo/dev >>> >>> >>> >>> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> Dev mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/dev >> > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |