The
ability to build apps from your desktop or local server is a huge plus
for developers using their own debug tools, test suites, etc. With our
latest Version 1.0.4 release, we now support these use cases plus the
ability to run apps from outside of your DSP and still enjoy the
flexibility of our REST API.
Simply log in to your DSP and click on the System Config
menu item on the left hand side. On the System Config screen you’ll see
the CORS Access options. Setting * will allow you to work from your
desktop or anywhere. You may also use your localhost server, or another
DSP or remote server you wish to have access to your data or service.
Having the allowed verbs checkboxes enforces another layer of access
control by locking down the entire DSP to use only the verbs checked for
CORS. A future release will have CORS Access specifiable per
application.
To use CORS without logging in, you’ll also have to
allow for Guest Access, and create a Role for guest user access. This
way you can limit any guest access to only database tables or services
you see fit.
If you’d like to pass authentication instead of having a guest role, consult our Swagger API docs here
for the latest API call for logging in a user (see the /user/session
POST request). That POST will return a session_id that you can pass as a
new header called X-DreamFactory-Session-Token with all your future API
requests. You will also need to include the API name you created with
your application as X-DreamFactory-Application-Name if you haven’t
already.
We’ve also added live data through a new publication / subscription framework.
We’re using Faye running on Node. Check here for the Faye documentation as well some good advice on security.
Need to see it working? Here’s a Plunker showing our Angular Todo Application using CORS and PubSub to talk to our demo server.
To see pub/sub working on it’s own, try this real time chat app on Plunker
Enjoy! And as always, if you have any questions, please contact us!
DreamFactory Services Platform (DSP)
was designed from the beginning to be a very secure way for an
enterprise customer to host mobile applications. This blog post covers
security benefits on the server side and at the client, and towards the
end we discuss the advantages of our user roles and permissions system.
From the server side, you can install a DSP on your own cloud
computer or data center. The DSP software package includes a complete
LAMP Stack with PHP and a dedicated MySQL database that can be installed
on any Linux virtual machine. This allows a company to use the same
deployment and management practices for a DSP that they are already
using for other applications. They can monitor usage, make backups,
control cost, configure firewalls, and deploy applications with familiar
tools and systems.
The open source nature of the DSP code base
is also designed for security. An open source product has "many eyes" on
the code base. We have signed up for third party security audits as
well. DreamFactory Software has a team of engineers adding new features
and looking for security problems on a regular basis. The latest version
of the software is available from us at various cloud marketplaces.
Since we are not hosting your application, there is no risk of
DreamFactory losing your data. You do not need to worry about how we
manage our data center, or how we keep your data separate from other
customers.
There are aspects of the service architecture that
also lend themselves to security. The service architecture has a single
point of entry, so all service calls pass through this gateway. We have
written the code in the latest version of PHP, the most widely used web
programming framework in the world. The use of PHP helps with issues
like buffer overrun attacks. The SQL interface completely decomposes and
recomposes all query strings to prevent SQL injection attacks as well.
When
a user signs on to a DSP they receive a session ID, which is securely
managed as a browser cookie in an HTML5 application, or as a transient
local variable in a native application. All network transactions are
conducted over HTTPS, thus adding the security capabilities of SSL/TLS
to standard HTTP communications. The DSP also implements cross-origin
resource sharing (CORS) support and a white list that controls which
domains can use the platform. This enables any website or domain to use
the platform services if desired. By default CORS support is turned off
and the services are only available from the originating host.
The
DSP service interface enables automated or manual data synchronization
with other databases or external partners as needed. A special user role
could be created for the DSP that grants access only to required
database objects. This allows an enterprise to construct a "data
firewall" where sensitive data can be moved in or out of the DSP as
needed. This data is exposed to mobile users, so even if the DSP
database is compromised, there would be no way to gain access to the
master database.
From the client side, each DSP comes with a
complete and comprehensive services palette. This makes your mobile
application somewhat future proof: there is no need to re-engineer the
backend services for every new feature at the client. Our user
management features are also very extensive. Single sign-on, user roles,
guest users, open registration, password resets, email services, email
templates, and password hashing are all carefully implemented.
One
special security feature for users is that administrative updates to
user roles and permissions are instantly reflected in the current
session. For example, if a user is inactivated his session becomes
invalid immediately. This provides a more secure environment for people
entering or leaving the company and for lost devices or security
breaches.
Each DSP also contains some high level security
features for controlling which users see which data, services, and
applications. This is very useful for segmenting the user base with
different roles. The information that a sales or marketing person might
see can be different from a project manager or company executive. This
capability implements a higher level of security that prevents
accidental data loss or disclosure of sensitive information.
Multiple
applications can be hosted on a single DSP, and the administrator can
create user roles to control which users see which applications. For
example, a project manager would see a Gantt chart application,
individual contributors would see a project calendar, and executives
would see a report generator. The entire suite of visible applications
can be adjusted based on appropriate user interest and role.
User
roles also control what database objects are visible. This enables
people to use the same application in different ways. For example, some
people might see all data as read only, while others have the rights to
create or delete data. The application can detect these permissions for a
particular object at runtime and make various options available or
inactive as needed. This capability also allows information to be hidden
from certain groups. For example, individual sales people might not
have access to salary information, while this data might be available
for managers or executives.
Roles have the ability to enable or
disable individual services as well. This controls access to 3rd party
services that have been integrated with the DSP. One popular service is
BLOB storage, these are binary documents stored locally on the DSP
server or remotely in S3 or Azure. Each service can specify the external
credentials to the service and also the access root of the folder tree.
This enables each user role fine grained access to multiple document
repositories.
The services have another useful capability.
Various URL parameters and HTTP headers can be specified in the service
object. This information is entered by an administrator and securely
stored on the DSP server. Once the user enters their single sign-on
credentials, they have controlled access to these external services as
enabled by their user role. This capability removes the need for the
client application at runtime to store any master credentials to
external services. Another benefit of this architecture is that external
services can be activated, deactivated, or redirected without changing
client software.
Every DSP features a comprehensive and unified services palette. This
approach reduces the need for rewriting and redeploying the services
platform when new client side features are needed. We provide very
carefully written features for user management, single sign-on, open
registration, and guest accounts. If a user leaves their iPad on an
airplane an administrator can instantly kill their session. We provide
programmable CORs support so that your services can be exposed to
foreign web sites, or you can run all the applications off the
originating host depending on your security policies.
At a higher level, each DSP provides detailed administrative
permissions for users by role. The administrator can control application
visibility, CRUD access for SQL and noSQL data, CRUD access for BLOB
storage by folder tree, and REST access to external services with
credential hiding. This allows the admin to limit user information by
role, further enhancing system security.
Without diving into too much detail, here is this process in action. Suppose
you want to add a /contact page to your Symfony application. First, start
by adding an entry for /contact to your routing configuration file:
This example uses YAML to define the routing
configuration. Routing configuration can also be written in other formats
such as XML or PHP.
When someone visits the /contact page, this route is matched, and the
specified controller is executed. As you'll learn in the routing chapter,
the AcmeDemoBundle:Main:contact string is a short syntax that points to a
specific PHP method contactAction inside a class called MainController:
In this very simple example, the controller simply creates a
Response object with the HTML
<h1>Contact us!</h1>. In the controller chapter,
you'll learn how a controller can render templates, allowing your "presentation"
code (i.e. anything that actually writes out HTML) to live in a separate
template file. This frees up the controller to worry only about the hard
stuff: interacting with the database, handling submitted data, or sending
email messages.
You now know that the goal of any app is to interpret each incoming request
and create an appropriate response. As an application grows, it becomes more
difficult to keep your code organized and maintainable. Invariably, the same
complex tasks keep coming up over and over again: persisting things to the
database, rendering and reusing templates, handling form submissions, sending
emails, validating user input and handling security.
The good news is that none of these problems is unique. Symfony provides
a framework full of tools that allow you to build your application, not your
tools. With Symfony2, nothing is imposed on you: you're free to use the full
Symfony framework, or just one piece of Symfony all by itself.
So what is Symfony2? First, Symfony2 is a collection of over twenty independent
libraries that can be used inside any PHP project. These libraries, called
the Symfony2 Components, contain something useful for almost any situation,
regardless of how your project is developed. To name a few:
HttpFoundation - Contains
the Request and Response classes, as well as other classes for handling
sessions and file uploads;
Routing - Powerful and fast routing system that
allows you to map a specific URI (e.g. /contact) to some information
about how that request should be handled (e.g. execute the contactAction()
method);
Form - A full-featured and flexible framework for creating forms and
handling form submissions;
Validator - A system for creating rules about data and then validating
whether or not user-submitted data follows those rules;
ClassLoader - An autoloading library that allows
PHP classes to be used without needing to manually require the files
containing those classes;
Templating - A toolkit for rendering
templates, handling template inheritance (i.e. a template is decorated with
a layout) and performing other common template tasks;
Security - A powerful library for handling all types of security inside
an application;
Translation A framework for translating strings in your application.
Each and every one of these components is decoupled and can be used in any
PHP project, regardless of whether or not you use the Symfony2 fram
So then, what is the Symfony2 Framework? The Symfony2 Framework is
a PHP library that accomplishes two distinct tasks:
Provides a selection of components (i.e. the Symfony2 Components) and
third-party libraries (e.g. Swift Mailer for sending emails);
Provides sensible configuration and a "glue" library that ties all of these
pieces together.
The goal of the framework is to integrate many independent tools in order
to provide a consistent experience for the developer. Even the framework
itself is a Symfony2 bundle (i.e. a plugin) that can be configured or replaced
entirely.
Symfony2 provides a powerful set of tools for rapidly developing web applications
without imposing on your application. Normal users can quickly start development
by using a Symfony2 distribution, which provides a project skeleton with
sensible defaults. For more advanced users, the sky is the limit.
ework.
Every part is made to be used if needed and replaced when necessary.
When you let Symfony handle each request, life is much easier. Symfony follows
the same simple pattern for every request:
Incoming requests are interpreted by the routing and passed to controller
functions that return Response objects.
Each "page" of your site is defined in a routing configuration file that
maps different URLs to different PHP functions. The job of each PHP function,
called a controller, is to use information from the request - along
with many other tools Symfony makes available - to create and return a Response
object. In other words, the controller is where your code goes: it's where
you interpret the request and create a response.t's that easy! To review:
Each request executes a front controller file;
The routing system determines which PHP function should be executed based
on information from the request and routing configuration you've created;
The correct PHP function is executed, where your code creates and returns
the appropriate Response object.
Like HTTP itself, the Request and Response objects are pretty simple.
The hard part of building an application is writing what comes in between.
In other words, the real work comes in writing the code that interprets the
request information and creates the response.
Your application probably does many things, like sending emails, handling
form submissions, saving things to a database, rendering HTML pages and protecting
content with security. How can you manage all of this and still keep your
code organized and maintainable?
Traditionally, applications were built so that each "page" of a site was
its own physical file:
1
2
3
index.php
contact.php
blog.php
There are several problems with this approach, including the inflexibility
of the URLs (what if you wanted to change blog.php to news.php without
breaking all of your links?) and the fact that each file must manually
include some set of core files so that security, database connections and
the "look" of the site can remain consistent.
A much better solution is to use a front controller: a single PHP
file that handles every request coming into your application. For example:
/index.php
executes index.php
/index.php/contact
executes index.phpNow, every request is handled exactly the same way. Instead of individual URLs
executing different PHP files, the front controller is always executed,
and the routing of different URLs to different parts of your application
is done internally. This solves both problems with the original approach.
Almost all modern web apps do this - including apps like WordPress.
Using Apache's mod_rewrite (or equivalent with other web servers),
the URLs can easily be cleaned up to be just /, /contact and
/blog.
Symfony was created to solve these problems so that you don't have to.
Inside your front controller, you have to figure out which code should be
executed and what the content to return should be. To figure this out, you'll
need to check the incoming URI and execute different parts of your code depending
on that value. This can get ugly quickly:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// index.phpuseSymfony\Component\HttpFoundation\Request;useSymfony\Component\HttpFoundation\Response;$request=Request::createFromGlobals();$path=$request->getPathInfo();// the URI path being requestedif(in_array($path,array('','/'))){$response=newResponse('Welcome to the homepage.');}elseif($path=='/contact'){$response=newResponse('Contact us');}else{$response=newResponse('Page not found.',Response::HTTP_NOT_FOUND);}$response->send();
Solving this problem can be difficult. Fortunately it's exactly what Symfony
is designed to do.
Symfony also provides a Response class: a simple PHP representation of
an HTTP response message. This allows your application to use an object-oriented
interface to construct the response that needs to be returned to the client:
1
2
3
4
5
6
7
8
9
useSymfony\Component\HttpFoundation\Response;$response=newResponse();$response->setContent('<html><body><h1>Hello world!</h1></body></html>');$response->setStatusCode(Response::HTTP_OK);$response->headers->set('Content-Type','text/html');// prints the HTTP headers followed by the content$response->send();
New in version 2.4: Support for HTTP status code constants was added in Symfony 2.4.
If Symfony offered nothing else, you would already have a toolkit for easily
accessing request information and an object-oriented interface for creating
the response. Even as you learn the many powerful features in Symfony, keep
in mind that the goal of your application is always to interpret a request
and create the appropriate response based on your application logic.
The Request and Response classes are part of a standalone component
included with Symfony called HttpFoundation. This component can be
used entirely independently of Symfony and also provides classes for handling
sessions and file uploads.
So how do you interact with the "request" and create a "response" when using
PHP? In reality, PHP abstracts you a bit from the whole process:
1
2
3
4
5
6
$uri=$_SERVER['REQUEST_URI'];$foo=$_GET['foo'];header('Content-type: text/html');echo'The URI requested is: '.$uri;echo'The value of the "foo" parameter is: '.$foo;
As strange as it sounds, this small application is in fact taking information
from the HTTP request and using it to create an HTTP response. Instead of
parsing the raw HTTP request message, PHP prepares superglobal variables
such as $_SERVER and $_GET that contain all the information from
the request. Similarly, instead of returning the HTTP-formatted text response,
you can use the header() function to create response headers and simply
print out the actual content that will be the content portion of the response
message. PHP will create a true HTTP response and return it to the client:
1
2
3
4
5
6
7
HTTP/1.1 200 OK
Date: Sat, 03 Apr 2011 02:14:33 GMT
Server: Apache/2.2.17 (Unix)
Content-Type: text/html
The URI requested is: /testing?foo=symfony
The value of the "foo" parameter is: symfony
Symfony provides an alternative to the raw PHP approach via two classes that
allow you to interact with the HTTP request and response in an easier way.
The Request class is a simple
object-oriented representation of the HTTP request message. With it, you
have all the request information at your fingertips:
useSymfony\Component\HttpFoundation\Request;$request=Request::createFromGlobals();// the URI being requested (e.g. /about) minus any query parameters$request->getPathInfo();// retrieve GET and POST variables respectively$request->query->get('foo');$request->request->get('bar','default value if bar does not exist');// retrieve SERVER variables$request->server->get('HTTP_HOST');// retrieves an instance of UploadedFile identified by foo$request->files->get('foo');// retrieve a COOKIE value$request->cookies->get('PHPSESSID');// retrieve an HTTP request header, with normalized, lowercase keys$request->headers->get('host');$request->headers->get('content_type');$request->getMethod();// GET, POST, PUT, DELETE, HEAD$request->getLanguages();// an array of languages the client accepts
As a bonus, the Request class does a lot of work in the background that
you'll never need to worry about. For example, the isSecure() method
checks the three different values in PHP that can indicate whether or not
the user is connecting via a secured connection (i.e. HTTPS).
As seen above, the $_GET and $_POST variables are accessible via
the public query and request properties respectively. Each of
these objects is a ParameterBag
object, which has methods like
get(),
has(),
all() and more.
In fact, every public property used in the previous example is some instance
of the ParameterBag.
The Request class also has a public attributes property, which holds
special data related to how the application works internally. For the
Symfony2 framework, the attributes holds the values returned by the
matched route, like _controller, id (if you have an {id}
wildcard), and even the name of the matched route (_route). The
attributes property exists entirely to be a place where you can
prepare and store context-specific information about the request.
Once a server has received the request, it knows exactly which resource the
client needs (via the URI) and what the client wants to do with that resource
(via the method). For example, in the case of a GET request, the server
prepares the resource and returns it in an HTTP response. Consider the response
from the xkcd web server:
nslated into HTTP, the response sent back to the browser will look something
like this:
1
2
3
4
5
6
7
8
HTTP/1.1 200 OK
Date: Sat, 02 Apr 2011 21:05:05 GMT
Server: lighttpd/1.4.19
Content-Type: text/html
<html>
<!-- ... HTML for the xkcd comic -->
</html>
The HTTP response contains the requested resource (the HTML content in this
case), as well as other information about the response. The first line is
especially important and contains the HTTP response status code (200 in this
case). The status code communicates the overall outcome of the request back
to the client. Was the request successful? Was there an error? Different
status codes exist that indicate success, an error, or that the client needs
to do something (e.g. redirect to another page). A full list can be found
on Wikipedia's List of HTTP status codes article.
Like the request, an HTTP response contains additional pieces of information
known as HTTP headers. For example, one important HTTP response header is
Content-Type. The body of the same resource could be returned in multiple
different formats like HTML, XML, or JSON and the Content-Type header uses
Internet Media Types like text/html to tell the client which format is
being returned. A list of common media types can be found on Wikipedia's
List of common media types article.
Many other headers exist, some of which are very powerful. For example, certain
headers can be used to create a powerful caching system.
This request-response conversation is the fundamental process that drives all
communication on the web. And as important and powerful as this process is,
it's inescapably simple.
The most important fact is this: regardless of the language you use, the
type of application you build (web, mobile, JSON API), or the development
philosophy you follow, the end goal of an application is always to understand
each request and create and return the appropriate response.
Symfony is architected to match this reality.
To learn more about the HTTP specification, read the original HTTP 1.1 RFC
or the HTTP Bis, which is an active effort to clarify the original
specification. A great tool to check both the request and response headers
while browsing is the Live HTTP Headers extension for Firefox.
Every conversation on the web starts with a request. The request is a text
message created by a client (e.g. a browser, an iPhone app, etc) in a
special format known as HTTP. The client sends that request to a server,
and then waits for the response.
Take a look at the first part of the interaction (the request) between a
browser and the xkcd web server: n HTTP-speak, this HTTP request would actually look something like this:
1
2
3
4
GET / HTTP/1.1
Host: xkcd.com
Accept: text/html
User-Agent: Mozilla/5.0 (Macintosh)
This simple message communicates everything necessary about exactly which
resource the client is requesting. The first line of an HTTP request is the
most important and contains two things: the URI and the HTTP method.
The URI (e.g. /, /contact, etc) is the unique address or location
that identifies the resource the client wants. The HTTP method (e.g. GET)
defines what you want to do with the resource. The HTTP methods are the
verbs of the request and define the few common ways that you can act upon
the resource:resource:
GET
Retrieve the resource from the server
POST
Create a resource on the serverIn addition to the first line, an HTTP request invariably contains other
lines of information called request headers. The headers can supply a wide
range of information such as the requested Host, the response formats
the client accepts (Accept) and the application the client is using to
make the request (User-Agent). Many other headers exist and can be found
on Wikipedia's List of HTTP header fields article.
PUT
Update the resource on the server
DELETE
Delete the resource from the server
With this in mind, you can imagine what an HTTP request might look like to
delete a specific blog entry, for example:
1
DELETE /blog/15 HTTP/1.1
There are actually nine HTTP methods defined by the HTTP specification,
but many of them are not widely used or supported. In reality, many modern
browsers don't support the PUT and DELETE methods.
Symfony2 and HTTP Fundamentals
Congratulations! By learning about Symfony2, you're well on your way towards
being a more productive, well-rounded and popular web developer (actually,
you're on your own for the last part). Symfony2 is built to get back to
basics: to develop tools that let you develop faster and build more robust
applications, while staying out of your way. Symfony is built on the best
ideas from many technologies: the tools and concepts you're about to learn
represent the efforts of thousands of people, over many years. In other words,
you're not just learning "Symfony", you're learning the fundamentals of the
web, development best practices, and how to use many amazing new PHP libraries,
inside or independently of Symfony2. So, get ready.
True to the Symfony2 philosophy, this chapter begins by explaining the fundamental
concept common to web development: HTTP. Regardless of your background or
preferred programming
HTTP (Hypertext Transfer Protocol to the geeks) is a text language that allows
two machines to communicate with each other. That's it! For example, when
checking for the latest xkcd comic, the following (approximate) conversation
takes place:
And while the actual language used is a bit more formal, it's still dead-simple.
HTTP is the term used to describe this simple text-based language. And no
matter how you develop on the web, the goal of your server is always to
understand simple text requests, and return simple text responses.
language, this chapter is a must-read for everyone.Symfony2 is built from the ground-up around that reality. Whether you realize
it or not, HTTP is something you use everyday. With Symfony2, you'll learn
how to master it.
Besides a framework, there are other solutions that are available to develop both Web
sites and Web applications: CMSs (Content Management System) and their supplemental
modules, as well as packaged professional solutions (CRM, e-commerce solutions, etc.).
If their native features line up perfectly with your immediate and future needs, no
question about it: Go for it! There is no point in reinventing the wheel.
On the other hand, when there are specific needs, specific business rules or even the
need to mix building blocks (content and e-commerce, for example), a framework solution
is necessary: it al
The right questions
To make sure that you are making the right choice, both for the short as well as the
long term, it is necessary to ask the right questions:
What are my current needs? Are they covered by a packaged solution?
What skills do I need if I choose a framework?
Will the developed solution be upgradeable?
And finally, don’t fall into the trap of the “apparent simplicity of the requirements.”
In many cases it quickly becomes apparent that both the business rules and functions
to be implemented are just not so simple to put in place.
By the way, Symfony is also very well suited for “mini-projects.”
lows an application to be developed that perfectly matches your
current needs, while still being innovative.
A framework can be tailored to all requirements.
...but that is not always necessary, especially when the requirements are of a more generic nature.
Before making your selection, map out your current and future
requirements in detail, and then compare the various solutions available
on the market.
Why should I use a framework?
A framework is not absolutely necessary: it is “just” one of the tools that is available
to help you develop better and faster!
Better, because a framework provides you with the certainty that you are developing an
application that is in full compliance with the business rules, that is structured, and
that is both maintainable and upgradable.
Faster, because it allows developers to save time by re-using generic modules in order
to focus on other areas. Without, however, ever being tied to the framework itself.
Investing in the task, not in the technology
This is the basic principle of a framework: Not having to reinvent the wheel.
And doing away with
Guaranteed upgradability and maintenance
In the longer term, a framework ensures the longevity of your applications.
If a development team works as they please, only that particular team will
be able to maintain and upgrade the application with ease. The way that a
publisher supports a proprietary solution.
On the other hand, the structure that a framework provides for the application
makes it possible to avoid this pitfall altogether and it gives any developer
- whether she participated in its development or not – the ability to easily
“adopt” an application, to maintain it over time and to upgrade it both
quickly and neatly, whenever necessary.
In this regard, a framework is not a black box! In the case of Symfony,
it is still PHP… The applications that are developed are not limited to
the Symfony universe, and they are
natively interoperable
with any other PHP library, for example.
foreboding, low value added tasks (for example, the development
of generic components) in order to fully focus on the business rules.
As an example, a framework will keep the developer from having to spend 2 or 3
days creating an authentication form (which is not a specific task). The time
that is saved can be dedicated to more specific components as well as to the
corresponding unit tests; giving you solid, sustainable and high quality code.
A framework is not an absolute necessity, but nonetheless it is very useful.
A framework is a pledge of quality, upgradability and maintainability of applications at lower cost.
Applications developed using a framework are interoperable with market standards.
In order to better understand what a framework is, let’s leave the
world of computer science for a moment and imagine a mountaineering
adventure. Developing an application is very similar to climbing a
rock wall: you are at the bottom (you have an application to be created)
and you need to reach the summit (and be pleased with the achievement
of designing an application that works perfectly.)
If no one has ever climbed the wall in question, you will have to get
by on your own: testing routes, occasionally backtracking so that you
don’t get stuck in a corner, driving in pitons, etc. In contrast, if
the wall has already been conquered, those who have gone before you
will already have done this trial and error work, opening up possible
paths (the frame) and installing the tools that will facilitate the
climb (your work).
Basically, a framework consists of:
A toolbox
- a set of prefabricated, rapidly integratable software components.
This means that you will have to write less code, with less risk of error.
This also means greater productivity and the ability to devote more time
to doing those things which provide greater added value, such as managing
guiding principles, side effects, etc.
A methodology
– an “assembly diagram” for applications. A structured approach may seem
constraining at first. But in reality it allows developers to work both
efficiently and effectively on the most complex aspects of a task, and
the use of Best Practices guarantees the stability, maintainability and
upgradeability of the applications you develop.
And although it might be obvious, we thought it best to say it anyway – Symfony
is a PHP framewo
What could be more useful than an application developed by users for their
own needs? This is the story of the genesis of Symfony – born from the imagination
of the web designers at SensioLabs, a web developer in its own right. Symfony was
made available to everyone under an Open Source license. This benefits other
developers, who also have the ability to improve it by adding their own modules.
All this was done in an environment of Best Practices, standardization and
interoperability of applications.
rk, which means that it permits web applications to be built in PHP!
And behind Symfony, there are people. We are the people of SensioLabs. We created Symfony
to solve our own web development problems and we’re pleased to promote it. We are also
a community of developers, users, and contributors which has formed around Symfony
over the past 5 years.
Symfony is a PHP framework.
Symfony is a framework, a set of tools and a development methodology.
Beyond the tools, Symfony is also a Philosophy and a Community.
In
today's advanced technology, mobile applications plays an important role
to promote any business. In fact, the entire world is going mobile and
want to take the full advantage of this trend as more and more people
are having access to smartphones. So, if you are one of those who want
to build brand and awareness, then there is no better tool than app. You
can market mobile app in few of the effective ways which be simple and
exiting for you. Here are some of the most effective ways that will help
you to market your mobile apps and gain a competitive advantage:
Firstly, the social media sites is one of the best options. Use social
newtorks to post your app as these days people are net savvy. Moreover,
you are targeting the news to exisiting customers who already like your
brand so they will be more interested to download your app.
Secondly, since the home page of your website is usually the first
place that attracts audience so you need to feature your app on the
homepage. This way you will have adavnatge over the targeted audience.
Always remember the most important thing that is to provide a link to
download the app. Also, promote your app who access your websitre
through mobile devices.
Thirdly, blog is something that will help you to a large extent. Your
blog is one place where you can talk about your app. It will be an
opportunity for you to present users with a reason as to why they need
to download your app.
Fourthly, traditional adversting is one of the great ways to promote
your app. To market your app through online channels and offline
channels such as posters and magazines will be a good idea. Furthermore,
you can include, text like “ Download the app at the App store or
Android market etc.
Lastly, in the app itself,you can let your exisiting fans promote your
brand. One of the ways to do is by hosting buzz- worthy giveways or
contents in your app. Like, you can upload attractive and simple content
in your app so that it is easily understoood by the users.
In nutshell, to have a marketing plan ready for your app is an cost
effective way. Just by simply following these quick and interesting
tips, you can launch your app to reach at the pinnacle of success.
This article is contributed by ValueCoders.
For a web application developer it is very difficult to stay organized
if they don't have a clear structure for their apps. Starting with app
development from scratch is a very tough and tedious task, so several
developers select a framework and start development according to it.
Many developers want to initiate their work with PHP frameworks but they
don't have the required knowledge about the best PHP frameworks which
can be really useful for their projects.
The knowledge about the best PHP frameworks comes in handy. Frameworks
are great assistance to PHP developers as they help in structuring the
codes so they can function as a streamlined and logical application.
Frameworks were introduced long time back but it was only with the
advent of Ruby on Rails that developers started adopting frameworks for
their projects.
Nowadays a majority of frameworks follows the model-view-controller
pattern. MVC pattern deals with the presentation of your data. So, now
we have a little overview about the frameworks so let us explore, what
are the best PHP frameworks for your project:
SymfonyDeveloped
by SensioLabs, this framework uses a handy debugging toolbar and
profiler which are very much required for the best PHP framework.
Symfony is very easily customizable and allows you to choose the
different software components that you are already using in your
project.
Zend
The Zend Framework is quite popular among businesses across the globe.
Zend is a very efficient framework, in addition to that it also has
several tools to ease the development process, like it has its own
flavor of PHP and it also has a custom server.
Another feature included in the Zend Studio is a very nicely integrated
development environment, which helps you gain full profits of the
services mentioned above. Though Zend is a pricey framework but if you
don't want to settle with nothing but the best it is the hottest selling
PHP frameworks in the market today.
CodeIgniter
CodeIgniter is a very light application that won't take ton of space
and it is one of the best PHP framework of present times. This framework
is built for speed and its implementation is really easy. To start up
with this framework all you have to do is get the latest version from
Github and download the manual. CodeIgniter is a very powerful PHP
framework and it has a past record of creating tools that make work of
programmers much easier.
The above list of PHP Frameworks is really instrumental in creating a
stunning app from the scratch. Using these frameworks the developers can
attain pinnacle of success in their development business and gain an
edge over their competitors.
This article concludes our introduction to HTML with a
presentation of some valuable guidelines for working with HTML documents
and code that will help maximize their maintainability and reusability.
Of central importance is the need to understand HTML and its role in
Web applications, to plan ahead for maintainable and reusable code, and
to adopt a consistent policy on coding style.
Coding Style Guidelines
Consistency is absolutely a prerequisite for maximizing
maintainability and reusability. These general guidelines for coding
style can form the basis of a set of standards that will help ensure
that all developers in a project—or, better, in all projects across an organization—write code consistently.
Use well-formed HTML.
Pick good names and ID values.
Indent consistently.
Limit line length.
Standardize character case.
Use comments judiciously.
Use Well-formed HTML
Although Web browsers are generally forgiving and can ignore many
mistakes, rendering most HTML as the document author intended, it is
still a good idea to use well-formed HTML code, for a number of reasons.
Well-formed markup code is a concept that has gained importance
with increased implementation of XML. While browsers did not, in
general, enforce HTML language rules very closely, XML parsers do. Code
is considered well formed when it is structured according to the rules
for XML 1.0. These rules relate to character case, tags, nesting, and
attribute values.
In general, when most browsers encounter an unrecognized or
extraneous tag, they ignore them. However, different browsers might
deliver results in different—and unpredictable—ways. In addition, future
versions of browsers might adhere to standards more closely than do
current versions. Finally, code that includes such elements can be
harder to read and understand, making maintenance more difficult.
Lowercase names—To be well-formed, element and
attribute names must be in all lower case. In versions through 4.01,
HTML is not case-sensitive. However, XML is case-sensitive, and it
follows that the XHTML 1.0 recommendation is also case-sensitive. So, to
ensure that code keeps working and to maximize reusability, this must
be planned for.
Closing tags—All nonempty elements must have
corresponding closing tags. Empty elements—those previously signified
with a single tag, such as
and —must be followed immediately by a corresponding closing tag, or the tag must end with "/". For example, and are both examples of well-formed code.
Nested elements—All nested attributes must be properly nested—for example:
Some text
Note that the tag and its corresponding closing tag, , are both nested inside the
and
tags.
If elements overlap, then they are not properly nested, as illustrated in the following code:
Some text
While many browsers have accepted overlapping elements and
given the expected results, they have always been, strictly speaking,
illegal in HTML, and future versions of browsers might not support them.
Attribute values—Attribute values, even numeric attributes should be quoted—for example:
Code validation: Another step toward improving
HTML code is to validate it against a formal published grammar and to
declare this validation at the beginning of the HTML document. For
example, the following line declares validation against the public HTML
3.2 Final grammar:
Use a consistent scheme for assigning the value of name and ID
properties. They should be as short as reasonably possible, but without
giving up descriptive power. Also, use mixed-case property values to
help readability (see Listing 2). In this code snippet, the check box
names express not only what the purpose of the element is, but also
information about the element's type. The code also illustrates the use
of mixed case to help readability.
Listing 2: Example of Good Element Names
Member?
Admin?
Owner?
HTML primarily refers to elements by their name property, while DHTML and client-side scripts use the ID
property. Although DHTML documents IDs must be unique in the document,
in general, there is no reason not to use the same value for an
element's name and ID properties. Using the same value for these
properties can reduce confusion that might arise when mixing HTML and
client-side scripting.
Indent Consistently
Use indentation consistently to enhance the readability of the
code. When elements carry over more than one line of code, indent the
contents of elements between the start tag and the end tag. This will
make it easy to see where the element begins and ends. Also, use
indentation to align code at attribute names (see Listing 3).
It is a good idea to use no more than two to four spaces for each
level in indentation, so as not to use up all the available line length
in indentation. If possible, set up the development tool to convert
tabs to spaces so that the indentation will be the same when the source
is viewed in different editors or as printed output.
Listing 3: Indent Code Consistently
To log into the system, enter your user
name and password in the text boxes. Then
click the "Login" button.
Limit Line Length
Break up lines when they run too long. It is much easier to read
and understand code when you can see the entire line at once. When lines
of code are so long that the reader must scroll right and left to read
them, it requires much more cognitive effort to understand what the code
is doing. Alternatively, in some applications, long lines might wrap to
the next line at the nearest word break. In either case, source code is
much easier to read and understand if the developer takes explicit
control of line length.
HTML is not sensitive to line breaks, so the developer can break
lines at will between keywords for readability. For example, Listing 4
illustrates a code snippet in which two elements have word-wrapped to
the next line because they were two long for the editor window.
Listing 4: HTML Source Code with Uncontrolled Line Breaks
Compare this with Listing 5, where the developer took explicit
control of line length. Here the code is much easier to read because the
developer used line breaks and indenting to visually organize the
source code.
Listing 5: HTML Source Code with Explicit Line Breaks
Keep the limitations of printed output in mind as well. Lines
longer than 80 characters will often wrap in printed output without
consideration for word breaks, making source code very difficult to
read.
Standardize Character Case
Source code is easier to read if the developer has applied a
consistent set of rules for the use of character case—for example, the
use of lower case exclusively for HTML tags. When scanning source code,
the reader can unconsciously apply a visual filter, focusing attention
on the HTML keywords.
The approach taken in code that appears in this article is to use
all lowercase letters for HTML tags and the names of its attributes,
while using mixed case and a modified form of Hungarian Notation for
some attribute values (see the sidebar entitled "Hungarian Notation").
Hungarian Notation
Hungarian Notation is a convention for naming identifiers that
adds a prefix to the name to provide information about the type and
scope of the identifier. Dr. Charles Simonyi, a Microsoft Chief
Architect at the time, introduced Hungarian Notation in the early
1980's. Long an internal Microsoft standard, variants of the convention
have been widely adopted outside of Microsoft as well.
As an example of a simplified Hungarian Notation scheme, variables that contain a string could be prefixed with the character s, and a variable with global scope could be indicated with a gprefix. In this case, then, the variables sTemp and gsName in source code would be immediately identifiable as string variables with local and global scope, respectively.
In general, HTML is not a typed language, and Hungarian Notation
plays a more important role in other types of Web development. However,
in some cases it can add to readability. For example, the names or IDs
of form elements are likely candidates for a modified form of Hungarian
Notation. The prefix "btn" or "cmd" might be used for an input button.
Text boxes might be prefixed with "txt," and check boxes might be
prefixed with "chk" or "cb."
Use Comments Judiciously
Good comments can be invaluable for understanding and maintaining
code. However, the unique nature of HTML introduces a trade-off between
the value of thorough comments and the efficiency of the Web
application.
The Web server reads in the HTML code and sends it as a stream of
text over the network to the browser. Only after arriving at the client
does the browser parse and interpret the HTML code, displaying the
visible elements and ignoring the comments. The obvious implication is
that the comments add nothing to the document as the browser displays
it, yet they add to the processing overhead on both the server and
client computers, and they increase the amount of data transferred. With
almost 50 percent comments, Listing 6 illustrates what is probably
excessively commented code.
Listing 6: Heavily Commented HTML Code
The trick is to find an appropriate level of commenting that
balances these two issues. It is a good idea to comment the major
logical flow and document sections to help readers quickly gain an
overview of the code. Also comment dependencies and assumptions.
Consistently following the other design and coding guidelines as
suggested in this article—especially the ones related to naming and
metadata—will help create self-documenting code.
Listing 7 illustrates how fewer comment lines and more
descriptive element names can combine to provide effective documentation
with a lot less overhead.
Listing 7: Lightly Commented HTML Code
Check list
Use Well-formed HTML
Avoid Style attributes in html
All non empty elements must have corresponding closing tags.
use Lowercase names
All nested attributes must be properly nested—for example:
Some text
Attribute values, even numeric attributes should be quoted
Pick Good Names and ID Values
Use a consistent scheme for assigning the value of name and ID properties.
Documents IDs must be unique in the document
Indent Consistently
Use indentation consistently to enhance the readability of the code
Standardize Character Case
Hungarian Notation is a convention for naming identifiers that
adds a prefix to the name to provide information about the type and
scope of the identifier.e.g. txt for text
One of the ways in which you can cloak your affiliate
link is by creating a php redirect. While this process may seem very
complex it really is not.
Homework
Cloak your affiliate link using a php redirect
Step 1: Create a folder on your desktop called "Suggests"
Step 2: Inside of the new folder create another folder named for the affiliate product you're promoting
Step 3: Open the new sub-folder
Step 4: Download the file in the SUGGESTS folder create a new sub-folder for each product/offer
Step 5: Change the file extension from .txt to .php
Step 6: Log into your FTP program
Step 7: Upload both folders into your website files
If the process of cloaking your link through a php
redirect requires a little too much technical ability then the best
solution is a program called Link Trackr. Using PHP to cloak your affiliate links is a bit
daunting for you then we recommend using LinkTrackr.com. Not
only do they offer to cloak your affiliate links, they also
track your link conversions so you can test your links and see which
ones are most effective.
Because of there conversion tracker you can run tests to
see which button colors are better, which anchor text generates more
clicks and the placement of the link
on different areas of the website. This can help you find
the best types and placements of links to optimize your conversions and
make you more money. Watch the
following video walkthrough for detailed instruction on
setting up your LinkTrackr links.
Homework
Set up a LinkTrackr.com account
Create your first cloaked link
Using BudURL to Cloak your Affiliate Link
BudURL is a lot like LinkTrackr.com and is a worthy alternative and may be better for your needs.
It allows you to track your URLs, track the number of
clicks your URLs are getting and how well they're converting. They offer
a 21 day free trial so feel free to
give it a test run to see if you like it.
Homework:
Set up a BudURL.com Account
Cloak your affiliate link using BudURL
The easiest way to introduce new products to your
followers is through email. The main purpose behind building our own
blog/website is so that we can bring visitors
to our website and get them to join our mailing list; thus
allowing us to market to them on an ongoing basis (hence the term
"permission marketing"). Permission Marketing
Permission marketing is a specific kind of marketing that
includes getting new customers or prospective customers to grant you
permissions to contact them in some
form, whether it's through email, by phone or by mail.
The opposite of permission marketing is interruption
marketing. Commercials and TV are great examples of interruption
marketing because they interrupt the TV shows
you're watching.
Permission marketing is very powerful because you can
build a list of thousands of people who have told you it's ok for you to
contact them. Contrast that attitude
with the attitude most of us have towards commercials, we
either ignore them or we TiVo the show in advance and just skip them.
When building an affiliate website the easiest way to
build a list of current or prospective customers is through email. In
the next few sections we'll cover the
details of how to collect and market to an email list.
Think of your business like an iceberg. Above the water
you can tell basically how much is there. It's obvious and
straightforward. However you know that below the
surface of the water there could be many times the amount of
ice that's above the water but you can't tell.
The tip of the iceberg represents our efforts to acquire new
customers and sell them up front or one time. The rest of the iceberg
represents upsells and the
efforts we make to sell our products to our current
customer.
Forgetting about the ice below the surface of the water
is like forgetting about all the customers who have purchased products
from our website via our customer
acquisition channels like PPC and SEO. First we need to
understand that all those customers represent people who have trusted us
enough to pull out their credit cards
and buy from us.
It is far easier to retain current customers than it is
to acquire new customers
EXAMPLE
Lets say you have a website that does $100,000 in sales
in one year. After expenses you'll have $15k-$20k in take home profit.
Not bad at all for website but it can
definitely be better if you implement permission marketing.
Now lets say during the course of the year you had built
up an email list of 10,000 customers who have already bought from you.
Every other month you sent them a
promotional email offering them a discount or some special
deal. Here are some reasonable numbers to expect from an email campaign:
25% open rate = 2500 people
35% click through rate = 875 people
10% conversion rate = 87.5 people buy
If your average profit per order is $50 that means for
every email you sent out you got $4,375. 6 emails per year would net you
an EXTRA $26,250. That's $6,250 more
than you made with just your one time sales to new
customers.
As you can see permission marketing can be very
profitable, and if you don't implement it you'll be missing out on a LOT
of money.
In the next few sections we'll show you how to build a list and how to write emails that convert into all those extra sales.
so we need to make the most of the relationship
we have with our current customers
and strengthen it.
The
ability to build apps from your desktop or local server is a huge plus
for developers using their own debug tools, test suites, etc. With our
latest Version 1.0.4 release, we now support these use cases plus the
ability to run apps from outside of your DSP and still enjoy the
flexibility of our REST API.
n HTTP-speak, this HTTP request would actually look something like this:
And while the actual language used is a bit more formal, it's still dead-simple.
HTTP is the term used to describe this simple text-based language. And no
matter how you develop on the web, the goal of your server is always to
understand simple text requests, and return simple text responses.
A methodology
– an “assembly diagram” for applications. A structured approach may seem
constraining at first. But in reality it allows developers to work both
efficiently and effectively on the most complex aspects of a task, and
the use of Best Practices guarantees the stability, maintainability and
upgradeability of the applications you develop.
Offshore Mobile Application Development