Archivi tag: web

ASP NET MVC WEB Tips : differenze fra Html.ActionLink e Url.Action Helper Tags

ASP NET MVC WEB Tips : differenze fra @Html.ActionLink e @Url.Action Tag Helper.

 

@Html.ActionLink(
                 "link text", 
                  "someaction", 
                  "somecontroller", 
                  new { id = "123" },
                  null
                 )
Genera :
<a href="/somecontroller/someaction/123">
      link text
</a>

Url.Action(
        "someaction", 
        "somecontroller", 
        new { id = "123" }
        )
Genera :
/somecontroller/someaction/123

Utilizzo @Html.ActionLink:

  • @Html. ActionLink(“About this Website”, “About”).
  • <%=Html. ActionLink(“About this Website”, “About”) %>
  • @Html. ActionLink(“Edit Record”, “Edit” , new {Id=3})
  • @Html. ActionLink(“Edit Record”, “Edit” , New With{.Id=3})
  • <a href=”/Home/Edit/3″>Edit Record</a>

Utilizzo @Url.Action:

  • <a href=”@Url.Action(“AddProduct”, “Product”, new { id = UrlParameter.Optional })”>Add anProduct</a>

https://stackoverflow.com/questions/19107061/url-action-including-route-values

Propietà@Html.ActionLink:

Proprietà Descrizione
.linkText Il testo del link (label)
.actionName L’azione di destinazione
.routeValues I valori passati all’azione
.controllerName Il controllore di destinazione
.htmlAttributes L’insieme di attributi al link
.protocol Il protocollo di collegamento
.hostname Il nome host per il link
.fragment L’obiettivo di ancoraggio per il link

FONTI:

 

 

 

Java REST e RESTful: implementazione con Restlet

Proseguendo con l’articolo anteriore nelle  prossime righe verranno illustrati tutte le  diverse implementazione per poter progettare un servizio Rest (applicativi, framework). in particolare implementazione JAX-RS con Apache CXF.

REST_implementations_implementazioni
REST_implementations_implementazioni

Le implementazioni di REST ( implementazione JAX-RS):

Apache CXF Web Service Development
Apache CXF è un Framework open source che permette lo sviluppo di servizi web in forma facile, semplice e basato sugli standard.

Web services possono essere implementati utilizzando i più svariati protocolli tali come SOAP, XML, JSON,RESTful HTTP,  e anche possono supportare varii protocolo di trasporto come HTTP o JMS (JavaMessage Service).

Caraterristiche di CXF (non solo REST)
il servizio CXF ha infinite caratteristiche per facilitare la programmazione delle interfacce (frontEnd); il trasporto e le connessioni fra i dati; il supporto a diversi protocolli e altri concetti avanzati come Features (caratteristiche) e Invokers ( con due componenti principali: una classe Java runnable con public static main mettodo), e una classe loader (che carica), che è utilizzata per istanziare l’altra classe riducendo cosi la complessità dello classpath management)  proporziona un modello di programmazione per creare e distribuire servizi web RESTful.

Tools support
CXF provides different tools for conversion between JavaBeans, web services, and
WSDL. These tools assist developers in generating web service clients like Java and
JavaScript from WSDL or generating a WSDL file from a service implementation.
CXF provides support for Maven and Ant integration for build and dependency
management. Some of the tools supported are as follows:
• Java to web service
• Java to WSDL
• WSDL to Java
• WSDL to JavaScript
• WSDL to Service
• WSDL to SOAP
• WSDL to XML
• WSDL Validator
• XSD to WSDL


per saperne di più … altre fonti

Java REST e RESTful: implementazione JAX-RS con Apache CXF- parte 1

Proseguendo con l’articolo precedente(java REST RESTful fondamenti)  nelle  prossime righe verranno illustrati tutte le  diverse implementazione per poter progettare un servizio Rest (applicativi, framework).

nei prossimi post si tratteranno altre implementazioni per i servizi REST in Java:

  • Jersey
  • RESTEasy
  • Restlet
  • Spring MVC
  • DROPWIZARD
  • altri

a continuazione Apache CXF Web Service Development

REST_implementations_implementazioni
REST_implementations_implementazioni

Le implementazioni di REST ( implementazione JAX-RS):

Apache CXF Web Service Development
Apache CXF è un Framework open source che permette lo sviluppo di servizi web in forma facile, semplice e basato sugli standard.

Web services possono essere implementati utilizzando i più svariati protocolli tali come SOAP, XML, JSON, RESTful HTTP,  e anche possono supportare varii protocolo di trasporto come HTTP o JMS (JavaMessage Service).

Caraterristiche di CXF (non solo REST)
il servizio CXF ha infinite caratteristiche per facilitare la programmazione delle interfacce (frontEnd); il trasporto e le connessioni fra i dati; il supporto a diversi protocolli e altri concetti avanzati come Features (caratteristiche) e Invokers ( con due componenti principali: una classe Java runnable con public static main mettodo), e una classe loader (che carica), che è utilizzata per istanziare l’altra classe riducendo cosi la complessità dello classpath management)  proporziona un modello di programmazione per creare e distribuire servizi web RESTful.

Strumenti di supporto
CXF supporta diversi strumenti di sviluppo per la conversione fra JavaBeans, web services, and WSDL( Web Services Description Language  linguaggio di definizione dell’interfaccia in XML, viene utilizzato per descrivere le funzionalità offerte da un servizio web . L’acronimo è utilizzato anche per una descrizione WSDL specifica di un web service -indicato anche come un file WSDL- che fornisce una descrizione leggibile dalla macchina come il servizio può essere chiamato, che parametri si aspetta, e quali strutture o quali dati restituisce.)

Questi strumenti assistono i programmatori nella generazione (creazione) dei “clienti”o del lato cliente del servizio web, come Java and JavaScript da WSDL o alla generarazione di un file WSDL dalla implementazione di un servizio.

CXF ha dei supporti per Maven e integrazione per Ant sia per il build come per la gestione delle dependency. alcuni dei tool di supporto sono:
• Java to web service
• Java to WSDL
• WSDL to Java
• WSDL to JavaScript
• WSDL to Service
• WSDL to SOAP
• WSDL to XML
• WSDL Validator
• XSD to WSDL

 Supporto per servizi RESTful
CXF supporta il concetto di servizi RESTful (Representational State Transfer) e le specifiche JAX-RS che specifica la semantica per creare servizi web secondo lo stile architettonico REST. Specifiche JAX-RS non fornisce alcuna Dettagli sui client RESTful.

CXF fa un passo avanti e offre varie opzioni per creare client che possono interagire con il web service JAX-RS. CXF supporta ancheJava Script Object Notation (JSON) formato dei dati che è un formato ampiamente utilizzato lo sviluppo di applicazioni Web 2.0-based.

Supporto per diversi tipi di trasporto e associazioni dati
L’associazione dati (databinding) è la chiave per tutto lo sviluppo del servizio web. Data binding significa mappatura fra oggetti Java e formati di esposizione dei dati o messaggi formatati, i quali possono essere esposti attraverso la implementazione del servizio, per esempio in formati XML o JSON (Java Script Object Notation).
Servizi web basati su SOAP avrebbero usato XML come formato di dati, mentre i servizi RESTful possono usare sia XML che JSON come formato dati.

CXF ha dei componenti  che aiutano il programmatore nella gestione delle mappature (costruzione degli alberi di navigazione) dei dati.

Supporta data binding con formati diversi di xml e CORBA
CXF gestisce non-XML bindings tali come  JavaScript Object Notation (JSON) e CORBA – Common Object Request Broker Architecture.

CXF supporta la architettura Java Business Integration (JBI) e la architettura Service Component (SCAs).

La caratteristica di non XML binding proporziona maggiori facilità per consentire l’integrazione con altre  infrastrutture esistenti che già supportavano altri formati.

per saperne di più … altre fonti

libri

mobile app italia 2014 vargas
mobile app italia 2014 vargas

Java REST e RESTful: fondamenti e filosofia

Nelle prossime righe verranno illustrati un insieme di principi di progettazione che dovrebbero essere rispettati quando si crea una web service RESTful.

java REST AND RESTFUL mobile app Italia 2014
java REST AND RESTFUL

REST è una Representational State Transfer.
REST è lo stile architettonico del web stesso.

REST è uno stile architecturale.

REST si riferisce ad un insieme di principi di architetture di rete, i quali specificanola forma come le risorse sono definite e indirizzate.

Esso si basa su rapporti client-server, utilizzando un protocollo di comunicazione cacheable (in memoria), stateless (comunicazione senza stato) e a livelli.
REST è indipendente dal protocollo. Non è accoppiato ad HTTP. Al giorno d’oggi, molte applicazioni REST
sono costruite utilizzando il protocollo HTTP, tuttavia REST non è legato ad questo specifico protocollo.
Un’applicazione REST può utilizzare qualsiasi protocollo per i quali esista uno schema URI standardizzato.

HTTP e REST Insieme contribuiscono a creare una struttura semplice e leggera, con cui si possono costruire applicazioni web complesse.
Al centro di REST con HTTP, sono i metodi HTTP.

Essi possono essere liberamente pensati come operazioni CRUD,
-creare(Create) leggere(Read) aggiornare(Upload) e cancellare(Delete) dei dati o delle risorse-
Sfruttando i metodi HTTP, un’applicazione REST offre spesso rappresentazioni POST, GET, PUT e DELETE per le operazioni CRUD.

FONDAMENTI DI REST
Identificazione delle risorse
Utilizzo esplicito dei metodi HTTP
Risorse autodescrittive
Collegamenti tra risorse
Comunicazione senza stato

REST NON è:
REST non è la mappatura o rappresentazione CRUD dei metodi HTTP.  REST non è REST senza HATEOAS. REST non è uno stile architetturale solo web/mobile application. ma ha un utilizzo più generale.

CARATTERISTICHE NECESSARIE PER DIVENTARE RESTFUL

Lo stile architetturale REST descrive sei regole caratteristiche per diventare Restfull.

  • Client/Server – Un insieme di interfacce uniformi separa i client dai server. Questa separazione di ruoli e attività significa che, per esempio, il client non si deve preoccupare del salvataggio delle informazioni, che rimangono all’interno di ogni singolo server, in questo modo la portabilità del codice del client ne trae vantaggio. I server non si devono preoccupare dell’interfaccia grafica o dello stato dell’utente, in questo modo i server sono più semplici e maggiormente scalabili. Server e client possono essere sostituiti e sviluppati indipendentemente fintanto che l’interfaccia non viene modificata.
  • Comunicazione libera di stato (senza stato) -La comunicazione client–server è ulteriormente vincolata in modo che in nessun contesto il client venga memorizzato (comunicato)  sul server tra le richieste. Ogni richiesta da ogni client contiene tutte le informazioni necessarie per richiedere il servizio, e lo stato della sessione è contenuto sul lato client. Lo stato della sessione può essere trasferito al server attraverso un altro servizio che controlla la persistenza (stato dei dati di un database).
  • Cacheable (utilizzabile in memoria temporanea) – Come nel World Wide Web, i client possono fare caching delle risposte. Le risposte devono in ogni modo definirsi implicitamente o esplicitamente cacheable o no, in modo da prevenire che i client possano riusare stati vecchi o dati errati. Una gestione ben fatta della cache può ridurre o parzialmente eliminare le comunicazioni client server, migliorando scalabilità e performance.
  • Organizzato a livelli – Un client non può dire se è connesso direttamente ad un server di livello più basso od intermedio, i server intermedi possono migliorare la scalabilità del sistema con load-balancing o con cache distribuite. livelli  intermedi possono offrire inoltre delle politiche di sicurezza.
  • Codice a Richiesta (non obbligatorio) – I server possono temporaneamente estendere o personalizzare le funzionalità del client trasferendo del codice eseguibile. Ad esempio questo può includere componenti compilati come Applet Java o linguaggi di scripting client side come JavaScript.
  • Interfaccia uniforme – Un’interfaccia di comunicazione omogenea tra client e server permette di semplificare e disaccoppiare l’architettura, la quale si può evolvere separatamente.

FILOSOFIA  REST

  • Tutto è una risorsa
  • Ogni risorsa ha un ID.
    L’ID è un URI.
    Un URI può identificare oggetti.
  • Tutte le risorse espongono un’interfaccia standard
  • Tutte le operazioni REST devono essere sicure ( l’operazione non deve avere effetti collaterali ); cacheable ( il risultato può essere memorizzato nella cache, ad esempio da un server proxy); concrete e integre ( L’operazione deve sempre restituire lo stesso – unico risultato).
  • ogni risorse può contenere collegamenti ad altre risorse.comunicazione senza stato Ogni cosa che necessita processare una richiesta deve essere contenuto nella richiesta estesa (conformazione). Non esistono sessioni dei client nel Server.

REST E Risorse: Le risorse sono sostantivi (oggetti – cose – nomi) . Le risorse sono identificate da URI.

      http:/myApp/medici/8456201
      http:/myApp/medici/usl/5

REST E Metodi: I metodi sono verbi (azioni, attività da fare sulle risorse) . Essi svolgono operazioni CRUD.
   metodi sono: POST, GET, PUT, DELETE

REST E Rappresentazione delle risposte/soluzioni:
Il formato per rappresentare le  risorse spesso è XML o JSON, (utilizzabile anche PDF / text / word).

per saperne di più … altre fonti

 

 

app mobile ibrida web o nativa le ragioni di una scelta

Già dai primi momenti in cui si decide di sviluppare una App mobile, ci si deve confrontare con il dover scegliere se essa sarà di tipo Nativo, Web o Ibrido ?

app nativa web ibrida
app nativa web ibrida

Si rende utile allora capire cosa sono le Mobile app.
Le mobile app sono programmi software sviluppati espressamente per essere installati nei dispositivi mobili chiamati oggi smartphone, tablet, PDA o altri mobile gadgets, sono piccoli applicativi software “specifici e specialistici” che rendono possibile ad un particolare utente, in determinati momenti, la sua connessione permanente con il web, la posta elettronica, i social, il proprio pc, il cloud, società di servizi ecc… (esiste anche la possibilità di utilizzare mobile app off-line).

Queste App sono gestite da un sistema operativo mobile Android, Blackberry, iOS, Windows Phone, Firefox OS, OS Sailfish, Symbian, Tizen, Ubuntu touch OS, Canonical Ltd. e possono svolgere una molteplicità di funzioni utilizzando le caratteristiche tecniche del proprio dispositivo: GPS di navigazione portatile, macchina fotografica, videocamera, riconoscimento vocale, registratore vocale, lettore musicale, Near Field Communication e blaster a infrarossi, touchscreen, cellulare, Bluetooth, Wi-Fi.

a questo punto viene chiaro a noi sviluppatori il chiedersi ma con quale di tutti questi sistemi operativi è meglio iniziare il processo di sviluppo della mobile app ?
la risposta è una nuova domanda, nell’ albero decisionale,  si vuole sviluppare una mobile app uni-piattaforma o multi-piattaforma ?

se la risposta è la prima si chiamano mobile App native, se è  la seconda si possono chiamare web mobile app… ma se è una combinazione di tutte le due decisioni si chiamano mobile app ibride.

ma quali le ragioni di una o altra scelta programmatica ?
la risposta la dà il marketing,  gli studi di mercato, la reale conoscenza del comportamenti di acquisto degli utenti delle app,  le tendenze del mercato….  oggi è ovvio sviluppare mobile App Native per il Mondo Android, iOS, e Blackberry e Windows Phone …

chi deve sviluppare o decidere deve pensare a … 4 sistemi operativi diversi !!!, quattro applicativi differenti, utilizzo di tecnologie per ogni piattaforma diverse e complesse, quasi quasi si ha la necessità di 4 esperti diversi, con conoscenze tecniche specifiche per ogni ambiente di sviluppo… ovvero Objective-C per iOS, Java per Android e. NET per Windows.  con tempi e costi da non sottovalutare…

allora arriva un dubbio ma come lasciare fuori il mercato trainato da Firefox OS, OS Sailfish, Symbian, Tizen, Ubuntu touch OS, Canonical Ltd ?

si tende a pensare alle soluzioni web e ibride che offrono oggi gli studiosi di HTML5 CSS3 e Javascript MVC. Molte soluzioni che emulano la visualizzazione della web app attraverso i browser. Sistemi che interpretano web view. Ambienti di sviluppo che creano una sola SOLUZIONE… Cross-platform che permettono di farle girare in tutte le piattaforme mobile (o cosi predicano…) senza grandi problemi di adattamento…

si è catapultati  allora in un approfondito studio su tutti i  toolkit mobili cross-platform un vero conglomerato… quasi infinito di soluzioni per  trovare LA unica SOLUZIONE … una App ibrida  (vedi Phonegap, AngularJs, Titanium, todoMVC, emberjs, backbone ecc..)  tutti con un minimo comune denominatore … quello di offrire una soluzione quasi miracolosa. che funziona uguale (o quasi) su tutte le piattaforme mobile.

viene da credere che questi tools di sviluppo siano caduti dal cielo … e anche che essi siano facili da apprendere, da utilizzare o si tende a credere che la curva di apprendimento sia corta… ma non è così .

che la mobile  App sia  ibrida web o nativa, il gruppo di lavoro, gli, analisti e gli sviluppatori, deveno conoscere molto bene il proprio mercato, le necessità del mercato obiettivo,  le specificità della app che si vuole sviluppare, la propensione al acquisto di apparecchiature mobile come iphone, android, winphone, o blackberry dei futuri utilizzatori e sopratutto del’utilizzo che farà l’utente della mobile app… sia in termini del dove, del come e del quando … mobile in movimento…

concludendo posso dire che  ci sono mobile app che è definitivamente necessario sviluppare in ambiente nativo (si pensi alla propria interazione con la piattaforma hardware, la connettività on-line off-line, la relazione con i meccanismi di gps, geo,ecc)….  altre che va bene sviluppare in ambiente web … per la facilità di reperimento dei dati on line, per le potenzialità che offrono oggi i browser, i linguaggi come html, la gestione diretta dei dati nei server, le web services (REST) e  i nuovi formati dati come  json, sqlite ecc… e infine ci sono mobile app che vanno bene sviluppate come ibride (con una architettura che unisce caratteristiche delle app native a delle web app… in fondo sono  nativa che sfruttano il web per adattarsi alle diverse piattaforme e ai diversi mobile devices).
… addirittura negli ultimi giorni c’è la tendenza di fare coesistere nei market o store le  App in due soluzioni …native e ibride.


 

collegamenti

vargas carmen
autor