[
https://issues.apache.org/jira/browse/OFBIZ-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446660#comment-13446660
]
Jacques Le Roux commented on OFBIZ-5020:
----------------------------------------
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
