let me try on my macbook
// server side
$.post( "http://localhost:5425/app/v1/present", data)
.done(function( representation ) {
$( "#representation" ).html( representation );
}
);
which line is the error?
Is the error on the server?
The HTML should be wired to the blog.js actions. If you look in blog.js it should look like this:
var actions = {} ;
actions.edit = function(data) {
data.lastEdited = {title: data.title, description: data.description, id: data.id } ;
present(data) ;
return false ;
} ;
actions.save = function(data) {
data.item = {title: data.title, description: data.description, id: data.id || null} ;
present(data) ;
return false ;
} ;
actions.delete = function(data) {
data = {deletedItemId: data.id} ;
present(data) ;
return false ;
} ;
actions.cancel = function(data) {
present(data) ;
return false ;
} ;
You can also run the sample without a server, you should uncomment the client code and comment the server code
sorry have to go
OK, I got it working. The problem was that I was using the wrong url in my browser. Instead of C://crud-blog/blog.html, I was using http://localhost:5425/app/v1/init
Thank you for all of your work!
@jdubray Hi JJ its me again, I am looking at the code of your website http://www.ebpml.org and I am trying to get an understanding of how SAM can be used in the "real world". Lets say for example, that I published the crud-blog example where a jquery HTTP request is made to the server. Is it safe to expose the server address and file structure to the client? How did you address security in your site?
In the http://www.ebpml.org/about page, I simply make a request to the feed.xml file so there is security (but that's server side)
On the Web there is only one security architecture for back-end APIs, either it is safe for anyone to call them (say like feed.xml) or you need users to login and either call the API with a valid session token from the browser or you need to call them safely from the server (say with APIKey)
You should never bring API credentials on the browser (say like API key), it is 100% unsafe.
I am a server side guy, I don't believe much in complex browser-based apps. I like the UX of SPA but I prefer when most of the SPA comes from the server rather than making AJAX calls from the browser.
That's why SAM is 100% isomorphic and I came up with it because I felt that the Front-End driving API signatures was the wrong thing to do.
yes, you would want the user to login and if you need to call the API from the browser, I would use a session token. In general API Gateways (such as AWS, Azure, ...) don't implement that pattern, they prefer a server to call the API with an API Key because they implement things like throttling, ... but if you implement your API say with Node.js then it's not hard to manage session tokens.
Just published an implementation of SAM in AWS Lambda with a DynamoDB session manager
https://github.com/jdubray/sam-samples/tree/master/crud-blog-lambda
https://github.com/jdubray/sam-samples/tree/master/crud-blog-lambda
What did you have in mind?
I want to change color (for example) of my view-component and I would like to select this component from DOM, and set style. In my case (as I understand) we dont have state-representation, so there is nothing to pass to view.display function. Where I should store the function that selects component from DOM and sets new style? Is it state-representation function? Can you provide some small example? Thanks. And sorry for my English.
I want to change color (for example) of my view-component and I would like to select this component from DOM
You should not do that, the whole point of V = f(M) is that you (almost) never manipulate the DOM, the color should be part of the model and when you generate the stateRepresentation based on the new application state.
you can easily adapt this example to draw the rectangle in a different color
https://github.com/jdubray/sam-samples/blob/master/js-rectangle/rectangle.html
https://github.com/jdubray/sam-samples/blob/master/js-rectangle/rectangle.html
the key to understand is that with V = f(M) and SAM's nap() function, you never need to manipulate the DOM
The whole point of SAM is to avoid DOM manipulations
'The whole point of SAM is to avoid DOM manipulations' - and how about performance? I think element.classList.add much faster then root.innerHTML
you have to try it
I'm having trouble understanding how to deal with events that (I think) don't change the model. Say I have a button "Create new user" that displays a dialog to input user data. This action ("display dialog") is somehow managed by the model? There are no data to be evaluated by the model, only fancy visuals, so would I need a flag on the model to identify this click event? Or this event would be outside the SAM cycle?
@f-matos yes, in general this will be mediated by an action-model-state loop. The action will translate the event/intent into a proposal to the model (displayDialog:true), which the model could accept or reject based on the application state. The state representation will render a dialog. In general you want 100% of the application state to be managed by the model.
Doesn't this create a lot of complexity to the model? The more actions you have, the more states you have to deal with and more bloated the model is.
If for every action all states are evaluated, it'll become troublesome to prevent side effects (as in, one action proposal affects an unintended state), unless you start naming your proposals "SpecificNameThatImSureIsUniqueFlag"
Why should the model care - or even know - about the view presenting a dialog? Unless the state "dialog open" intentionally changes how other elements behave, I don't understand why would it be beneficial to give this information to the model.
If for every action all states are evaluated, it'll become troublesome to prevent side effects (as in, one action proposal affects an unintended state), unless you start naming your proposals "SpecificNameThatImSureIsUniqueFlag"
Why should the model care - or even know - about the view presenting a dialog? Unless the state "dialog open" intentionally changes how other elements behave, I don't understand why would it be beneficial to give this information to the model.
Everything is tradeoff. Single State Tree approaches are becoming pretty standard these days. People have tried to decompose the application state in components and that's not pretty.
Please note that SAM supports parent/child instances so the effect that you are talking about is not given at all. These ancillary aspects of the application states should be implemented that way and the parent model should only be presented with key proposals such as a { newUser: {name, ...}}
Please note that SAM supports parent/child instances so the effect that you are talking about is not given at all. These ancillary aspects of the application states should be implemented that way and the parent model should only be presented with key proposals such as a { newUser: {name, ...}}
@f-matos For small UX effects, such as a spinner, it's ok to manipulate the DOM onEvent as long as the resulting state does not need to know it happened (it will be automatically cleaned up on the next rendering of the State representation).
The key to understand the SAM pattern is that with SAM you are/need to be always in the position of associating a "unit of work" to an event. Component publish events, they have no idea what happens next. The unit of work is responsible for changing the application state. The problem is when you think you are better off working locally and ignoring global application state changes. There is a (rather big) mismatch between the view and these units of work, they can't be driven by the view. You need "adapters" that will translate these events into the call that will ultimately be responsible for updating the application state. Coupling events with application state mutation is, IMHO, the worst thing you can do.
Hi. In the rocket launcher example, ¿What is the purpose of this line?
present = present || model.present ;When i would want to pass a custom present function? in which cases?
Another question: It's a bad idea to deal with a model directly from an action instead of passing a associative-array like data to model.present() ?
For example:
function actionsLaunch()
{
model.start() //Set model->started member to true
model.present()
}Instead of:
actions.launch = function(data, present) {
present = present || model.present ;
data.launched = true ;
present(data) ;
}I'm trying to port it to PHP, and see how it look in an Object-Oriented like style.
Thanks you