Why do I need to have site unique form element id's when using jQuery Mobile? I would really like to know how the DOM works in order to create my app memory efficient.
I get this information about the DOM cache:
http://demos.jquerymobile.com/1.3.2/widgets/pages/
Whenever it loads a page via AJAX, it flags the page to be removed
from the DOM when you navigate away from it later (technically, on the
pagehide event).
So this information about Markup conventions seems to be contradicting, or at least incomplete:
http://view.jquerymobile.com/1.3.2/dist/demos/widgets/forms/
...the id attributes of form
controls need to be not only unique on a given page, but also unique
across the pages in a site.
This is because jQuery Mobile's single-page navigation model allows
many different "pages" to be present in the DOM at the same time. You
must be careful to use unique id attributes so there will be only one
of each in the DOM.
I have the following requirement:
We have a page that requires a user to enter some data into a form that consists of various input fields and dropdowns.
Special is, imho, that within this form is a part for fileupload. The user shall there be able to upload some (multiple) files. Then when he/she presses submit at the end of the page, the whole input shall be submitted and written to an object. In this object also the path to the uploaded files must be saved.
I want to achieve the file upload with primefaces' (3.4) component.
Now to my challenge:
The fileUpload requires its own h:form with enctype "multipart/form-data". The other data is within a "normal" .
For me this means that I must place the forms after each other within the page. But the fileUpload component shall be displayed in the middle of the other form.
How can I achieve this?
Any ideas?
Best regards,
Florian
Now to my challenge: The fileUpload requires its own h:form with enctype "multipart/form-data". The other data is within a "normal" . For me this means that I must place the forms after each other within the page.
This makes honestly no sense. I'm not sure how you come up to this conclusion. Perhaps you concluded this based on an incorrect observation of a problem. Perhaps you used the wrong bean scope and encountered null values for all so far entered input and previously uploaded files while processing the form submit. You should be using #ViewScoped if you want the very same bean instance to live as long as you're interacting with the same view by several ajax requests.
You can perfectly put "normal" input fields like <h:inputText> in the very same form with multipart/form-data encoding. With this encoding, the HTTP request is just been sent in a bit different format which allows room for binary content. See also params not getting passed to backing bean for h:commandLink under rich:popupPanel and t:dataList for a detailed background explanation.
See also:
How to choose the right bean scope?
Image not getting updated
Multiple Image upload in primefaces
Unrelated to the concrete problem, I'm not sure how to interpret
In this object also the path to the uploaded files must be saved
but I'd like to note that you can absoutely not rely on the full client side file paths being sent to the server. This would only occur when the IE browser is been used due to a security bug in that browser. You should rather be interested in the file contents in flavor of InputStream or byte[]. You should be autogenerating a (temp) file with an unique name yourself, if necessary based on the sole filename (and make sure that a second uploaded file with coincidentally the same filename doesn't override it). See also How to get the file path from HTML input form in Firefox 3
what design approach would you take for security and scalability (and perhaps level of effort) when posting an ASP.NET MVC HTML form that also has a Flash component, as described in the scenario below?
I have a scenario where there's an ASP.NET MVC site, and a page that requires user authentication & authorization to access (using ASP.NET forms authentication). On that page there's an HTML form. The form also has a Flash component. The form has a few text fields, and the Flash component has binary data that needs to get submitted to the server in tandem with the HTML form fields. When the user hits the submit button on the HTML form, the form contents and binary data from the Flash need to get submitted as part of one atomic unit, so to speak.
I know that I can use HTML / Flash JavaScript bridging to post the form either through JavaScript, or through the Flash component. I could even do both, perhaps posting the binary data from the Flash component when the user clicks submit, and then posting the HTML form content following that.
From your experience, what approach would be the path of least resistance to post the form with? Considering the user authentication and authorization part, I imagine that Flash would higher effort than HTML. What about the user authentication aspect? If the page posted from Flash to the server, would Flash also have to authenticate the user, in addition to the standard HTML authentication form?
My Flash binary data should not typically be greater than 300KB, often less...any opinions / insights are greatly appreciated!
EDIT:
I also vaguely remember that with Flash 10.1, ExternalInterface seemed to not work right when transferring binary data to JavaScript, am I mistaken with that, and that you can easily transfer 300KB or more of binary data from Flash to a JavaScript variable that is then posted to the server?
Thanks!
That's one way of doing it:
Make your flash component call a javascript function through ExternalInterface.call().
Make the called javascript function change a hidden field inside the form.
When the form is posted, the hidden field will send the desired value to the server.
I guess this is also the safest way - since the Flash component will not communicate with the server. Everything you need is a standard, non-AJAX form post.
Edit
Sorry, I guess I should have paid more attention... If there is too much data being sent from the flash component, maybe you should post it directly to the server.
Still, you could use ExternalInterface to synchronize the whole process. Make Flash call a server-side method (I would use FluorineFX for that, but your opinion may vary). Then .NET will return an ID, meaning it has received and saved the binary data for future use. Then call ExternalInterface to set that ID to a hidden field. After that, when the HTML is posted to the server, the server-side action method just need to retrieve the binary data using the posted ID...
The problem here is that you will end up with some binary data that will never be associated to any form post... But that's OK I guess, just run some "garbage-collector" script from time to time.
About the authentication issue: FluorineFX does implement .NET authentication, and it is able to retrieve the current logged in user. Of course, there are some issues.
Is that possible to have values inside a silverlight application be passed out unto the webpage, whether calling a javascript function with the values, etc.
The functionality I'm looking for: I have a map in silverlight, I select some values, I click the html submit button that is located on the webpage. The values in silverlight and also whatever input was made on the webpage is sent to the server (ASP.NET MVC Controller).
Yes, it is possible by accessing the html elements in the page:
HtmlElement field = HtmlPage.Document.GetElementByID("hiddenFieldID");
field.SetProperty("innerHTML", "someValue");
You can call this functionality when the map control is updated inside the Silverlight control. When the submit will be called in the web page it'll have the value ready on the field.
I'm making my way into web development and have seen the word postback thrown around. Coming from a non-web based background, what does a new web developer have to know about postbacks? (i.e. what are they and when do they arise?)
Any more information you'd like to share to help a newbie in the web world be aware of postbacks would be most greatly appreciated.
The following is aimed at beginners to ASP.Net...
When does it happen?
A postback originates from the client browser. Usually one of the controls on the page will be manipulated by the user (a button clicked or dropdown changed, etc), and this control will initiate a postback. The state of this control, plus all other controls on the page,(known as the View State) is Posted Back to the web server.
What happens?
Most commonly the postback causes the web server to create an instance of the code behind class of the page that initiated the postback. This page object is then executed within the normal page lifecycle with a slight difference (see below). If you do not redirect the user specifically to another page somewhere during the page lifecycle, the final result of the postback will be the same page displayed to the user again, and then another postback could happen, and so on.
Why does it happen?
The web application is running on the web server. In order to process the user’s response, cause the application state to change, or move to a different page, you need to get some code to execute on the web server. The only way to achieve this is to collect up all the information that the user is currently working on and send it all back to the server.
Some things for a beginner to note are...
The state of the controls on the posting back page are available within the context. This will allow you to manipulate the page controls or redirect to another page based on the information there.
Controls on a web form have events, and therefore event handlers, just like any other controls. The initialisation part of the page lifecycle will execute before the event handler of the control that caused the post back. Therefore the code in the page’s Init and Load event handler will execute before the code in the event handler for the button that the user clicked.
The value of the “Page.IsPostBack” property will be set to “true” when the page is executing after a postback, and “false” otherwise.
Technologies like Ajax and MVC have changed the way postbacks work.
From wikipedia:
A Postback is an action taken by an
interactive webpage, when the entire
page and its contents are sent to the
server for processing some information
and then, the server posts the same
page back to the browser.
Expanding on the definitions given, the most important thing you need to know as a web-developer is that NO STATE IS SAVED between postbacks. There are ways to retain state, such as the Session or Viewstate collections in ASP.NET, but as a rule of thumb write your programs where you can recreate your state on every postback.
This is probably the biggest difference between desktop and web-based application programming, and took me months to learn to the point where I was instinctively writing this way.
Postback happens when a webpage posts its data back to the same script/dll/whatever that generated the page in the first place.
Example in C# (asp.net)
...
if (!IsPostback)
// generate form
else
process submitted data;
Web developement generally involves html pages that hold forms (<form> tags). Forms post to URLs. You can set a given form to post to any url you want to. A postback is when a form posts back to it's own page/url.
The term has special significance for ASP.Net WebForms developers, because it is the primary mechanism driving a lot of the behavior for a page — specifically 'event handling'. ASP.Net WebForms pages have exactly one server form which nearly always posts back to itself, and these postbacks trigger execution on the server of something called the Page Lifecycle.
The term is also used in web application development when interacting with 3rd party web-service APIs
Many APIs require both an interactive and non-interactive integration. Typically the interactive part is done using redirects (site 1 redirects a user to site 2, where they sign in, and are redirected back). The non-interactive part is done using a 'postback', or an HTTP POST from site 2's servers to site 1's servers.
When a script generates an html form and that form's action http POSTs back to the same form.
Postback is essentially when a form is submitted to the same page or script (.php .asp etc) as you are currently on to proccesses the data rather than sending you to a new page.
An example could be a page on a forum (viewpage.php), where you submit a comment and it is submitted to the same page (viewpage.php) and you would then see it with the new content added.
See: http://en.wikipedia.org/wiki/Postback
Postback refers to HTML forms. An HTML form has 2 methods: GET and POST. These methods determine how data is sent from the client via the form, to the server. A Postback is the action of POSTing back to the submitting page. In essence, it forms a complete circuit from the client, to the server, and back again.
A post back is anything that cause the page from the client's web browser to be pushed back to the server.
There's alot of info out there, search google for postbacks.
Most of the time, any ASP control will cause a post back (button/link click) but some don't unless you tell them to (checkbox/combobox)
Yet the question is answered accurately above, but just want to share my knowledge .
Postback is basically a property that we can use while doing some tasks that need us to manage the state of the page, that is either we have fired some event for e.g. a button click or if we have refreshed our page.
When our page loads for the very first time , that is if we have refreshed our page, at that time postback-property is false, and after that it becomes true.
if(!ispostback)
{
// do some task here
}
else
{
//do another task here
}
http://happycodng.blogspot.in/2013/09/concept-of-postback-in.html