i have a textblock in mainpage.xaml. I have another page which has a textblock whose value is bound to observable collection and its value changes depending on user events on that page. How can i bind the textblock value in this other page to textblock value in mainpage.xaml?
Can anybody please guide me to any resources or examples which may explain how to do this or any workaround?
Well, you can't directly bind properties of two controls on different pages since they aren't displayed at the same time. You'll need to store your state elsewhere and retrieve the values from there.
Basically you'll need to store your application state somewhere, either inside the App class or singleton/static properties. Alternativelly you could persist the state between pages (to a file or setting) and retrieve it again when loading the page.
In any case you should bind the controls in both pages to a view model which would retrieve the values from the application state or itself be stored there. This way the values set from one page will reflect on the other one.
Depending on how you navigate between pages you might be able to take advantage of parameters as well (Frame.Navigate(typeof(OtherPage), parameter)) but you're limited to tranferring only basic types this way, so you'll be able to transfer ids but not complete objects.
Related
I don't see the benefit of having hidden input? If you set the value of the hidden input why not just use that value at the point where you reference this hidden input?
There are reasons for this but I just don't know them.
They're used to pass data that will be needed when the form is submitted. One of the more common cases would be a form allowing users to edit some existing entry. You'll need to know which entry they're editing so that you can update the correct row in the database when they submit the form. The user doesn't need to edit (or even know) the ID of the entry though, so a hidden field works well here.
Other options
URL parameters:
This could also be done by building the parameters into the url that the form is being submitted to:
<form action="save.php?entry_id=1234">
but this means you have to handle building the URL properly and escaping the data yourself, and the length of URLs servers will accept is limited so it may not work for longer data. So generally using hidden form fields is the easier way to go.
Session variables: When the edit page loads you'd store the entry ID in a session variable, and then retrieve it on the page that saves the changes. That's a lot easier to mess up though; setting up and maintaining sessions may require adding code in several different places, and then their session could expire in between loading and saving, and you have to make sure it works if they have multiple windows or tabs open, and you have to make sure it doesn't do weird things when they hit back/forward. Because of all these potential pitfalls it isn't a great way to solve this problem--passing the id with the data being submitted is a lot more robust.
Cookies: In many languages/frameworks sessions are tracked using cookies, so they're basically the same solution. The pitfalls are the same as for session variables even when sessions are tracked by other methods though.
It sends additional information that the user doesn't know or isn't interested in (such as a security token) so that if the form is submitted twice, you can compare the tokens and reject/accept that submission.
Not using hidden inputs means the server needs to keep track of these values instead. This requires the server to keep state, which could otherwise be embedded into the request (form) itself. This may make the page RESTless (not RESTful), i.e. break the self-containedness of an HTTP request. If you did keep track of hidden values on the server, you would at least need to embed a unique token into each form to deal with several different unique submissions of the same form. The cleanest way to embed such a token is, drumroll, through a hidden input. :)
The Hidden Input field is not displayed on the page, so it does not allow visitors to add anything into it. The Hidden Input allows you, the webmaster, to add specific information to a form, to be passed through the form processor along with the data entered by the visitor.
For example, if you have several forms on different pages on your website, you could use a Hidden tag, in each form, that identifies which page the visitor was on when they filled out the form.
The hidden input is for when you want to send information back on a post without the user seeing the data as a UI element.
The web is stateless - ergo, when a POST comes in, you have only a couple pieces of information to determine what you need to do; Session, Url, some ServerVariables, and the Form data passed to you.
If a piece of data is transient that is not useful for putting in the session, sometimes it is prudent to put into a hidden field.
They can also be useful for storing data on the client side for rich internet applications (such as a product Id that is easily accessible to use in ajax calls).
because you have a php while loop with alot of different objects which you can't get the id's of later and you just save them by storing them in the hidden input... also i like them to be a security check to know my users aren't messing with my post variables through tamper data
If you build a tag system like the one here. You can set the values into a a hidden field.
Consider a form that's being displayed to edit a record in a database, one technique is to bake the id of that record in a hidden input and have it submitted back so the server can read it back.
It's also used frequently for security purposes (as genesis has said).
Another reason might be for javascript-oriented scenarios, perhaps for non standard controls such as treeviews, where the concept of a selected node cannot be represented as a normal input. Instead, JS can manipulate a hidden field and store the node's name/id in it, so that it can be read by the server.
It's just what it's name implies, a form input that is hidden from the user. It's a way of getting data to the server that the user doesn't need to see or control directly. This is especially useful for maintaining state.
I'm working on a project right now where a user creates several items that are represented as data objects in JavaScript and serialized when sent to the server. These data items are expressed one way when displayed to the user with HTML, another way as JavaScript, and a third way when sent to the server. A hidden input is the only way to accomplish this. (Okay, fine not actually the only way, but certainly the most reasonable way).
For example, if you have a form to edit an entity from you data model, you could use an hidden input to place the id of the entity you are updating, since you don't want to have this value put in the text input field to be posted back to the server. the hidden field will be posted to the server as if it were part of your form.
All answers explained why we using hidden inputs in form but here is the security concern.
Security concern
Using hidden inputs in forms can be tampered/changed by View source or using developer tools in any browser.
Solution
Use cryptography in your code/project to avoid changing values in
hidden input by attackers/hackers.
Generic Solution
If you want to store any data in hidden input first encrypt the data and store them in hidden input.
When form is submitted then decrypt them if values not change then save your data.
If changed then show some error or else.
Further reading
Cryptography
Wiki Cryptography
For framework Developers
Other framework developers can find cryptography in their framework.
Cryptography in Laravel(PHP)
Cryptography in .Net
Cryptography in Django
As name implies, Hidden fields are similar to other input fields except one difference i.e, hidden fields are not actually shown to the user and hence can not be edited by the user.Its value can only be set at the time of execution i.e. may be form submitting which posts the data to the server.
But the data set on the html page i.e. name/value can be seen in the html source of the page (view source of the page).
We are currently using a generic report which will be used differently by multiple usergroups. We have made this possible by creating linked reports with different settings of hidden parameters (such as 'show column x', 'enable feature y').
These settings (parameters) are needed on other reports as well, so we pass them along using the Go to ... Action.
To create the look and feel we are after, we are passing some additional parameters as well, HTML Viewer commands and Report Server commands such as &rc:Parameters=False (reference).
Unfortunately, this leaves us with only the option Go to URL, since Microsoft hasn't implemented these commands for Go to Report. This means we have to pass our settings (the hidden parameters) along in the URL. This results in a security issue, example given: &PARAMETER_ENABLE_FEATURE_Y=False.
The user might notice this parameter in the URL and is so given the possibility to enable this function by editing the URL to &PARAMETER_ENABLE_FEATURE_Y=True.
So my question is: how to use an Action in Reporting Services while preventing users from editing our sensitive parameters and while being able to use HTML Viewer commands and Report Server commands?
You will never get complete security in this sense if you absolutely have to use URL based parameters.
When navigating via the URL, the only way you can hide parameter values without hard coding them is to make them data driven. In your scenario however this will not be 100% secure as you will still need to pass the value that populates your data driven parameters.
This level of obfuscation is probably enough and can be achieved by collating a list of either every parameter combination or just the ones your need and assigning it an ID that you can call in a dataset. This can obviously still be changed by your users should they get curious and can be a faff to maintain.
I would say your only other option is to hide the URL bar completely by providing a 'landing page' for your reporting and displaying everything in an iframe. This frame can be targeted with a javascript link in your Go To URL:
="javascript:void(window.open('URL to open','iFrame Name'))"
If you are able to though, I would advise you group your users into Active Directory security groups and then maintain a collection of permissions and customisations per group. You can then check which groups a user is a part of using custom code similar to the answers here and return the required parameter values accordingly.
Doing things this way will also enable you to maintain which groups can see what from a central location, assuming you have rolled out the same parameter structure across all reports.
I am developing one application, in that I have 3 pages. In first page I have List Box with some data and in 3rd page I have application bar for navigating to first page. I will get the list box data from the server. Whenever I am binding the List Box with server data, it is rendering properly but if the user navigate from 3rd page to 1st page using application bar then List box is not updating with fresh data, it is still displaying old data. If user comes to first page using back key press then new data is rendering.
I am using observable collection to bind List Box data and used NavigationService.Naviagte() for navigation.
Help me to resolve this issue.
Thanks in advance.
I am not very sure about your problem because you haven't cleared the whole context. But assuming that your data is refreshing on back key press, I can suggest you use NavigationService.GoBack() instead of NavigationService.Naviagte(). The former method call is equivalent to back key press. NavigationService.Naviagte() creates another instance of the page in the memory while NavigationService.GoBack() takes you back to the previous instance. Hope this helps.
As I understand everything is fine when you start. But the update is not happening upon second return, i.e. Through navigation.
My thought is that all your code to do this is in the constructor, and since the page is not removed from memory the constructor will not be called.
Two solutions move the code to a loaded event. Simply in the constructor write this.loaded += eventname;
Or you could put code in the onnavigatedto event. Write as a new function protected override onnavigatedto.
Putting it in the navigatedto, would probably make your app less responsive if you do server calls. If you have the code in the loaded event then the information will be uploaded when it is done. Which means the user will have a moment with old information. You could then introduce a waiting screen if it is an issue.
I have a tabbed dialog that has 4 tabs. The parent component is an mx:TabNavigator and each of the tab's views are custom MXML components inside an s:NavigatorContent. The data for 3 of the tabs has to be sent as one unit to a back end service. I'm trying to work out the best way to have the 3 tabs access the data that's to be sent down as one unit. I currently have one .mxml file that defines the top level mx:TabNavigator with each of the 4 tabs representing the s:NavigatorContent defined in it's own separate.mxml file to keep the file sizes fairly short. My current approach is to have each of the tabs load their data from the back end service in their creationComplete handlers and store it in a common class for the data model shared by the 3 tabs. This solution is OK except:
The creation complete handler for the first tab is called on application startup even though it's not the first visible component (i.e. there are other parts of the UI that the user sees first). I'd prefer to have true lazy loading where the data is not loaded until the tab becomes visible to the user.
If the user edits data on the first tab, then navigates to the second tab for the first time without hitting the apply button, changes made in the first tab are lost, because the creation complete handler of the 2nd tab will load the data model shared by the 3 tabs.
What I ideally want is:
True lazy loading; data is not loaded until the user clicks on a tab and it becomes visible.
Have it so that when the user hits apply on any of the 3 tabs the current entries on each of the 3 tabs is sent down to the back end service.
Thanks very much if anyone can advise on this. I can explain in further detail if needed.
I'm trying to work out the best way to have the 3 tabs access the data
that's to be sent down as one unit.
Best is always subjective. The easiest way is going to be to create a single variable for your shared data, and pass that instance into each relevant tab.
In some cases you may store the data in some central location, and the use Dependency Injection to inject that data into the relevant tab components that need it. Dependency Injection is implemented by a bunch of Flex frameworks, such as RobotLegs or Swiz.
An alternate option is to use a Singleton approach or static variables on a class to share the data between your multiple tabs.
My current approach is to have each of the tabs load their data from
the back end service in their creationComplete handlers
Why use creationComplete? The creationComplete event is fired after the component has completed it's layout routines and layout routines of it's children, and then everything is ready to use. I assume the act of loading more data, will force a lot of your components to have to go through their rendering process again. You may consider moving this into an earlier spot during the lifecycle, such as initialize or preinitialize.
1) The creation complete handler for the first tab is called on
application startup even though it's not the first visible component
(i.e. there are other parts of the UI that the user sees first). I'd
prefer to have true lazy loading where the data is not loaded until
the tab becomes visible to the user.
This would be expected behavior, based on the way that TabNavigators initialize. You can look at creationPolicy for more information. You can rewrite your 'load data' method to operate on the show method of the component, perhaps?
2) If the user edits data on the first tab, then navigates to the
second tab for the first time without hitting the apply button,
changes made in the first tab are lost, because the creation complete
handler of the 2nd tab will load the data model shared by the 3 tabs.
You can force a save of the data on the hide event of the component. Or possibly on the change event o the TabNavigator.
I don't see the benefit of having hidden input? If you set the value of the hidden input why not just use that value at the point where you reference this hidden input?
There are reasons for this but I just don't know them.
They're used to pass data that will be needed when the form is submitted. One of the more common cases would be a form allowing users to edit some existing entry. You'll need to know which entry they're editing so that you can update the correct row in the database when they submit the form. The user doesn't need to edit (or even know) the ID of the entry though, so a hidden field works well here.
Other options
URL parameters:
This could also be done by building the parameters into the url that the form is being submitted to:
<form action="save.php?entry_id=1234">
but this means you have to handle building the URL properly and escaping the data yourself, and the length of URLs servers will accept is limited so it may not work for longer data. So generally using hidden form fields is the easier way to go.
Session variables: When the edit page loads you'd store the entry ID in a session variable, and then retrieve it on the page that saves the changes. That's a lot easier to mess up though; setting up and maintaining sessions may require adding code in several different places, and then their session could expire in between loading and saving, and you have to make sure it works if they have multiple windows or tabs open, and you have to make sure it doesn't do weird things when they hit back/forward. Because of all these potential pitfalls it isn't a great way to solve this problem--passing the id with the data being submitted is a lot more robust.
Cookies: In many languages/frameworks sessions are tracked using cookies, so they're basically the same solution. The pitfalls are the same as for session variables even when sessions are tracked by other methods though.
It sends additional information that the user doesn't know or isn't interested in (such as a security token) so that if the form is submitted twice, you can compare the tokens and reject/accept that submission.
Not using hidden inputs means the server needs to keep track of these values instead. This requires the server to keep state, which could otherwise be embedded into the request (form) itself. This may make the page RESTless (not RESTful), i.e. break the self-containedness of an HTTP request. If you did keep track of hidden values on the server, you would at least need to embed a unique token into each form to deal with several different unique submissions of the same form. The cleanest way to embed such a token is, drumroll, through a hidden input. :)
The Hidden Input field is not displayed on the page, so it does not allow visitors to add anything into it. The Hidden Input allows you, the webmaster, to add specific information to a form, to be passed through the form processor along with the data entered by the visitor.
For example, if you have several forms on different pages on your website, you could use a Hidden tag, in each form, that identifies which page the visitor was on when they filled out the form.
The hidden input is for when you want to send information back on a post without the user seeing the data as a UI element.
The web is stateless - ergo, when a POST comes in, you have only a couple pieces of information to determine what you need to do; Session, Url, some ServerVariables, and the Form data passed to you.
If a piece of data is transient that is not useful for putting in the session, sometimes it is prudent to put into a hidden field.
They can also be useful for storing data on the client side for rich internet applications (such as a product Id that is easily accessible to use in ajax calls).
because you have a php while loop with alot of different objects which you can't get the id's of later and you just save them by storing them in the hidden input... also i like them to be a security check to know my users aren't messing with my post variables through tamper data
If you build a tag system like the one here. You can set the values into a a hidden field.
Consider a form that's being displayed to edit a record in a database, one technique is to bake the id of that record in a hidden input and have it submitted back so the server can read it back.
It's also used frequently for security purposes (as genesis has said).
Another reason might be for javascript-oriented scenarios, perhaps for non standard controls such as treeviews, where the concept of a selected node cannot be represented as a normal input. Instead, JS can manipulate a hidden field and store the node's name/id in it, so that it can be read by the server.
It's just what it's name implies, a form input that is hidden from the user. It's a way of getting data to the server that the user doesn't need to see or control directly. This is especially useful for maintaining state.
I'm working on a project right now where a user creates several items that are represented as data objects in JavaScript and serialized when sent to the server. These data items are expressed one way when displayed to the user with HTML, another way as JavaScript, and a third way when sent to the server. A hidden input is the only way to accomplish this. (Okay, fine not actually the only way, but certainly the most reasonable way).
For example, if you have a form to edit an entity from you data model, you could use an hidden input to place the id of the entity you are updating, since you don't want to have this value put in the text input field to be posted back to the server. the hidden field will be posted to the server as if it were part of your form.
All answers explained why we using hidden inputs in form but here is the security concern.
Security concern
Using hidden inputs in forms can be tampered/changed by View source or using developer tools in any browser.
Solution
Use cryptography in your code/project to avoid changing values in
hidden input by attackers/hackers.
Generic Solution
If you want to store any data in hidden input first encrypt the data and store them in hidden input.
When form is submitted then decrypt them if values not change then save your data.
If changed then show some error or else.
Further reading
Cryptography
Wiki Cryptography
For framework Developers
Other framework developers can find cryptography in their framework.
Cryptography in Laravel(PHP)
Cryptography in .Net
Cryptography in Django
As name implies, Hidden fields are similar to other input fields except one difference i.e, hidden fields are not actually shown to the user and hence can not be edited by the user.Its value can only be set at the time of execution i.e. may be form submitting which posts the data to the server.
But the data set on the html page i.e. name/value can be seen in the html source of the page (view source of the page).