With "help" dependent on content, I believe content should be moved into
the framework. One of the main dependencies in content is from survey to order. One option is to remove survey into it's own dedicated component. Any thoughts on this? The other main dependency is on party. I believe we should move the core party stuff (Party, PartyAttribute, PartyTypeAttr, PartyGroup, PartyType, PartyRole, RoleType) into a partycore component that is part of the framework. Any thoughts on this? Content also has a dependency on Person via WebSiteRole. I'm not sure Person should become part of partycore. However, I'm not sure that Person should be part of WebSiteRole. Any thoughts on this? <entity entity-name="WebSiteRole" package-name="org.ofbiz.party.party" title="WebSite Role Association Entity"> <field name="partyId" type="id-ne"></field> <field name="roleTypeId" type="id-ne"></field> <field name="webSiteId" type="id-ne"></field> <field name="fromDate" type="date-time"></field> <field name="thruDate" type="date-time"></field> <field name="sequenceNum" type="numeric"></field> <prim-key field="partyId"/> <prim-key field="roleTypeId"/> <prim-key field="webSiteId"/> <prim-key field="fromDate"/> <relation type="one-nofk" rel-entity-name="Party"> <key-map field-name="partyId"/> </relation> <relation type="one-nofk" rel-entity-name="RoleType"> <key-map field-name="roleTypeId"/> </relation> <relation type="one-nofk" rel-entity-name="Person"> <key-map field-name="partyId"/> </relation> <relation type="one-nofk" rel-entity-name="PartyGroup"> <key-map field-name="partyId"/> </relation> <relation type="one" fk-name="WSRLE_PTYRLE" rel-entity-name="PartyRole"> <key-map field-name="partyId"/> <key-map field-name="roleTypeId"/> </relation> <relation type="one" fk-name="WSRLE_WSITE" rel-entity-name="WebSite"> <key-map field-name="webSiteId"/> </relation> </entity> Thanks in advance, Chris |
Chris,
thanks for your report: On Feb 24, 2010, at 12:50 PM, Christopher Snow wrote: > With "help" dependent on content, I believe content should be moved into the framework. > IMO the content should be split into two parts: one will go into the framework, the other one ("contentext") will stay in the applications > One of the main dependencies in content is from survey to order. One option is to remove survey into it's own dedicated component. Any thoughts on this? > This could be a good candidate for the "contentext" component I have mentioned before. > The other main dependency is on party. I believe we should move the core party stuff (Party, PartyAttribute, PartyTypeAttr, PartyGroup, PartyType, PartyRole, RoleType) into a partycore component that is part of the framework. Any thoughts on this? > I still think (and hope) that the framework will be able to live without dependencies on Party; we should carefully evaluate the current dependencies and see if we can resolve them. > Content also has a dependency on Person via WebSiteRole. I'm not sure Person should become part of partycore. However, I'm not sure that Person should be part of WebSiteRole. Any thoughts on this? > The dependency on Person should be removed from the data model: this should be a simple task to perform. Kind regards, Jacopo |
Hi Jacopo,
I will try and identify exactly which entities would be required in content, and those required in contentext. In the meantime, would you agree with the following list? Component CONTENT view AssocRevisionItemView view ContentAssocRevisionItemView view MaxRevisionItemView view MaxContentApprovalView view ContentAssocOptViewFrom view ContentRevisionItemAndContentApprovalView entity Content view ContentAndRole entity ContentApproval entity ContentAssoc view ContentAssocDataResourceViewFrom view ContentAssocDataResourceViewTo entity ContentAssocPredicate view ContentAssocViewFrom view ContentAssocViewTo entity ContentAttribute view ContentDataResourceView entity ContentMetaData entity ContentOperation entity ContentPurpose entity ContentPurposeOperation entity ContentPurposeType entity ContentRevision entity ContentRevisionItem entity ContentRole entity ContentType entity ContentTypeAttr view SubContentDataResourceView entity AudioDataResource entity CharacterSet entity DataCategory entity DataResource entity DataResourceAttribute view DataResourceContentView entity DataResourceMetaData entity DataResourcePurpose entity DataResourceRole entity DataResourceType entity DataResourceTypeAttr entity DataTemplateType entity ElectronicText entity FileExtension entity ImageDataResource entity MetaDataPredicate entity MimeType entity MimeTypeHtmlTemplate entity OtherDataResource entity VideoDataResource entity Document entity DocumentAttribute entity DocumentType entity DocumentTypeAttr entity WebPreferenceType entity WebUserPreference extend-entity WebPage entity WebSiteContent view WebSiteAndContent entity WebSiteContentType entity WebSitePathAlias entity WebSitePublishPoint entity WebSiteRole view ContentAssocAndContentPurpose Component CONTENTEXT entity Survey entity SurveyApplType entity SurveyMultiResp entity SurveyMultiRespColumn entity SurveyPage entity SurveyQuestion view SurveyQuestionAndAppl entity SurveyQuestionAppl entity SurveyQuestionCategory entity SurveyQuestionOption entity SurveyQuestionType entity SurveyResponse view SurveyResponseAndAnswer entity SurveyResponseAnswer entity SurveyTrigger Many thanks, Chris Jacopo Cappellato wrote: > Chris, > > thanks for your report: > > On Feb 24, 2010, at 12:50 PM, Christopher Snow wrote: > > >> With "help" dependent on content, I believe content should be moved into the framework. >> >> > > IMO the content should be split into two parts: one will go into the framework, the other one ("contentext") will stay in the applications > > >> One of the main dependencies in content is from survey to order. One option is to remove survey into it's own dedicated component. Any thoughts on this? >> >> > > This could be a good candidate for the "contentext" component I have mentioned before. > > >> The other main dependency is on party. I believe we should move the core party stuff (Party, PartyAttribute, PartyTypeAttr, PartyGroup, PartyType, PartyRole, RoleType) into a partycore component that is part of the framework. Any thoughts on this? >> >> > > I still think (and hope) that the framework will be able to live without dependencies on Party; we should carefully evaluate the current dependencies and see if we can resolve them. > > >> Content also has a dependency on Person via WebSiteRole. I'm not sure Person should become part of partycore. However, I'm not sure that Person should be part of WebSiteRole. Any thoughts on this? >> >> > > The dependency on Person should be removed from the data model: this should be a simple task to perform. > > Kind regards, > > Jacopo > > |
Hi Chris,
first of all I want thank you for the effort spent on this subject. Some time ago I approached this issue in another way: I tryed to build an OFBiz with only the framework, the content and the party applications. Actually what I did was a change to the data model only. I have a patch that changes the data model so that all dependencies in the data model are removed. I moved some entities from an application to another and extended some entity from others. Please note that only the data model has been changed and not the application code. So it is not a working OFBiz but I think it could be good to see what I discovered to be done. I will create a new JIRA and attach the patch. -Bruno 2010/2/24 Christopher Snow <[hidden email]>: > Hi Jacopo, > > I will try and identify exactly which entities would be required in content, > and those required in contentext. In the meantime, would you agree with the > following list? > > Component CONTENT > > view AssocRevisionItemView > view ContentAssocRevisionItemView > view MaxRevisionItemView > view MaxContentApprovalView > view ContentAssocOptViewFrom > view ContentRevisionItemAndContentApprovalView > > entity Content > view ContentAndRole > entity ContentApproval > entity ContentAssoc > view ContentAssocDataResourceViewFrom > view ContentAssocDataResourceViewTo > entity ContentAssocPredicate > view ContentAssocViewFrom > view ContentAssocViewTo > entity ContentAttribute > view ContentDataResourceView > entity ContentMetaData > entity ContentOperation > entity ContentPurpose > entity ContentPurposeOperation > entity ContentPurposeType > entity ContentRevision > entity ContentRevisionItem > entity ContentRole > entity ContentType > entity ContentTypeAttr > view SubContentDataResourceView > > entity AudioDataResource > entity CharacterSet > entity DataCategory > entity DataResource > entity DataResourceAttribute > view DataResourceContentView > entity DataResourceMetaData > entity DataResourcePurpose > entity DataResourceRole > entity DataResourceType > entity DataResourceTypeAttr > entity DataTemplateType > entity ElectronicText > entity FileExtension > entity ImageDataResource > entity MetaDataPredicate > entity MimeType > entity MimeTypeHtmlTemplate > entity OtherDataResource > entity VideoDataResource > > entity Document > entity DocumentAttribute > entity DocumentType > entity DocumentTypeAttr > > entity WebPreferenceType > entity WebUserPreference > > extend-entity WebPage > entity WebSiteContent > view WebSiteAndContent > entity WebSiteContentType > entity WebSitePathAlias > entity WebSitePublishPoint > entity WebSiteRole > view ContentAssocAndContentPurpose > > Component CONTENTEXT > > entity Survey > entity SurveyApplType > entity SurveyMultiResp > entity SurveyMultiRespColumn > entity SurveyPage > entity SurveyQuestion > view SurveyQuestionAndAppl > entity SurveyQuestionAppl > entity SurveyQuestionCategory > entity SurveyQuestionOption > entity SurveyQuestionType > entity SurveyResponse > view SurveyResponseAndAnswer > entity SurveyResponseAnswer > entity SurveyTrigger > > Many thanks, > > Chris > > Jacopo Cappellato wrote: >> >> Chris, >> >> thanks for your report: >> >> On Feb 24, 2010, at 12:50 PM, Christopher Snow wrote: >> >> >>> >>> With "help" dependent on content, I believe content should be moved into >>> the framework. >>> >>> >> >> IMO the content should be split into two parts: one will go into the >> framework, the other one ("contentext") will stay in the applications >> >> >>> >>> One of the main dependencies in content is from survey to order. Â One >>> option is to remove survey into it's own dedicated component. Â Any thoughts >>> on this? >>> >>> >> >> This could be a good candidate for the "contentext" component I have >> mentioned before. >> >> >>> >>> The other main dependency is on party. Â I believe we should move the core >>> party stuff (Party, PartyAttribute, PartyTypeAttr, PartyGroup, PartyType, >>> PartyRole, RoleType) into a partycore component that is part of the >>> framework. Â Any thoughts on this? >>> >>> >> >> I still think (and hope) that the framework will be able to live without >> dependencies on Party; we should carefully evaluate the current dependencies >> and see if we can resolve them. >> >> >>> >>> Content also has a dependency on Person via WebSiteRole. Â I'm not sure >>> Person should become part of partycore. Â However, I'm not sure that Person >>> should be part of WebSiteRole. Â Any thoughts on this? >>> >>> >> >> The dependency on Person should be removed from the data model: this >> should be a simple task to perform. >> >> Kind regards, >> >> Jacopo >> >> > > |
Hi Bruno, that's similar to the approach I followed this morning. I
commented out all the applicants and specialpurpose. I then followed the procedure I documented in the wiki for creaking a stanalone framework based on release 10.04. I then uncommented content and proceded to move all the entity items that content required from party to partycore. These are : >>>> Party, PartyAttribute, PartyTypeAttr, PartyGroup, >>>> PartyType, >>>> PartyRole, RoleType, Person I then commented ou the references to order in the content survey tables and started ofbiz. I was thinking that if we could decide which entities should go in core, we can then figure out what to do with the application code. I know it's unlikely, but it would be great to have the 10.04 available as a standalone framework! Cheers, Chris > Hi Chris, > first of all I want thank you for the effort spent on this subject. > Some time ago I approached this issue in another way: > I tryed to build an OFBiz with only the framework, the content and the > party applications. > Actually what I did was a change to the data model only. > I have a patch that changes the data model so that all dependencies in > the data model are removed. I moved some entities from an application > to another and extended some entity from others. > > Please note that only the data model has been changed and not the > application code. So it is not a working OFBiz but I think it could be > good to see what I discovered to be done. > > I will create a new JIRA and attach the patch. > > -Bruno > > 2010/2/24 Christopher Snow <[hidden email]>: >> Hi Jacopo, >> >> I will try and identify exactly which entities would be required in >> content, >> and those required in contentext. In the meantime, would you agree with >> the >> following list? >> >> Component CONTENT >> >> view AssocRevisionItemView >> view ContentAssocRevisionItemView >> view MaxRevisionItemView >> view MaxContentApprovalView >> view ContentAssocOptViewFrom >> view ContentRevisionItemAndContentApprovalView >> >> entity Content >> view ContentAndRole >> entity ContentApproval >> entity ContentAssoc >> view ContentAssocDataResourceViewFrom >> view ContentAssocDataResourceViewTo >> entity ContentAssocPredicate >> view ContentAssocViewFrom >> view ContentAssocViewTo >> entity ContentAttribute >> view ContentDataResourceView >> entity ContentMetaData >> entity ContentOperation >> entity ContentPurpose >> entity ContentPurposeOperation >> entity ContentPurposeType >> entity ContentRevision >> entity ContentRevisionItem >> entity ContentRole >> entity ContentType >> entity ContentTypeAttr >> view SubContentDataResourceView >> >> entity AudioDataResource >> entity CharacterSet >> entity DataCategory >> entity DataResource >> entity DataResourceAttribute >> view DataResourceContentView >> entity DataResourceMetaData >> entity DataResourcePurpose >> entity DataResourceRole >> entity DataResourceType >> entity DataResourceTypeAttr >> entity DataTemplateType >> entity ElectronicText >> entity FileExtension >> entity ImageDataResource >> entity MetaDataPredicate >> entity MimeType >> entity MimeTypeHtmlTemplate >> entity OtherDataResource >> entity VideoDataResource >> >> entity Document >> entity DocumentAttribute >> entity DocumentType >> entity DocumentTypeAttr >> >> entity WebPreferenceType >> entity WebUserPreference >> >> extend-entity WebPage >> entity WebSiteContent >> view WebSiteAndContent >> entity WebSiteContentType >> entity WebSitePathAlias >> entity WebSitePublishPoint >> entity WebSiteRole >> view ContentAssocAndContentPurpose >> >> Component CONTENTEXT >> >> entity Survey >> entity SurveyApplType >> entity SurveyMultiResp >> entity SurveyMultiRespColumn >> entity SurveyPage >> entity SurveyQuestion >> view SurveyQuestionAndAppl >> entity SurveyQuestionAppl >> entity SurveyQuestionCategory >> entity SurveyQuestionOption >> entity SurveyQuestionType >> entity SurveyResponse >> view SurveyResponseAndAnswer >> entity SurveyResponseAnswer >> entity SurveyTrigger >> >> Many thanks, >> >> Chris >> >> Jacopo Cappellato wrote: >>> >>> Chris, >>> >>> thanks for your report: >>> >>> On Feb 24, 2010, at 12:50 PM, Christopher Snow wrote: >>> >>> >>>> >>>> With "help" dependent on content, I believe content should be moved >>>> into >>>> the framework. >>>> >>>> >>> >>> IMO the content should be split into two parts: one will go into the >>> framework, the other one ("contentext") will stay in the applications >>> >>> >>>> >>>> One of the main dependencies in content is from survey to order. Â One >>>> option is to remove survey into it's own dedicated component. Â Any >>>> thoughts >>>> on this? >>>> >>>> >>> >>> This could be a good candidate for the "contentext" component I have >>> mentioned before. >>> >>> >>>> >>>> The other main dependency is on party. Â I believe we should move the >>>> core >>>> party stuff (Party, PartyAttribute, PartyTypeAttr, PartyGroup, >>>> PartyType, >>>> PartyRole, RoleType) into a partycore component that is part of the >>>> framework. Â Any thoughts on this? >>>> >>>> >>> >>> I still think (and hope) that the framework will be able to live >>> without >>> dependencies on Party; we should carefully evaluate the current >>> dependencies >>> and see if we can resolve them. >>> >>> >>>> >>>> Content also has a dependency on Person via WebSiteRole. Â I'm not sure >>>> Person should become part of partycore. Â However, I'm not sure that >>>> Person >>>> should be part of WebSiteRole. Â Any thoughts on this? >>>> >>>> >>> >>> The dependency on Person should be removed from the data model: this >>> should be a simple task to perform. >>> >>> Kind regards, >>> >>> Jacopo >>> >>> >> >> > -- Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP Tel: 01453 890660 Mob: 07944 880950 Www: www.snowconsulting.co.uk |
In reply to this post by Chris Snow-3
Hi Devs, do any of you have an opinion on what entities would stay in
content if it was migrated to framework, and what entities would move to contentext? My ideas are below... Many thanks, Chris Christopher Snow wrote: > Hi Jacopo, > > I will try and identify exactly which entities would be required in > content, and those required in contentext. In the meantime, would you > agree with the following list? > > Component CONTENT > > view AssocRevisionItemView > view ContentAssocRevisionItemView > view MaxRevisionItemView > view MaxContentApprovalView > view ContentAssocOptViewFrom > view ContentRevisionItemAndContentApprovalView > > entity Content > view ContentAndRole > entity ContentApproval > entity ContentAssoc > view ContentAssocDataResourceViewFrom > view ContentAssocDataResourceViewTo > entity ContentAssocPredicate > view ContentAssocViewFrom > view ContentAssocViewTo > entity ContentAttribute > view ContentDataResourceView > entity ContentMetaData > entity ContentOperation > entity ContentPurpose > entity ContentPurposeOperation > entity ContentPurposeType > entity ContentRevision > entity ContentRevisionItem > entity ContentRole > entity ContentType > entity ContentTypeAttr > view SubContentDataResourceView > > entity AudioDataResource > entity CharacterSet > entity DataCategory > entity DataResource > entity DataResourceAttribute > view DataResourceContentView > entity DataResourceMetaData > entity DataResourcePurpose > entity DataResourceRole > entity DataResourceType > entity DataResourceTypeAttr > entity DataTemplateType > entity ElectronicText > entity FileExtension > entity ImageDataResource > entity MetaDataPredicate > entity MimeType > entity MimeTypeHtmlTemplate > entity OtherDataResource > entity VideoDataResource > > entity Document > entity DocumentAttribute > entity DocumentType > entity DocumentTypeAttr > > entity WebPreferenceType > entity WebUserPreference > > extend-entity WebPage > entity WebSiteContent > view WebSiteAndContent > entity WebSiteContentType > entity WebSitePathAlias > entity WebSitePublishPoint > entity WebSiteRole > view ContentAssocAndContentPurpose > > Component CONTENTEXT > > entity Survey > entity SurveyApplType > entity SurveyMultiResp > entity SurveyMultiRespColumn > entity SurveyPage > entity SurveyQuestion > view SurveyQuestionAndAppl > entity SurveyQuestionAppl > entity SurveyQuestionCategory > entity SurveyQuestionOption > entity SurveyQuestionType > entity SurveyResponse > view SurveyResponseAndAnswer > entity SurveyResponseAnswer > entity SurveyTrigger > > Many thanks, > > Chris > > Jacopo Cappellato wrote: >> Chris, >> >> thanks for your report: >> >> On Feb 24, 2010, at 12:50 PM, Christopher Snow wrote: >> >> >>> With "help" dependent on content, I believe content should be moved >>> into the framework. >>> >>> >> >> IMO the content should be split into two parts: one will go into the >> framework, the other one ("contentext") will stay in the applications >> >> >>> One of the main dependencies in content is from survey to order. >>> One option is to remove survey into it's own dedicated component. >>> Any thoughts on this? >>> >>> >> >> This could be a good candidate for the "contentext" component I have >> mentioned before. >> >> >>> The other main dependency is on party. I believe we should move the >>> core party stuff (Party, PartyAttribute, PartyTypeAttr, PartyGroup, >>> PartyType, PartyRole, RoleType) into a partycore component that is >>> part of the framework. Any thoughts on this? >>> >>> >> >> I still think (and hope) that the framework will be able to live >> without dependencies on Party; we should carefully evaluate the >> current dependencies and see if we can resolve them. >> >> >>> Content also has a dependency on Person via WebSiteRole. I'm not >>> sure Person should become part of partycore. However, I'm not sure >>> that Person should be part of WebSiteRole. Any thoughts on this? >>> >>> >> >> The dependency on Person should be removed from the data model: this >> should be a simple task to perform. >> >> Kind regards, >> >> Jacopo >> >> > |
I have documented my thoughts in OFBIZ-3505
Feedback please everyone! Christopher Snow wrote: > Hi Devs, do any of you have an opinion on what entities would stay in > content if it was migrated to framework, and what entities would move > to contentext? My ideas are below... > > Many thanks, > > Chris > > > Christopher Snow wrote: >> Hi Jacopo, >> >> I will try and identify exactly which entities would be required in >> content, and those required in contentext. In the meantime, would you >> agree with the following list? >> >> Component CONTENT >> >> view AssocRevisionItemView >> view ContentAssocRevisionItemView >> view MaxRevisionItemView >> view MaxContentApprovalView >> view ContentAssocOptViewFrom >> view ContentRevisionItemAndContentApprovalView >> >> entity Content >> view ContentAndRole >> entity ContentApproval >> entity ContentAssoc >> view ContentAssocDataResourceViewFrom >> view ContentAssocDataResourceViewTo >> entity ContentAssocPredicate >> view ContentAssocViewFrom >> view ContentAssocViewTo >> entity ContentAttribute >> view ContentDataResourceView >> entity ContentMetaData >> entity ContentOperation >> entity ContentPurpose >> entity ContentPurposeOperation >> entity ContentPurposeType >> entity ContentRevision >> entity ContentRevisionItem >> entity ContentRole >> entity ContentType >> entity ContentTypeAttr >> view SubContentDataResourceView >> >> entity AudioDataResource >> entity CharacterSet >> entity DataCategory >> entity DataResource >> entity DataResourceAttribute >> view DataResourceContentView >> entity DataResourceMetaData >> entity DataResourcePurpose >> entity DataResourceRole >> entity DataResourceType >> entity DataResourceTypeAttr >> entity DataTemplateType >> entity ElectronicText >> entity FileExtension >> entity ImageDataResource >> entity MetaDataPredicate >> entity MimeType >> entity MimeTypeHtmlTemplate >> entity OtherDataResource >> entity VideoDataResource >> >> entity Document >> entity DocumentAttribute >> entity DocumentType >> entity DocumentTypeAttr >> >> entity WebPreferenceType >> entity WebUserPreference >> >> extend-entity WebPage >> entity WebSiteContent >> view WebSiteAndContent >> entity WebSiteContentType >> entity WebSitePathAlias >> entity WebSitePublishPoint >> entity WebSiteRole >> view ContentAssocAndContentPurpose >> >> Component CONTENTEXT >> >> entity Survey >> entity SurveyApplType >> entity SurveyMultiResp >> entity SurveyMultiRespColumn >> entity SurveyPage >> entity SurveyQuestion >> view SurveyQuestionAndAppl >> entity SurveyQuestionAppl >> entity SurveyQuestionCategory >> entity SurveyQuestionOption >> entity SurveyQuestionType >> entity SurveyResponse >> view SurveyResponseAndAnswer >> entity SurveyResponseAnswer >> entity SurveyTrigger >> >> Many thanks, >> >> Chris >> >> Jacopo Cappellato wrote: >>> Chris, >>> >>> thanks for your report: >>> >>> On Feb 24, 2010, at 12:50 PM, Christopher Snow wrote: >>> >>> >>>> With "help" dependent on content, I believe content should be moved >>>> into the framework. >>>> >>>> >>> >>> IMO the content should be split into two parts: one will go into the >>> framework, the other one ("contentext") will stay in the applications >>> >>> >>>> One of the main dependencies in content is from survey to order. >>>> One option is to remove survey into it's own dedicated component. >>>> Any thoughts on this? >>>> >>>> >>> >>> This could be a good candidate for the "contentext" component I have >>> mentioned before. >>> >>> >>>> The other main dependency is on party. I believe we should move >>>> the core party stuff (Party, PartyAttribute, PartyTypeAttr, >>>> PartyGroup, PartyType, PartyRole, RoleType) into a partycore >>>> component that is part of the framework. Any thoughts on this? >>>> >>>> >>> >>> I still think (and hope) that the framework will be able to live >>> without dependencies on Party; we should carefully evaluate the >>> current dependencies and see if we can resolve them. >>> >>> >>>> Content also has a dependency on Person via WebSiteRole. I'm not >>>> sure Person should become part of partycore. However, I'm not sure >>>> that Person should be part of WebSiteRole. Any thoughts on this? >>>> >>>> >>> >>> The dependency on Person should be removed from the data model: this >>> should be a simple task to perform. >>> >>> Kind regards, >>> >>> Jacopo >>> >>> >> > |
I'd recommend looking at entity relationships (especially those with foreign keys). For example, by including any of the *Role entities you would be including the Party, RoleType and other such entities in the party component. The same may be true of other components. In other words, you're implicitly talking about including those things as well. Also, why not include the Survey* entities? Do those depend on something you want to leave out, or are you just not interested in the idea of dynamic forms? -David On Feb 24, 2010, at 10:52 PM, Christopher Snow wrote: > I have documented my thoughts in OFBIZ-3505 > > Feedback please everyone! > > > Christopher Snow wrote: >> Hi Devs, do any of you have an opinion on what entities would stay in content if it was migrated to framework, and what entities would move to contentext? My ideas are below... >> >> Many thanks, >> >> Chris >> >> >> Christopher Snow wrote: >>> Hi Jacopo, >>> >>> I will try and identify exactly which entities would be required in content, and those required in contentext. In the meantime, would you agree with the following list? >>> >>> Component CONTENT >>> >>> view AssocRevisionItemView >>> view ContentAssocRevisionItemView >>> view MaxRevisionItemView >>> view MaxContentApprovalView >>> view ContentAssocOptViewFrom >>> view ContentRevisionItemAndContentApprovalView >>> >>> entity Content >>> view ContentAndRole >>> entity ContentApproval >>> entity ContentAssoc >>> view ContentAssocDataResourceViewFrom >>> view ContentAssocDataResourceViewTo >>> entity ContentAssocPredicate >>> view ContentAssocViewFrom >>> view ContentAssocViewTo >>> entity ContentAttribute >>> view ContentDataResourceView >>> entity ContentMetaData >>> entity ContentOperation >>> entity ContentPurpose >>> entity ContentPurposeOperation >>> entity ContentPurposeType >>> entity ContentRevision >>> entity ContentRevisionItem >>> entity ContentRole >>> entity ContentType >>> entity ContentTypeAttr >>> view SubContentDataResourceView >>> >>> entity AudioDataResource >>> entity CharacterSet >>> entity DataCategory >>> entity DataResource >>> entity DataResourceAttribute >>> view DataResourceContentView >>> entity DataResourceMetaData >>> entity DataResourcePurpose >>> entity DataResourceRole >>> entity DataResourceType >>> entity DataResourceTypeAttr >>> entity DataTemplateType >>> entity ElectronicText >>> entity FileExtension >>> entity ImageDataResource >>> entity MetaDataPredicate >>> entity MimeType >>> entity MimeTypeHtmlTemplate >>> entity OtherDataResource >>> entity VideoDataResource >>> >>> entity Document >>> entity DocumentAttribute >>> entity DocumentType >>> entity DocumentTypeAttr >>> >>> entity WebPreferenceType >>> entity WebUserPreference >>> >>> extend-entity WebPage >>> entity WebSiteContent >>> view WebSiteAndContent >>> entity WebSiteContentType >>> entity WebSitePathAlias >>> entity WebSitePublishPoint >>> entity WebSiteRole >>> view ContentAssocAndContentPurpose >>> >>> Component CONTENTEXT >>> >>> entity Survey >>> entity SurveyApplType >>> entity SurveyMultiResp >>> entity SurveyMultiRespColumn >>> entity SurveyPage >>> entity SurveyQuestion >>> view SurveyQuestionAndAppl >>> entity SurveyQuestionAppl >>> entity SurveyQuestionCategory >>> entity SurveyQuestionOption >>> entity SurveyQuestionType >>> entity SurveyResponse >>> view SurveyResponseAndAnswer >>> entity SurveyResponseAnswer >>> entity SurveyTrigger >>> >>> Many thanks, >>> >>> Chris >>> >>> Jacopo Cappellato wrote: >>>> Chris, >>>> >>>> thanks for your report: >>>> >>>> On Feb 24, 2010, at 12:50 PM, Christopher Snow wrote: >>>> >>>> >>>>> With "help" dependent on content, I believe content should be moved into the framework. >>>>> >>>>> >>>> >>>> IMO the content should be split into two parts: one will go into the framework, the other one ("contentext") will stay in the applications >>>> >>>> >>>>> One of the main dependencies in content is from survey to order. One option is to remove survey into it's own dedicated component. Any thoughts on this? >>>>> >>>>> >>>> >>>> This could be a good candidate for the "contentext" component I have mentioned before. >>>> >>>> >>>>> The other main dependency is on party. I believe we should move the core party stuff (Party, PartyAttribute, PartyTypeAttr, PartyGroup, PartyType, PartyRole, RoleType) into a partycore component that is part of the framework. Any thoughts on this? >>>>> >>>>> >>>> >>>> I still think (and hope) that the framework will be able to live without dependencies on Party; we should carefully evaluate the current dependencies and see if we can resolve them. >>>> >>>> >>>>> Content also has a dependency on Person via WebSiteRole. I'm not sure Person should become part of partycore. However, I'm not sure that Person should be part of WebSiteRole. Any thoughts on this? >>>>> >>>>> >>>> >>>> The dependency on Person should be removed from the data model: this should be a simple task to perform. >>>> >>>> Kind regards, >>>> >>>> Jacopo >>>> >>>> >>> >> > |
Hi David. thanks for the feedback.
I don't mind eaither way with survey, though SurveyResponse does have a dependency on order. If survey became core, the dependency could be reversed by the order component extending the SurveyResponse entity? Many thanks, Chris > > I'd recommend looking at entity relationships (especially those with > foreign keys). For example, by including any of the *Role entities you > would be including the Party, RoleType and other such entities in the > party component. The same may be true of other components. In other words, > you're implicitly talking about including those things as well. > > Also, why not include the Survey* entities? Do those depend on something > you want to leave out, or are you just not interested in the idea of > dynamic forms? > > -David > > > On Feb 24, 2010, at 10:52 PM, Christopher Snow wrote: > >> I have documented my thoughts in OFBIZ-3505 >> >> Feedback please everyone! >> >> >> Christopher Snow wrote: >>> Hi Devs, do any of you have an opinion on what entities would stay in >>> content if it was migrated to framework, and what entities would move >>> to contentext? My ideas are below... >>> >>> Many thanks, >>> >>> Chris >>> >>> >>> Christopher Snow wrote: >>>> Hi Jacopo, >>>> >>>> I will try and identify exactly which entities would be required in >>>> content, and those required in contentext. In the meantime, would you >>>> agree with the following list? >>>> >>>> Component CONTENT >>>> >>>> view AssocRevisionItemView >>>> view ContentAssocRevisionItemView >>>> view MaxRevisionItemView >>>> view MaxContentApprovalView >>>> view ContentAssocOptViewFrom >>>> view ContentRevisionItemAndContentApprovalView >>>> >>>> entity Content >>>> view ContentAndRole >>>> entity ContentApproval >>>> entity ContentAssoc >>>> view ContentAssocDataResourceViewFrom >>>> view ContentAssocDataResourceViewTo >>>> entity ContentAssocPredicate >>>> view ContentAssocViewFrom >>>> view ContentAssocViewTo >>>> entity ContentAttribute >>>> view ContentDataResourceView >>>> entity ContentMetaData >>>> entity ContentOperation >>>> entity ContentPurpose >>>> entity ContentPurposeOperation >>>> entity ContentPurposeType >>>> entity ContentRevision >>>> entity ContentRevisionItem >>>> entity ContentRole >>>> entity ContentType >>>> entity ContentTypeAttr >>>> view SubContentDataResourceView >>>> >>>> entity AudioDataResource >>>> entity CharacterSet >>>> entity DataCategory >>>> entity DataResource >>>> entity DataResourceAttribute >>>> view DataResourceContentView >>>> entity DataResourceMetaData >>>> entity DataResourcePurpose >>>> entity DataResourceRole >>>> entity DataResourceType >>>> entity DataResourceTypeAttr >>>> entity DataTemplateType >>>> entity ElectronicText >>>> entity FileExtension >>>> entity ImageDataResource >>>> entity MetaDataPredicate >>>> entity MimeType >>>> entity MimeTypeHtmlTemplate >>>> entity OtherDataResource >>>> entity VideoDataResource >>>> >>>> entity Document >>>> entity DocumentAttribute >>>> entity DocumentType >>>> entity DocumentTypeAttr >>>> >>>> entity WebPreferenceType >>>> entity WebUserPreference >>>> >>>> extend-entity WebPage >>>> entity WebSiteContent >>>> view WebSiteAndContent >>>> entity WebSiteContentType >>>> entity WebSitePathAlias >>>> entity WebSitePublishPoint >>>> entity WebSiteRole >>>> view ContentAssocAndContentPurpose >>>> >>>> Component CONTENTEXT >>>> >>>> entity Survey >>>> entity SurveyApplType >>>> entity SurveyMultiResp >>>> entity SurveyMultiRespColumn >>>> entity SurveyPage >>>> entity SurveyQuestion >>>> view SurveyQuestionAndAppl >>>> entity SurveyQuestionAppl >>>> entity SurveyQuestionCategory >>>> entity SurveyQuestionOption >>>> entity SurveyQuestionType >>>> entity SurveyResponse >>>> view SurveyResponseAndAnswer >>>> entity SurveyResponseAnswer >>>> entity SurveyTrigger >>>> >>>> Many thanks, >>>> >>>> Chris >>>> >>>> Jacopo Cappellato wrote: >>>>> Chris, >>>>> >>>>> thanks for your report: >>>>> >>>>> On Feb 24, 2010, at 12:50 PM, Christopher Snow wrote: >>>>> >>>>> >>>>>> With "help" dependent on content, I believe content should be moved >>>>>> into the framework. >>>>>> >>>>>> >>>>> >>>>> IMO the content should be split into two parts: one will go into the >>>>> framework, the other one ("contentext") will stay in the applications >>>>> >>>>> >>>>>> One of the main dependencies in content is from survey to order. >>>>>> One option is to remove survey into it's own dedicated component. >>>>>> Any thoughts on this? >>>>>> >>>>>> >>>>> >>>>> This could be a good candidate for the "contentext" component I have >>>>> mentioned before. >>>>> >>>>> >>>>>> The other main dependency is on party. I believe we should move the >>>>>> core party stuff (Party, PartyAttribute, PartyTypeAttr, PartyGroup, >>>>>> PartyType, PartyRole, RoleType) into a partycore component that is >>>>>> part of the framework. Any thoughts on this? >>>>>> >>>>>> >>>>> >>>>> I still think (and hope) that the framework will be able to live >>>>> without dependencies on Party; we should carefully evaluate the >>>>> current dependencies and see if we can resolve them. >>>>> >>>>> >>>>>> Content also has a dependency on Person via WebSiteRole. I'm not >>>>>> sure Person should become part of partycore. However, I'm not sure >>>>>> that Person should be part of WebSiteRole. Any thoughts on this? >>>>>> >>>>>> >>>>> >>>>> The dependency on Person should be removed from the data model: this >>>>> should be a simple task to perform. >>>>> >>>>> Kind regards, >>>>> >>>>> Jacopo >>>>> >>>>> >>>> >>> >> > > -- Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP Tel: 01453 890660 Mob: 07944 880950 Www: www.snowconsulting.co.uk |
Yes, from a data modeling perspective (and in general for the most part) nearly any dependency can be reversed. -David On Feb 24, 2010, at 11:14 PM, Chris Snow wrote: > Hi David. thanks for the feedback. > > I don't mind eaither way with survey, though SurveyResponse does have a > dependency on order. If survey became core, the dependency could be > reversed by the order component extending the SurveyResponse entity? > > Many thanks, > > Chris > >> >> I'd recommend looking at entity relationships (especially those with >> foreign keys). For example, by including any of the *Role entities you >> would be including the Party, RoleType and other such entities in the >> party component. The same may be true of other components. In other words, >> you're implicitly talking about including those things as well. >> >> Also, why not include the Survey* entities? Do those depend on something >> you want to leave out, or are you just not interested in the idea of >> dynamic forms? >> >> -David >> >> >> On Feb 24, 2010, at 10:52 PM, Christopher Snow wrote: >> >>> I have documented my thoughts in OFBIZ-3505 >>> >>> Feedback please everyone! >>> >>> >>> Christopher Snow wrote: >>>> Hi Devs, do any of you have an opinion on what entities would stay in >>>> content if it was migrated to framework, and what entities would move >>>> to contentext? My ideas are below... >>>> >>>> Many thanks, >>>> >>>> Chris >>>> >>>> >>>> Christopher Snow wrote: >>>>> Hi Jacopo, >>>>> >>>>> I will try and identify exactly which entities would be required in >>>>> content, and those required in contentext. In the meantime, would you >>>>> agree with the following list? >>>>> >>>>> Component CONTENT >>>>> >>>>> view AssocRevisionItemView >>>>> view ContentAssocRevisionItemView >>>>> view MaxRevisionItemView >>>>> view MaxContentApprovalView >>>>> view ContentAssocOptViewFrom >>>>> view ContentRevisionItemAndContentApprovalView >>>>> >>>>> entity Content >>>>> view ContentAndRole >>>>> entity ContentApproval >>>>> entity ContentAssoc >>>>> view ContentAssocDataResourceViewFrom >>>>> view ContentAssocDataResourceViewTo >>>>> entity ContentAssocPredicate >>>>> view ContentAssocViewFrom >>>>> view ContentAssocViewTo >>>>> entity ContentAttribute >>>>> view ContentDataResourceView >>>>> entity ContentMetaData >>>>> entity ContentOperation >>>>> entity ContentPurpose >>>>> entity ContentPurposeOperation >>>>> entity ContentPurposeType >>>>> entity ContentRevision >>>>> entity ContentRevisionItem >>>>> entity ContentRole >>>>> entity ContentType >>>>> entity ContentTypeAttr >>>>> view SubContentDataResourceView >>>>> >>>>> entity AudioDataResource >>>>> entity CharacterSet >>>>> entity DataCategory >>>>> entity DataResource >>>>> entity DataResourceAttribute >>>>> view DataResourceContentView >>>>> entity DataResourceMetaData >>>>> entity DataResourcePurpose >>>>> entity DataResourceRole >>>>> entity DataResourceType >>>>> entity DataResourceTypeAttr >>>>> entity DataTemplateType >>>>> entity ElectronicText >>>>> entity FileExtension >>>>> entity ImageDataResource >>>>> entity MetaDataPredicate >>>>> entity MimeType >>>>> entity MimeTypeHtmlTemplate >>>>> entity OtherDataResource >>>>> entity VideoDataResource >>>>> >>>>> entity Document >>>>> entity DocumentAttribute >>>>> entity DocumentType >>>>> entity DocumentTypeAttr >>>>> >>>>> entity WebPreferenceType >>>>> entity WebUserPreference >>>>> >>>>> extend-entity WebPage >>>>> entity WebSiteContent >>>>> view WebSiteAndContent >>>>> entity WebSiteContentType >>>>> entity WebSitePathAlias >>>>> entity WebSitePublishPoint >>>>> entity WebSiteRole >>>>> view ContentAssocAndContentPurpose >>>>> >>>>> Component CONTENTEXT >>>>> >>>>> entity Survey >>>>> entity SurveyApplType >>>>> entity SurveyMultiResp >>>>> entity SurveyMultiRespColumn >>>>> entity SurveyPage >>>>> entity SurveyQuestion >>>>> view SurveyQuestionAndAppl >>>>> entity SurveyQuestionAppl >>>>> entity SurveyQuestionCategory >>>>> entity SurveyQuestionOption >>>>> entity SurveyQuestionType >>>>> entity SurveyResponse >>>>> view SurveyResponseAndAnswer >>>>> entity SurveyResponseAnswer >>>>> entity SurveyTrigger >>>>> >>>>> Many thanks, >>>>> >>>>> Chris >>>>> >>>>> Jacopo Cappellato wrote: >>>>>> Chris, >>>>>> >>>>>> thanks for your report: >>>>>> >>>>>> On Feb 24, 2010, at 12:50 PM, Christopher Snow wrote: >>>>>> >>>>>> >>>>>>> With "help" dependent on content, I believe content should be moved >>>>>>> into the framework. >>>>>>> >>>>>>> >>>>>> >>>>>> IMO the content should be split into two parts: one will go into the >>>>>> framework, the other one ("contentext") will stay in the applications >>>>>> >>>>>> >>>>>>> One of the main dependencies in content is from survey to order. >>>>>>> One option is to remove survey into it's own dedicated component. >>>>>>> Any thoughts on this? >>>>>>> >>>>>>> >>>>>> >>>>>> This could be a good candidate for the "contentext" component I have >>>>>> mentioned before. >>>>>> >>>>>> >>>>>>> The other main dependency is on party. I believe we should move the >>>>>>> core party stuff (Party, PartyAttribute, PartyTypeAttr, PartyGroup, >>>>>>> PartyType, PartyRole, RoleType) into a partycore component that is >>>>>>> part of the framework. Any thoughts on this? >>>>>>> >>>>>>> >>>>>> >>>>>> I still think (and hope) that the framework will be able to live >>>>>> without dependencies on Party; we should carefully evaluate the >>>>>> current dependencies and see if we can resolve them. >>>>>> >>>>>> >>>>>>> Content also has a dependency on Person via WebSiteRole. I'm not >>>>>>> sure Person should become part of partycore. However, I'm not sure >>>>>>> that Person should be part of WebSiteRole. Any thoughts on this? >>>>>>> >>>>>>> >>>>>> >>>>>> The dependency on Person should be removed from the data model: this >>>>>> should be a simple task to perform. >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Jacopo >>>>>> >>>>>> >>>>> >>>> >>> >> >> > > > -- > Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP > > Tel: 01453 890660 > Mob: 07944 880950 > Www: www.snowconsulting.co.uk > |
Free forum by Nabble | Edit this page |