FreeVar - Revision history

Mviilvee: /* Server/kliendirakenduse retsesnsioon Skeddl'e */

2016-06-04T15:56:15Z

Server/kliendirakenduse retsesnsioon Skeddl'e

← Older revision		Revision as of 18:56, 4 June 2016
Line 494:		Line 494:
	==Server/kliendirakenduse retsesnsioon Skeddl'e==		==Server/kliendirakenduse retsesnsioon Skeddl'e==

	* Üldpilt: Kogu rakendus on jaotatud ilusti loogilisteks projektideks. Ei saa hästi aru mida teeb ClientRepo projekt solutionis. Aluseks võetud ~~lmselt ContactApp, mitte hilisemas faasis tekkinud~~ Web & WebAPI projekt. Klasside nimetusel on osad klassid mingil põhjusel snake_case'is, tegemist pole otseselt veaga vaid stiiliprobleemiga. Alles on jäetud ka klassid mida pole vaja. Äriloogika tükke eraldi ei leia, kogu loogika laotud controlleritesse. samuti puudu service'd.		* Üldpilt: Kogu rakendus on jaotatud ilusti loogilisteks projektideks. Ei saa hästi aru mida teeb ClientRepo projekt solutionis. Aluseks võetud ilmselt Web & WebAPI projekt. Klasside nimetusel on osad klassid mingil põhjusel snake_case'is, tegemist pole otseselt veaga vaid stiiliprobleemiga. Alles on jäetud ka klassid mida pole vaja. Äriloogika tükke eraldi ei leia, kogu loogika laotud controlleritesse. samuti puudu service'd.

	* Serverrakendus : ~~WebAPI rakendust ei leia~~ ning ~~samuti~~ ei ~~näe peale ApiAccountControlleri ühtegi controllerit~~, mis ~~oleks seotud WebAPI'ga~~. ~~Seega ei saa retsenseerida seda rakenduse~~ osa.		* Serverrakendus : Klientrakendus kasutab serveriga suhtlemiseks serverrakendust. Serverrakenduse jaoks on eraldi olemas projekt DAL. Serverrakenduse aluseks on ilmselt võetud kliendipool kirjutatud kontrollerid ning siis kirjutatud API sisu asemele. Sellisel lähenemisel on omad kiiksud - võib tekkida olukordi, kus API teeb vähem, kui rakendus nõuab. Näiteks, kui süsteemis salvestatakse mingi kanne, mis eeldab ka mingit muud toimingut, kuid see toiming tehakse muu API päringuga. Samuti annab see märku, kuidas on andmebaas struktureeritud. Ilusti on kasutatud "Route" annotatsioone, kuid REST teenust see väga ei meenuta (sama häda ka enda projektis, kuid osades kohtades katsusin RESTi jälgida). Näiteks Subjectcontroller::GetSubjectById() võiks olla mapitud "api/Subject/{id}" vastu. Hetkel on urlis sees veel SubjectGetById, mis on sisuliselt irrelevantne. Järgnev mis silma hakkas on ka enda projektis probleemiks, kui manipuleeritakse mingit resurssi, mis on mingi resursi osa - näiteks kasutaja subjektid, siis võiks meenutada url midagi sellist: "user/{userId}/subjects".

	* Klientrakendus: Mõned actionid on muutunud üsna lohisevaks ning võiks olla eraldi klassis, mis tegeleb mingi tegevusega (TasksController::Index). On kasutatud annotatsioone(mis meetodile vastab mingi action, custom route'd). Tundub, et on olemas ka turvavead. Mitmetes actionites tehakse päringuid ainult findById() meetodit kasutades. Väga paljud controllerid on ilma authorize parameetriteta, mis tähendab, et voli igale poole ligi saada on olemas. Hea näide näiteks SubjectsController::Unsubscribe, õiguseid pole piiratud aga samas otsib controller User.Identity alt aktiivset kasutajat. Siinkohal siis tekib kohe nullpointer. CommentsController::deleteConfirmed on imelik, kuna leitakse mingi TaskId aga samas ei kontrollita selle põhjalt mitte midagi.

	* ~~Kokkuvõte~~: ~~Arvan~~, et ~~autorid~~ on ~~saanud pildi ette~~, mida ~~saab teha asp~~.~~net~~'ga aga ~~serverrakendus puudumine viitab sellele~~, et ~~aine põhirõhk~~ on ~~täitmata~~.		REST best practices: http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

			* Klientrakendus: Mõned actionid on muutunud üsna lohisevaks ning võiks olla eraldi klassis, mis tegeleb mingi tegevusega (TasksController::Index). On kasutatud annotatsioone(mis meetodile vastab mingi action, custom route'd). Tundub, et on olemas ka turvavead. Mitmetes actionites tehakse päringuid ainult findById() meetodit kasutades. Väga paljud controllerid on ilma authorize annotatsioonita, mis tähendab, et voli igale poole ligi saada on olemas. Oleks olnud hea ka praktiseerida role based accessi, ehk siis omistada kasutajatele rollid ning kasutada neid rolle Authorize meetodis. Hea näide turvaprobleemist on näiteks SubjectsController::Unsubscribe, õiguseid pole piiratud aga samas otsib controller User.Identity alt aktiivset kasutajat. Siinkohal siis tekib kohe nullpointer. CommentsController::deleteConfirmed on imelik, kuna leitakse mingi TaskId aga samas ei kontrollita selle põhjalt mitte midagi. On olemas ka eraldi DAL projekt, kuid halb on see, et kasutatakse samu interface'i mida kasutatakse serveri DAL osale. Enda projektis tekkis ka sama häda. Häda on selles, et meetodid on interface'is defineeritud domeenimudelitga aga need hakkavad reetma andmebaasi struktuuri. Sestap peaks kasutama erinevates DAL projektides erinevaid interface'i. Siis saaks kasutada ka DTO'sid andmete postitamisel kui ka lugemisel. Minu arvamus API'dest on see, et tagastada võiks enamat, kui lihtsalt bool'i või tühja returni. Eriti halb olukord tekib näiteks UserSubjectRepository::SubscribeUser'i meetodis kus return on sama, kuigi kontroll on staatus koodi jaoks olemas.


			* Kokkuvõte: Arvan, et autorid on teinud hea töö ning mõistavad, kuidas koostada API teenust.

Mviilvee: /* Server/kliendirakenduse retsesnsioon Skeddl'e */

2016-06-03T10:47:24Z

Server/kliendirakenduse retsesnsioon Skeddl'e

← Older revision		Revision as of 13:47, 3 June 2016
Line 494:		Line 494:
	==Server/kliendirakenduse retsesnsioon Skeddl'e==		==Server/kliendirakenduse retsesnsioon Skeddl'e==

	* Üldpilt:		* Üldpilt: Kogu rakendus on jaotatud ilusti loogilisteks projektideks. Ei saa hästi aru mida teeb ClientRepo projekt solutionis. Aluseks võetud lmselt ContactApp, mitte hilisemas faasis tekkinud Web & WebAPI projekt. Klasside nimetusel on osad klassid mingil põhjusel snake_case'is, tegemist pole otseselt veaga vaid stiiliprobleemiga. Alles on jäetud ka klassid mida pole vaja. Äriloogika tükke eraldi ei leia, kogu loogika laotud controlleritesse. samuti puudu service'd.
	Kogu rakendus on jaotatud ilusti loogilisteks projektideks. Ei saa hästi aru mida teeb ClientRepo projekt solutionis. Aluseks võetud lmselt ContactApp, mitte hilisemas faasis tekkinud Web & WebAPI projekt. Klasside nimetusel on osad klassid mingil põhjusel snake_case'is, tegemist pole otseselt veaga vaid stiiliprobleemiga. Alles on jäetud ka klassid mida pole vaja. Äriloogika tükke eraldi ei leia, kogu loogika laotud controlleritesse. samuti puudu service'd.

	* Serverrakendus : WebAPI rakendust ei leia ning samuti ei näe peale ApiAccountControlleri ühtegi controllerit, mis oleks seotud WebAPI'ga. Seega ei saa retsenseerida seda rakenduse osa.		* Serverrakendus : WebAPI rakendust ei leia ning samuti ei näe peale ApiAccountControlleri ühtegi controllerit, mis oleks seotud WebAPI'ga. Seega ei saa retsenseerida seda rakenduse osa.

Mviilvee: /* Server/kliendirakenduse retsesnsioon Skiddle */

2016-06-03T10:47:09Z

Server/kliendirakenduse retsesnsioon Skiddle

← Older revision		Revision as of 13:47, 3 June 2016
Line 492:		Line 492:
	XML vastab laiaslaastus ülesannete nõuetele, sisaldades viite dimensiooni kuid ei ole väga kasutatud atribuute va. ID. Tegemist on koolis oleva klassi süsteemi kirjeldava XML'iga. Isikliku eelistusena oleksin <Groups> asendanud <Classes> ja <Group> <Class>'iga (kuna XML alguses olev kommentaar vihjab Klassidele mitte gruppidele mis kaotab kommentaari lisamise mõtte. Kommentaarid peaksid abistama sisu mõistmisel.) Lisa atribuutide soovitusena oleks võimalik olnud kasutada groupId="" atribuuti <Student> elemendis mis olekes elemedi sisu jätnud ainult tudengi/õpilase isiklike andmeid sisaldavate elementide jaoks (<Contacts>, <EnrolledCourses> jne.). XSD on VS poolt genereeritud ja atribuut ID tüübiks jäetud unsignedByte mis ei võimalda rohkemat kui 255 väärtust. Kuna andmeid on väga vähe XMLis, siis on raske mingeid reegleid XSD'sse panna. On näha, et autor on vähemalt ära määranud miinimum ja maksimum pikkused õppejõu nimele. XSLT ülesanne on jäänud poolikuks, kahest on tehtud üks. XSLT keelesüntaksit oleks võinud rohkem kasutada (puudu on tingimuste kasutus ja soovituslik muutuja kasutamine), HTMLi on samas piisavalt kirjutatud.		XML vastab laiaslaastus ülesannete nõuetele, sisaldades viite dimensiooni kuid ei ole väga kasutatud atribuute va. ID. Tegemist on koolis oleva klassi süsteemi kirjeldava XML'iga. Isikliku eelistusena oleksin <Groups> asendanud <Classes> ja <Group> <Class>'iga (kuna XML alguses olev kommentaar vihjab Klassidele mitte gruppidele mis kaotab kommentaari lisamise mõtte. Kommentaarid peaksid abistama sisu mõistmisel.) Lisa atribuutide soovitusena oleks võimalik olnud kasutada groupId="" atribuuti <Student> elemendis mis olekes elemedi sisu jätnud ainult tudengi/õpilase isiklike andmeid sisaldavate elementide jaoks (<Contacts>, <EnrolledCourses> jne.). XSD on VS poolt genereeritud ja atribuut ID tüübiks jäetud unsignedByte mis ei võimalda rohkemat kui 255 väärtust. Kuna andmeid on väga vähe XMLis, siis on raske mingeid reegleid XSD'sse panna. On näha, et autor on vähemalt ära määranud miinimum ja maksimum pikkused õppejõu nimele. XSLT ülesanne on jäänud poolikuks, kahest on tehtud üks. XSLT keelesüntaksit oleks võinud rohkem kasutada (puudu on tingimuste kasutus ja soovituslik muutuja kasutamine), HTMLi on samas piisavalt kirjutatud.

	==Server/kliendirakenduse retsesnsioon ~~Skiddle~~==		==Server/kliendirakenduse retsesnsioon Skeddl'e==

	Üldpilt:		* Üldpilt:
	Kogu rakendus on jaotatud ilusti loogilisteks projektideks. Ei saa hästi aru mida teeb ClientRepo projekt solutionis. Aluseks võetud lmselt ContactApp, mitte hilisemas faasis tekkinud Web & WebAPI projekt. Klasside nimetusel on osad klassid mingil põhjusel snake_case'is, tegemist pole otseselt veaga vaid stiiliprobleemiga. Alles on jäetud ka klassid mida pole vaja. Äriloogika tükke eraldi ei leia, kogu loogika laotud controlleritesse. samuti puudu service'd.		Kogu rakendus on jaotatud ilusti loogilisteks projektideks. Ei saa hästi aru mida teeb ClientRepo projekt solutionis. Aluseks võetud lmselt ContactApp, mitte hilisemas faasis tekkinud Web & WebAPI projekt. Klasside nimetusel on osad klassid mingil põhjusel snake_case'is, tegemist pole otseselt veaga vaid stiiliprobleemiga. Alles on jäetud ka klassid mida pole vaja. Äriloogika tükke eraldi ei leia, kogu loogika laotud controlleritesse. samuti puudu service'd.

	Serverrakendus : WebAPI rakendust ei leia ning samuti ei näe peale ApiAccountControlleri ühtegi controllerit, mis oleks seotud WebAPI'ga. Seega ei saa retsenseerida seda rakenduse osa.		* Serverrakendus : WebAPI rakendust ei leia ning samuti ei näe peale ApiAccountControlleri ühtegi controllerit, mis oleks seotud WebAPI'ga. Seega ei saa retsenseerida seda rakenduse osa.

			* Klientrakendus: Mõned actionid on muutunud üsna lohisevaks ning võiks olla eraldi klassis, mis tegeleb mingi tegevusega (TasksController::Index). On kasutatud annotatsioone(mis meetodile vastab mingi action, custom route'd). Tundub, et on olemas ka turvavead. Mitmetes actionites tehakse päringuid ainult findById() meetodit kasutades. Väga paljud controllerid on ilma authorize parameetriteta, mis tähendab, et voli igale poole ligi saada on olemas. Hea näide näiteks SubjectsController::Unsubscribe, õiguseid pole piiratud aga samas otsib controller User.Identity alt aktiivset kasutajat. Siinkohal siis tekib kohe nullpointer. CommentsController::deleteConfirmed on imelik, kuna leitakse mingi TaskId aga samas ei kontrollita selle põhjalt mitte midagi.

	KLientrakendus: Mõned actionid on muutunud üsna lohisevaks ning võiks olla eraldi klassis, mis tegeleb mingi tegevusega (TasksController::Index). On kasutatud annotatsioone(mis meetodile vastab mingi action, custom route'd). Tundub, et on olemas ka turvavead. Mitmetes actionites tehakse päringuid ainult findById() meetodit kasutades. Väga paljud controllerid on ilma authorize parameetriteta, mis tähendab, et voli igale poole ligi saada on olemas. Hea näide näiteks SubjectsController::Unsubscribe, õiguseid pole piiratud aga samas otsib controller User.Identity alt aktiivset kasutajat. Siinkohal siis tekib kohe nullpointer. CommentsController::deleteConfirmed on imelik, kuna leitakse mingi TaskId aga samas ei kontrollita selle põhjalt mitte midagi.		* Kokkuvõte: Arvan, et autorid on saanud pildi ette, mida saab teha asp.net'ga aga serverrakendus puudumine viitab sellele, et aine põhirõhk on täitmata.

	Kokkuvõte: Arvan, et autorid on saanud pildi ette, mida saab teha asp.net'ga aga serverrakendus puudumine viitab sellele, et aine põhirõhk on täitmata.

Mviilvee at 10:46, 3 June 2016

2016-06-03T10:46:11Z

← Older revision		Revision as of 13:46, 3 June 2016
Line 491:		Line 491:

	XML vastab laiaslaastus ülesannete nõuetele, sisaldades viite dimensiooni kuid ei ole väga kasutatud atribuute va. ID. Tegemist on koolis oleva klassi süsteemi kirjeldava XML'iga. Isikliku eelistusena oleksin <Groups> asendanud <Classes> ja <Group> <Class>'iga (kuna XML alguses olev kommentaar vihjab Klassidele mitte gruppidele mis kaotab kommentaari lisamise mõtte. Kommentaarid peaksid abistama sisu mõistmisel.) Lisa atribuutide soovitusena oleks võimalik olnud kasutada groupId="" atribuuti <Student> elemendis mis olekes elemedi sisu jätnud ainult tudengi/õpilase isiklike andmeid sisaldavate elementide jaoks (<Contacts>, <EnrolledCourses> jne.). XSD on VS poolt genereeritud ja atribuut ID tüübiks jäetud unsignedByte mis ei võimalda rohkemat kui 255 väärtust. Kuna andmeid on väga vähe XMLis, siis on raske mingeid reegleid XSD'sse panna. On näha, et autor on vähemalt ära määranud miinimum ja maksimum pikkused õppejõu nimele. XSLT ülesanne on jäänud poolikuks, kahest on tehtud üks. XSLT keelesüntaksit oleks võinud rohkem kasutada (puudu on tingimuste kasutus ja soovituslik muutuja kasutamine), HTMLi on samas piisavalt kirjutatud.		XML vastab laiaslaastus ülesannete nõuetele, sisaldades viite dimensiooni kuid ei ole väga kasutatud atribuute va. ID. Tegemist on koolis oleva klassi süsteemi kirjeldava XML'iga. Isikliku eelistusena oleksin <Groups> asendanud <Classes> ja <Group> <Class>'iga (kuna XML alguses olev kommentaar vihjab Klassidele mitte gruppidele mis kaotab kommentaari lisamise mõtte. Kommentaarid peaksid abistama sisu mõistmisel.) Lisa atribuutide soovitusena oleks võimalik olnud kasutada groupId="" atribuuti <Student> elemendis mis olekes elemedi sisu jätnud ainult tudengi/õpilase isiklike andmeid sisaldavate elementide jaoks (<Contacts>, <EnrolledCourses> jne.). XSD on VS poolt genereeritud ja atribuut ID tüübiks jäetud unsignedByte mis ei võimalda rohkemat kui 255 väärtust. Kuna andmeid on väga vähe XMLis, siis on raske mingeid reegleid XSD'sse panna. On näha, et autor on vähemalt ära määranud miinimum ja maksimum pikkused õppejõu nimele. XSLT ülesanne on jäänud poolikuks, kahest on tehtud üks. XSLT keelesüntaksit oleks võinud rohkem kasutada (puudu on tingimuste kasutus ja soovituslik muutuja kasutamine), HTMLi on samas piisavalt kirjutatud.

			==Server/kliendirakenduse retsesnsioon Skiddle==

			Üldpilt:
			Kogu rakendus on jaotatud ilusti loogilisteks projektideks. Ei saa hästi aru mida teeb ClientRepo projekt solutionis. Aluseks võetud lmselt ContactApp, mitte hilisemas faasis tekkinud Web & WebAPI projekt. Klasside nimetusel on osad klassid mingil põhjusel snake_case'is, tegemist pole otseselt veaga vaid stiiliprobleemiga. Alles on jäetud ka klassid mida pole vaja. Äriloogika tükke eraldi ei leia, kogu loogika laotud controlleritesse. samuti puudu service'd.

			Serverrakendus : WebAPI rakendust ei leia ning samuti ei näe peale ApiAccountControlleri ühtegi controllerit, mis oleks seotud WebAPI'ga. Seega ei saa retsenseerida seda rakenduse osa.


			KLientrakendus: Mõned actionid on muutunud üsna lohisevaks ning võiks olla eraldi klassis, mis tegeleb mingi tegevusega (TasksController::Index). On kasutatud annotatsioone(mis meetodile vastab mingi action, custom route'd). Tundub, et on olemas ka turvavead. Mitmetes actionites tehakse päringuid ainult findById() meetodit kasutades. Väga paljud controllerid on ilma authorize parameetriteta, mis tähendab, et voli igale poole ligi saada on olemas. Hea näide näiteks SubjectsController::Unsubscribe, õiguseid pole piiratud aga samas otsib controller User.Identity alt aktiivset kasutajat. Siinkohal siis tekib kohe nullpointer. CommentsController::deleteConfirmed on imelik, kuna leitakse mingi TaskId aga samas ei kontrollita selle põhjalt mitte midagi.

			Kokkuvõte: Arvan, et autorid on saanud pildi ette, mida saab teha asp.net'ga aga serverrakendus puudumine viitab sellele, et aine põhirõhk on täitmata.

Mviilvee: /* Projekti esitus */

2016-06-02T06:44:38Z

Projekti esitus

← Older revision		Revision as of 09:44, 2 June 2016
Line 24:		Line 24:
	* Konto kõikide õigustega: U: administrator@tyyp.ee P: admin1		* Konto kõikide õigustega: U: administrator@tyyp.ee P: admin1

	~~----~~		<br>
	Projekti eesmärk oli luua kasutajatele keskkond, kus kasutaja saaks jagada enda sõidukitega toimuvat infot. Hetkel on olemas palju erinevaid automargi foorumeid, kus on sarnaseid teemasid väga palju. Kes tuunivad, kes ehitavad, kellel hobiauto, kellel niisama hea päevikut pidada. Kogu rakendus tiirleb ümber auto ning auto külge seotud blogidega. Kasutajad saavad blogisid märkida lemmikuks ning nendele tekib avalehele feed lemmik blogidest. Samuti kuvatakse avalehel uuemad blogid. Olemas on ka otsingu funktsionaalsus. Lisaks eelnevale on olemas ka sõnumivahetus osa. Kasutaja saab kirjutada teisele kasutajale, et küsida abi/nõu mingi mure kohta või siis niisama vestluseks.		Projekti eesmärk oli luua kasutajatele keskkond, kus kasutaja saaks jagada enda sõidukitega toimuvat infot. Hetkel on olemas palju erinevaid automargi foorumeid, kus on sarnaseid teemasid väga palju. Kes tuunivad, kes ehitavad, kellel hobiauto, kellel niisama hea päevikut pidada. Kogu rakendus tiirleb ümber auto ning auto külge seotud blogidega. Kasutajad saavad blogisid märkida lemmikuks ning nendele tekib avalehele feed lemmik blogidest. Samuti kuvatakse avalehel uuemad blogid. Olemas on ka otsingu funktsionaalsus. Lisaks eelnevale on olemas ka sõnumivahetus osa. Kasutaja saab kirjutada teisele kasutajale, et küsida abi/nõu mingi mure kohta või siis niisama vestluseks.

			<br>

			Projekt valmis 99% Mihkli panusel seepärast on Mihkel teinud palju ohverdusi selleks, et projekt üldse mingil kujul oleks presenteeritav. Kuna Mihklil oli ka "ASP.NET veebirakendused" aine võetud, siis kliendipool sai tehtud spetsiaalselt selleks, et saada ka teine aine tehtud. Tänu sellele pühendas Mihkel ka sellele projektile rohkem aega. Kuna eesmärk oli saada projektile pilt ette ei kasutanud Mihkel igas kohas nn "best practise" nõuandeid. Näiteks sai ainukesena VehicleController endale Service'i ning suhtlemiseks kasutatakse DTO'si.

	== Idee ==		== Idee ==

Mviilvee: /* Projekti esitus */

2016-05-30T16:48:02Z

Projekti esitus

← Older revision		Revision as of 19:48, 30 May 2016
Line 23:		Line 23:

	* Konto kõikide õigustega: U: administrator@tyyp.ee P: admin1		* Konto kõikide õigustega: U: administrator@tyyp.ee P: admin1

			----
			Projekti eesmärk oli luua kasutajatele keskkond, kus kasutaja saaks jagada enda sõidukitega toimuvat infot. Hetkel on olemas palju erinevaid automargi foorumeid, kus on sarnaseid teemasid väga palju. Kes tuunivad, kes ehitavad, kellel hobiauto, kellel niisama hea päevikut pidada. Kogu rakendus tiirleb ümber auto ning auto külge seotud blogidega. Kasutajad saavad blogisid märkida lemmikuks ning nendele tekib avalehele feed lemmik blogidest. Samuti kuvatakse avalehel uuemad blogid. Olemas on ka otsingu funktsionaalsus. Lisaks eelnevale on olemas ka sõnumivahetus osa. Kasutaja saab kirjutada teisele kasutajale, et küsida abi/nõu mingi mure kohta või siis niisama vestluseks.

	== Idee ==		== Idee ==

Mviilvee: /* Projekti esitus */

2016-05-30T08:22:33Z

Projekti esitus

← Older revision		Revision as of 11:22, 30 May 2016
Line 20:		Line 20:
	*Server: http://tyypvigaserver.azurewebsites.net		*Server: http://tyypvigaserver.azurewebsites.net
	*Dokk: http://tyypvigaserver.azurewebsites.net/Help (seisuga 29.05.2016 on sisestatud ainult sisulise osa päringute kommentaarid)		*Dokk: http://tyypvigaserver.azurewebsites.net/Help (seisuga 29.05.2016 on sisestatud ainult sisulise osa päringute kommentaarid)
			*Lähtekood: https://github.com/viilveer/vr2_asp (esialgu arendasin VSO'sse, kuna peab avalik olema siis tõstsin github'i ümber)

	* Konto kõikide õigustega: U: administrator@tyyp.ee P: admin1		* Konto kõikide õigustega: U: administrator@tyyp.ee P: admin1

Mviilvee: /* Projekti esitus */

2016-05-29T21:15:28Z

Projekti esitus

← Older revision		Revision as of 00:15, 30 May 2016
Line 20:		Line 20:
	*Server: http://tyypvigaserver.azurewebsites.net		*Server: http://tyypvigaserver.azurewebsites.net
	*Dokk: http://tyypvigaserver.azurewebsites.net/Help (seisuga 29.05.2016 on sisestatud ainult sisulise osa päringute kommentaarid)		*Dokk: http://tyypvigaserver.azurewebsites.net/Help (seisuga 29.05.2016 on sisestatud ainult sisulise osa päringute kommentaarid)

			* Konto kõikide õigustega: U: administrator@tyyp.ee P: admin1

	== Idee ==		== Idee ==

Mviilvee: /* Projekti esitus */

2016-05-29T20:56:25Z

Projekti esitus

← Older revision		Revision as of 23:56, 29 May 2016
Line 19:		Line 19:
	*Klient: http://tyypvigaclient.azurewebsites.net/Memberarea , http://tyypvigaclient.azurewebsites.net/		*Klient: http://tyypvigaclient.azurewebsites.net/Memberarea , http://tyypvigaclient.azurewebsites.net/
	*Server: http://tyypvigaserver.azurewebsites.net		*Server: http://tyypvigaserver.azurewebsites.net
	*Dokk: http://tyypvigaserver.azurewebsites.net/Help (seisuga 29.05.2016 on ~~puudu~~ kommentaarid)		*Dokk: http://tyypvigaserver.azurewebsites.net/Help (seisuga 29.05.2016 on sisestatud ainult sisulise osa päringute kommentaarid)

	== Idee ==		== Idee ==

Mviilvee at 20:24, 29 May 2016

2016-05-29T20:24:59Z

← Older revision		Revision as of 23:24, 29 May 2016
Line 17:		Line 17:
	== Projekti esitus ==		== Projekti esitus ==

	Klient: http://tyypvigaclient.azurewebsites.net/Memberarea , http://tyypvigaclient.azurewebsites.net/		*Klient: http://tyypvigaclient.azurewebsites.net/Memberarea , http://tyypvigaclient.azurewebsites.net/
	Server: http://tyypvigaserver.azurewebsites.net		*Server: http://tyypvigaserver.azurewebsites.net
	Dokk: http://tyypvigaserver.azurewebsites.net/Help (seisuga 29.05.2016 on puudu kommentaarid)		*Dokk: http://tyypvigaserver.azurewebsites.net/Help (seisuga 29.05.2016 on puudu kommentaarid)

	== Idee ==		== Idee ==