@nicolasbadia I am trying to run through the different scenarios. My change catches state observable triggers which happens as a result of what is done while the enterState is being executed. This is kind of what you expect when running the enterState: the state is essentially ready to respond to events. I would think that the opposite is true of exitState: you expect the state to have stopped responding to events, and the exitState is used to clean up afterwards. Having state observers trigger during the exitState is going to make things much more difficult to predict.
in addition: I think the original idea behind this was that any kind of async action would go through
this.performAsync('method'). Getting data from the store is such an action. The method called asynchronously is called after the observers are attached. I think it is telling that in this example app it is already not done that way.Especially regarding the recent JS developments (async await etc) it makes sense to have the observers attached as early as possible.
Also: I am updating the guides to use the NodeJS BT, as well as installing sproutcore in the project/frameworks folder by default. There is no real benefit in having some old SC floating around on the system.
So I will roll back the change on master, it causes loads of issues
@nicolasbadia I have noticed that using the selectsearch view with records from the store causes records being set editable (and locked because of that) as soon as the mouse hovers over the option in the menu. The cause is that the menu pane will select the item on mouse-over. While this behavior is required in order to display a submenu, in a menu without submenus the same visual effect could be created through CSS. The main issue with selecting the record/menuitem is that this action locks the record in the (nested) store, and consequently prevents any updates pushed into the store through pushRetrieve to display in the app, even if the record itself has never really been displayed in the app.
I created a workaround in my app now, which checks for the combination of SC.Record.READY_CLEAN and the editable state, and force-update the store if that is the case. Of course this is not something to keep doing.
Also, notice that when I add the 'needs review' label to a PR, it means to me it is ready to be merged to master and someone other than me should review it and merge it if it looks good.
The build system supports a custom build number which is kept in a separate file.
The default configuration should not use that, but complains about it anyway
@nicolasbadia a few things: I had to move and convert the sproutcore blog @blog.sproutcore.com to github pages (https://github.com/sproutcore-blog/sproutcore-blog) because the hosting contract stopped and I didn't want to pay $16 a month for something we could easily get for free using github.
I recreated the sproutcore blog layout with jekyll so it would be more or less the same. The only thing that might not have survived is the hardlinks, but I didn't test that.
I also wrote the first part of a series of blog posts about how we could get SC to a more modern version of JS, and what kind of issues there are. Also gives a nice insight in how the runtime framework and the inheritance scheme works.
And thinking about my development process I suddenly realized that half of the time I am searching in a complex app where I left the controller responsible for certain actions. This in turn brought me to the project folder structure: what if we started to organise things according to state instead?
About statechart and controllers, most of my code still seat in the controllers. It might have to do that when I started designing my app, statechart was not there yet. I now maintain states for each page in my app, and the few handlers in it mostly call methods which are defined in my controllers. My controllers are responsible of creating, updating and deleting records, managing selection, reordering, table columns... It feel to me all of this best fit in the controller.
I mostly have one array controller and one object controller per record type, but several states may relates to a record type.
Clear, we should perhaps at some point walk through my biggest application to see what the problem is exactly. Suffice to say that for every page I have a separate state which allows certain actions. Some of these pages are not accessible by all users, and because there are around 9 pages with at least 4 controllers per page the location of that controller, and also it's exact definition and location gets a bit complex.
Using: sudo npm install -g sproutcore
Unable to save binary /usr/local/lib/node_modules/sproutcore/node_modules/node-sass/vendor/darwin-x64-64 : { Error: EACCES: permission denied, mkdir '/usr/local/lib/node_modules/sproutcore/node_modules/node-sass/vendor'
at Object.mkdirSync (fs.js:757:3)
at sync (/usr/local/lib/node_modules/sproutcore/node_modules/mkdirp/index.js:71:13)
at Function.sync (/usr/local/lib/node_modules/sproutcore/node_modules/mkdirp/index.js:77:24)
at checkAndDownloadBinary (/usr/local/lib/node_modules/sproutcore/node_modules/node-sass/scripts/install.js:114:11)
at Object.<anonymous> (/usr/local/lib/node_modules/sproutcore/node_modules/node-sass/scripts/install.js:157:1)
at Module._compile (internal/modules/cjs/loader.js:776:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
errno: -13,
syscall: 'mkdir',
code: 'EACCES',
path:
'/usr/local/lib/node_modules/sproutcore/node_modules/node-sass/vendor' }
at Object.mkdirSync (fs.js:757:3)
at sync (/usr/local/lib/node_modules/sproutcore/node_modules/mkdirp/index.js:71:13)
at Function.sync (/usr/local/lib/node_modules/sproutcore/node_modules/mkdirp/index.js:77:24)
at checkAndDownloadBinary (/usr/local/lib/node_modules/sproutcore/node_modules/node-sass/scripts/install.js:114:11)
at Object.<anonymous> (/usr/local/lib/node_modules/sproutcore/node_modules/node-sass/scripts/install.js:157:1)
at Module._compile (internal/modules/cjs/loader.js:776:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
errno: -13,
syscall: 'mkdir',
code: 'EACCES',
path:
'/usr/local/lib/node_modules/sproutcore/node_modules/node-sass/vendor' }
(and others following). I tried making the directories by hand and didn't have a problem, but the error persisted.
Hello SproutCore Friends!
I made this with your framework: https://www.classicmacfinder.com/server-admin/
I do have to say that even though I really like Vue, SproutCore is a lot of fun and surprisingly very productive... especially for a mostly-backend guy. I made that whole Server Admin clone in about a months time, learning as I went, so I won’t pretend to really know SC in/out, but I am happy to help contribute to the project if I can.
I'm trying to make work sproutcore with node 12.16.2, but I have a problem when I perform 'sproutcore serve': ERROR: Sass parsing error in /Users/marcoscontreras/.nvm/versions/node/v12.16.2/lib/node_modules/sproutcore/frameworks/sproutcore/frameworks/desktop/resources/icons.css: Error: no mixin named slice
@bszyman Great job Ben with 'server-admin'
@contrerasmarc yes, one of the things we have been doing is to get rid of the slicing all together
in tandem with switching to Aki as default theme
Aki is very similar, but doesn't use image slicing at all
The @slice command was specifically for the image slicer and would be parsed before the css would ever end up in sass. So, if you switch to Aki as theme, your problem should be solved
Hello, starting my app nowadays show the following message in the console: seems a foundation.js problem, line 9849 "status = appCache.status". [Deprecation] Application Cache API use is deprecated and will be removed in M82, around April 2020. See https://www.chromestatus.com/features/6192449487634432 for more details.
_appCacheStatusDidChange @ foundation.js:9849
_appCacheStatusDidChange @ foundation.js:9849
What can be done to remove this warning, any suggestions? Thanks in advance.
@fpkfpk we will come back to you as soon as we have some upgrade path. Most likely it will simply require you to update the build tools through npm, depending on whether you have SproutCore installed as a framework in your project.