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
Related
So I have decided to take a project I have been working on, and project management system, and convert it from a standard multi-paged application to a single-page application. In the process I have looked at a number of javascript MV*ish frameworks (ember, knockout, backbone, etc...) and have decided to go with backbone.js as it seems the most flexible solution and that I already use underscore.js for both its utilities and template system.
The one biggest concern I have with doing this is the potential code duplication I am going to have for model and business/domain logic in both my PHP models and in my backbone models.
This is just a technical cost I have pay when going with an architecture like this or are there some things I can do to lessen this concern?
You may want to take a look at a previous question I answered involving Node.js:
Reusing backbone views/routes on the server when using Backbone.js pushstate for seo/bookmarking
What I'm currently doing right now is using Davis.js + Mustache + Java Spring MVC backened (based on my original question: Single page Web App in Java framework or examples?).
If the browser does not support Pushstate then I have the server do the entire rendering of the page using a Java version of Mustache (ie standard Web 1.0). If the browser does support Pushstate then the browser will make an AJAX request for a JSON version of the model. The model is then rendered client side use icanhz (ie javascript mustache).
This works fairly well if a large part of your logic is getting a model an then rendering it based on specific URL. That is your business logic is "based on some URL I'm going to render this". This is how most of the sites on the web work (including this one which is still rather web 1.0). Obviously this would not work for say something like real time chat or HTML5 game.
A python version of this design is mentioned here: http://duganchen.ca/single-page-web-app-architecture-done-right/
I'm sure someone has done a PHP version.
If you are using different languages in server and in client I think there is not possibility to avoid this partial logic duplication you are concern on.
If you definitely want to use same code in server and client you have to move all of it to the only common language: JavaScript.
There are multiple JS frameworks those integrate very transparently the development between server and client: derby, meteor, ...
This might look like a dumb question but I am new to MVC particularly to extJs. I wish to work with the MVC approach. I followed this link http://www.extjsframework.com/mvc/simple-mvc-application. But it has only a single page as example. The example page uses app.js to load extjs views. Now here is my question. I have an application with multiple pages. Do i need to make separate app.js like scripts for each page of my app or could i use the same app.js accross all my pages. If i could, kindly mention how.
Thanks...
All of the answers here are correct, however the question seems to be a bit ambiguous so that's why they are all slightly different.
The typical RIA app is a single HTML(or php,jsp,asp) page with many different views all managed by the the JS framework, so changing pages is no longer required (and in most cases avoided for performance reasons).
Your server side code/scripts are then typically reduced to JSON data services that provide data to the RIA app running completely independently in the client browser.
As you can see you would not need to have test.php and index.php and would suffice to have one index.php with ExtJS application running out of that page.
If this answer is not useful because you already knew all of this and really meant to ask about multiple controllers and modularization of an ExtJS application then that's a separate discussion and has been addressed to an extent in other posts. (look for lazy loading controllers).
Hope this helps.
Every page. Every time a page unloads, it's like the JS slate gets cleared. The browser will actually cache the files but the code executes like it was the first time.
Usually it's same app.js for all different views.
The MVC concept of ExtJS 4 is about architecture. The documentation clarifies that pretty easily.
Every Ext JS 4 application starts with an instance of Application class. The Application contains global settings for your application (such as the app's name), as well as maintains references to all of the models, views and controllers used by the app. An Application also contains a launch function, which is run automatically when everything is loaded.B
As you can see in the docs, you will have one single app.js, that is gonna be like a bootstrap, responsible to instantiate the whole application.
You are gonna structure your files, however, following the MVC approach, or pattern, in order to have a nice and clean architecture.
I've been developing a site to be able to curate sports media using Django, and that's going reasonably well, but my friend that I'm working with has some of our required functionality (some information display, page-level stuff) going with PHP. Is there an easy way to integrate those, like maybe running the php through the Django templates, or should we try and convert some the functions to one language or the other?
In such cases, I think, it makes sense to make some kind of internal interface through which your sites would communicate, and expose only one of them to public. That would make everything more maintainable.
For example, your friend can make his PHP pages to output information in JSON or YAML. In corresponding Django views, you'll have little to no logic, just making internal HTTP requests to these pages, and basically passing the data to templates.
This way, you'll have output via Django templates, and some logic still in PHP. If PHP code does some work with database or performs computation that can't be converted easily enough to Python, and you have limited time, this option may be the best.
Though, I guess, it depends a lot on the architecture of the project, especially the PHP part. There's not enough information to say what's the best option for you.
Don't mix languages if you have any other option. Honestly, I don't think the type of integration you're imagining is even possible. About the closest you would ever get would be two separate websites that shared a common look and feel and passed info back and forth to each other. At the end of the day, though, there would always be a separation of management and data.
There's some pretty robust PHP frameworks out there. Assuming your friend is using one of those, you'll need to decide which best fits with the time and skills you both have to devote to the project. If your friend is not using a framework, the decision is simple: move everything over to Django.
I'm working on a project that allows multiple users to submit large data files and perform operations on them. The "backend" which performs these operations is written in Perl while the "frontend" uses PHP to load HTML template files and determines which content to deliver. Data is stored in a database (MySQL, SQLite, Oracle) and while there is data which has not yet been acted upon, Perl adds it to a running queue which delivers data to other threads based on system load. In addition, there may be pre- and post-processing of the data before and after the main Perl script operates (the specifications are unclear) so I may want to allow these processors to be user-selectable plugins. I had been writing this project in a more procedural fashion but I am quickly realizing the benefit of separating concerns as to limit the scope one change has on the rest of the project.
I'm quite unexperienced with design patterns and am curious what the best way to proceed is. I've heard MVC thrown around quite a bit but I am unsure of how to apply it. Specifically, what are some good options to structure this code (in terms of design patterns and folder hierarchy)? How can I achieve this with both PHP and Perl while minimizing duplicated code between languages? Should I keep my PHP files in the top level so I don't have ugly paths in the URL?
Also, if I want to provide interchangeable databases, does each table need its own DAO implementation?
This is really several questions, but here goes:
MVC
To implement MVC you'll need to have a clear idea of what the Model, View and Controller sections are responsible for. You can read about this for yourself, but in this case:
The model should only contain the code which performs operations on the data files, i.e. the back-end Perl scripts
The view will be the HTML templates only. No PHP logic should be embedded in them except what's necessary to display the page.
The controller will be the rest of the application: the parts that connect the PHP front-end to the Perl back-end, and possibly the Perl scripts that poll for new files.
For every php, html or perl file you create, it should be absolutely clear to which section it belongs, in its entirety. Never mix up model, view or controller code in the same file.
There should be no reason why you can't continue writing procedurally. You don't necessarily need a framework either; It may help you to slot things into place, but may also take some time to learn.
MVC is a more of a separation of concerns that you need to keep in mind. A good way to think about it is: "Can each of these components work separately from the others", e.g.:
can you write a 'mocked up' (example) data file, and have the Perl scripts process it without running any of the PHP code?
can you request an operation from the front-end, and have it deliver all the parameters to a single place, ready for a single Perl routine to pick up, without running and Perl code?
You shouldn't need to worry about code duplication if the PHP and Perl scripts are doing totally different things (PHP is only setting up users parameters and input files, and Perl is only taking those parameters and files, and outputting new files).
As for folder hierarchy, if you're not using any existing framework, the most important thing is just that it makes sense, is consistent, and that you document your decisions, e.g. in a readme file.
Ugly URLs
You don't need to put your php files in any particular place. Use Apache rewrite rules to make the URLs pretty afterwards. (rewrite rules generator - see the "301 Redirect File" section). But a good MVC framework will solve this for you.
User-selectable plugins
Be careful not to optimise too early. You may be able to develop the new pre/post-processing steps yourself, and just put them in a list for users to select from.
MVC frameworks are a great tool, for any web developer, that provides well-defined separation indispensable for keeping your code organized.
For PHP I recommend Zend Framework
Database schema will change depending on what platform you use.
I've noticed that a PHP frameworks; Zend, Cake, and Symfony; seem to either generate JavaScript or allow it to be embedded as a string into the PHP itself. Is this a good idea? From people who've used these frameworks/libraries, what has been your experience working with the Ajax and JavaScript helpers? Has it been easy to maintain? Does it cut down on development time?
No it is a bad idea,
Generated javascript usually means that the site won't even function without it (like many asp.net sites). If you want to do more complex things or want to enhance accesibility there is no other way around than clearly seperating HTML from CSS and Javascript.
Seperating Javascript also makes your code more maintainable as you do not need to have your client side frontend developers mess with your PHP code and the other way around.
The best way to use Javascript is to first let php generate your html, then at the bottom of that page include your javascript files and use functionality like onDomReady. This also doesn't force you to use a particular library just because your framework is using that as base for its generated Javascript.
This is quite a subjective question, but personally, I wouldn't want a back-end framework to do this for me. It's better to keep a clean seperation between business logic, presentation, and client-side UI behaviours for a number of reasons:
More maintainable applications.
Easier to test individual components.
Easier collaboration. Different skill-sets can work on different areas.
Should help ensure your application does not rely on JavaScript in the end users environment.
Personally, I like to write my Javascript by hand, unobtrusively so that i just have to add an extra event to document.domReady with for example the correct parameters. That little trigger function then gets the ball rolling.
Best practice of the day:
Keep frontend-code and backend code
untangled as much as you can
I would say it depends, like anything. There is certainly some value in having "smart" server side widgets. For example, a widget that "knows" how to update itself through AJAX, or a form which can handle client side, and server side validation. The latter is an example of which it would be costly and time consuming and error prone to rewrite boring validation code in the client. It doesn't require rocket-science javascript, so as long as your framework can handle it unobtrusively, I would actually advise this route.
Additionally, framework code that will handle GUI stuff also (a la ext or something similar), is also not a bad a idea.
However, anything more complicated than that, please use Javascript itself.
I personally love writing my own Javascript so I don't really want it written for me, but I don't see it as being particularly 'dangerous' or 'harmful' to have frameworks that do it for you, as long as it is properly done. My biggest problem with them is that most of them will work as long as you want the standard behavior of a feature, but as soon as you want something a little different to meet your project's needs better it takes so much work to customize it you would have been better served to do it yourself. At least that was my experience with CakePHP's javascript automation.
My experience with the Javascript and Ajax helpers in CakePHP has been very positive.
They have allowed server-side developers to prototype and build features that otherwise would require someone with real client-side experience to do, all without having worry about the quality of the javascript code they "write" and leaving the real front-end engineers free to focus on the advanced client-side features.
It's not a good idea for the PHP to generate Javascript. The only javascript I would recommend exporting is simple JSON assignments like the following:
<script type="text/javascript"><!--
var MyNamespace.info = <?php echo json_encode($info_array) ?>
// --></script>
This is the easiest way to sanitize PHP information and let it be accessible to javascript on the client. However, anything else should be written in actual JAVASCRIPT FILES that are referenced with tags at the head of the document. The only other appearance of Javascript from server-side files, that I would say is alright, is stuff placed into "onclick" and other such attributes.
The rationale for this is that the Javascript should be written and maintained by front-end people who know Javascript, and the site should be able to work (at least partially) without javascript. There is no reason to generate spaghetti Javascript inline.
Check out my PHP framework, PHP On Pie (http://phponpie.com) for an example of how to implement this properly. It keeps the JS and PHP separate, except when exporting JSON as shown above. However it also provides conventions for easy interoperation between the client and server via AJAX.
I believe you should keep languages apart. Even though they can complement each other. That way you can pick the implementation of said language and create a mix that fits you perfect.
I think there is definitely a place for generated javascript. (1)
The number one reason for generated javascript is ease of maintenance. Any dependencies are explicitly encoded and configured from the framework (PHP, ruby, scala, python) itself. For instance if you move your assets or change the upload directory, just update the configuration and watch things Just Work.
Need client side input validation to take some load off your server? (2) Let the framework generate correct validation code derived directly from your data model for you. With generated, javascripted population your framework can serve pre-rendered, static HTML forms from the cache. This could be a huge win if your forms contain lots of selects and options.
1) Assuming that the client has decided that it's OK for the site to depend (more or less) on javascript, with all the caveats that entails. Graceful degradation may or may not be possible or desirable.
2) You need server side side validation too, but you knew that, right?