MVC Web design patterns and Rich Internet Applications

MVC Web designpatternsand Rich Internet Applications F. Morales-Chaparo,R.; Linaje,M.; Preciado,J. C.; Sánchez-Figueroa QUERCUSSoftwareEngineeringGroup EscuelaPolitécnica. UniversidaddeExlemadum 10071Cáceres rúinaje;jcpreciado;femando}@unex.es { robe¡morales;

Abstract l,ooking for the best design pattem to develop an application is not a trivi¿l task ¿nd it dependson the requirements, target platform and expenence of the development group a¡nong others. However, general guidelines for the design pattems issue have aided us during the last yea¡s. In this sense, we recommend a general purpose MVC design pattem for Rich lritemet Applications that will allow taking advantagc of all the curent featu¡es of these applications, facilitating ergineering processes. 1. Introduction Nowadays, the g¡owth of the Internet is a reality and it has great impact on busioess, indusfy, comrnerceand society [4]. The Web has become a comñon platform for providing access to information, therefore ma¡y of the old desktop applications tend to be developed as Web applications. The web Engineering community has proposed methodologies and tools to support the design, development, and mai¡tenance of these Web applicaüons [7] and they can be also specifred at a high level of abshaction to facilitate codegeneration[14]. However, tr¿ditioDal Web applications a¡e inadequate to respond to the new ftnctionalities that users demand within them [l7]. web-tool vendors and Web developers are tying to ¿Nwer such needs th¡ough the introduction of Rich Intemet Applications (RIAS) which increase client-side storageand Focess capacities[2]. This new kind of applications is so novel that currently thele is a lack of full developñert methodologies and architectu¡es in this alea [7]. Froú this situation, problems of maintenanceand reusability may easily arise (as happened previously with deskop and web applications)

which, at worse, could end in a new softwale crisi$ [4]. In this paper we discuss a gener¿l pu¡pose design pattern, based on Model-View-Conholler (MVC), whioh is a standa¡d for interactlve applications [l8] ¿nd a generalized solution to software recurring design problems in development. This pappr is mainly motivated by the lack of coobasted liter¿tu¡e on Rich Intemet Applications ard designpattems at piesert. To show the validiry of the proposal, we present a multi-step Web application case study used tbroughout the paper, over different clientside renderiog teob¡¡ologies in order to present advantages and disadva4tages of each MvC design pattem. The proposed design could be applied to large-scaleRIAS and developers could decreasetime and costs ofengineering processes. This docume¡t is structued as follows: the main features of RIAS are presentedin Section 2. Next, section 3 presents a brief introduction to MvC. In section 4 we show three different Web applications MVC approaohesand we conclude it fixing a RIA MVC that is able to take advantage of the current RIA featu¡es, Finally, in Section 5 conclusions are dmwn. 2. RIA overview Traditional Web applications (based otr HTML) have been extended io several directioís (imp¡oving multimedia contents, interactivity, dataretrieval...). In pa¡ticular, Web loteractive Applications (WIAS) [3] a¡e defined as Web applications where a client program uses the Web irifrastructure in order to leach end-usels through Web based GUI (that usually ¡equi¡es a plug-in iústallation o¡ the cliedt-browser). RIAS lit well in this category but they present new featúes that have not been present togethe! inside Web applications befo¡e, since RIA includes functionality i¡herited from

multimedia desktop applicatio¡s such as drag-anddrop among others. RIA does not fy to replace HTML, because this languagestill reñains perfect for ¡epresenting simple data (including gaphs and photos) without high interactionlevels. The concept of ¡ichness in RIA extends the ffaditional Web in three main aspects: data. presentation and communication capacities.These traditional web applications imp¡ovements involve both,client and se¡ve¡. Ricbnessof data meansusers may manipulate a more sophisticated data úodel at client-side, reducing nework communications.improving data refreshment or data filte¡ing and the effective integration of multimedia contentsamong othe$. fuchness of preseDtation model p¡ovides advantages on use¡ intemctions, facilitating the Use¡ Interface (UI) manipulation avoiding full UI rcfteshments. allows of communication Richness synchronous or asynch¡onous co¡nect¡ons, message-based communications, etc. New data possibilitiesof connections,as asynchronous retrievals or synchronise clients in collaboÉtive Web applications a¡e native in RlAs. RIAS ca¡l be implemented over multiple development platforms such as Adobe Flex or Openlaszlo [2]. Howevera setof RIA featuresis commonlyacceptedby developers[2] [5]. 3. MVC oYerYiew The MVC design pattem was introduced in Smalltalk-80and widely used in softwa¡edesign [6]. MVC irnprovesscalabilityand maintena¡ce, easirigpe¡sor¡alization,etc. [8]. The main benefits we expect from using design pattems include gúranteeing the quality and decreasingtime and cosl of engineering p¡ocesses !31. Dealing with interactive applications, ModelView-Controller(MVC) is a standa¡dfor design and a generalized solution in softwa¡e developments u8l and RIA, as an interactive application is not an exceptionas our previous developments ü6] haveshown. MVC sepa¡atesthe domdiri model (Model), the prcsentationmodel (View), and behaviours (Contloller). General well-knorvr¡ MVC schemais depictedin Figure 1.

D D n f:t

FigureL Desktoplvfvc ln generaldesktopapplications,Model, View a¡d Contoller are usually p¡ogrammed under the samelanglage (e.g. C+) and they composeone executable file plus libra¡ies (usually OS dependent to take adva¡tages of Ul or input fvÍctiñns). Model, VieuJ a d Controller üe aI client-side,so the applicationand the User are at the sameside[19]. Some specific ftameworks are available to but the cont¡ibutionof respondto RIA necessities, this paperis diffe¡ent,showinga generalpurpose MVC architecture that is not focused on a particula¡issue. 4. MVC and Web applications Web applications The evolution of developmentis drivenby the desireto modularize c¡osscutting concems and decrease the dependencybefween Web desig¡ers and web programmers[9]. A traditionalWeb applicationis generallyan HTTP gat€way to certain server-side resources (e.9. XML files, databases,etc.) wherc request parametersa¡eprocessed by the serverand pass€d to the Web application,which generatesan HTTP response. In this paperwe will focuson large-scaleweb applicationswhich are datadynamicand t'?ically written in at least two prcgramming languages. The presentationis desc¡ibed in a client-side Ianguage(e.g. XHTML) and the tunctionality is specified using a seúer-side language(CFML, JSP,etc.). In traditional web applications,the domain model is storcd at se¡ve(s) and the user makes low-level i[teractions with software running on the client, usually though a browserthat renders the HTTP responseat client-side.So in Íaditional Web applications development, Model, View ar'd

Coktroller $e distributed across the server/s ¿Ind the clienf/sover the networku2l. we will show a case study used th¡oughout the pape¡ on the different MVC altematives. ln each of the following sub-sectionsare depicted at least two figu¡es to show the MVC dia$am artd the implications of this lvfvc design pattem over the selectedcasestudy. The selected case stüdy is a t)?ical four steps hotel booking applicatiotr, because it allows advantagesto be taken of some RIA goals like siñplirying selections, multiple configurations and different purchase options. Also, it is simple demonshate advatrtages and enough to disadvantagesof different MVC design pattems. Booking stepsa¡e orgaoizedas follows: . Step I : date selection and number of rooús . Step 2: selection ofroom type . Step 3: summary and payment inforrnation . Step 4: confirmation page. 4.1, S€rver-sideMVC This altemative is based entirely on server-side (depicted in Figure 2) and it is derived directly from desktop MVq providitrg the server with all the computations and operations.A clear example ofthis situation is given in [9] [20] among othe¡s.

2) User ---¡Controller + Model - Víew+ User In this cycle, Us¿r interacts with the application and this is sent to the Controller that updatesthe st¿teofthe Model, Fi\ally the fiev' 1s updated to match the Model ¿rd sends it to the User. This MVC choice is very usefiil when application capabilities lequircments a¡e poor at client-side (e.g. mobile browsers without Javascript functionality) o¡ when application necessity is only to display information with low levels of use¡ inteÉctioo [21]. But we must be careful using this design pattem for all kinds of web applications beoause: . It c¿¡ not update pa¡t of a ,/is'r, it needs to create a new p¡esentation at server-side and serds it to the ¿./ser, . lt increases ba¡dwidth usage in Web applications depending on interactioo necessities. . It causesthe seÍe¡ to be busy all the time, not only serving pages, but also making form validations, generatingUIs, etc. The sefle¡-side must check two kinds of informatioD retrieved f¡om client-side: that all the fo¡m input fields a¡e valid (e.g, a valid email) and tl¡at user selections a¡e available (e.g. availability ofrooms for selecteddates),

@

s8*¡iffr*i¡M:,ir

: f-r L__l

D

MVC Figure2. Sewer-side In this MVC design we must note that when we talk about User ¿t client-side, we t¿lk about a browser that provides an interf¿ce visualiz¿tion and hypertext navigation. This MVC design pattem ct€atestwo cycles in the graph: l) User + Controller + View "+ User The Us¿r inte¡acts with the application and this is seDt to the Coktloller (to the server as a ¡equest) that responds sending a messageto the ,/ie', that updates its information and sends it to the User (to the client as a response).

f"q.:,"::: mEE l*l" *"r'

E,:::: F;¡.E,IE Fisure 3. Network communication in server-side MVC

Communication between server and clients will increasedramaricallyif the numberofusers is too high. Figure 3 shows the communication between one client and one server with oDly one error (form validation) in page 1. Figu¡e 3 represeDts a bad user experience: waiting for refreshrnents, obtaining unavailability ove¡ their selections...but even a bad companyexperience. because they lost clients through booking probleñs [5] and money because they pay per bandwidth usage. One advantagein the Serve¡-sideMVC is that there is only one Model, one ,'¡ew and orie ContrclleL so ir is ñot too difficult to maintain the integrity of the Model, ^t leasf no ñorc tha¡ in deskop applications. Also, all the application may be implemented ur¡der one serve¡-page language ge¡emting HTML fo¡ clients. 4.2. Mixed client-s¡deand server-sideMVC with this Íiixed approach,designerstried to focus their attention solving the problems that we have shownin section4.1 dedvedfrom use¡ interaction and serve¡ overriding. In this way designerschoseto use the clientside processo¡to do soúe validations on the data, usually r¡singa client-sidelanguagesupportedby the browserlike Javascriptor VBscript. It's quite easyto make simple validations with script languagesthat run at clie¡t-side, but the main p¡oblem derives from the browser compatibility. Access to the UI elements is differentamongdiversebrowsers(i.e. Mozilla and Intemet Explo¡e¡) and sometimes it depends on the clients' ope¡ative system. Browser vendoñ do not irnple¡¡ent exactly the same stand¿rd andtbey havetheir owú bugs[5]. specifications This situation is solved using client-side a¡d browser-dependent system detection validationi¡nctions (i.e. one snippetof code for lExplorer, other for Mozilla, etc.). This solution increases the "page weighf' that is sent to the client wasting network ¡esources.Also there ¡s a lack of full script documentation support fo¡ each current browser version available and this situation is worse when we talk about supporting olderbrowse¡versions, Forgiving these technological p¡oblems, a good development choice that has been la¡gely applied is to use the MVC design pattem that

shows Figure 4. This design divides Controller and tsie, between the server and the client-side Ul lea'r'lngthe Model at sewer-side.

"-_

L__l

l-l

D

Figure4. Mixedclient-side andserver-s;de MVC ( I ) The mixed MVC designis more complexthan the server-side one, due to the fact that it gives morefunctionalityto the clieDt.This MVC design pattem createsthree cfcles in the graph, one more than in the server-sideMVC: l) User a Controller (Client) + View (Client) User The UJer interacts with the application only at client-side,so the page is sent to the user only onc€ and later on, the user can interactwith the intedaceobtainingquick responsessince he does not need to access the server-sidefor these operations.The Cortlo,l1el, at client-side, must be capableof taking decisions about the scope of the requi¡ed opeÉtions t¡iggered by user intemction. If these operations require changeson the Model, the application control will give the control to the sewer Controller, but if they affect only the Ul, /i¿M7is upd¿tedarid sent to the Usel at client-side. 2) User - Controller (Client) é Controller (Sener) -View (Server) + View (Client) + User The U,rer iúteracts with the application and this action fires fhe Controller af client-side that decidesto send it to the Controller af server-side. Finally,the fiew at server-sideis updatedand sent to the client-side,/i¿lr. This is not a very usual situation, because ,'l¿r? changesat server-sidearc usually ruled by changes in the Model since presentationchanges by client interaclion are possible,but hardto code. 3) User - Controller (Clienl) + Controller (Semer) + Model + View (Sewer) + View (Client) a Uset The Urer interacts with the application and this is sent to the Controller at client-side that Í:¡es the Coktroller at sewei-side which updates the slateof the Model. Finally, the ,/ien is updated

43

to n'¿tch the Model at sewe¡-side and the new UI is sent to the {/¡el. This mixed design pattem is produced by seveml cuñent ftameworks and it generates a special q?e of HTML k0own as DHTML (Dynamic HTML = HTML + J¿vascript) []. The mixed MVC desigr approach decreases bandwidth usage and the se¡ve¡ oveniding that arise in the server-side MVC (Figure 5), because fo¡m validations alrd conütiotrs are p¡ocessedat client-side.

@ lt**l

'': : "i,'," ¡r*";;;¡¡*q#,i

" E,EtE

DE EMG] f.il f."::\,.,:,::r.1,,,.,,. EE E'E

ED

E f;:;¡..":r.,"_ mE,E EE."r"l

Figure5. Networkcommunic¿tion in mixedMvC (l) But Web applications that use this mixed MVC still have several limitations, such as . limitations on ñaking asynch¡otrous data retrievals with ttrc Model at serve¡-side without page refreshment. . limitations on providing high interaction levels. since there is no Model at clier.t-side. . difficult data manipulation, becausewithout at least pan of the Model at c lient-side, business - logic or data is not available at this side. And rew problems a¡ise: . additional communications have appeared fiom requeslresponse HTTP between /¡¿wJ and Controllers at cllent atrd server sides. . the cycles that üoss the client-server architeoture (the la$t two that we have

explained) ¿¡¡e more expensive in computation time and complexity than in the server-side MVC approach since there is piece ofbusiness logic at client-side. We can solve the first problem of this mixed MVC design pattem leaving part of the Model at cliert-side. This solution usually i[volves migrating $ippets of code f¡om the Controller at server-side to tl¡e client-side (Figu¡e 6) and it rcquires a browse¡ with higher oapabilities.

l**----,------J fa* t _ J I _ tf-l L-----l I

I|

'+

f-l| -)l

---,----,_l

lt.f ) ll L--¡

J

+

nl -r

I L

t1--*) lL-----J

Figure ó. Mixed clieDt-side and server-side MVC (2)

Again this design is not problem free. The main problems of this second mixed MVC approachare: . computations for tasks that requi¡e access to the MVC at server-side are slow, since they need to coñmutate through all the client MVC elemeds, . the Model ¿t client-side is extremely ha¡d to program and maintain because, as we have explained before, it is necessary to deploy differeot codes per client platfo¡m (browset operative systeñ ard device), with the associated problems of development mainte¡anceand testingamongothers. . Also oÍe mo¡e complex cycle appears,so we can be sure that over-heading o¡I design communications among MVC elemetrtswill appear. This last mixed MVC is widely used by those current ftañework that have been adapted tom sever-sidedesign pattem to support advanceduser interactions at client-side. This design pattem is able to be used for AJAX (HTML + Javascript + Aslnchrcnous XML dat¿ ¡et¡ieval) and other similar technologies[0]. Cunently our group is collaborating with orc software factory a¡d rccent projeots have been developed using AJAX and this MVC designpattem. Wiü this last designapproach,if rhe user is able to usea RIA plug-in at client-side,inc¡easi¡g even morc client-side capabilities, developersmay decreaseoode development efforts and eliminate multi-version problems [7]. Anyway, with RIA

as client rende¡ing technology, Model, View a¡d Controller arc divided between the client and the server-side and problems like additional commutations continues unsolved. 4.3. RIA MVC To ¡educe problems derived f¡om the serve¡-side MVC and the two mixed MVC design pattems for RlAs, the altemative seems to give more functionality to the client-side, so the whole Controller ar'd Víew of the application will be placed at client-side and also an important piece ofúe businesslogic (as patt ofthe Model). Figure 7 shows the RIA MVC approach th¿t solves some p¡oblems we have presentedbefore, but it reñains the p¡oblem of multiple client-$ide platforms. Also it requires having different velsions of the same'qpplication adapted for each client-side Dlatform. bu't ?s we have mentioned at the bottom ofsection 4.2, plug-insmay solvethis situation extending browsers capabilities. r;;úfJ-]

bandwidth usage is minimized (in these two first cycles). 3) User + Controller + Model (Client) + Model (Sener) + Yíevta User Different interpretations of this cycle are possible.It canbe seenas a completecycle o¡ not, becausethe communication beñeen the Models at client and se¡ve¡ sides is able to be asynchronousin RIA (transparentto the use¡). I¡ this case the Model af cliert-side is the one that takes the decisior to accessthe server-sideModel e.g.ifnew datais ¡equiredo¡ to maintainthe data ofthe Ul updated. This MVC design decreases network communication and seler computation (Figu¡e 8), taki¡g advantageofthe p¡ocessingcapabilities and resources(p¡ocestor,memory...) availableat client-side.

E

m

/iñ;---'l

f _]lD l IDII.D. |

il

i I fl - - - l ] l Figure7. RIA MVC

The RIA MVC design pattern that we propose createsthree cycles in the graph: l) User + Controller + View - User The Us¿,,interacts with the application o¡ly at client-side, so the page is sent once and the UJe¡ can interact with the interface with quick responsessince he does not need to accessto the server-side. The Controller is able to indicate charges in the Model ^t client-side, so high levels of intemction with the showed data are available too. 2) User + Controllet + Model (Client) + Viev) + User The User interacts with the application and this is send to the Corlrol/¿¡ that updatesthe state of the Model at cllent. Finally üe tz¡,?}"it updated to rratch the Model úrd sent to the Ute,', All these opelations are only at client-side, so network

tr¡ ED -E

,,"i'tsi,:.^ I;'tr, f-\

--r-

t " " l

.l;),

"".

Figure8. Networkcommunication in RIA MVC Problems derived f¡om the sewe¡-side MVC design approachare solved with this approach: o use¡ can updatepart of the ,/iew at client-side (avoidingdisplayrefteshments). . there is a decreaseof bandwidth usage,as shows a simple compa¡ison between figu¡es 6 and 9.

t

I I )

t t t t I

t

a I

t ,

I t t

t I

t , , ) '

t ,

t I I )

I

t I I ) )

the server is ready to serve the application to new users nea¡ly all the time while cu¡rent usels interact and receive feedback only ftom the client-side application. Also, problems that a¡ise ftom the ñixed Mvc approachesare successfully solved with this RIA MVC design,which has capabilities to: . make asyncl¡¡onous d¿ta retrievals with the Model at sefleígide, . provide high interaction levels, not so limited as before, since there is ao importánt piece of the Mod¿l at client-side. Additional problems that a¡ise ftom the clientserver mixed MVC design, like additional coÍrmunications and context commutations, do not conti¡ruewithin this approach. Some RIA developers tend to leave all the Model at cliert-side, and this is possible (having the f\úl Model. View ard Contoller at clierl-side). However, from our expe¡ience it is better to distribüte the Model between the client and the sewe¡-side, becausesecurity and privacy issuesio RIA ale lot corqpletely solved at the moment. As readersm! obsewe, paIt of the client-side design patt€m is @luded in the second mixed design patte¡n (compáie figu¡es 7 and 8), so some of the tecbnologies mentioned in section 4.2 (e.g. AJAX) may use this designpattem too. Finally, in order to coñplete our MVC clientside design pattem proposal, we propose a deeper sepantion within. This proposal (Figlre 9) extends our client-side proposal discussed above with many benefits that we will enumerate,

.

I t )

t t I I l I )

I

t I

t I )

t I )

t I ,

I

Figure9. RIA deeperIúVC This MVC design divides the Mode¡ at client add server sides in two sublaye¡s, so: . The server-side Model '¡thich involves two intemal sub-layers: 1) Persistencelaye¡ that maintains non-volatile dat4 2) Nonpe¡sistencelayer that maintains volatile data. . Client-side Mode¡ which involves two intemal sub-layers: l) Persistence layel: maintains

dat¿ retrieved ñom the seúer-side Model,2\ Non-persistencelayer that maint¿ins volatile dáta at clie -side. Also this design pattem divides the Contoller into two sublayers: . Aclive Controller which t¿kes control fiom use¡ interaction (user triggered). . Passive Controllet which takes conhol ftom predefined actions (time triggered). The main probleo of this approach, used in some olour previous developments [16], is that it increasesthe developing time. However, there are other importaít advantages,riainly: . maintenancetime dec¡eases . quantity ofreusable code inúeases . the separationoftasks facilitates development efforts. 5. Conclusions As usual, one cotrclusion about MVC is clear: MVC design pattem election for an application depetrdson the n¿tu¡e of the application atrd the analyst and develope¡sexperience. Morcover, not all kinds ofapplicationshave client processingor storagerccessities. We have discüssed differert gene¡al Web MVC design pattems th¡oughout the document, which stand fo¡ different kinds of web applicationsin orderto adaptthem to RIA. RIA could use any of the design pattem proposals presented, however to take full advantage of the client-side capacities, we have proposed a general pu¡pose clieot-side design patte¡tr. This design optimizes co¡únutations inside the MVC design and takes all the advantagesfrom the previous ones towa¡ds RIA. Finally, we propose a deeperseparationwithin ou¡ RIA MVC proposal that improves some lifecycle stagesof the applioation. Nowadays we use this proposal in many RlAs with very nice ¡esults. 6. Acknowledgements This work has been ca¡ried out under the p¡ojects PDT06A042y TIN2005-09405-C02-02. Referencias

Fl Betz K., LeffA. and RayfieldJ.T., Developing highly-respor$ive user interfaces with DHTML a¡d servlets, IEEE Intemational and Performance, Computing, Conference,2000 Communications [2] Brent S.: XULRunner: A New Approach fo¡ Developing fuch lnternet Applications. Joumal on I¡temet Computing, IEEE, 2007 [3] Christodoulou S. P., Styliaras G. D. and Papatheodorou T. S., Evaluation of Hypermedia Application Development and Management Systems, ACM conference on Hypertext and H)?ermedia, I 998 [4] Da¡t S., Conliguration ma¡agemenÍ the missidg link in Web engineering, ACM Books,2000 [5] Duhl J., Rich lntemet Applications white papel',http://www.macromedia.cor/platfom/ whitepapers/idc_impact_ol¡ias.pdf, 2003 [6] CammaE., Helm R., JohnsonR. and Vlissides J., Desig¡ pattems: elements of ¡eusable object-o ented software, Add¡son-Wesley Reading,1995 \ [7] Ginige A. and Murugesa¡ S.; web IEEE ergineering: an introduction, Multir¡edia, 2001 [8] Guangchun L., Lu w. and Hanhong X., A novel Web Application firame developed by MVC, ACM SIGSOFTSoftwareEngineering Notes,2003 [9] Kojarski S. and Lorenz D.H., Domain Driven Web Development with webjinn, ACM SIGPLAN confe¡ence on Object-o¡iented pfog¡amming, systems, languages, and applications,2003 [0] Leff A. and Rayfield J.T., Web-application using the development ModeyvieíController design pattem. IEEE Int. Enterpdse Distributed Object Computing Conference,200l ll Linaje, M., Preciado,J.C.,Siánchez-Figueroa, F.: A Methodfor Model BasedDesignofRich Intemet Application Interactive User Interfaces. Int. Confercnce on web Engineering,LNCS, 2007,to be published

[12] Morse S.F. and AndersonC.L., "lnhoducing applicariondesign and software engineering principles in inhoducto¡y CS cou¡ses: modelview-controller Java application framework", Joumal of Computing Sciericesin Colleges, 2004 [13] Paolini P., GarzottoF., Bolchini D., Valenti S., Modelling by Pattem of Web Applications, lnt. Workshop on the World-Wide Web arid ConceptualModelidg,I 999 u4l PastorO., Gómez J., Insfián E., Pelechano V., The OO-Method approachfor infomation systems modeling: from object-oriented concepfi¡al modeling to automated programming,Information Systems,Special issueon Databases: creation,ñanagementand utilization,Elsevie!ScienceLtd., 2001 u5l Phillips 8., DeSigners:The Browser war Casualties, Computer,I 998 [1ó] PreciadoJ.C.,Linaje M., PérezJ.M., Collado P., PLAG: PlataformaRIA pa¡a la gestión centralizada de prácticasde piogramación,Int. Symp.on Computersand Education,2005 u7l Preciado J.C., Linaje M., SánchezF. and Comai S., Necessity of methodologiesto model tuch Intemet Applications. IEEE Intematio¡al Sla¡posium on Web Site Evolution,2005 u8l SauterP., Vógle¡ G., SpechtG. and Flor T., A Model-View-Conholler extension fo¡ pervasive ñulti-client user interfaces, Personal arid Ubiquitous Computing, Springer-verlag, 2005 u9l SmalltalkMVC: http://st-www.cs.uiuc.ed [20] TurauV., web ard e-businessapplication:A ftamework for automatic genemtion of Webbaseddata entry applicationsbasedon XML, ACM symposium on Applied computing,

2002 [21] Wojciechowski,J., Sakowicz,8., Dura, K., Napieralski, A., MvC model, struts framewo¡k a¡d file upload issues in Web Applications based on J2EE platform, Int. Conference Modem Problems of Radio Enginee¡ing, Telecommunications and ComputerScience,2004