Let's say I have a calendar on my page and clicking on a day would mark that day as complete.
But I want to use POST and not GET, since GET is not suitable for this kind of stuff (changing something). And I also don't want to use JavaScript.
What I'm going for here is to build a page that will work without JavaScript (which I will use to "upgrade" the UI so that this updating is done via XHR) but I would also like to comply with how HTTP is meant to be used (this is what REST is about if I understand REST correctly).
So is there any way to do this, or is using links to change data the wrong approach from the start? If it is, the only viable solution (for my concrete problem) I can see is to use submit buttons for every day (along with a form for every day). But I'm more interested in the general idea here not just for my problem.
So is there any way to do this, or
No, there isn't.
is using links to change data the wrong approach from the start?
Yes, it is.
… although you could apply CSS to buttons.
Related
I'm learning basic web dev and started with HTML, CSS, Bootstrap. Haven't touched PHP or anything server side yet.
What I've done so far is I've created a pretty basic registration form with 5 fields and what I'm trying to do is display the input of those fields in a table that I've created on another page. The submit button has the "method" and action. Now, I've Googled a ton to find some solutions and have gone through most of the questions of this site but I still can't find out to achieve what I'm trying to do without the use of PHP/JS.
So, is it even possible to read form data from another page like this without the use of JS/PHP? If so, how do I proceed and what needs to be done? I can post the source code but I don't think it's going to help since there isn't much there, everything else is working fine except for finding a solution to this.
Thank you.
You need a programming language.
If you want to do it entirely client-side, then that has to be JS.
If you want to do it server-side (which allows you to access the data and, optionally, make it available to other people, instead of limiting it to the user of the browser) then you can use any programming language at all (although JS and PHP are among the most common choices).
Since you are trying to create a registration page, you'll need to use server-side programming.
You necessarily need to use JavaScript / PHP.
Since you are just starting, I would highly recommend you to check out the W3Schools tutorials on HTML, CSS, JavaScript, PHP, Bootstrap and jQuery.
:)
So this is long gone but I was actually able to resolve my problem without using anything other than basic HTML , so here's how I did it for anyone else who's trying to find the answer to problem (probably not, you don't usually do this professionally and basically this was a challenge from a friend).
So, two things.
SessionStorage
LocalStorage
This is built-in to your browser and you can use it to achieve simple tasks by simply assigning values to it. They'll remain there and you can use however you want.
But, as the name implies, sessionstorage will only retain those values during the session (the time you have your browser open for) while localstorage can retain it indefinitely. Not sure if I can link other sites over here so just Google these terms to learn more and how to use them.
I've been working on the web for quite a long time and I saw the "best practices" evolve. I'm now fairly convinced separating HTML (Content), Javascript (Behavior) and CSS (UI) is the best thing to do.
A few months ago, I started using knockout.js . I did choose it among other similar frameworks like backbone or angular because a chapter in an MVC training I followed was about knockout, and the concept seduced me. Then after a quick comparison on the web it didn't look as a bad choice for my needs, and for a start.
But here's my problem : when I look at my HTML code now, after a few weeks of dev on a project, there's quite a lot of knockout bindings in it, and it makes me think a lot about the old times, when we (or at least I) used to put inline javascript event handling through onclick attribute and so on.
Therefore those 2 questions, which I'm not sure are 100% suited for SO, but I can't find any better StackExchange site to ask it :
Is using knockout (or the other frameworks as they all seem to basically work with the same pattern) contrary to the "separation rule" ? Or is it an acceptable small-step-out of this rule ? or is it even perfectly acceptable because it uses the "data-" attributes ?
In the case this would be a somehow bad practice, is there any possibility to do all the binding through a separate javascript file, using for example jQuery to select the controls and apply bindings to them ? If not possible in knockout, is it with another framework ? I must admit at the time I did my selection, I diddn't think about this kind of implications...
Thank you and sorry if this should be moved to another SE site.
I had the same initial reservations as you, but I have to say that having the bindings in the html and not hidden away in a JS file seems so much better to me, as the link between presentation and functionality is now completely obvious. It massively reduces the possibility of changing some HTML and breaking functionality because you weren't aware that someone had hooked up some javascript to an element using jQuery.
Also, as you point out, the use of the data-bind attribute does, I think, mean that it does adhere to the separation rule, though if you want to stick to it rigidly then make sure all bindings are to observables, computed or functions on your view model, don't use any code (i.e. a visible binding that checks the state of two observables). I'm not sure I'd take it that far though.
I guess everyone started to learn KnockoutJS have the same concerns.
IMHO, there must be some way that connects models(JS object) with views(HTML markup). Then we should have something that says:"When that button is clicked call this function with that arguments." or "Hide this element while you that JS array is empty" and so on. So how we can put/say/state that connection in a readable, reusable and clean way.
If you used another JS file to handle that connection, then you 'll have large lines of code just to put your connection logic and you need to know how to select the DOM element you are targeting. You 'll end up with massive code(probably lot of jQuery) just to make your HTML dynamic and alive(i bet most developers got into that many times). I haven't use other libraries or frameworks but i think they just make your massive code more organized.
On the other hand by KnockoutJS use Declarative Bindings, this is the link between models and views. It's more readable, easy to plug it in/out and it allow you to just focus on writing a good JS model object.
I guess to truly check separation think what if you sometime needed to change your model, how much changes you need to do to your view? and vice versa?
Adding to the rest of the answers, some tips:
Make sure there's no business logic in your bindings. Any logic (which should be minimal) should be "view logic": decisions that only affect how your view looks, not how it works. Deciding how many items to display per screen is view logic; deciding whether the user can add another item is business logic. It's perfectly OK to put view logic in your viewmodel rather than your view, and it's desirable if it involves lengthy expressions.
Keep "magic numbers" out of any view logic in your bindings. If it's a parameter that could be changed (e.g. number of weeks of results to show) as opposed to a true constant (e.g. number of days in a week), make it a property of your viewmodel and reference it in any expressions in your views.
I am relatively new programmer, talking with a partner he told me, that before AJAX, he used a iframe to send data and change the content(obviously with help of JavaScript).
I understood that both are similar techniques, but i didn't find a article to describe their characteristic,
what are advantages of AJAX over Iframe ?
EDIT
i didnt find any explanation of the technique, but my partner told me he post the data trough a hidden iframe and submit the iframe, sound like just the iframe have to be refreshed, but i never did that
One advantage AJAX has is being able to read the state/status of the
request. You also have access to page headers, which you don't with
Iframes.
Ajax can handle multiple asynch requests. It's a little trickier
with Iframes as you need to create an Iframe per request (and keep
track of all of them to delete them later) instead of recycling the
same one.
Existing libraries are full of AJAX goodness and there is a larger community support base.
iframe
is a way show seperately two (or more) webpages in one
ajax
is a way to merge two (or more) webpages ( or new data ) into one
key advantages to Ajax I find are;
CSS will flow to the page called into it.
A way to retrieve data and update new information to the visitors without page refresh.
A fab mention to this site for it's clever use of Ajax.
A'Google instant' and suggestive searching is achieved via Ajax
Just my two cents:
I agree with Kris above that I wouldn't say they are comparable.
There's on use case that I find iFrames to be easier to work with over AJAX and that is if you need to submit a complicated form to another page but you don't need any response - the iframe route is by far the easiest to code.
Beyond that, AJAX, using a metaphor, acts a very knowledgeable go-between. It will handle multiple requests, the status of those requests, and hand back the data in the format you need.
I just wanted to add this because I didn't see in any of the answers.
The reasons to use Ajax are mostly about control, which you get a lot of. These reasons have been mentioned above.
One serious downside of Ajax, though, is that it is a JS fix. JavaScript is a great language, but people have been throwing it at every problem for a while now, and things which could be optimized if they were built in to the browsers, are now instead being done slowly (compared to compiled languages) with JS.
iFrames are a great example of this. They represent an incredibly common use case, wanting to include some html in some other html. Unfortunately, they aren't very amazing at it, often creating more headache than anything else.
If you want to include something and not have it mess with your site, nor your site to mess with it, iFrames are great. For the more common use case of including some random html in some other html, Ajax is better.
And here is the point I'm trying to make: this is dumb. There is no reason there shouldn't be something like an iFrame that acts more like Ajax. But, by jumping on board (as all of us did) with Ajax, we are now left with no choice.
The biggest reason this is a problem is that JS was never meant to be the absolute building blocks of the internet. Further, it's being used by pretty much every site around to violate user privacy. So, if you're looking for a good reason to use iFrames, this is mine:
It feels good to not need JS. If you can make your site improved by JS rather than dependent on it, that's a hard earned accomplishment, and the site will feel less "hacky" overall.
Anyways, that's just my input.
In my experience data loaded via AJAX is easier to manipulate versus data inside an iFrame. Also AJAX is really good for creating a better user experience. However I am not sure if I would necessarily put iFrames and AJAX in the same category because AJAX is asynchronous content and an iFrame is really just another page being loaded from outside of your site.
Also I could see iFraming creating SEO barriers and creating bad user experience. Honestly though if I had access to content I would prefer AJAX.
I'm currently evaluating the combination of jQuery Mobile and PhoneGap. For my application, I need a kind of "inner application" navigation model: A fixed header that contains elements to switch between various contexts and functions, and the entire region below that depends on whatever function is selected. An example: The user selects a customer and can then switch between different data and statistics views concerning that customer. Alternatively, the user can switch between different customers while keeping the same view. Each function / view might again be a rather complex construct of multiple pages with its own navigation.
I think I understand the basic ideas of jQuery Mobile by now, but I'm unsure how to implement this "the right way".
I could do this simply by coding the entire header with the navigation into every single page, but that feels like a really bad idea - lots of redundant code, lots of places to insert tiny mistakes that are very hard to find.
I could try to add all the UI elements for the different views to a single page, hide them and only display the ones that belong to the current function. This doesn't feel right either - I suspect that the DOM would be really large and I suspect that this might cause various (performance) issues.
I could try to create the contents of the page that depend on the function dynamically using jQuery DOM manipulation techniques. This sounds like a good idea, but the individual pages can be really complex, and I'm worried that generating lots of complex HTML code using JavaScript will lead to an unmaintainable blob of code.
I could try to combine the approaches - code the individual pages in the HTML file and then somehow "link" them into the appropriate place using DOM manipulation - but I've never done that and I'm unsure if and how I can get this working.
I could try to put the "detail" page into an iframe - would this work at all?
What is the best / canonical way of implementing this kind of application? Do you know of any tutorials or examples?
Just detach your header and then reattach it to your new page. For instance:
$footer = $("#myfooter");
$header = $("#myheader");
$footer.detach();
$footer.appendTo('#newpage');
$header.detach();
$header.prependTo('#newpage');
$.mobile.changePage('#newpage');
Detaching does not kill all of your button handlers / etc. You will need to keep track of what page you are on or look at location.hash to do different things depending on what page is being shown.
--Greg Frame
Thex Interactive
www.thexinteractive.com
The first way is the easiest way to do it. That's the way i did it too. Also this gives u the freedom to add a button specific to whats in the browsing area for that page.
The second approach will have loads of extra calls which you don't want.
The rest of the approaches are not worth the effort.
I imagine there are many of you out there who have developed an application online which automates a lot of processes and saves people at your company time and money.
The question is, what are your experiences with developing that application, having it all set in place, then "spicing" it up with some Ajax, so it makes for a better user experience?
Also, what libraries would you suggest using when adding Ajax to an already-developed web application?
Lastly, what are some common processes you see in web applications that Ajax does well with? For example, auto-populating the search box as you type.
My preferred way of building Ajax-enabled applications is to build it the old-fashioned way where every button, link, etc. posts to the server, and then hijack all those button, link, etc. clicks to the Ajax functionality.
This ensures that my app is down-browser compatible, which is good.
It doesn't really matter which you use, unless you're trying to do something very specialized.
Here's a good list: http://code.google.com/apis/ajaxlibs/.
Yes, auto-completers are a pretty handy implementation of Ajax. It's also quite useful for data-intensive activities like populating drill-down data.
A lot of what you can do with these libraries isn't Ajax-specific, there is a lot of UI interaction that can benefit the user as well. You can do things like slideshows and lightboxes quite easily with many of these libraries.
Pick the one that you're comfortable with. The syntax they all use is a little different. Give a few a spin and try to build simple examples. Stick with the one you like.
Using ASP.NET Ajax to wrap a few chunks of code is an easy way to get going. But personally I prefer to use jQuery. You can easily add some simple Ajax calls with it to make the UI more responsive without the ASP.NET Ajax overhead.
If you are using ASP.NET to write your applications, adding AJAX using ASP.NET AJAX is very straightforward and in many places will not require you to change any code at all except add two controls to the pages you want to modify.
This works using partial page loads. The controls you have to add (off the top off my head) are called something like
<asp:ScriptManager
and
<asp:UpdatePanel
The biggest thing I use for AJAX is lists and search forms. Why? Because the overhead of loading an entire page when you are going though a list of, let's say, 200 records, it will get frustrating for a user to go though everything. However, it is important that if you click on a link in the page and then hit the back button or use a link at the top to return to the same page you were on.
For search forms, as you fill out the form I use AJAX queries to return the first few results and a number indicating how many records that were returned.
For AJAX frameworks, I use mootools. http://www.mootools.net.
Please ignore if not using ASP.NET. Your platform wasn't clear from your question.
Depending on when you created your web application, your web config file may need some tweaks to use ASP.NET Ajax. The easiest way to see is to create a new web site with the ASP.NET Ajax template and compare the web config, copying over configuration items as needed to bring the old one up to date.
If "spicing it up" is all you're after then develop the fully functional app without AJAX first. From here you can unobtrusively add AJAX functionality and ensure that the app degrades well for non JavaScript-enabled browsers.
I've started using jQuery for JavaScript on my site. It takes away all the worry of cross-browser JavaScript differences - things like class and classname, and getElementById. It also includes some very handy and simple functionality for AJAX postbacks. It's very easy to learn and extremely lightweight when used well.
I've seen some good use of AJAX right here on Stack Overflow, things like the tag selector and the question lookup when you type a question title. I think these simple things work best; we're just adding to the user experience with small additions to functionality that are intuitive, we're not flooding the screen with drag/drop handles etc.
I would differ from the first poster. Adding Ajax isn't always as easy as 1,2,3. It really depends on what you are after.
Adding things such as a colour animation can be made fairly easy, but if you are after things such as auto populating a text box, this requires extra code. It's not as easy as adding just something client side. You would also need to add in server-side support to fetch the partial query results.
Going beyond that, it can become even more complex keeping your client-side script in sync with server-side support.
But with the spirit of simplicity in mind there are libraries you can use to 'spice' up a website with animations and other eyecandy that can be implemented fairly easily which have been mentioned already.
I've often had to Ajax-enable an old-fashioned ASP.NET 2.0 sites. The easiest way I've found to do that is to create a new Ajax-enabled site and copy and paste certain sections of the web.config into your old project's web.config.
Just compare the two and see what's missing in your old one. You'll obviously also need to add references to AjaxExtensions and AjaxControlToolkit.