mt-homonymy-support #2

2020-07-16T10:25:30Z

matic_t commented

2020-07-16 10:25:30 +00:00

No description provided.

ozbolt was assigned by matic_t

2020-07-16 10:25:31 +00:00

lkavcic was assigned by matic_t

2020-07-16 10:25:31 +00:00

matic_t added 4 commits 2020-07-16 10:25:33 +00:00

homonymy basic implementation a22490c0fc

Added support for name attribute 6f9142b046

modal supports editing name and value fb9a809c02

support homonymy inside modal b010414bfe

matic_t commented

2020-07-16 10:27:48 +00:00

Probably best if both of you check it out.
Ožbolt for prevention and Luka so we both can speed up understanding of whole stack.

Basically we're adding support for the example in vsms1.xml file. It's already in schema so we just had to provide support in editor.

https://lexonomy.cjvt.si/5pdds79p/ - link to plugin used on dictionary

Probably best if both of you check it out. Ožbolt for prevention and Luka so we both can speed up understanding of whole stack. Basically we're adding support for the example in vsms1.xml file. It's already in schema so we just had to provide support in editor. https://lexonomy.cjvt.si/5pdds79p/ - link to plugin used on dictionary

matic_t added 1 commit 2020-07-16 10:46:56 +00:00

upsy daisys 9c007f6dd6

matic_t added 1 commit 2020-07-16 10:50:29 +00:00

Merge branch 'master' of https://gitea.cjvt.si/lexonomy/lexonomy_custom_editor into mt-homonymy-support ed8bb37b15

matic_t added 1 commit 2020-07-16 11:23:09 +00:00

update build_and_upload.sh.template with unlink 6f157eeea1

ozbolt commented

2020-07-16 19:54:16 +00:00

First of all, I did not test the code, I just went over the changes.

About the code, there are two mistakes:

homonomy_list_getter in common_accessors is only used once. This is fine, but the way I imagined it is that if this kind of functionality is only used once, than implement it inside the class (this time its EditHomonymy). Then later if needed to avoid code duplication refactor stuff out of the class and in common_accessors. But that is fairly subjective point and you can decide to do it another way :)
second one, if your IDE does white spaces this way, than create a big commit with only white space changes and than work from there. This is again not so important, but makes git blame and commits themselfs much less readable.

Otherwise, yes, everything looks nice and clean, gg :)

First of all, I did not test the code, I just went over the changes. About the code, there are two mistakes: * `homonomy_list_getter` in `common_accessors` is only used once. This is fine, but the way I imagined it is that if this kind of functionality is only used once, than implement it inside the class (this time its `EditHomonymy`). Then later if needed to avoid code duplication refactor stuff out of the class and in common_accessors. But that is fairly subjective point and you can decide to do it another way :) * second one, if your IDE does white spaces this way, than create a big commit with only white space changes and than work from there. This is again not so important, but makes git blame and commits themselfs much less readable. Otherwise, yes, everything looks nice and clean, gg :)

lkavcic commented

2020-07-23 08:31:11 +00:00

ok

lexonomy manually merged commit a07b35c6a8 into master

2020-08-05 10:04:56 +00:00

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lexonomy/lexonomy_custom_editor#2