dynamic maps for status conversion
mteichtahl opened this issue · comments
I've been having a solid play with status conversion. I'm implementing work flows into an existing table and can't change the status strings - so conversions looked good
However, I believe it's not possible to dynamically assign the conversion map.
What I want to do is have the behaviour provide the map so I can iterate over my existing status strings and generate the mapping
However, I can't find a way to write to the map once the status conversion component is loaded
Is this the expected behaviour?
If so, I'd there any way to write to the map after component instantiation?
Yes, you're right, this is the expected behavior ... simply because I never thought about the use case you're facing (i.e assign status converter map at runtime).
Now you have 2 options to solve this :
- you create your own StatusConverter component, register it in your app under the id statusConverter and you're good to go.
- you wait until I modify the original StatusConverter component and add a setter (setMap())
I currently see now valuable reason why not to add a setter,... on the contrary : if it can help you that's a good reason ;)
ciao
Thanks for the response.
What is your timing for an update? I'd also be happy to fork and make a pr with the changes. I just won't get to it for a week at this stage
I will update before next Monday.
Excellent and thank you.
Id be happy to test a branch if you like
given the amount of times that the conversions may have to be read, have you considered possibly putting in a hash based cache ? not sure if this would give a performance improvement - what do you think ?
--
Marc Teichtahl
Sent with Airmail
From: raoul notifications@github.com
Reply: raoul2000/yii2-workflow reply@reply.github.com>
Date: 5 June 2015 at 5:41:18 pm
To: raoul2000/yii2-workflow yii2-workflow@noreply.github.com>
Cc: Marc Teichtahl marc@teichtahl.com>
Subject: Re: [yii2-workflow] dynamic maps for status conversion (#9)
I will update before next Monday.
—
Reply to this email directly or view it on GitHub.
Thanks for your offer. I think the change (very small impact) will be directly committed to the main branch ... and I'll be happy to get your test feedback.
Now regarding caching, I didn't though about that because, I had never considered a use case where the conversion map would be built dynamically... and so I'm not able to evaluate the performance improvement that could be obtained using a cache (it depends very much on how you create the conversion map isn't it ?).
Nevertheless, I think that as you're dealing with a very specific use case, maybe the cache (if cache there is) should not be handled by the default StatusConverter component, but by the code in charge of setting the map conversion...(the one that iterates and build the map).