[jira] [Comment Edited] (OFBIZ-5020) change serviceName by customMethod on Content

["Jacques Le Roux (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OFBIZ-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446660#comment-13446660 ] 

Jacques Le Roux edited comment on OFBIZ-5020 at 9/1/12 11:08 PM:
-----------------------------------------------------------------

== TYPO: userS ==
Adrian,

Yesterday I talked with Nicolas. It's because he wants to encourage people to use the new method.
IMO, the alternatives are:
# using both, by keeping serviceName as is and adding the new field. This was 1st suggested by BJ and you seem to be inclined to this too
** advantages: minimal changes, not need to provide a way for users to migrate their data
** drawbacks: it's not clear what to use. There is a redundant way of doing the same thing. Which demo data should be kept/added OOTB?
# rename the serviceName field to oldServiceName but not use the col-name trick
** advantages: follow the standard procedure, clear path, no redundancy
** drawbacks: 
*** the contributor or committer needs to provide a way for users to migrate their data for existent DBs
*** the user with an existent DB must detect the change, find the procedure to migrate data in the wiki, and apply the change to DB. 
# rename the serviceName field to oldServiceName and use the col-name trick
** advantages: , 
*** the contributor or committer don't need to provide a way for users to migrate their data
*** the user does not need to do anything: it's done silently/automatically when updating code and possibly reloading 
** drawbacks: 
*** on an existing DB, if the user reload data the DB ends with duplicated data (demo only IIIRW). The user is not aware of that unless if looks closely at this commit, Jira, or in the Content Entity
*** minor: in a new DB the The Content.oldServiceName field will be named service_name in the DB. so SQL queries using old_Service_Name will not work.

Not sure I put all advantages and drawbacks. At least that's what I have in my mind.

Actually Nicolas called me after I put my Jira comment for the commit above. Like you Adrian, I did not spot the col-name trick. So in my Jira comment above I asked Nicolas to follow the std (2nd) procedure. Hence to provide a way for users to migrate their data. But then he explained me he used the col-name trick. I thought it was clever and supported it. I thought more about it this morning and the 3 points above follows. Note that I'm not clearly decided. But if it was only me I'd use the 3rd way: it's safe, clarify (give an information to users to follow the new way), and avoid the migration burden.

The reason I put much efforts in this is because I would like the community to think about the last (3rd) solution, instead of always using the 2nd (in some cases clearly using the 2nd would be better, here the change in code is easy). The 1st seems unclear to me (confusing, redundant) but is the one with less work.

                
      was (Author: jacques.le.roux):
    Adrian,

Yesterday I talked with Nicolas. It's because he wants to encourage people to use the new method.
IMO, the alternatives are:
# using both, by keeping serviceName as is and adding the new field. This was 1st suggested by BJ and you seem to be inclined to this too
** advantages: minimal changes, not need to provide a way for user to migrate their data
** drawbacks: it's not clear what to use. There is a redundant way of doing the same thing. Which demo data should be kept/added OOTB?
# rename the serviceName field to oldServiceName but not use the col-name trick
** advantages: follow the standard procedure, clear path, no redundancy
** drawbacks: 
*** the contributor or committer needs to provide a way for user to migrate their data for existent DBs
*** the user with an existent DB must detect the change, find the procedure to migrate data in the wiki, and apply the change to DB. 
# rename the serviceName field to oldServiceName and use the col-name trick
** advantages: , 
*** the contributor or committer don't need to provide a way for user to migrate their data
*** the user does not need to do anything: it's done silently/automatically when updating code and possibly reloading 
** drawbacks: 
*** on an existing DB, if the user reload data the DB ends with duplicated data (demo only IIIRW). The user is not aware of that unless if looks closely at this commit, Jira, or in the Content Entity
*** minor: in a new DB the The Content.oldServiceName field will be named service_name in the DB. so SQL queries using old_Service_Name will not work.

Not sure I put all advantages and drawbacks. At least that's what I have in my mind.

Actually Nicolas called me after I put my Jira comment for the commit above. Like you Adrian, I did not spot the col-name trick. So in my Jira comment above I asked Nicolas to follow the std (2nd) procedure. Hence to provide a way for users to migrate their data. But then he explained me he used the col-name trick. I thought it was clever and supported it. I thought more about it this morning and the 3 points above follows. Note that I'm not clearly decided. But if it was only me I'd use the 3rd way: it's safe, clarify (give an information to users to follow the new way), and avoid the migration burden.

The reason I put much efforts in this is because I would like the community to think about the last (3rd) solution, instead of always using the 2nd (in some cases clearly using the 2nd would be better, here the change in code is easy). The 1st seems unclear to me (confusing, redundant) but is the one with less work.

                  
> change serviceName by customMethod on Content
> ---------------------------------------------
>
>                 Key: OFBIZ-5020
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-5020
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: content
>    Affects Versions: SVN trunk
>            Reporter: Nicolas Malin
>            Assignee: Jacques Le Roux
>            Priority: Minor
>             Fix For: SVN trunk
>
>         Attachments: OFBIZ-5020.patch, OFBIZ-5020.patch, OFBIZ-5020.patch
>
>
> At this time, when you use a content as template, the content.serviceName value use to call the context populate service before rendering.
> I propose to replace serviceName field by customMethodId and use customMethod pattern for more flexibility.
> serviceName field will be move to oldServiceName field for backward compatibility

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira