These are chat archives for reactioncommerce/reaction

2nd
Jun 2015
Adam
@Neobii
Jun 02 2015 17:22
Hmm, I like the statemachine, it gives us all the callbacks we need to put the events in the right place, but how about using a statemachine from atmosphere?
Aaron Judd
@aaronjudd
Jun 02 2015 17:29
we could do that, it’s the same state machine library there
Adam
@Neobii
Jun 02 2015 17:31
is there any benefit to doing it the way you did it?
Aaron Judd
@aaronjudd
Jun 02 2015 17:41
mainly because I didn’t/don’t want to rely on Meteor packages/ authors to maintain anything that our core uses if / or there wasn’t a stable package at the time. (particulary when meteor was pre-1.0 - packages rarely kept up)
this package doesn’t add anything though
Goutham Veeramachaneni
@gouthamve
Jun 02 2015 17:43
@aaronjudd I opened #383 to add some basic CMS functionality for new pages (Like an info page and stuff) and this will also add the option to specify new routes. I think I will have to load the routes from db for this.
Any thoughts?
Aaron Judd
@aaronjudd
Jun 02 2015 17:48
@Gouthamve one thought, is that we should store routes, etc using the package registry for the routes, as well as storing content area positional data. Not sure what that looks like exactly since it’s been a while, but that’s the direction we’ve been heading with the registry.
but otherwise, it shouldn’t be tough to implement
this way you can set package defaults for new content areas, but change allow user to modify (by modify the registry)
Goutham Veeramachaneni
@gouthamve
Jun 02 2015 17:56
Wait, so if I have want to have a new page like “manufacturing”, When the user creates it in the dashboard, the registry file has to change?
Aaron Judd
@aaronjudd
Jun 02 2015 17:59
I’m suggesting that if you are looking for a place to store the route for pages, like “manufacturing”, that route should be stored in packages.registry. the package registry file itself doesn’t need, but we import all that into packages.registry, so you can always/add/edit package properties there
Goutham Veeramachaneni
@gouthamve
Jun 02 2015 18:03
Just diving into the code, ReactionRegistry.Packages[packagename] is storing the package config. Which is then being inserted using fixtures.
Now if I add a new route, I dont think the route will persist across reboots.
Aaron Judd
@aaronjudd
Jun 02 2015 18:05
on initial load, yes - but once it’s imported into the Packages collection, it can be modified from there (so you could add placement info, route to this collection)
Goutham Veeramachaneni
@gouthamve
Jun 02 2015 18:17
Yep, the ReactionCore.registerPackage function in my register.coffee file will run everytime I run meteor which will change my ReactionRegistry.Packages[name] collection and now fixtures performs an upsert, resetting the pkgconfig to the one in my register.coffee if I am not wrong.
Aaron Judd
@aaronjudd
Jun 02 2015 18:19
it will upsert the original values, yes - but I was thinking that if there were additional settings, like placement, that it shouldn’t change that (if it’s not included in the original configuration).
Goutham Veeramachaneni
@gouthamve
Jun 02 2015 18:21
Ohh, Okay. Now it makes sense. Will test it soon.
Aaron Judd
@aaronjudd
Jun 02 2015 18:23
if doesn’t work that way - then we should make it work that way ;-)
Goutham Veeramachaneni
@gouthamve
Jun 02 2015 19:05
Yep, it works fine if I set a new one. And now I realise, we set the api keys in the db in the default fields and they are persisted across reboots! Complete idiot I was!
Aaron Judd
@aaronjudd
Jun 02 2015 19:37
there is yet another secret for that: suggest using private/settings/reaction.json for that
should allow you to persist settings, without changing registry, and without using meteor.settings