I have been asked by a client to develop a javascript(mootools)/html/css/php based game as a widget which can be deployed anywhere.
I have not written a widget before, so would love to get some tips and experiences so that I know some of the pitfalls before i start!
Encapsulate your variables. Don't put anything in the global namespace, because you don't want to conflict with anything else operating there.
Ideally, let your widget write itself into the page; that reduces the number of separate things that have to be dropped into the page by the user, thus making it easier to install.
Make it clear what requirements your widget has - if it needs external libraries like MooTools to function, the person installing the widget will need to know that.
First of it depends of what you mean with anywhere? How much code are you allowed to publish to "anywhere".
Any how, the simplest way to publish anywhere is to just send "anywhere" a that implements the game. If you need different variables from each "anywhere" (for example for tracking) you can specify a .php file in the src attr that generates a javascript base on the parameters.
In the script you can use AJAX to talk to your sever and document.write to write at "anywhere" page.
One thing to keep in mind is that using a JS library could be hard since the "anywhere" page might no implement the specific JS library.
good related thread.. Widget -what to do and what not
thanks for answers so far - the more the better!
Related
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.
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
I would like to know the best practice to use when listing items from a database in an ajax call with Zend Framework. The end result is to show notes concerning a customer in a css popup when clicking on a link.
I'm currently looking into using Zend_Json_Server, but I can't really see how I could implement it. Is Zend_Json_Server good to use in these cases - and if so, should I use it outside the MVC structure as some suggest?
Most importantly:
Could someone please give me an example of how it could look like?
From Calling the javascript function from the view to listing the items in the CSS div (popup).
This would help immensely and would be really interesting to know about!
KR
Josef
I have certainly seen commentary - I think by MWOP himself - that you want API service calls to be fast; if you are only returning JSON, for example, then you don't really need the full MVC. On the other hand, the context-switch action-helper is part of the MVC stack and is often used to handle AJAX calls. I guess idea is that if your AJAX call needs to perform much of the same processing as a standard MVC request, differing only in the return, then it might be DRY-er, albeit slower, to simply use the context-switch. If speed/performance is the issue, then perhaps a separate service might be warranted.
But I confess I have no experience here, so if I am just shooting crap, please feel free to correct me. ;-)
The MWOP link above contains some ideas for how to set up service endpoints.
I've learned CSS and HTML, what should I learn next if my goal is to create templates for Joomla and WordPress? Ajax? PHP? JS?
I poked around and haven't found a question that is alike so I posted this one
Both Joomla and Wordpress are PHP applications, so in order to understand what exactly happens with your templates and in order to override template parts succesfully, it surely is a good idea to learn some basic PHP.
Now Javascript and AJAX are two different pairs of gloves and the terms belong to two different levels of abstraction.
Javascript is a scripting/programming language while AJAX is a technology which makes use of Javascript. Learning Javascript is definitely a MUST if you're in the UI design area. And once you know it, using AJAX (asynchronous javascript communication with the server) scripts will be one of your possibilities.
So, if I were you (but it also depends on the task at hand) I would learn Javascript (jQuery as a library) first and later look into some basic PHP.
From your question the best answer I can give is:
Install Joomla & Wordpress, then start tinkering with the templates
See how the templates are structures what the different template engines are
Modify the default templates to create some changes you can see.
Add jQuery if you so choose, and try some JS/Ajax tutorials (jQuery has plenty of demos)
View the completed changes in your CMS templates.
Otherwise from your question going to read about something, isn't going to help you 'learn' you need to start with baby steps and work your way into more complex examples. Then just exmplore with either technology and see how others are doing it. Always review and correct, and learn from your mistakes.
A little bit of php will surely help you, but if the developer (or the cms) is good you'll never have to edit the php parts (you should see just many foreach, while, if, else loop/condition)
Js (ajax) is used (sometimes, mis-used) to handle some layouts elements, so yes, take a look at jQuery, but remember: never rely just on javascript.
I am looking to build a website that allows the user to fully customise the content that they see. I will be building this using CodeIgniter or Zend Framework and also jQuery. What I need to know and gain some advice on is how is the best way to create the content on the fly,
When a user selects that they would like the blog section to be on their website, I need to gather the blog information on the fly and print out the appropriate div on screen.
What would be the best way to do this? Would I be best creating the Div in the DOM or just calling a view onto the page?
In my opinion loading views would be a much easier and maintainable approach.
Imagining trying to do that in javascript gives me a headache.
My recommendation is don't. Don't re-invent the wheel. Choose an already available system like Drupal or Joomla.
If you really need to re-implement this because of a constrain you cannot tell us, then all I can say is that using JQuery is a damn good idea.
One way is to create the dom objects on the fly using jQuery. This will work fine.
But another option would be to keep all your view logic in PHP and make a request to the server using jQuery, which will then return a snippet of html (a partial view). This would keep your code cleaner and your javascript files smaller and more manageable. Plus, whenever you make a change to your view, you won't have to do it in 2 places.