In general we call the jqgrid as in$("#grid_loc").jqGrid({});
But i want to specify the context like $("#grid_loc",context).jqGrid({}). But this is not working. Can somebody help in this?
I have to load server side data using url option.
Infact i occured to have this, as i have tabs on my page.
In each tab, i have to have a jqgrid, not different grids but same grid with different data .
Here i am getting the tab context using var tabset = $("div.tabset");
newdivid = $("div[class*='active_tab']",tabset).attr("id");
var newmenudivid = $("#"+newdivid);
And
the grid code as
$("#grid_workflow", newmenudivid).jqGrid({....});
I have been trying to find out a way to do this. you can find some of my effort in the comments section of the link
how to develop same jqgrid in multiple tabs
i was successful with id overwriting for the same purpose. But that is not a good way though. So i am forced to have another approach ie. context
I suppose that you misunderstand some important things which corresponds to id attribute. The most important that all elements on the page having id attribute have to have unique value of the attribute. In other words the ids have to be unique over the whole HTML page.
So if you need create for example tree grids inside of tree tabs you have to define different id attributes for every grid. For example; grid_workflow1, grid_workflow2, grid_workflow3. If you create the tabs and grids dynamically then you can have some variable in the outer scope (for example global variable) and increase the value of the variable. You can construct id of the grid using some prefix (like "grid_workflow") and the value of the variable. In the way you can create multiple grids with unique ids. Many JavaScript libraries uses the way to generate unique id attribute. Ij you want you can use $.jgrid.randId() method which will returns you unique strings which can be used as ids.
Because of the syntax $("#grid_workflow", newmenudivid) you should understand one important thing. I would recommend never use it. The reason is very easy. It could help only if you have id duplicates. In all other cases if will works exactly like $("#grid_workflow") but slowly. The reason is easy to understand. Web browser hold internally the list if all ids on the page and if you use getElementById method directly of indirectly (in $("#grid_workflow")) the searching of the element with the required id will be like searching in the index in the database. So you will have best performance results. If you use $("#grid_workflow", newmenudivid) then you don't allow web browser to use the index of elements by id. So the usage of context will follow to slow searching throw all children elements of newmenudivid. So you should avoid usage of jQuery context with id selectors.
Related
I'm using Google Data Studio to visualize results from various queries (from different tables within the same BigQuery-database).
For this reason, I created and use multiple data-sources-connectors. Each one of them has a SQL query included and makes use of an defined input parameter (which can be changed by report editors) - called "userid". It is the same id for all queries and resulting charts.
However, when I click "Manage URL parameters", I'm not allowed to use the same URL parameter for more than one data source (instead they are called ds0, ds1, ds2 etc - although they all end up being used as "userid").
If I add a data source under File - Report Settings, a new field "userid" appears, which I can alter - this will update ALL charts in the report with the very same userid (as expected). This works, but I do want to make use of an url which delivers an report with all updated queries depending on ONE userid.
Therefore, I guess I'm overseeing something - it should be possible to just use one query parameter to update the same "userid" for all queries in all data connectors? Or have I overlooked the possibility to fire multiple queries within one data source connector? Or is it expected to create a looong url full of redundant query parameters in this case?
I'm curious for your input!
Best regards :)
There does not seem to be any good solution for this.
For now the best workaround seems to be to just repeat the parameter multiple times -- it's ugly but it works. For example, use the URL parameter mapping screen to call the parameter u1, u2, etc., and then just pass all of them:
?params={"u1":"foo","u2":"foo"}
(URL encoded of course)
The ugliness is mostly for us developers: it violates our sense of DRY and clean code, and makes the URL much longer than it needs to be. However, most people don't care or know about the URL parameters so its irrelevant to them.
The bigger downside is that when the URL is distributed to clients (bookmarks, mobile apps), every time new data sources are added that require the same URL parameters, a new URL has to be distributed to clients for no good reason. A workaround for this is to build the URL dynamically via a simple redirector function.
This issue https://issuetracker.google.com/issues/180705297 is a feature request to implement this capability.
If you group the elements that you want to control with the same parameter (select and then shift G) then it will give you options to select the data source and the params box to apply to the group.
I have 2 entities, let's call them Parent and Child, with a 1:n relationship, where one Parent can have 0-n Child.
The Parent has two fields, Parent.Number and Parent.Name. When creating the Child via the plus button in a subgrid of Parent, the Child.Name should be preset to:
Child of Parent.Name (Parent.Number)
I've tried lots of different approaches wich all led to dead Ends. Some of them were:
Calculating via BusinessRules
Calculated Field on Child in combination with BusinessRules
Calculated Field on Parent, transferring the precalculated Text to the Child entity by Mapping.
Calculated Field on Parent, using a BusinessRule to set it's value as the default value of Child.Name
Using a workflow for Child.OnAfterCreate (works, need it in the OnFormLoad, though)
(For brevity I will not go into details of why each approach did not work, but will elaborate on request.)
Is there any way to achieve this without the use of Client side Scripting that I am not aware of?
Without using JavaScript (which is a solution) I can only suggest the following approaches (of which you can use some or all) which are all compromises really:
Change your requirement to make the name as shown below. A business rule on the child can then be used to populate this information. It can access the name but not any other field, i.e. number.
Child of Parent.Name
Use a quick view form to show the parent details on the child. This allows users to see the data even if the name is not set correctly.
Use one of the above, and the workflow. So the correct value is still finally set and you provide the user with as much information as possible until that point.
Remove the name field from the child form body. Use a workflow to set the value, when the form is saved. CRM displays names at the top of the form so it will appear as soon as they save but they wont see an empty field before that.
Change the name of the parent record to as shown below, you can then use that in business rules on the child.
Parent.Name (Parent.Number)
I want to have a form which has a simple 2 step process:
(If a person on has one school assigned to them then skip straight to step 2)
Step 1 - Select a school from a drop-down list
Step 2 - Enter the required data from a data-entry form. Certain fields are disabled based on which school was selected.
I have had a look at the various methods for creating 'wizards' and at using partial Views. What is the best way to handle this? I was wondering if using AJAX is worthwhile considering or just having a two step process in the form.
James :-)
You should absolutely do this via ajax so your options are either
use small partial views. your view logic determines what to disable/enable
(probably easier and more lightweight) use json to get a list of property names to disable.Then you can simply disable them via jQuery ideally by iterating through each item with the .each() call.
See: looping through JSON array in a jQuery list
for a use of the each call.
got jQuery getJson, see: http://api.jquery.com/jQuery.getJSON/
so:
1. getJson to get the results from a controller
2. enumerate using .each() and set the property
$("#" + yourFieldName).attr("disabled","disabled");
When you have more than one jqGrid on the page at the same time, their child-element ids can conflict. You might want to have three or four identical grids stacked one above the other, showing the same data but from different years.
Child-element ids should have the table-id prepended to them. Is there a "fully-qualified|verbose ids" setting that does this?
Thanks
First of all I find your question very interesting, so +1 for the question. What you find out can be really large problem which can be difficult diagnosed. So I recommend you to place the corresponding suggestion in the feature request on http://www.trirand.com/blog/?page_id=393/feature-request/.
Now about the workaround possibilities. The easiest way is to generate an unique Ids for different grids on the server side. But it is of cause not always possible. You can add an id_prefix as an additional parameter of your server code which produce JSON/XML reply from jqGrid. Then server should add this prefix to all ids before sending back to jqGrid. This workaround is not nice but it will work.
Another way which I see is the changing of id of all jqGrids rows with respect of jsonReader (see http://www.trirand.com/jqgridwiki/doku.php?id=wiki:retrieving_data#jsonreader_as_function). If you add to the jqGrid the parameter like following:
jsonReader: { id: function(obj) { return "BlaBla" + obj.id; } }
then all ids in the table will receive prefix "BlaBla". If you use jqGrids on your page only to display data in the grid this can be your solution. You should don't forget about possible new problems which produce this workaround. If you use master/detail scenario, Edit/Delete etc you have to take in consideration, that ids of grids will have prefixes now. So you will have to include additional code in evens like onclickSubmit, serializeRowData, serializeGridData and so on to cut the prefix before the usage of id or before sending ids to the server.
I've been having a look at several MVC frameworks (like rails, merb, cakephp, codeignitier, and similars...)
All the samples I've seen are basically plain and simple CRUD pages, carrying all the infr needed in the querystring and the posted field values.
I've got a couple of apps made with some sort of framework built with classic asp.
This framework handles some CRUD stuff a little more complex than the examples I found.
Something like master-detail, filtering by example, paging, sorting and similars.
I have a controller class that it's just a finite state machine, that goes thru diferent states (like new, browse, filter, show, etc.), then performs the appropiate action depending on the event raised and finally retrieves the neede info to the calling page.
To achieve this I have several hidden inputs to keep the state of the web page (like current id, filter criterias, order criterias, previous state, previous event, well, you get the idea)
What do you think would be the finnest approach to achieve this kind of funcionality?
hidden inputs built in the view and used from the controller??? (I guess that would be the equivalent of what I'm doing right now in classi asp)
--
(added in response to tvanfosson)
basically, my question refers to the third category, the context-dependent setting (in respect to the other two categories I agree with you) the info I was storing in hidden fields to store them on the querystring, I guess that when you click on the "next page" you include everything you need to save in the querystring, right? so that piece of query string gets appended in each and every link that performns some kind of action...
I'm not sure, what are the advantages and disadvantages of using the querystring instead of hidden inputs???
I use different strategies depending on the character of the actual data. Things that are preferences, like default page size, I keep in a Preferences object (table) that is associated with the current logged in user and retrieve from there when needed.
Persistent settings associated with the current logon, like filter settings for a page, are stored in the user's session. Generally these are things that if a user sets them in the current session they should remain sticky. I think filter settings and visibility are like this. If I filter a list, navigate away from it to drill down into a particular item, then come back to the list, I want my filter settings to be reapplied -- so I make it part of the session.
Context-dependent settings -- like the current sort column or page number, are controlled using query parameters. Paging and sort controls (links) are built with the appropriate query parameters to "do the right thing" when clicked and pass any necessary query parameters to maintain or update the current context of the control. Using the query parameters allows you to use an HTTP GET, which is bookmarkable, rather than a POST. Using hidden form parameters makes it much harder for the user to save or enter a URL that takes them directly where they want to go. This is probably more useful for sorting than it is for paging, but the principle applies equally.