I'd like to ask your opinion on this. This is a theoretical question.
I'm in a situation where I have an interface shown to a user that uses AJAX to talk to the server. The server-side language does not matter here. I have a form with fields and each of them are deletable. If the user selects a few "delete" -checkboxes and presses Update, then I have these two options to do:
Option 1:
When deleting fields, use JavaScript to remove the HTML immediately and run AJAX on background to delete those fields. This achieves a look of a fast interface -> better user experience. However, if the AJAX call fails on the server side (the fields couldn't be deleted), then the previously deleted HTML fields would give a false assumption for the user (of them being deleted).
Option 2:
When deleting fields, run AJAX, depending on its success, either remove the HTML or do not. This gives accurate feedback for the user, but the form would freeze until the AJAX call finishes = slow(er).
What are your thoughts? Which approach seems better for me to take or should I make it an option?
Option 3: Mark the controls as being deleted (e.g. overlay a translucent gray box with a delete icon on it). Send the request. When it returns, either remove the controls, or change the box to show an error icon for a few seconds (then remove the box).
Allow the rest of the interface to be interacted with while this goes on.
Nice question.
A third option would be to :
disable immediately the controls
delete them when the Ajax returns
This gives the user feedback that something was effectively requested (responsiveness),
while showing also the moment where it is effectively completed.
Also, the user somehow feels the "distant call", which does not induce him in error, because it is was really happens. Anyway, there is nothing meaningful we can do to hide this feeling, because the delay will always be there.
Related
I have a subgrid on my form which I assign a dynamically generated fetchxml query using javascript. When the user clicks on the subgrid's "pop out" button, the query is lost and it displays the default view for that entity.
The user needs to be able to perform multi selection and bulk editing. As far as I know this is not possible for subgrids in CRM 2013 upwards. Is there a way to retain the query when it is popped out?
There's no supported way to interact with a popped out grid. If you started digging into the client side application code, you might be able to find a hook to the new window, but doing so would be unsupported, liable to break, and I wouldn't recommend it.
I was going to suggest hiding that pop-out button on your entity's sub-grid altogether before re-reading that your users need to use the popped out grid for bulk edit.
In that case your best option will be to do ditch the JS and move to a RetrieveMultiple plugin against the sub-entity. RetrieveMultiple plugins should be generally avoided, but from what it sounds like in your case, it's your only option.
And, just to be thorough, are you positive you need dynamic fetch for the sub-grid? Is there any way you could come up with a view that would get close enough to your requirement, even if it's not perfect?
Update:
Based on the additional information you provided in your comment, I can only think of two options:
Implement a custom grid--or modify one of the free ones out there--that allows multi-select and bulk edit
Your custom web app takes the user's criteria, creates a personal view (entity: userquery) for the user and saves it to the database, then your JS on the form sets the grid to that view.
You can do that liks this:
document.getElementById("someGridId").control.SetParameter("viewtype", "4230"); // 4230 is the objecttypecode for userquery
document.getElementById("someGridId").control.SetParameter("viewid", "{11310965-0306-E611-80E5-3863BB36DD08}");
Doing this actually does make the popped out grid load the personal view, but in my tests just now the grid gets upset if you try to refresh it.
This approach has obvious downsides: 1) You have to come up with a way to clean up the personal views that get generated 2) the grid might break on refresh 3) it's unsupported and liable to break on an update.
Still worth considering, I suppose.
A more supported way instead of using unsupported getElementById is to hook a plugin to multiple retrieve of the entity and amend the query in there
Chris
I have a question on the subject of composite attributes that I would be grateful if you could help me with.
I posted this before on other question blogs but got no response I am satisfied with.
I am writing JavaScript that will update the fields (i.e. address1_line1, address1_line2, address1_line3, address1_city, address1_stateorprovince, address1_postalcode, address1_country) in the composite (address1_composite). When the fields are updated the composite does not seem to update. I have to open the composite and close it again. Is there a way of doing this automatically in JavaScript?
I have tried the following ideas:
Idea 1:
Xrm.Page.data.entity.save();
This is recomended at http://community.dynamics.com/crm/b/magnetismsolutionscrmblog/archive/2013/10/22/working-with-dynamics-crm-2013-composite-fields-fly-out-menu.aspx
This is not any good as my customers want to view the composite before saving the page. Also I would not want to save the page for my customers as they do not want this. They would like to decide when to do this themselves.
Idea 2:
Xrm.Page.data.refresh();
This is not really what I wanted as I do not want to refresh the whole page. I just want to refresh the composite. Also it bring up a popup that warns you about not having saved the page which will be annoying for my customers.
Idea 3:
Writing the address from the address lines to the composite.
This feels like a nasty hack.
There is probably more than one way of doing this. I used the function
Xrm.Page.getAttribute("address1_composite")._attribute.setValueForCompositeField();
I do not like this for the following reasons:
This is a hack as it is not using the system functionality of the done button to write the data.
You do not get the system formatting you get with the done button although this will get done when the form is saved so it is not so bad.
In the future if customers are allowed to add their own composite fields it could cause problems as the field names could be different.
It requires me to write extra code for each form that has a composite which has fields with different schema names. E.g. I have to write different code for forms with ShipTo and BillTo addresses as the code for the account form will not work.
Another idea was to set the focus to the composite field after a change has been made to any of the fields inside the composite.
Xrm.Page.data.entity.attributes.get("address1_composite").controls.get(0).setFocus();
This is the best idea so for but it is far from perfect. This forces the user to press the done button and hence the fields will be written. I was hoping for something more automated.
My Question:
What would be great is if there was a way to click the composite done button in JavaScript. This would give me the formatting of the done button and the automation I need.
Update - 14/04/2014
Since posting this question I have been in contact with Microsoft and they say there is no supported way of clicking the done button via a program.
If the field is locked down CRM JavaScript does not send the data back to the server for updating. Another approach would be:
perform the update using JavaScript (so the user sees the change); and
use a server side plugin on the Update event so the value is persisted.
My project is using Wicket's AjaxFormValidatingBehavior to auto-save form content to Session on sort of a multi-tab form with a tree menu (there is no save button on individual tabs, though there is a "Save" button that actually submits the form, runs the validations and saves contents to database). I am facing few issues:
Since the behavior is added to all form components' onChange event, there is a server-trip every time user moves from one field to another. I know that a throttle duration can be specified to prevent this, but its not possible to set in my case as my forms are of different lengths/complexity, many components dynamically generated (including the tree menu). But is there a more elegant solution to auto-save form content (that doesn't have a submit button) rather than this annoying solution.
Another issue I am facing is that post onChange event, on Firefox the component loses its focus after the "server trip" ends. While on IE7 it works fine.
For the first question I think you need to add a pipelining facility, on your components' onchange call a javascript function of your which calls your webapp. You can include a feature similar to the one provided with the throttle duration but page-wide (delay each calls and only trigger the last if it is older than x milliseconds for example).
For the second one, I think you have to use the AjaxRequestTarget#focusComponent in your behaviors, or handle this thing in your "wrapper" as described in the first answer.
I'm using the jQuery Form plugin and more specifically the ajaxForm method to hijack a normal form and post it using ajax. I have a form with lots of rows. Each row has edit and delete options and each section has an add option. Hijacking the form I can work out on the server whether to add, edit or delete but would like the ability to know which button was pressed in the success method back in my JS. Is this possible?
I know there are two params: responseText and statusText and that I can work out the button type in beforeSubmit but I need it when the data is returned which button has been pressed. The reason is that I want to display a form in a light box for edit and add but for delete I want to do something different. It seems a bit naff to check the data coming back to look for a certain string (not to mention flakey and unmaintainable).
Anyone know of a simple solution?
Look at the beforeSubmit option: it's a function that will get called, well, before submit. More importantly, it provides the data. You could look at the data and set a flag that would then be used within the success function. This isn't beautiful, but better than being coupled to the server's behavior.
In this situation, I have often just created two different forms-- one for update and one for delete. Then, instrument them separately.
I am familiar with several approaches to making the back button work in AJAX applications in various situations, but I have not found a solution that will work gracefully in my specific scenario.
The pages I am working with are the search interface for a site. You enter terms in a normal search box, click "go and wind up at a search results page. On the search results page there are a ton of UI controls for filtering/sorting the search results to find what you are looking for. Some of the operations triggered by these controls may take a (relatively) long time to complete (e.g. several seconds).
This latency is fine in case where the user is initially filtering/sorting their results... there's a nice AJAX spinner and so on... however when the user clicks on a search result and then clicks on the BACK button, I would like the page to instantly be restored to the state it was in when they clicked through.
I can restore the states using IFRAMEs/fragment identifiers as a dictionary of page history, but what ends up happening is that when the user first hits the back button the initial page is loaded, then it (re) makes the AJAX query to get the page state back, which triggers the AJAX spinner and another wait of possible several seconds.
Is there any approach that does not require this kind of two-stage load of the page when the user returns to the page via the BACK button?
Edited to add: I am partial to jquery but I'd be happy with solutions that depend on other libraries/toolkits or that are standalone/raw javascript.
Edited to add: I should've added that I'm trying to avoid cookies/sessions because this prevents people having multiple brower windows/tabs open and manipulating different sets of search results at the same time.
Edit: Matt, can you elaborate on your proposed solution (triggering a page change event via fragment identifer)? I see how this would help with BACK button clicks across the same page but not coming BACK to the search results page after clicking on a specific result.
Just use a cookie.
Have you investigated the YUI Browser History Manager?
Try to use localStorage object. Here is crossbrower libs jStorage and WEBSHIMS json-storage
Would it help to trigger a page change event using the "Add some info to the # at the end of the URL approach".
That way, clicking the back button shouldn't actually change the page, and you should be able to restore state without the first page load.
Use something persistent that is tied to the user's profile.
Cookies and sessions are good ideas, but you can also keep those stuff in the database. That gives you an added advantage of being able to save the user's filtering preferences accross different browsing session.(if, for exampple, he was looking for something in the office and then decided to continue searching when he is back at home).
It all depends on the complexity of the filters and weather or not it is something you think that the user will want to use accross diffrent browsing sessions..
Edited to add: I should've added that
I'm trying to avoid cookies/sessions
because this prevents people having
multiple brower windows/tabs open and
manipulating different sets of search
results at the same time.
You can create a random token and assign it to the fragment identifier.
on first page load create a token if no fragment identifier is set
before navigating out, store all the temporary ajax data in a cookie with that token as index.
when hitting back, if you have a fragment identifier set, load the data from the corresponding token in the cookie.
you can even add a "time" field to expire tokens, etc...
sample cookie (JSON):
{"ajaxcache":[{"token":<token>,"time":<time>,"data":<data>}, ... ]}