Geeks With Blogs
Jakub Malinowski's blog The blog about ASP.NET

Translation of original post by Scott Guthrie: / Tłumaczenie oryginalnego posta napisanego przez Scott’a Guthrie:  http://weblogs.asp.net/scottgu/archive/2009/07/31/asp-net-mvc-v2-preview-1-released.aspx

Zespół ASP.NET właśnie opublikował pierwszy preview nowej wersji ASP.NET MVC – MVC Version 2. Możesz pobrać go tutaj.

Preview 1 działa w środowisku .NET 3.5 SP1 i VS 2008, i może być zainstalowane równolegle z ASP.NET MVC 1.0 (co oznacza, iż nie pojawi się między nimi konflikt, a dotąd działające aplikacje ASP.NET MVC 1.0 nie zostaną uszkodzone jeśli zainstalujesz nowe preview). Gdy zainstalujesz zarówno ASP.NET MVC 1.0, jak i ASP.NET MVC 2.0, w oknie dialogowym nowego projektu Visual Studio 2008, będziesz miał do wyboru dwa projekty ASP.NET MVC:

W release notes, które znajdziesz w  ASP.NET MVC 2 Preview, opisane jest, co należy zrobić, aby upgrade’ować aplikacje ASP.NET MVC 1.0, by już móc używać nowych możliwości MVC 2.0.

Nowe funkcje

ASP.NET MVC 2.0 zawierać będzie sporo nowych funkcji i możliwości (część z nich już znajduje się na roadmap’ie ASP.NET MVC). Preview 1 daje nam możliwość ogólnego spojrzenia na część nowych funkcji. A jeszcze więcej z nich pojawi się w przyszłych, kolejnych wersjach preview. Preview 1 jest jednak wciąż wersją bardzo wczesną – zespół ASP.NET opublikował tą wersję, by uzyskać od społeczności ocenę planów rozwoju ASP.NET MVC oraz nowe pomysły na rozwój.

Poniżej znajdziesz detale kilku nowych możliwości Preview 1:

Wsparcie dla Obszarów

ASP.NET MVC 2.0 zawiera wsparcie dla nowej funkcji zwanej “obszary”, która umożliwia łatwiejsze dzielenie i grupowanie funkcjonalności w aplikacjach MVC.

Obszary pozwalają na grupowanie kontrolerów i widoków, by podzielić duże aplikacje na pewnego rodzaju sekcje, co pozwala je izolować. Każdy obszar może być zaimplementowany jako osobny projekt ASP.NET MVC, który może być powiązany z główną aplikacją. Pomaga to radzić sobie ze złożonością dużych aplikacji i ułatwia współpracę kilku różnych zespołów pracujących razem nad jedną aplikacją.

Poniżej widać screen, który pokazuje jedną solucję, która zawiera trzy projekty. Jeden z nich nazywa się “CompanySite” i zawiera główną treść portalu, layout,kontrolery i widoki. Następnie są dwa projekty obszarów – “Blogs” i “Forums”. Te projekty zawierają funkcjonalność dostępną pod URL’ami /Blogs i /Forums – mają własne kontrolery, widoki i własne ustawienia routingu:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Preview 1 zawiera wstępną implementację idei obszarów. Nie zawiera jednak jeszcze żadnego wsparcia w postaci narzędzi (na ten moment musisz ręcznie dodać build task, by utworzyć projekt obszaru i odpowiednio go ustawić). Przyszłe preview będą zawierać odpowiednie wsparcie narzędziowe i rozszerzą możliwości obszarów.

[Idea obszarów w aplikacjach ASP.NET MVC pojawiła się już stosunkowo dawno, lecz nie przyjęła tak rozbudowanej formy w sensie technicznym - http://haacked.com/archive/2008/11/04/areas-in-aspnetmvc.aspx – przyp. tłum.]

 

DataAnnotation Validation Support

ASP.NET MVC 2.0 zawiera teraz wbudowane wsparcie dla walidacji DataAnnotation, które pojawiło się w .NET 3.5 SP1 – i które jest teraz używane w ASP.NET Dynamic Data i .NET RIA Services. DataAnnotations umożliwia łatwe, deklaratywne utworzenie walidacji dla klas Model i ViewModel w obrębie aplikacji, oraz automatyczny binding i wsparcie UI helper dla walidacji w ASP.NET MVC.

Aby zobaczyć tą funkcję w akcji, możemy stworzyć nową klasę ViewModel o nazwie “Customer” (deklaracja poniżej), która ma 5 właściwości (zaimplementowane jako auto-properties).

 

 

 

 

 

 

 

Teraz możemy oznaczyć właściwości odpowiednimi atrybutami (System.ComponentModel.DataAnnotations namespace), by ustawić reguły walidacji. Koid poniżej pokazuje użycie 4 różnych reguł - [Required], [StringLength], [Range] i [RegularExpression]. W DataAnnotations znajdziesz też bazową klasę (ValidationAttribute), dzięki której możesz zbudować własne reguły walidacji.

 

Teraz utworzymy kontroler CustomersController, który będzie posiadać dwie akcje Create. Pierwsza z  nich  będzie obsługiwać żądania GET przychodzące na adres “/Customers/Create”, i renderować widok operty o pusty obiekt Customer. Druga akcja Create będzie obsługiwać żądania POST na ten sam adres URL (oraz będzie pobierać obiekt klasy Customer jako parametr). Jej zadaniem będzie wykonanie walidacji obiektu Customer, a następnie: powtórne wyświetlenie widoku z użyciem wprowadzonych danych – jeśli dane nie spełniają kryteriów walidacji, bądź wyświetlenie widoku o nazwie “Success” - jeśli dane spełnią kryteria.

 

Na końcu możemy kliknąć prawym przyciskiem myszy (PM) na jedną z tych akcji, wybrać “Add View” z menu kontekstowego i automatycznie wygenerować widok “create” ze schematu, oczywiście na podstawie klasy Customer. Kiedy to zrobimy, wygenerowany widok będzie zawierać (jak poniżej) tag <form> dla naszej klasy Customer:

 

Teraz, gdy przejdziemy do adresu “/Customers/Create” w przeglądarce, zobaczymy pusty formularz:

 

Jeśli wprowadzimy niepoprawne dane i wyślemy je do serwera, model binder odnajdzie atrybuty DataAnnotations, i automatycznie przeprowadzi walidacje w oparciu o zadeklarowane przez nas reguły. właśnie w przypadku tych niepoprawnych danych akcja zwróci ten sam widok jeszcze raz, tym razem jednak będzie on zawierał wprowadzone przez nas dane oraz wiadomość o tym, że błędnie je wprowadziliśmy. Zauważ, że informacje o błędnych danych zostały wyświetlone całkowicie automatycznie – nie trzeba było do tego żadnego dodatkowego kodu.

Powyższy formularz zostanie wyświetlony za każdym razem, kiedy wprowadzone zostaną błędne dane i zostaną one przesłane do serwera.

W przyszłych preview ASP.NET MVC 2.0 zamierzamy wprowadzić jQuery Validation plugin jako część domyślnego schematu projektu, i dodać również wsparcie dla automatycznej walidacji JavaScript po stronie klienta. To umożliwi developerom łatwe tworzenie walidacji w jednym miejscu – może to być Model lub ViewModel, oraz zastosowanie tej walidacji w dowolnym miejscu aplikacji.

Jeśli nie chcesz oznaczać atrybutami klas Modelu lub ViewModelu bezpośrednio, możesz utworzyć klasę-kumpla (“buddy class”), która będzie enkapsulować reguły walidacji. Jest to również bardzo przydatne w scenariuszach takich jak np. auto-generowanie kodu w VS (np. diagramy LinqToSql, EF).

Oprócz wbudowanego wsparcia dla  DataAnnotations, DefaultModelBinder w ASP.NET MVC 2.0 ma teraz nowe wirtualne metody, dzięki czemu możemy go zintegrować z innymi frameworkami do walidacji (np. Castle Validator, EntLib Validation, itd.). Metody UI helper’ów odpowiedzialne za walidację, stworzone są do współpracy z dowolnymi frameworkami – nie są świadome użycia DataAnnotations).

Silnie typowane UI helper’y

ASP.NET MVC 2.0 zawiera nowe HTML UI helper’y, które umożliwiają użycie silnie typomanych wyrażeń lambda podczas odwołania do Modelu. Umożliwia to łatwiejsze sprawdzanie widoku podczas kompilacji (w związku z czym bugi zostaną znalezione już podczas kompilacji, a nie podczas działania aplikacji), jak również umożliwia lepsze wsparcie Intellisense podczas tworzenia widoku.

Poniżej możesz zobaczyć usprawnienie Intellisense w akcji – zauważ w jaki sposób otrzymałem pełną listę właściwości Modelu, używając nowej metody UI helpera - Html.EditorFor():

 

 

 

 

 

 

 

 

 

Preview 1 ma wbudowane wsparcie dla nowych helperów Html.EditorFor(), Html.LabelFor() i Html.DisplayFor(). Nowe binaria MVC Futures, które opublikowaliśmy w tym tygodniu dodają również Html.TextBoxFor(), Html.TextAreaFor(), Html.DropDownListFor(), Html.HiddenFor() i Html.ValidationMesssageFor() (z czasem zostaną one przesunięte do głównej biblioteki ASP.NET MVC 2.0).

Poniżej możesz zobaczyć nową wersję widoku “Create” utworzoną z użyciem tych nowych helperów. Zamiast klasycznych helperów użyliśmy silnie typowanych wyrażeń lambda. Dzięki temu mamy  pełne wsparcie Intellisense, jak również sprawdzanie widoku podczas kompilacji.

Helper Html.LabelFor() powyżej generuje HTML w postaci <label for=”Name”>Name:</label>.

Helper Html.EditorFor() może być użyty do dowolnego typu danych. Domyślnie jest on sprytny i generuje odpowiedni tag HTML <input/> w zależności od typu danych. Na przykład, dla pierwszych czterech właściwości powyżej (łańcuchy znaków i integery) wygenerowany zostanie tag <input type=”text”/>, natomiast dla ostatniej właściwości (wartość bool) wygenerowany zostanie tag <input type=”checkbox”/>.

Html.EditorFor() ma jeszcze jedną ciekawą cechę – można też przekazać mu złożony obiekt. Domyślnie w takiej sytuacji dla każdej publicznej właściwości zostanie wtedy wygenerowany odpowiedni tag <label>, <input> oraz, jeżeli taki istnieje – komunikat walidacji. Możemy więc przepisać powyższy widok i wywołać Html.EditorFor() tylko raz – na obiekcie Customer, a wynikowy HTML będzie taki sam:

Silnie typowane helpery pozwalają też na oznaczenie właściwości ViewModel atrybutami [DisplayName], które pozwalają na zmianę nazwy wyświetlanej w tagu <label/> (tak więc na przykład: zamiast domyślnej nazwy “IsActive”, możemy ją zmienić - [DisplayName(“Is Active Customer:”)]).

Zadziała tutaj również atrybut [ScaffoldColumn(false)] – który spowoduje ukrycie właściwości, którą nim oznaczymy, oczywiście tylko, kiedy złożony obiekt analizować będzie Html.EditorFor().

[Tych samych atrybutów używamy w Dynamic Data – muszę więc przyznać, że w przyszłości może to dać ciekawe rezultaty – przyp. tłum.]

Wsparcie dla UI Helper Templating

Html.EditorFor() i Html.DisplayFor() obsługują zarówno proste typy, jak i złożone, z wieloma właściwościami, można by rzecz out-of-the-box. Jak wspomniałem wyżej, można to również nieco modyfikować za pomocą odpowiednich atrybutów.

Często jednak programiści chcą edytować wynikowy HTML w sposób bardziej niekonwencjonalny lub mieć nad nim całkowitą kontrolę. Html.EditorFor() i Html.DisplayFor umożliwiająto za pomocą mechanizmu schematów/templates. Schematy definiowane są w takim przypadku w kontekście danego typu (typu prostego, bądź klasy).

W Preview 1 można dodać opcjonalne foldery “EditorTemplates” i “DisplayTemplates” dla konkretnego kontrolera wewnątrz \Views\[nazwaKontrolera], bądź dla całej aplikacji wewnątrz \Views\Shared.

Następnie można dodać do tych folderów kontrolki ASP.NET, które będą służyć do zmieniania sposobu renderowania wybranych typów. Na przykład poniżej dodałem folder EditorTemplates do folderu \Views\Shared i dodałem do niego 3 kontrolki:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Schemat “Customer.ascx” który widzisz powyżej, zostanie użyty zawsze, kiedy wywołam Html.EditorFor() i jako parametr użyję obiekt typu “Customer” (np. mogę tu ustawić całkowicie dowolny layout dla różnych właściwości tej klasy). “DateTime.ascx” zostanie użyty dla właściwości typu DateTime (np. mogę tutaj ustawić JavaScript’owy datepicker dla pola <input/>). Ewentualnie mógłbym dodać kontrolkę “Object.ascx”, która zmieniłaby domyślny sposób renderowania dla wszystkich obiektów.

Dodatkowo można też użyć “named templates” do zmieniania wyglądu konkretnych właściwości. Standardowym scenariuszem w tym przypadku jest “CountryDropDownList”, który obsługuje właściwość typu string, ale zamiast zwykłego textbox’a, używa <select> z  listą wyboru, z której użytkownik może wybrać jakąś wartość. Poniżej widzisz, jak mógłby wyglądać taki schemat:

Możemy wyszukać odpowiedni schemat podając nazwę jako parametr przy wywołaniu Html.EditorFor(). Na przykład, poniżej oprócz wyrażenia podającego odpowiednią właściwość, określamy również nazwę schematu, którą chcemy użyć:

 

 

 

Ewentualnie, możemy oznaczyć atrybutem [UIHint] właściwości we ViewModel. Pozwoli to na określenie nazwy schematu w jednym miejscu, dla wszystkich miejsc (oznaczasz atrybutem typ/właściwość, a we wszystkich miejscach w aplikacji użyty jest podany schemat). Poniżej znajduje się przykład użycia atrybutu [UIHint] dla właściwości Customer.Country – dzięki temu podczas renderowania zostanie użyty schemat “CountryDropDown.ascx”:

 

 

 

 

 

 

 

 

 

Kiedy oznaczymy typ/właściwość tym atrybutem, nie musimy już wpisywać nazwy schematu przy wywoływaniu Html.EditorFor(). A kiedy odświeżymy stronę /Customers/Create, właściwość Country zostanie przedstawiona w postaci dropdownL zamiast textbox’a:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Inne super dodatki

ASP.NET MVC 2.0 zawiera też masę małych, ciekawych ułatwień. Oto kilka moich ulubionych:

Nowy atrybut [HttpPost]

Dość często w ASP.NET MVC rozdzielamy obsługę żądań na dwie akcje: jedną obsługujemy GET, a drugą POST.

W ASP.NET MVC 1.0 używasz zapewne atrybutu [AcceptVerbs(HttpVerbs.Post)], by oznaczyć, że akcja obsługuje POST.

 

 

 

 

 

 

 

 

 

 

 

 

 

Oczywiście, wciąż działa to w ASP.NET MVC 2. Alternatywnie jednak, możesz użyć nowszego atrybutu [HttpPost], który działa w ten sam sposób:

[W MvcContrib ten atrybut to [AcceptPost] – przyp. tłum.]

 

 

 

 

 

 

 

 

 

 

 

 

 

Domyślne wartości parametrów

Obsługa opcjonalnych parametrów to częsty scenariusz. W ASP.NET MVC 1.0 zapewne rozwiązałbyś to, przez zarejestrowanie odpowiednich zasad routingu i wpisanie tam domyślnych wartości albo przez oznaczenie parametrów jako nullable i odpowiednie obsłużenie ich w kodzie.

ASP.NET MVC 2.0 Preview 1 wspiera teraz domyślne wartości parametrów poprzez atrybut DefaultValueAttribute z System.ComponentModel namespace. Pozwala to na podanie wartości, którą ASP.NET MVC ma zwrócić, jeśli nie została podana w żądaniu. Na przykład poniżej widać jak możemy obsłużyć zarówno /Products/Browse/Beverages, jak i /Products/Browse/Beverages?page=2, w pierwszym przypadku automatycznie dostaniemy wartość “1”, bo nie jest ona określona w querystring:

 

 

 

 

VB pozwala już dziś na określenie domyślnej wartości bez użycia atrybutu [DefaultValue] jak powyżej, a C# będzie tę funkcję posiadał w .NET 4.0:

 

 

 

 

To znacznie ułatwi tego typu scenariusze.

Binding danych binarnych

ASP.NET MVC 2.0 Preview 1 dodaje też wsparcie dla bindingu łancuchów zakodowanych jako base64 do byte[] lub System.Data.Linq.Binary. Teraz mamy dwie przeciążone wersje Html.Hidden(), które mogą użyć danych tego typu. Są one bardzo użyteczne np. w celu umożliwienia concurrency control w aplikacji poprzez przechowywanie w tego typu polu wartości timestamp.

Podsumowanie

Kliknij tutaj, aby pobrać archiwum “.zip”, które zawiera projekt  ASP.NET MVC 2.0 z kodem, który tutaj przedstawiłem.

Dzisiejszy build ASP.NET MVC 2.0 to jedynie preview. Kolejne feature’y będą się z czasem pojawiać w kolejnych preview, a zespół ASP.NET czeka na Twoje opinie i pomysły, co można zmienić lub poprawić.

Celem regularnych wersji preview jest wspólne budowanie ASP.NET MVC tak, aby odpowiadał potrzebom społeczności. Wszelkie sugestie, pytania lub opinie możesz wysłać na forum ASP.NET MVC. Więcej o tym release’ie możesz się dowiedzieć z posta Phila Haacka na ten temat lub z video na Channel9.

Scott

P.S. Śledź mnie na portalu Twitter tam często wysyłam mini-posty i publikuje ciekawe linki. Mój Twitter : http://www.twitter.com/scottgu. A nazwa mojego konta to: @scottgu.

 

Promuj

Posted on Friday, July 31, 2009 5:20 PM ScottGu's blog translations | Back to top


Comments on this post: ASP.NET MVC V2 Preview 1 Released – ScottGu’s Blog – Tłumaczenie

Comments are closed.
Comments have been closed on this topic.
Copyright © jakubmal | Powered by: GeeksWithBlogs.net