thanks for the assessment but it doesn't really means that. We're in the middle of integrating a RBAC logic on the resources while before it was all about setting something as private/public. Since you pointed out the issue I'd like to know more about how you would use such functionality:
- explicitly declare if entries can be private/public
- define if users can fetch entries that they own/made
- any more fine grained logic?
ok this tell me that written like that, the features is very misleading. You can ALWAYS retrieve all the data via API on any plan. The data is yours.
The export one is just a commodity to have it formatted on an Excel or CVS file (good for non tech people or for those who dont want to integrate via API to collect data)
By 'retrieve all the data' do you mean I'll have to write a script that goes through the API, iterates over things, and dumps it into a format I would like? Or is there a single 'dump' API endpoint that gives me all the data?
As a Stamplay co-founder, since the thread is getting crowded of many HN users that know this space very well I think that this is the perfect place to share my vision on how programming will evolve
I had to disable Ghostery and AdBlock to get your editor to load properly; I'd recommend taking a look at what resources you're depending on that they're blocking.
Yep you're right, that one solve a very specific problem about monitoring resources. We want to empower people to build products in an easier and more efficient way :)
Hi Amzil, we're rolling out a developer program but at its fist stage it will be only to add (and sell) App Templates. Components are still on us but we will open that too.
thanks for the feedback. You can click on the "i" that appears when you move your mouse over a component to get this modal view with the usable triggers and actions. http://imgur.com/EdGf9Hz
Otherwise you can click the info button on the upper right corner of settings view of every component http://imgur.com/UpAcLdk
I found the project very intresting to follow up (now and in the future).. And since i use HackerNews as my bookmarking service StamPlay just needed to be here ;)
It depends from the service, everyone has its own lock-in. With us you own the data and you can take it anytime, the hard part is to code the backend from scratch on your own.
Yes Cheriot, you're probably right but we wanted to keep it easy to understand. How would you change it? Happy to improve it and make it more "best-practice" compliant and then share it here https://github.com/Stamplay/stamplay-foodme
I disagree with the OP,in a system with dependency injection,it doesnt matter where the injected stuff comes from,only the fact that they are injected is important.
You could have 20 services instead of one it would not make any difference. Since the details and dependencies of the services are encapsulated. I would,however separate the modal methods from the config variables, as it's 2 different concerns.But the rest is totally fine.
It's a matter of opinion beyond that, there are no "best-practices",other than the fact that one should not use any data that is not injected somehow , in a controller.
Same for $http.Of course one might want to abstract some business logic as the application grows,because at some point one might need to do complex stuffs when it comes to api calls(validation,...) but YAGNI over DRY. The code is still testable.
Again the only thing one should NOT do in a controller is DOM manipulation,beyond that anything goes.
I'd say you shouldn't pollute your controller with too much non-UI specific logic - oftentimes, it's worth splitting off some controller logic that is heavy into a service to test it in a more managable fashion & confine the messiness away from the controller.
When there are no authorities, there are no compliance issues :)
The roll of controllers and link functions isn't to hold logic, it's to wire things together between the scope and services/models. For example, having a userStatus.getUserCall() is a step in the right direction. Now have the service check the response code and use the user data to create a single user object that can be returned/resolved. So your controller becomes userStatus.getUserCall().then(function(user) { $scope.user = user; }) or since angular templates are promise aware, you can reduce it to $scope.user = userStatus.getUserCall(). Now the NavbarCtrl and the MenuCtrl only need to share that one line rather than ~10!
thanks for the assessment but it doesn't really means that. We're in the middle of integrating a RBAC logic on the resources while before it was all about setting something as private/public. Since you pointed out the issue I'd like to know more about how you would use such functionality: - explicitly declare if entries can be private/public - define if users can fetch entries that they own/made - any more fine grained logic?