PHP easy

Monday, 8 October 2012

Important points in Zend SOAP webservice

1)Mention the comments in defined class which we are called in SOAP webservice.

If u r not mention the comments the result will not displayed.

HTML Iframes

An iframe is used to display a web page within a web page.

yntax for adding an iframe:

<iframe src="URL"></iframe>

The URL points to the location of the separate page.

Iframe - Set Height and Width

The height and width attributes are used to specify the height and width of the iframe.

The attribute values are specified in pixels by default, but they can also be in percent (like "80%").

Use iframe as a Target for a Link

An iframe can be used as the target frame for a link.
The target attribute of a link must refer to the name attribute of the iframe:

Example

<iframe src="demo_iframe.htm" name="iframe_a"></iframe>
<p><a href="http://www.w3schools.com" target="iframe_a">W3Schools.com</a></p>

Try it yourself »

Example

<iframe src="demo_iframe.htm" width="200" height="200"></iframe>

Iframe - Remove the Border

The frameborder attribute specifies whether or not to display a border around the iframe.
Set the attribute value to "0" to remove the border:

Example

<iframe src="demo_iframe.htm" frameborder="0"></iframe>

Thursday, 4 October 2012

Zend useful link

http://ailoo.net/2009/04/set-up-a-zend-framework-application-using-zend_application-including-phpunit-setup/

Zend SOAP webservice related urls

1)http://www.tutorial-portal.com/tutorial/show/id/40
2)http://electrotek.wordpress.com/2008/04/19/soap-web-service-with-zend-framework/
3)http://devzone.zend.com/25/php-soap-extension/
4)http://www.ibm.com/developerworks/webservices/library/x-zsoap/index.html
5)http://tutorials.jenkov.com/web-services/message-formats.html

SOAP Webservice

SOAP is a simple XML-based protocol to let applications exchange information over HTTP.

Or more simply: SOAP is a protocol for accessing a Web Service.

What is SOAP?

SOAP stands for Simple Object Access Protocol
SOAP is a communication protocol
SOAP is for communication between applications
SOAP is a format for sending messages
SOAP communicates via Internet
SOAP is platform independent
SOAP is language independent
SOAP is based on XML
SOAP is simple and extensible
SOAP allows you to get around firewalls
SOAP is a W3C recommendation

Why SOAP?

It is important for application development to allow Internet communication between programs.

Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic.

A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers and servers. SOAP was created to accomplish this.

SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages.

SOAP Building Blocks

A SOAP message is an ordinary XML document containing the following elements:

An Envelope element that identifies the XML document as a SOAP message
A Header element that contains header information
A Body element that contains call and response information
A Fault element containing errors and status information

All the elements above are declared in the default namespace for the SOAP envelope:

Syntax Rules

Here are some important syntax rules:

A SOAP message MUST be encoded using XML
A SOAP message MUST use the SOAP Envelope namespace
A SOAP message MUST use the SOAP Encoding namespace
A SOAP message must NOT contain a DTD reference
A SOAP message must NOT contain XML Processing Instructions

Skeleton SOAP Message

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header>

...

</soap:Header>

<soap:Body>

...

  <soap:Fault>

  ...

  </soap:Fault>

</soap:Body>

</soap:Envelope>

he SOAP Envelope element is the root element of a SOAP message.

The SOAP Envelope Element

The required SOAP Envelope element is the root element of a SOAP message. This element defines the XML document as a SOAP message.

Example

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

  ...

  Message information goes here

  ...

</soap:Envelope>

The xmlns:soap Namespace

Notice the xmlns:soap namespace in the example above. It should always have the value of: "http://www.w3.org/2001/12/soap-envelope".

The namespace defines the Envelope as a SOAP Envelope.

If a different namespace is used, the application generates an error and discards the message.

The encodingStyle Attribute

The encodingStyle attribute is used to define the data types used in the document. This attribute may appear on any SOAP element, and applies to the element's contents and all child elements.

A SOAP message has no default encoding.

Syntax

soap:encodingStyle="URI"

Example

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

  ...

  Message information goes here

  ...

</soap:Envelope>

Wednesday, 3 October 2012

Webservices

Web Services can convert your applications into Web-applications.

Web Services are published, found, and used through the Web.

What You Should Already Know

Before you continue, you should have a basic understanding of the following:

HTML
XML

If you want to study these subjects first, find the tutorials on our Home page.

What are Web Services?

Web services are application components
Web services communicate using open protocols
Web services are self-contained and self-describing
Web services can be discovered using UDDI
Web services can be used by other applications
XML is the basis for Web services

How Does it Work?

The basic Web services platform is XML + HTTP.

XML provides a language which can be used between different platforms and programming languages and still express complex messages and functions.

The HTTP protocol is the most used Internet protocol.

Web services platform elements:

SOAP (Simple Object Access Protocol)
UDDI (Universal Description, Discovery and Integration)
WSDL (Web Services Description Language)

We will explain these topics later in the tutorial.

Monday, 1 October 2012

Difference between native applicaton and mobile web app

Native App vs. Mobile Web App: A Quick Comparison

A light bulb goes off. You have the next great idea for a mobile app that you want to develop. It’ll change lives. It’ll make you millions. What’s the next step you need to take?

One of the things you’ll need to decide early on in your mobile application development process is how you’ll build and deploy your app. There are two main directions you can go: native app or mobile web app. In this article, we’ll talk about the differences between the two so you can make an informed decision.

Native App vs. Mobile Web App: Definition

First, let’s define what we mean in this article when we say "native app" and "mobile web app".

What is a Native App?

A native app is an app for a certain mobile device (smartphone, tablet, etc.) They’re installed directly onto the device. Users typically acquire these apps through an online store or marketplace such as The App Store or Android Apps on Google Play.

Examples of native apps are Camera+ for iOS devices and KeePassDroid for Android devices.

What is a Mobile Web App?

When we talk about mobile web apps in this article, we’re referring to Internet-enabled apps that have specific functionality for mobile devices. They’re accessed through the mobile device’s web browser (i.e. on the iPhone, this is Safari by default) and they don’t need to be downloaded and installed on the device.

Comparison of Native App vs. Mobile Web App

Let’s do a quick rundown and evaluate native apps versus mobile web apps under these factors:

User interface
Development
Capabilities
Monetization
Method of delivery
Versioning of the app
Strengths
Weaknesses

User Interface

Some companies choose to develop both a native app and a mobile web app. Here’s a side-by-side look at Facebook’s native app and mobile web app:

Notice that, in terms of the general look-and-feel, there’s little difference between the two, making for a consistent user experience.

Development

Native Apps	Mobile Web Apps
Each mobile application development platform (e.g. iOS, Android) requires its own development process	Runs in the mobile device’s web browser and each may have its own features and quirks
Each mobile application development platform has its own native programming language: Java (Android), Objective-C (iOS), and Visual C++ (Windows Mobile), etc.	Mobile web apps are written in HTML5, CSS3, JavaScript and server-side languages or web application frameworks of the developer’s choice (e.g. PHP, Rails, Python)
Standardized software development kits (SDKs), development tools and common user interface elements (buttons, text input fields, etc.) are often provided by the manufacturer of the platform	There are no standard software development kits (SDKs) that developers are required to use to make a mobile web app
There are tools and frameworks to help in developing apps for deployment on multiple mobile OS platforms and web browsers (e.g. PhoneGap, Sencha Touch 2, Appcelerator Titanium, etc.)

Capabilities

Native Apps	Mobile Web Apps
Can interface with the device’s native features, information and hardware (camera, accelerometer, etc.)	Mobile web apps can access a limited amount of the device’s native features and information (orientation, geolocation, media, etc.)

Monetization

Native Apps	Mobile Web Apps
Mobile-specific ad platforms such asAdMob (though there can berestrictions set by the mobile device’s manufacturer)	Mobile web apps can monetize through site advertisement and subscription fees
Developers have the ability to charge a download price and app stores will typically handle the payment process (in exchange for a percentage of sales)	Charging users to use the mobile web app requires you to set up your own paywall or subscription-based system

Method of Delivery

Native Apps	Mobile Web Apps
Downloaded onto a mobile device	Accessed through a mobile device’s web browser
Installed and runs as a standalone application (no web browser needed)	No need to install new software
Users must manually download and install app updates	Updates are made to the web server without user intervention
There are stores and marketplaces to help users find your app	Since there is no app store for the Mobile Web, it can be harder for users to find your app

Versioning of the App

Native Apps	Mobile Web Apps
Some users may choose to ignore an update, resulting in different users running different versions of the app	All users are on the same version

Strengths

Native Apps	Mobile Web Apps
Typically perform faster than mobile web apps	Have a common code base across all platforms
App stores and marketplaces help users find native apps	Users don’t have to go to a store or marketplace, download the app and install the app
App store approval processes can help assure users of the quality and safety of the app	Can be released in any form and any time as there isn’t an app store that has to approve the app
Tools, support and standard development best practices provided by device manufacturers can help speed up development	If you already have a web app, you can retrofit it with a responsive web design

Weaknesses

Native Apps	Mobile Web Apps
Are typically more expensive to develop, especially if you’re supporting multiple mobile devices	Mobile web apps can’t access all of the device’s features (yet)
Supporting multiple platforms requires maintaining multiple code bases and can result in higher costs in development, maintenance, pushing out updates, etc.	Supporting multiple mobile web browsers can result in higher costs in development and maintenance, etc.
Users can be on different versions and can make your app harder to maintain and provide support for	Users can be on different mobile browsers and can make your app harder to maintain and provide support for
App store approval processes can delay the launch of the app or prevent the release of the app	For users, it may be harder to find a mobile web app because of the lack of a centralized app store (though listings do exist such as Apple’s Web apps and you can request to be listed in them)

Native App vs. Mobile Web App: How Do You Choose?

To help you decide how you should build your mobile app, ask yourself these questions:

Does the mobile app require the use of any special device features (i.e., camera, the camera’s flash, accelerometer, etc.)?
What’s my budget?
Does the mobile app need to be Internet-enabled?
Do I need to target all mobile devices or just certain devices?
What programming languages do I already know?
How important is speed and performance?
How will this app be monetized effectively?

Answering these questions can help you make an informed decision.

Conclusion

Whether you decide to build a native app or a mobile web app depends on many factors: business objectives, target audience, technical requirements and so on.

You don’t necessarily have to choose between building a native app or a mobile web app. As mentioned earlier, companies like Facebook maintain both native apps and a mobile web app. However, for many of us, budget and resource constraints will require us to decide if we need to build a native app or a mobile web app (or, at least, will require us to prioritize which one to develop first).