Internett: www.wis.no E-post: wis@wis.no
Tlf: 7245 0190 Fax: 7245 0191

Startsiden | Produkter | Drift | Markedsføring | Ta kontakt | Gå til
Søk:

Startsiden

Søk

Om nettstedet

Nyhetsarkiv

KundeWeb

Om virksomheten

Ansatte

Blogg

Kompetanse

Prosjekter

Sikkerhet

Vår styrke

Wis i media

Sponsor

Om selskapet

Organisering

Historikk

Kontorer

Reise til WIS

Ta kontakt

Jobbe i WIS

Partnere

Den andre siden ..

WIS blogg


ExtGWT og RequestFactory integrasjon
Av: Stig Runar Vangen Fredag 04.02.2011 (13:42)

Sencha har sagt at de for neste versjon av ExtGWT kommer til å nærme seg standardene som Google bruker for GWT. Tidligere har man i ExtGWT måtte gjøre en del spesialtilpasninger for å få dataflyt til å fungere optimalt. Vi har forsøkt å foreberede kodebasen vår i påvente av ExtGWT 3, og en sentral bit her er RequestFactory, som både reduserer mengden data som overføres mellom klient og server, samt gjør at vi ikke trenger å skrive like mye kode for å endre på data. Disse endringene spenner seg over både server og klient side av kodebasen.

Spring og RequestFactory

Bruker foreløpig servlet angitt i web.xml. Denne er uavhengig av hvilken RequestContext du bruker, men hver implementasjon av disse er ikke Spring-kompatible. Derfor står dette som et punkt på listen over ting som må utbedres.

 

ExtGWT og RequestFactory

Sencha sier selv at main i ExtGWT 3 skal bevege seg mot en bedre integrasjon mot GWT. Dette innebærer å bruke de rammeverk som allerede eksisterer i GWT. Deriblant finner vi RequestFactory (introdusert i GWT 2.1), som er et rammeverk for å minimere trafikk over nettlinjen. Dette gjøres ved å bare sende endringer gjort i modellen i stedet for hele modellen. En grunnleggende introduksjon er tilgjengelig her:

 

http://code.google.com/webtoolkit/doc/latest/DevGuideRequestFactory.html

 

Det første som slår meg når jeg leser denne dokumentasjonen, er at Google har brutt alle skikker for god programmering når de lagde dette rammeverket. Alle metoder for å hente ut data fra databasen ligger her som statiske metoder på entiteten. Det at disse metodene er statiske stopper for integrasjon mot Spring/Guice eller lignende. Det at de er plassert på entiteten gjør at koden ikke er separert i kodelag som gjør videre utvikling lettere. Dette har blitt gjort litt lettere i GWT 2.1.1, med en god del forbedringer for RequestFactory:

 

http://code.google.com/p/google-web-toolkit/wiki/RequestFactory_2_1_1

 

Man kan her dra ut implementasjon av uthenting av data fra entiteter ved hjelp av locators. Disse trenger heller ikke lenger være statiske, noe som letter implementasjon mot Spring ganske mye. Derimot er det veldig lite dokumentasjon tilgjengelig enda. Hverken Google eller bloggere har begynte skrive om det forbedrede rammeverket enda. Det har derfor vært en lang prosess med prøving og feiling for å integrere RequestFactory i vårt system.

 

RequestFactory GIN provider

  1. public class ContactRequestFactoryProvider implements
  2.   Provider<ContactRequestFactory> {
  3.  
  4.   @Inject
  5.   private CoreGinjector coreGinjector;
  6.  
  7.   @Override
  8.   public final ContactRequestFactory get() {
  9.     ContactRequestFactory contactRequestFactory =
  10.       GWT.create(ContactRequestFactory.class);
  11.     contactRequestFactory.initialize(coreGinjector.getEventBus(),
  12.       coreGinjector.getRequestTransport());
  13.     return contactRequestFactory;
  14.   }
  15. }

 

For oppretting av RequestFactory-objekter brukes en GIN-provider. Resultatet av denne er igjen bundet inn som en singleton gjennom GIN-konfigurasjonen. Denne initieres ved å bruke vår globale eventbus og en tilpasset transport-metode. Grunnen til at vi trenger en tilpasset transport-metode er at vi henter data fra en annen web-context enn den klienten ligger på.

 

RequestFactory

  1. public interface ContactRequestFactory extends RequestFactory {
  2.   ContactRequest contactRequest();
  3. }

 

Factory i seg selv henviser bare til en request implementasjon.

 

Contact request

  1. @Service(value = ContactAdapter.class, locator = InstanceServiceLocator.class)
  2. public interface ContactRequest extends RequestContext {
  3.  
  4.   Request<ContactProxy> get(String id);
  5.  
  6.   Request<Void> persist(ContactProxy contact);
  7.  
  8.   Request<Void> remove(ContactProxy contact);
  9. }

 

Her defineres de metodene man ønsker å bruke for å kommunisere fra klient til server. Dette er de metodene som er spesifikt for kontakt-modulen. Klassen er i seg selv annotert som en GWT-service, der implementasjonen av disse metodene ligger i ContactAdapter-klassen (trenger ikke lenger være entitets-klassen i GWT 2.1.1), mens ContactLocator (locators er nytt i GWT 2.1.1) tar seg av oppdateringer av entiteter.

 

Contact RequestFactory adapter

  1. @Component
  2. public class ContactAdapter {
  3.  
  4.   private static ContactDao contactDao;
  5.  
  6.   public ContactAdapter() {
  7.   }
  8.  
  9.   @Autowired
  10.   public ContactAdapter(final ContactDao contactDao) {
  11.     ContactAdapter.contactDao = contactDao;
  12.   }
  13.  
  14.   public final Contact get(final String id) {
  15.     Scanner scanner = new Scanner(id);
  16.     scanner.useLocale(Locale.ROOT);
  17.     if (scanner.hasNextLong()) {
  18.       return contactDao.get(scanner.nextLong());
  19.     }
  20.     return null;
  21.   }
  22.  
  23.   public final void persist(final Contact contact) {
  24.     contactDao.saveOrUpdate(contact);
  25.   }
  26.  
  27.   public final void remove(final Contact contact) {
  28.     contactDao.delete(contact);
  29.   }
  30. }

 

Her implementeres de metodene som er definert i request-interfacet. Klassen er tagget med @Component slik at Spring finner denne klassen gjennom auto-scanning. Vi slipper dermed spesifikk konfigurasjon per modul. En kontakt-DAO blir gitt fra Spring sin kontekst. Denne lagres som en statisk variabel. Grunnen til dette er at RequestFactory oppretter instanser av dette objektet uavhengig av Spring. Ved oppstart blir DAO overlevert fra Spring, og alle instanser av denne adapteren vil ha tilgang til gjeldende DAO.

 

Instance ServiceLocator

  1. public class InstanceServiceLocator implements ServiceLocator {
  2.  
  3.   private static final Log LOGGER = LogFactory
  4.     .getLog(InstanceServiceLocator.class);
  5.  
  6.   @Override
  7.   public final Object getInstance(final Class<?> clazz) {
  8.     try {
  9.       Object newInstance = clazz.newInstance();
  10.       return newInstance;
  11.     } catch (InstantiationException ex) {
  12.       LOGGER.fatal("Failed to create instance", ex);
  13.     } catch (IllegalAccessException ex) {
  14.       LOGGER.fatal("Failed to create instance", ex);
  15.     }
  16.     return null;
  17.   }
  18. }

 

Dette er en veldig enkel ServiceLocator som ganske enkelt oppretter nye instanser av den klassen man etterspør. Det er mulig at vi i senere tid vil trenge å hente ut data fra Spring sin context i stedet for å lage objekter utenfor.

 

Entity proxy

  1. @ProxyFor(value = Contact.class, locator = ContactLocator.class)
  2. public interface ContactProxy extends BaseEntityProxy {
  3.  
  4.   String getAddress();
  5.  
  6.   String getFirstName();
  7.  
  8.   String getLastName();
  9.  
  10.   void setAddress(String address);
  11.  
  12.   void setFirstName(String firstName);
  13.  
  14.   void setLastName(String lastName);
  15. }

 

Entitets-proxy-er blir implementert som autobeans på klientsiden. Disse er en speiling av entiteter på server-siden. Man må i proxy angi navn på metoder basert på Java Bean-standarden. Dette vil vanligvis være en speiling av de metode-navnene man finner i entiteten. Dette for at RequestFactory skal kunne hente data entiteten før de dras over til klienten. Dersom disse ikke stemmer overens får man feil ved første forsøk på uthenting av data. Merk også at vi her peker til en locator. Denne er ikke av typen ServiceLocator, som plasseres på en request.

 

  1. @Entity
  2. public class Contact extends AbstractDocumentEntity implements Serializable {
  3.  
  4.   private String firstName;
  5.   private String lastName;
  6.   private String address;
  7.  
  8.   public String getAddress() {
  9.     return address;
  10.   }
  11.  
  12.   public void setAddress(String address) {
  13.     this.address = address;
  14.   }
  15.  
  16.   public String getFirstName() {
  17.     return firstName;
  18.   }
  19.  
  20.   public void setFirstName(String firstName) {
  21.     this.firstName = firstName;
  22.   }
  23.  
  24.   public String getLastName() {
  25.     return lastName;
  26.   }
  27.  
  28.   public void setLastName(String lastName) {
  29.     this.lastName = lastName;
  30.   }
  31. }

 

Dette er et forenklet utdrag av entiteten som autobean proxy peker til. Merk at metode-kallene i proxy kaller til feltene i klassen, ikke metodene. Begge klasser følger samme regelsett for navngiving av getters/setters.

 

Contact RequestFactory locator

  1. public abstract class DocumentEntityLocator<T extends AbstractDocumentEntity>
  2.   extends Locator<T, Long> {
  3.  
  4.   private static final Log LOGGER = LogFactory.getLog(DocumentEntityLocator.class);
  5.  
  6.   public DocumentEntityLocator() {
  7.   }
  8.  
  9.   public abstract BaseDao<T> getDao();
  10.  
  11.   @Override
  12.   public final T create(final Class<? extends T> clazz) {
  13.     try {
  14.       Class<? extends T> entityClass = getEntityClass(clazz);
  15.       if (entityClass != null) {
  16.       T newInstance = entityClass.newInstance();
  17.       getDao().saveOrUpdate(newInstance);
  18.         return newInstance;
  19.       }
  20.     } catch (InstantiationException ex) {
  21.       LOGGER.fatal("Failed to create instance", ex);
  22.     } catch (IllegalAccessException ex) {
  23.       LOGGER.fatal("Failed to create instance", ex);
  24.     }
  25.     return null;
  26.   }
  27.  
  28.   @Override
  29.   public final T find(final Class<? extends T> clazz, final Long id) {
  30.     return getDao().get(id);
  31.   }
  32.  
  33.   @Override
  34.   public final Class<T> getDomainType() {
  35.     return getDao().getDomainType();
  36.   }
  37.  
  38.   @Override
  39.   public final Long getId(final T domainObject) {
  40.     return domainObject.getId();
  41.   }
  42.  
  43.   @Override
  44.   public final Class<Long> getIdType() {
  45.     return Long.TYPE;
  46.   }
  47.  
  48.   @Override
  49.   public final Object getVersion(final T domainObject) {
  50.     return domainObject.getRevisionNumber();
  51.   }
  52.  
  53.   @SuppressWarnings("unchecked")
  54.   private <X extends Object> Class<X> getEntityClass(
  55.     final Class<? extends Object> clazz) {
  56.     Entity entity = clazz.getAnnotation(Entity.class);
  57.     if (entity != null) {
  58.       return (Class<X>) clazz;
  59.     }
  60.  
  61.     Class<?> superclass = clazz.getSuperclass();
  62.     if (superclass != null) {
  63.       return getEntityClass(superclass);
  64.     }
  65.  
  66.     return null;
  67.   }
  68. }

 

En locator er bindeledded mellom din modell-struktur og RequestFactory. Her definerer du hvordan man henter ut en entitet fra en id. I tillegg definers hvordan man finner id, versjon og type fra en entitet. DAO hentes her ut gjennom en abstrakt metode.

 

  1. @Component
  2. public class ContactLocator extends DocumentEntityLocator<Contact> {
  3.  
  4.   private static final Log LOGGER = LogFactory.getLog(ContactLocator.class);
  5.   private static ContactDao contactDao;
  6.  
  7.   public ContactLocator() {
  8.   }
  9.  
  10.   @Autowired
  11.   public ContactLocator(final ContactDao contactDao) {
  12.     ContactLocator.contactDao = contactDao;
  13.   }
  14.  
  15.   @Override
  16.   public final BaseDao<Contact> getDao() {
  17.     return ContactLocator.contactDao;
  18.   }
  19. }

 

Dette er en implementasjon av en locator for en gitt modul. Denne klassen er annotert med @Component for at Spring skal behandle den ved oppstart. Den statiske kontakt DAO blir da satt. Denne må være statisk da det er RequestFactory som i ettertid vil lage nye instanser av denne, og er som kjent ikke fullstendig Spring-kompatibel. Denne gis så til den abstrakte klassen via implementeringen av DAO-uthenting. Dette gjør det raskt og enkelt å sette opp nye moduler.

 

Videre plan er å gjøre et forsøk på å utvide RequestFactory på serverside slik at vi ikke er så avhengige av statiske variabler for Spring-Beans. Dette vil gjøre at koden er bedre rustet på endringer i fremtiden.

 

 

--Emner: Java, Utvikling, Web 2.0, WisWeb 2
Kommentarer: 0


 
 Nye poster
Fixing missing (30.05.2012)
Redirect dll us (30.05.2012)
Laste ned passo (11.05.2012)
Bare si "Nei ti (12.12.2011)
Posten er slett (16.11.2011)
 Søk
 
 Populære emner
Access  Ajax  Ansatte  Brannmur  Database/SQL  Debugging  Delphi  FortiClient  Fortigate  GSI  Hjemmet  Html  Internett  iPhone  iPhone Apps  Java  JavaScript  JVM  Nerdehumor  Nettverk  Operativsystem  Palm  Servere  Skrivere  Sybase  Utvikling  VBA  Vista  VPN  Web 2.0  Windows  WinXP  WIS  Wis Tiltak  WisWeb 1  WisWeb 2  Word  XML
 Vis måned
Mai 2012 (3)
Desember 2011 (1)
November 2011 (1)
September 2011 (2)
August 2011 (1)
 Vis fra forfatter
Ove Halseth (46)
Dag Waade (9)
Stig Runar Vangen (7)
Svein Waade (6)
Inge Valaas (1)
Inger Berg (1)
Kristian Ljøkelsøy Vitsø (1)