With ember-data 1.0, is there any way to wrap up a set of changes to a record and only apply those changes once they've successfully hit the server?
My use case is a simple one - there's an 'edit' modal for a Post that's triggered by an 'edit' button. I'm trying to find a way to emulate a traditional form that only updates the Post's attributes when a 'save' button is clicked and the server confirms the patch.
I can use one-way bindings in my TextFields in the modal, but that still doesn't solve the problem of delivering those changed attributes to the server without storing them in the record first.
Is there a way to duplicate a record and use it to persist the changes before throwing it away?
Duplication doesn't exist yet, there is talk of it.
Technically the values aren't persisted on the record yet, they are stored on a _attributes hash. On any non-save step (cancel, exiting the route w/o save) you can rollback the record.
Related
I am building a review form that will post to a single model in my database. This form will have multiple sections, each with its own set of questions. I want the user to be able to complete a section and hit a submit button that will save the progress and redirect them to the next section. In essence I want to create an in progress status for the review with the idea that as all sections are finished the user can hit a complete button that will run my validation on the entire form. However, I do not want to allow posting information to the database that has not been cleaned.
I've been thinking through this trying to work out what I need to do and believe the best bet would be to have a complete button on the last page that changes blank to False for the fields of the form. I believe this would allow me to fill out each form and post it to the database as all fields would start as optional but then for that specific model instance the click of the button at the end would institute a change making all fields required, thereby running validators to ensure the form is complete. I believe this will also allow for saving progress and returning to it later if interrupted during completion of the form.
Can anyone provide any insight on if this is even possible? If so does anyone have examples that could guide me?
You can store the unvalidated data to the user's session. The final stage pulls all previous step data out of the session for validation. IIRC the Django form wizard does just this so you don't have to write it.
I might instead do this client-side, using one big (probably Crispy) form, and some client-side pseudo-submit buttons that just invoke Javascript to hide one section of the big form and reveal the next. The final one is a real submit, and redisplay of the whole thing if there are errors.
I have a page Item on Apex 19.2
In page validation where i'm setting the value of the item : P1_MyItem. The value is set properly in session state. However it's not reflected immedialy in the html item. I still need to reload the page to get the right value in the item.
Is there any way to reflect it immediatly please ? (without reloading the page)
Thanks.
Cheers,
You need to ensure Items to Return lists any item that is updated within the PL/SQL, that you would also like updated within the web page once the dynamic action is completed.
As opposed to 'Items to Submit', which sends any information in pages items the browser is aware of to the database, before execution of the PL/SQL block.
Page processing now defaults to using Ajax. So, if a validation error occurs, the page is no longer re-rendered by default because the assumption is that validations will not change session state. If you want to see your changes, you'll need to locate the page property named Reload on Submit and set that to Always.
But, of course, that means the page will be re-rendered/re-loaded which is what you're trying to avoid.
Also, it's not possible to set the page property to Reload on Submit if you want to use an Interactive Grid on the same page. It requires the option Only for Success, so you have to refresh the page item somehow else.
I would like to crate a form whith two submit buttons: Save, let's say, and Back to edit. (The form is meant for a preview / confirm view of stuff that is currently being edited).
For obvious reasons the Save button has a formaction attribute with value post and the other button get. For the post action to work, I include the usual csrfmiddlewaretoken in the form.
So far all works well, the only problem is that the csrfmiddlewaretoken value is now included in the GET requests (which seems to be discouraged for security reasons).
Currently I add some custom javascript that finds all submit buttons with get action and adds a click handler that removes the csrfmiddlewaretoken from the field before submit. This seems a rather wierd and roundabaout way to do things.
Question: Is there a better / more standard / more stable way to handle this situation?
Edit: Why do I want to use get requests for some form actions?
Well, I would like to stick to the rule to use POST requests (only) for requests that change data (and in that case respond with a redirect).
As an example, think of a form where the user can edit ("page A") some fields, and then can press "preview" (a GET action), which leads "page B" where the same form is presented, but readonly, with a preview image generated by the system. If the user is happy, they can press "save" (a POST action) which will actually save the data, or they can press "back" (a GET action, similar to the Browser's back button), to continue editing the data. I would not be happy to implement this "Back" operation as POST, as this messes up the interaction with the actual Browser back button etc.
In this simple example, one could of course ask the user to use the browser back button instead of a form button, or (probably?) use javascript to simulate a browser back. But with slightly more complicated flow control a simple "back" is not an option.
The problem is that you send GET request from the form that contains your CSRF token. I would rather recommend PUT request than GET request. The CSRF token value is not exposed on the URL because the PUT request allows the body value to be passed.
About HTTP PUT method
Is there a way to distinguish access through external link (e.g. from history, or from other site) or access by link from other page of the same app in beforeModel handler?
Here is my case:
If user accesses my app by direct link and requests route requiring authenticated user, I make a transition to index route and show popup with an authorization form.
If user is already on my site and trying to access the requested route requiring authenticated user, I abort transition and show the popup on a previous page.
I have no separate page for authentication.
My current work around is to check some strange private property called sequence of transition object which has been passed to beforeModel handler, if transition.sequence === 0, then user came from "outside", otherwise user follow by link "inside" my app.
I think this is a bad way to achieve the goal, core developers can remove sequence property any time.
So, is there any clean way to distinguish whether current route was requested from "outside" or "inside" of my app?
I'll appreciate any help, thanks!
P.S. EmberJS v1.10.0
P.S.S. Sorry for my English
If you want to avoid using an internal call you could keep track of the history in the application route something like this Implementing a "conditional" back button in ember.js
But in your router would probably be better since controllers are going away soonish.
You could probably use http://emberjs.com/api/classes/Ember.Route.html#event_didTransition
UPDATE after chatting
Logic for counting, aborting, etc transitions can be done in the willTransition action in application route http://emberjs.com/guides/routing/preventing-and-retrying-transitions/
I configured my Ember App to run with the localstorage_adapter.
I am new to Ember and probably, I don't grasp all its details yet. Still, from what I understand, when you refresh the browser the ember store data should not be lost. Obviously the localstorage is not affected by a browser refresh.
This is what happens:
1. after login, I fetch the data from the server and store it using store.push() or store.pushMany()
2. play around with the application
3. at some point hit a browser refresh (or on my Android phone when I hit the home button, the browser get's closed and when I open it again from the running applications window, it opens and does a refresh by default)
4. the page which I was on gets messed up
For example, I'm on page where I display the user name, a question and a list of possible answers. Please note that there are 20+ questions in store. I know this by using Ember Inspector. I hit refresh, now the store has 1 user entity (the logged user) which is fine, 1 question only (not good at all), the one which was displayed on the page, and the answers store is empty. All other entities (which have nothing to do with this page) are gone too! So what I can see on my web page is the user name and the question's text, no answers, no way to move forward.
Is this supposed to happen? The "in memory" store gets cleared and not repopulated from localstorage?
thanks!
Is this supposed to happen? The "in memory" store gets cleared and not repopulated from localstorage?
Yes, it is supposed to happen. To understand why, first remember that the localStorage in your browser is seen as a server. To Ember-Data, there's absolutely no difference between your localStorage and a Rails server with a REST API. Ember-Data treats them both as asynchronous data stores that it communicates with through an adapter. The LocalStorageAdapter is no different.
What does this mean? It means that your store only gets populated with records that you specifically request. Just as Ember-Data doesn't try to get all of the records from a Rails server at startup, it doesn't try to get all of the records from your localStorage at startup. This is by design. Ember-Data doesn't play favorites; it treats all adapters equally.
In order to repopulate your store with entries from the localStorage, use the store's find() method like you would in any other situation. The calls with be quick, although still asynchronous.
Also, as Beerlington mentioned, you must save your data explicitly if you want it to go into the localStorage. The store won't place it there automatically.