I've built a fairly complex web app (html, javascript, jQuery, php, mySQL) and use several mechanisms for navigating through the site (e.g. anchor/links, submit buttons, window.location, window.open). I'm looking for two things:
What are all the mechanisms possible for moving around a site or a source that will allow me to find such a list
What, if any, documentation standards are there for documenting such actions; something like the flow charts used to document procedural code.
I'm not sure either by what you mean in "thing 1". The best tool to map all the paths is the UML Sequence Diagram.
Services such as Omniture and Google Analytics let you visualize such paths of user navigation. You could explore that option. Basically they work by tracking a page's URL and its referrer URL (accessible via document.referrer) and then making the connection.
If I understand your comment on dj_segfault properly, I'm not even sure you understand the concept of server/client interaction.
I don't think there is an answer to this because the technology is changing all the time and it is different depending on what devices you are using.
You only have to look at Node.js (if you understand the technology) to see that the lines between server and client can be blurred, and that it's just not a simple answer.
The bottom line is in fact there are no navigation "things" unless you program them, and how you program them is your choice depending on requirement.
For example a vanilla link
Google
Can either be static HTML content or echo'ed from a php script which was used to select the data from a database to get the URL and print it. But it doesn't have to be either of these.
If you wanted to navigate to google you could use a button with an onClick javascript or an event listener with data collected by AJAX. It could be derived from other content values on-the-fly or be a string. I could probably imagine 20 different possibilities but that doesn't make them all suitable for the application.
Just keep incrementally improving your project, use this forum to answer specific questions and you'll learn a lot. I did.
Related
I want to try creating a canvas were multiple users can type and edit for brainstorming etc. I am thinking of php as backend. What are the technique used for it? For example, lets say its
pure text. How do we update the text like in the google wave(b4) and in google doc?
Is it just using websocket(or js pooling) and updating the text file? or are there any
better logical way to solve this issue?
Well, its not as easy as it is said in Brad's answer but he is partially right. You will definitely need WebSockets today to make it happen. But logically, it is not that simple to create a collaborative environment. There are issues like broadcasting changes of every user to every other user viewing the same document. Then you will have to make sure that every user gets to see exactly the same thing no matter who changes what and when. This gets difficult when multiple users are working on the same document collaboratively. There can be conflicts while merging changes of one another.
As far as PHP is concerned, language is not really a problem. Its how you handle the above stated problem.
Google released its research and engineering details on Google Wave (I guess after abandoning the project). This link might be some help to you: http://www.waveprotocol.org/whitepapers/
Websockets are the way to go for this. However, they are difficult to implement in PHP, and not supported by many browsers as of yet. You can do long-polling of AJAX requests pretty easily with PHP, but it can be quite a waste of resources.
This might not be what you are looking for, but I'd suggest changing your server-side technology. You can use Node.js with Socket.IO to easily use Websockets (or seemlessly emulate them for browsers that don't support them). This will provide the fastest method for pushing data to your users.
I have a website for a client offering information from a database. But other websites want to show that information in their website, so my client ask me for it.
Since the begining I thought it might be something similar to the twitter widget. As I want to give out a code similar to this:
<script src="http://widgets.twimg.com/j/2/widget.js"></script>
<script>
new TWTR.Widget({ ......
And other websites will show the information from my database.
But I cannot find a exactly example, I found this: http://tutorialzine.com/2010/03/who-is-online-widget-php-mysql-jquery/
But it is not exactly what I want.
My deployment is the following: In the server I've got a mySQL database and a website, I would like to create php and javascript code (or even jquery, but I'm not very expert with it) so other website could incorporate the information from the database in a secure mode.
Could anybody give a hint?
You'll need a RESTful service on your server which other sites can ping. You will use an AJAX request to get the information from that service.
The big piece of this for you will be creating a JavaScript object that has all the functionality you want. It is much easier to give people directions on how to use your REST API and let them implement it via AJAX on their own pages. If you really do want a full widget, you'll want to check out a lot of things. First is closures in JS to ensure you don't conflict with any of their variables. Also make sure you are good at developing cross-browser Javascript independent of libraries. And finally, you'll want to make sure your server is configured for cross-domain AJAX requests. Again, my recommendation is to set up a REST API for them, and let them do the dirty work.
There is an interesting tutorial about how to create a twitter widget using PHP and JavaScript on the nettuts website, I think you may find it useful.
Well, although it's not specific for PHP, this is by far the best resource I could find to this subject:
http://alexmarandon.com/articles/web_widget_jquery/
I've now got some very good understanding of (X)HTML and CSS, and plan to move on. My next choices are PHP and JS (and don't know if I'll ever end up learning one of them, but I would love to).
So, I need to choose one of them. I have learnt that PHP is server-side programming and JavaScript is client-side programming, and I am NOT asking you to compare the two of them for me. What I would like to know is, can I do anything (or most of) in PHP that can be done with JS? (or put it this way, can do everything people use JS for, on the server-side with PHP?)
Instances include, using PHP instead of JS in web themes, real-time content display (as in live blogging, live comments etc), effects etc.
This might seem dumb, and there's definitely a reason why people use JS in all the above instances, but since I cannot (really) learn the two of them, thought I should ask for some advise here.
EDIT: Would it be possible to reload only a part of a web page (not the entire web page) every few seconds with PHP? That should be good enough for the real-time application that I am planning.
If you absolutely don't want to learn both, then learn Javascript. There are possibilities to implement a Javascript-based backend with node.js.
I advise you to at least try PHP since it is widely used - maybe even at your company.
For nice user experience (dynamic menu, ajax, effects, ... ) you need client-side programming and for dynamic content you (almost always) need server-side programming.
In short, you need both.
PHP and JavaScript cannot really be compared in the way you're asking...
Both are powerful in what they've ment for and they have a very similar syntax. If you can't absolutely study more than one of them, learn PHP in my opinion. I coded with PHP for almost 10 years before really getting into JS. I would say PHP is the food and JS is the spice.
In order to create AJAX web apps Javascript AND a server-side language is required.
No, you can't. PHP only works on the server side. Once you've delivered content to the client, PHP can't do anything until the page reloads or the user loads a new page. If you want to do anything client-side in between, you need JavaScript (this includes loading content in real-time, doing a lot of modern UI stuff, etc).
Either learn both PHP and JS or use a blogging CMS and use a minimal amount of both.
If you put enough effort into it, you can do almost anything server-side using lots and lots of page reloads. You can also generate arbitrarily complex dynamic content using Javascript.
But it's a lot easier to do minor changes to a page's content from Javascript, it's only possible to do animations and effects from Javascript. It's also much easier to directly access the database from server-side code – there might be pure-javascript drivers for SQL databases, and you could use a NoSQL databases that's accessed using web services, but both are relatively uncommon techniques.
I have a thought regarding your original question/situation. I know this is about four years tardy, but I thought I should throw in my two cents for people who are looking back on this conversation as a reference from Google like I am. In your situation, because you are a blogger who is trying to save time when it comes to programming, I would recommend looking into WordPress (the .org version, not the .com). It is a sort of marriage of WYSIWYG blogging/website creation and programming. It takes care a lot of the back end stuff (including Javascript, PHP, and more), but also leaves it open for you to edit if you so desire. You probably could get away with using Wordpress as a total non-coder, but with HTML and CSS, you're already off to a great start. WordPress is super simple to learn and amazingly powerful. If you do take this route, I would suggest learning PHP as an asset because that is the language that WordPress runs off of. If you know PHP and are using WordPress, you have vast potential, not to mention that speedy blogging is a snap. If you don't feel the need to have whipped everything up from scratch and want to work faster, give WP & PHP a try. They'll take you a long ways.
My question might not be understandable enough, so let me explain the situation :
I'm working on a big ajax webApp built, server side, with PHP using CodeIgniter. This framework saperates clearly models, controllers and views. The view files are rendered in HTML and then sent to the client that does some js treatments on it (like attaching events).
This way of working seems strange to me, as it separates the view between the server side and the client side.
I was thinking about moving all the View treatments to the client part that will build dynamically its html in js. The server side will then send only raw data.
I worked this way on smaller projects, and I was really happy with the result (easily understandable, portable and reusable).
Is it a right way to implement an MVC app ? Any advices around that reflexion ?
I've done pretty much what you are describing on a fairly large data services app as an internal application. In my case I was using ExtJS for the client-side rendering/views, and was communicating to a C# WCF endpoint exposed on the web server. Essentially requests were made/submitted and responses were serialized to/from JSON. It ran very smooth, once some kinks were worked out. The original author had written a custom serializer to do direct results from their data layer directly... this leads to a lot of extra data going down the pipe. As long as you are judicious with your payload data it can be very effective.
Some caveats though...
You should probably avoid this if you expect users without javascript enabled to be able to access the site (anything involving money transactions from external users).
You will want to document your methodology as clearly as possible.
Finding developers for maintenance tasks after you have implemented your application will be very difficult. (many server-side devs are shy of, scared of, or just plain inneffective with JS skills.
For the most part it's a toss up, I find that most people at least have JS enabled, but may have other things blocked off. AJAX/XmlHttpRequest supports is nearly universal at this point.
As to templating for client-side display, there are a few options there (but that's a separate discussion).
Building JavaScript views works fine within the MVC pattern, since your view is not mixed in with your business logic or model.
However, there are a couple drawbacks to using full javascript views. Mainly it eliminates the ability for graceful degradation if the client has javascript turned off. Also, some browsers (IE) don't have a very fast javascript engine, which will make your page load more slowly. It is true that some of the view is separated between the client and the server, but it kind of makes sense when you think about it.
In most cases the HTML that you send to clients is the same for everyone (unless you are doing browser detection on the server side). However the JavaScript routines are different. If you are using a library like JQuery, this will be hidden from you, but the code that is running on each client may differ greatly. One example of this would be the XMLHttpRequest that is used by firefox/webkit etc browser and the active x control that is used by IE. Since the html portion of the content is the same for everyone it makes sense to build on the server, and since the JavaScript portion of the view may differ, it make sense that it is built on the client side.
HTH
I started using the same approach: JavaScript for the user interface layer and PHP for the database access layer. I'm using AJAX to pass all the data back and forth between the 2 layers. So far, AJAX has occasionally frozen on me, but it has been speedy enough most of the time. So I guess it'll work well enough.
(The result is that my code has gone from 90% PHP with 10% JavaScript...to 65% JavaScript with 35% PHP.)
I've also separated the code for my page views from the code for my triggered event action functions. So I like to think that I have an MVC arrangement now (even though I'm not using an off-the-shelf MVC framework like Backbone.js).
I'm not using HTML templates, though. I don't think it feels natural to have 100% separation between HTML and programming. I think simple programming loops, conditional statements, and JavaScript triggers all go nicely with HTML.
If you will think it in the way that there is the main view that creates the html/js engine and couple of ajax views with the data streams - it will be quite OK in MVC terms imo.
Is there anything more dynamic going on on the site itself? Does it do more AJAXy things, dynamically refresh parts of the site etc.? If so, it may be reasonable to have a Javascript-only site.
Since this is not how the web traditionally works though, sending HTML from the server is still the baseline. If your pages are basically static, if you want to serve older clients, an audience that may have disabled Javascript, an audience that may have accessibility problems with Javascript-only pages, alternative clients that cannot understand Javascript or search engines, you should serve HTML pages from the server. There's nothing wrong with it, it's straight forward, simple and foolproof. There are many things to consider when reinventing the wheel in Javascript on the client side. Unless you have a good use for the potential this offers (see for example the highly dynamic Facebook or Twitter pages), it may be more trouble than it's worth to your users.
It sounds like you are one step away from going from the MVC pattern to the MVVM pattern.
MVVM is ideal for complex user interfaces (which is exactly what you would be creating with all the AJAX and JavaScript and whatnot) because in this case your HTML view will be able to act as the controller via JavaScript. There is a library (warning: I've never used it but it looks promising) for this called Knockout JS.
I'm developing a web application and I'm using PHP and Javascript. Today, I'm starting to draw all the design class diagrams, but I don't know exactly how to mix both technologies.
I think that something like the following should be good:
But, really, I'm not sure if typing the .php extension in the class name is sufficiently clear, or what I need is to separate diagrams in two: one for Javascript classes and another one for PHP classes.
I'm using CodeIgniter (MVC pattern) and Javascript. Any suggestion will be really appreciated.
Thanks!
Usually, you don't want to do this. It's a problem of latency when viewing the web page in a browser. Each separate javascript file defeats caching and requires additional transfer time before a page can load. It's commonly advised to combine JS files wherever possible and practical to better take advantage of browser caching. So my first suggestion is to not arbitrarily split up your JS for architectural reasons...
Now, with that said, to answer you question in entirety, I think it depends on how you view JS. If you're looking at it form the perspective that it enhances your PHP application, then dividing it up along side your views is not bad (the above suggestion not withstanding).
However, I usually see JS as a separate application layer on top of the PHP application. The JS interacts with the PHP layer through defined APIs. So it's basically just a full blown GUI application that just so happens to use the API defined by the PHP application. So with that in mind, I usually build the JS application with its own architecture that's more dependent on itself then the PHP application. So in other words, just because a piece of the JS application interacts with PHP doesn't mean that the piece of code belongs with the PHP application.
Does that make sense?
Trying to put all your classes (even within one application - you have two: a PHP applicatoin and a JS application) on one UML diagram is pretty much a way to waste a lot of time and gain nothing.
Use UML to show dependecies within a package or a group of classes working together, but don't try to do it for a whole app.
I don't know the way you do things usually but in my projects, I tend to separate PHP and JS. First of all, its easier to develop and debug if you go that way, secondly, if you treat javascript as a second layer instead of being on the same level of programming as PHP you will get a working fallback in the case that your JS doesn't work, or the user of your web app have javascript disabled.
I tend to make everything work in PHP and later on I override some actions with javascript to get them working through ajax instead of the traditionnal way of working in old school Web.
--- Revision following first comment ---
Then, you might want to treat the PHP and the Javascript part as separates applications. The first system (PHP) generate the initial state. Upon user action the second system (JS) makes a query to the first one and wait for the answer, this way, you will setup some sort of API that will standardise your transactions.
I used to work with design information specialists and they often refer to Jesse James Garrett as a "Guru" in that field of expertise, you might want to check his site (there are premade stencils for omnigraffle, visio and few others).
Through his writing and example you might be able to find the right symbols and elements to represent your system.
Jesse James Garrett's website