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.
The biggest question I have at the moment is where your SproutCore framework "lives": in your project or as part of the BT (the sproutcore cli)?
@mauritslamers Hey Maurits, it's been a while... I saw the other day you published https://github.com/sproutcore/sproutcore_next Are you still working on it? I was wondering if you ever generated the SC documentation with https://github.com/sproutcore/docs ? I was thinking I could use it to document my app, but it looks fairly outdated...
I haven't regenerated the docs, because essentially I think the API is mostly the same.
Also, I have seen that jsdoc might have been updated in such a way that it might become complex to generate the docs that way
@nicolasbadia managed to get most of the view tests passing, but now I am running into the issue that the tests also seem to depend on the css. As I am running bare metal (as in: simple handwritten html + ES6 modules) I either have to find a way around that, or I start including css somehow...
everyone!
i just joined
!!
any one online?
Welcome!