1 Introduction 2 Used technologies - students site

deliriousattackInternet και Εφαρμογές Web

4 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

104 εμφανίσεις

Wobby
Popescu Andreea-Diana, Porea Ioana Adina, Toma Bianca Gabriela
Faculty of Computer Science, Alexandru Ioan Cuza University , Iași
{diana.popescu, ioana.porea, bianca.toma} @info.uaic.ro
Abstract. A web application that allows users to share their passion and make
suggestions
Keywords: wobby, social, sharing, passions
1 Introduction
This application allows users to share their passions and make suggestions to other
users. After the sign up and log in processes, users can start making suggestions simp-
ly by posting a text, an image or a video. All the other users can see all the sugges-
tions that have been made so far and they can share it on their Facebook account.
2 Used technologies
2.1 HTML5
HTML5 is a markup language for structuring and presenting content for the World
Wide Web and a core technology of the Internet.
HTML has been in continuous evolution since it was introduced to the Internet in the
early 1990s. Some features were introduced in specifications; others were introduced
in software releases. In some respects, implementations and author practices have
converged with each other and with specifications and standards, but in other ways,
they continue to diverge.
HTML4 became a W3C Recommendation in 1997. While it continues to serve as a
rough guide to many of the core features of HTML, it does not provide enough
information to build implementations that interoperate with each other and, more
importantly, with a critical mass of deployed content. The same goes for XHTML1,
which defines an XML serialization for HTML4, and DOM Level 2 HTML, which
defines JavaScript APIs for both HTML and XHTML. HTML5 will replace these
documents.
The HTML5 draft reflects an effort, started in 2004, to study contemporary HTML
implementations and deployed content. The draft:
1. Defines a single language called HTML5 which can be written in HTML
syntax and in XML syntax.
2. Defines detailed processing models to foster interoperable implementations.
3. Improves markup for documents.
4. Introduces markup and APIs for emerging idioms, such as Web applications.
2.2 CSS
The main graphic and attractive presentation form of web pages. It facilitated the
imposition of gradients, textures, icons for controls in the interface, hiding the mark-
up elements, repositioning others.
2.3 API (Application-programming interface)
An application-programming interface is a set of programming instructions and
standards for accessing a Web-based software application or Web tool. A software
company releases its API to the public so that other software developers can design
products that are powered by its service.
An API is a software-to-software interface, not a user interface. With APIs, appli-
cations talk to each other without any user knowledge or intervention. When you buy
movie tickets online and enter your credit card information, the movie ticket Web site
uses an API to send your credit card information to a remote application that verifies
whether your information is correct. Once payment is confirmed, the remote applica-
tion sends a response back to the movie ticket Web site saying it’s OK to issue the
tickets.
As a user, you only see one interface — the movie ticket Web site — but behind
the scenes, many applications are working together using APIs. This type of integra-
tion is called seamless, since the user never notices when software functions are
handed from one application to another.

An API resembles Software as a Service (SaaS), since software developers don’t
have to start from scratch every time they write a program. Instead of building one
core application that tries to do everything — e-mail, billing, tracking, etcetera — the
same application can contract out certain responsibilities to remote software that does
it better.
With APIs, the calls back and forth between applications are managed through
something called Web services. Web services are a collection of technological stand-
ards and protocols, including XML (Extensible Markup Language), the programming
language by which applications communicate over the Internet.
The API itself is a chunk of software code written as a series of XML messages.
Each XML message corresponds to a different function of the remote service.
APIs and Web services are completely invisible to Web site surfers and software
users. Their job is to run silently in the background, providing a way for applications
to work with each other to get the user the information or functionality he needs.
Along with XML, the following technological standards, protocols and program-
ming languages are what make Web services work:
SOAP (Simple Object Access Protocol): SOAP is responsible for encoding XML
messages so that they can be received and understood by any operating system over
any type of network protocol.
UDDI (Universal Description, Discovery and Integration): Described as a “yellow
pages for the Internet,” UDDI is an XML-based directory that allows businesses to
list themselves, find each other and colaborate using Web services.
WSDL (Web Services Description Language): WDSL is the SOAP of the UDDI.
Basically, WDSL is the XML-based language that businesses use to describe their
services in the UDDI.

2.4 AngularJS
AngularJS is a structural framework for dynamic web apps. Angular is what HTML
would have been had it been designed for applications. HTML is a great declarative
language for static documents. It does not contain much in the way of creating appli-
cations, and as a result building web applications is an exercise in what do I have to
do to trick the browser into doing what I want.
Data-binding is probably the most useful feature in AngularJS. A typical web ap-
plication may contain up to 80% of its code base, dedicated to traversing, manipulat-
ing, and listening to the DOM. Data-binding makes this code disappear, so you can
focus on your application.
Traditionally, when the model changes, the developer is responsible for manually
manipulating the DOM elements and attributes to reflect these changes. This is a two-
way street. In one direction, the model changes drive change in DOM elements. In the
other, DOM element changes necessitate changes in the model. AngularJS’ two-way
data-binding handles the synchronization between the DOM and the model, and vice
versa.
AngularJS incorporates the basic principles behind the original MVC software de-
sign pattern into how it builds client-side web applications.The MVC or Model-View-
Controller pattern means a lot of different things to different people. AngularJS does
not implement MVC in the traditional sense, but rather something closer to MVVM
(Model-View-ViewModel).
AngularJS has a built-in dependency injection subsystem that helps the developer
by making the application easier to develop, understand, and test.
2.5 ORM (Object-relational mapping)
Object-relational mapping (ORM) in computer software is a programming technique
for converting data between incompatible type systems in object-oriented program-
ming languages. This creates, in effect, a “virtual object database” that can be used
from within the programming language. There are both free and commercial packages
available that perform object-relational mapping, although some programmers opt to
create their own ORM tools.
However, many popular database products such as structured query language data-
base management systems (SQL DBMS) can only store and manipulate scalar values
such as integers and strings organized within tables. The programmer must either
convert the object values into groups of simpler values for storage in the database
(and convert them back upon retrieval), or only use simple scalar values within the
program. Object-relational mapping is used to implement the first approach.
The heart of the problem is translating the logical representation of the objects into
an atomized form that is capable of being stored on the database, while somehow
preserving the properties of the objects and their relationships so that they can be
reloaded as an object when needed. If this storage and retrieval functionality is im-
plemented, the objects are then said to be persistent
Compared to traditional techniques of exchange between an object-oriented lan-
guage and a relational database, ORM often reduces the amount of code that needs to
be written.
Regarding Non-SQL databases, another solution is to use an object-oriented data-
base management system (OODBMS) or document-oriented databases such as na-
tive XML databases. OODBMSs are databases designed specifically for working with
object-oriented values. Using an OODBMS eliminates the need for converting data to
and from its SQL form, as the data is stored in its original object representation and
relationships are directly represented, rather than requiring join tables/operations.
2.6 The play framework.

Play is a high-productivity Java and Scala web application framework that inte-
grates the components and APIs you need for modern web application development.
Play is based on a lightweight, stateless, web-friendly architecture and features
predictable and minimal resource consumption (CPU, memory, threads) for highly-
scalable applications thanks to its reactive model, based on Iteratee IO.

The request life cycle.

The play framework is fully stateless and only Request/Response oriented. All
HTTP Requests follow the same path:
An HTTP Request is received by the framework.
The Router component tries to find the most specific route able to accept this re-
quest. The corresponding action method is then invoked.
The application code is executed.If a complex view needs to be generated, a tem-
plate file is rendered. The result of the action method (HTTP Response code, Content)
is then written as an HTTP Reponse.
The standard application layout.
The layout of a play application is standardized to keep things as simple as possi-
ble.
The app directory
This directory contains all executable artifacts: Java source code and views tem-
plates.
Where are my class files??.
Don’t look for compiled Java classes. The framework compiles the Java source
code at runtime and only keep compiled classes in a bytecode cache under the tmp
directory. The main executables artifacts in a play application are the .java source
files, not the compiled classes.
There are three standard packages in the app directory, one for each layer of the
MVC architectural pattern. You can of course add your own packages like for exam-
ple an utils packages.
In addition, the views package is further organized into sub-packages:
tags, hosts application tags, e.g. reusable pieces of templates.
One views folder for each Controller, by convention templates related to each Con-
troller are stored in their own sub-package.
The public directory
Resources stored in the public directory are static assets and are served directly by
the Web server.
This directory is split into three standard sub-directories: for images, CSS
stylesheets and Javascript files. You should try to organize your static assets like this
to keep all play applications consistent.
Tip.
By default the /public directory is mapped to the /public URL path, but you can
easily change that, or even use several directories for your static assets.
The conf directory.
The conf directory contains all configuration files for the application.
There are two required configurations files:
application.conf, the main configuration file for the application. It contains stand-
ard configuration options.
routes, the routes definition file.
Tip.
If you need to add some configuration options specific to your application, it’s a
good idea to add more options to the application.conf file. If any library needs a spe-
cific configuration file, try to file it under the conf directory: this directory is included
in the Java ClassPath.
The lib directory.
This directory contains all standard Java libraries needed by your application.
There are automatically added to the Java Classpath.
Development life cycle.
There are no compilation, packaging or deployment phases while working with
play. However play implements two distinct environments: DEV mode during the
development phase and PROD mode when the application is deployed.
About DEV/PROD modes.
You can run an application either in a DEV or PROD mode. You toggle this mode
using the application.mode configuration property. When run in DEV mode, play will
check for file changes and will handle hot reloading if necessary.
The PROD mode is fully optimized for production: java sources and templates are
compiled once and cached for multiple uses.
Java source code is compiled and loaded at runtime. If a Java source file is modi-
fied while the application is running, the source code is recompiled and hot-swapped
into the JVM.
If a compilation error occurs, the exact problem is displayed in the browser (in
DEV mode only).


Template files are hot-compiled and hot-reloaded too.
Connect a Java debugger.
When you run the application in DEV mode, you can connect a Java debugger to
the port 8000.
For example, using the netbeans debugger:


Continuing the discussion.
Now that you’ve seen what a play application is, let’s see how the Router works.
The Router is in charge of translating incoming HTTP Requests into actions.
2.7 The MVC application model
A play application follows the MVC architectural pattern applied to the Web architec-
ture.
This pattern splits the application into separate layers: the Presentation layer and
the Model layer. The Presentation layer is further split into a View and a Controller
layer.
The Model is the domain-specific representation of the information on which the
application operates. Domain logic adds ‘meaning’ to raw data (e.g., calculating if
today is the user’s birthday, or the totals, taxes, and shipping charges for a shopping
cart). Most applications use a persistent storage mechanism such as a database to store
data. MVC does not specifically mention the data access layer because it is under-
stood to be underneath, or encapsulated by, the Model.
The View renders the model into a form suitable for interactions, typically a user
interface. Multiple views can exist for a single model, for different purposes. In a
Web application the view is usually rendered in a ‘Web format’ like HTML, XML or
JSON. However there are some cases where the view can be expressed in a binary
form, e.g. dynamically rendered chart diagrams.
The Controller responds to events (typically user actions) and processes them, and
may also invoke changes on the model. In a Web application, events are typically
HTTP requests: a Controller listens for HTTP requests, extracts relevant data from the
‘event’, such as query string parameters, request headers… And applies changes on
the underlying model objects.
2.8 JQUERY
User-friendly library, used for rapid integration of important elements of the interac-
tivity of the application graphics, and more. This technology allows obtaining im-
portant visual effects, depending on events triggered by user - click, mouseenter,
MouseLeave, etc..
2.9 JavaScript

The main scripting language of the application. Through it I could keep track of all
web graphics software and more. Highly developed, with a similar syntax to C fami-
ly, and very supported by the community - the wide range of libraries and existing
pluggins language enabled finding quick solutions for certain features.
2.10 Facebook API
2.11 Twitter API
3 Application architecture
The application architecture was designed according to the MVC model, but also
modularized in order to define more clearly the functionality and facilitate the imple-
mentation.
3.1 MVC
3.2 Authentication Module
When a person accesses Wobby, he can login using a previously created existing
account . This view is composed of only one field to enter the user name and pass-
word.
3.3 Registration Module
If the user hasn’t already created an account on the website application, he will need
to register. It will only be required basic information like username and password to
be confirmed.
3.4 Hobby page
Includes presentation of suggestions, made up of posts of users, they can either be
text or media.

4 Implementation details
The application is based on the MVC pattern. Our Model contains 2 components :
Recommendation and User.



The Controller is used to create a link between the Model and The View and it
contains methods such as : index(),showSignUp(),showLogin() that render the wanted
View.
The View is built using AngularJs framework. It allows us to have a dynamic
representation using HTML Look-A-Like language.


5 Conclusions
Social Web is becoming more commonly used today, offering applications with var-
ied functionalities and interfaces that are intuitive. Every Internet user has heard about
sites such as Facebook, Twitter, LinkedIn, YouTube or, more recently, Google Plus.
The natural need of human interaction and the desire for communication / expression
may explain the popularity of these social platforms. Whatever the reason, the number
of users of social media is growing.
Wobby assumes the need for a social platform for sharing hobbies, passions and con-
cerns among users. They will form a community site similar to the sites mentioned
above.
6 References
1. http://www.playframework.com/documentation/2.1.1/Home
2. http://docs.angularjs.org/tutorial
3. http://www.orm.net
4. http://diveintohtml5.info
5. http://www.w3.org/TR/html5-diff/