-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated composite panel #151
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quite a large change. Not everything seems related to the core change proposed?
I note further opportunities for refactoring. I am open to deferring some of that refactoring to a later issue, but would like to understand whether it's feasible to do this efficiently now...
Thanks, @arturboronat and @barnettwilliam for discussing these comments so extensively. What's the most efficient way of splitting the work? (I guess, really I'm asking @arturboronat whether you have any capacity of lending a hand with some of these changes?) |
It's probably easier if I refactor |
Thanks, @arturboronat, that would be extremely helpful! |
Thank you both for working on this pull request. I merged the changes to my codebase by there is not much I can do :-) The proposed refactoring won't work because these functions (findPanel and resolveRef) are used to perform data bindings (converting JSON objects into class instances). These are scripting functions processing JSON/YAML objects and we can't benefit from OOP features like inheritance until we have class instances. On the other hand, the activity configuration used in the YAMTL playground fails to pass the validator. See the errors: The OCL activity under platformtools does not have composite panels (it's three months old) and I don't know where the example above can be found. @barnettwilliam Could you test the validator with the YAMTL activity https://yamtl.github.io/playground-activities/yamtl-demo-activity.yml ? @szschaler Do you see any other way of performing some meaningful refactoring? |
@arturboronat ah yes. Looking at this again, I realise my misunderstanding. But that really only means we need to refactor more consistently: it should be the initialisation function of the panel that gets passed in the JSON sub-structure providing the details of this panel and then using that to setup the panel, possibly recursively so. Once we have this, all the rest can happen over |
@arturboronat yes I'll test with your example, it's likely the validation rules need to be updated. I'm surprised the example I tested didn't pick that up. I'll also update the ocl example in mdenet/educationplatform-examples. |
@szschaler The initialize() function is already defined/overriden in each Panel class and the idea of passing a JSON document as parameter would help refactor the switch statement mentioned above but it is not specific to CompositePanel. The search for the relevant JSON document when looking for panel details seems to belong to ActivityManager though. |
@arturboronat do you have a version of your activity files available for me to test with? they don't appear to be available in the YAMTL repositories. A change I made was to rename childrenPanels to childPanels so the activity needs to be updated to reflect this. Update on this - I tested a local copy of yamtl-demo-activity with test file stubs and childPanel naming and the activity validates. |
@barnettwilliam The activity is https://yamtl.github.io/playground-activities/yamtl-demo-activity.yml In that file the |
Thanks Artur, when using the activity prefix suggested and childPanels naming the activity validates functions correctly. |
Fab, I'll try this later today. |
@szschaler does this mean that the ActivityManager will then take on the responsibility of creating Panel instances? the approach I have been taking is to keep ActivityManager and ToolsManager handling config file objects that are free of any UI code. Then, have the Playground.js construct the platform level objects like Panel. And if this is the case, do we then favour instantiating objects from configs earlier and mind Panel objects with UI information being included in the ActivityManager etc.? |
Updated documentation can be found mdenet/educationplatform.wiki@9bb39b88d4c230a6db1653f3e1c1af9837d7ab39 branch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy except for the implementation of save()
Thanks for these comments about the proposed refactoring. It looks like this is significantly more complex than I thought and, therefore, really doesn't belong into this PR. I have resolved the corresponding conversations and am happy for this to be merged, subject to a small fix to the implementation of |
…mposite panels and mdenet/educationplatform#148 only save modified panels.
Rebase of PR #134 to incorporate the recent platform changes.