Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. PHP
Code

Ang Paggawa ng Iyong Startup: Ang Paghiling ng Pagbabago sa Iskedyul

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Building Your Startup With PHP.
Building Your Startup: Advanced Scheduling Commands
Building Your Startup: Meetings With Multiple Participants

Tagalog (Wikang Tagalog) translation by Anna Nelson (you can also view the original English article)

Final product image
What You'll Be Creating

Ang tutorial na ito ay bahagi ngserye tungkol sa pagbuo ng iyong startup gamit ang PHP sa Envato Tuts+. Sa seryeng ito, gagabayan ko kayo sa paglulunsad ng isang startup mula sa konsepto sa kasalukuyan gamit ang aking Meeting Planner app bilang isang makatotohanan na halimbawa.  Bawat hakbang sa kahabaan ng proseso, ibibigay ko ang open-source code ng aking Meeting Planner app bilang halimbawa kung saan maaari mong malaman ang pinagmulan. Tatalakayin ko din angmga isyu tungkol sa negosyo kung meron tayong madaanan.

Ang Pagbabago ng Iyong Planong Pagtitipon

Habang nagsisimula ang alpha testing phase ng Meeting Planner, makikita na ang pinakamalinaw na isyu sa feature ay ang kawalan ng kakayanan na baguhin ang pagtitipon matapos itong maiskedyul. Ito ay hindi madaling problema. Maaari bang baguhin ang pagtitipon ng walang permiso ng kalahok?  O dapat kang humingi ng permiso? O gawin ang kahit ano sa dalawang iyon, depende sa iyong tungkulin sa pag-aayos ng pagtitipon? Paano kung nais mo lang tanungin kung maaaring magtipon makalipas ang 15 minuto mula sa orihinal na oras ng pagtitipon – dapat madali lang itong gawin, tama ba?

Ang paglutas ng lahat ng ito ay nangangailangan ng panlipunang aspeto ng pagbabago ng pagtitipon.

Sa paglipas ng panahon, naunawaan ko na ang kakayanan sa pagsasaayos ng mga pagtitipon nang madali matapos itong maitakda ay maaaring ikaganda o ikasira ng tatak ng Meeting Planner.

Sa huling episode tungkol sa Advanced Scheduling, ipinatupad ko ang Make Changes, kung saan ang nag-organisa o ang kalahok ay binibigyan ng permiso na baguhin ang itinakdang pagtitipon ng hindi humihingi ng pahintulot. Sa tutoryal ngayon, ipapakita ko sa inyo ang paggawa ng Imprastraktura ng Request Changes. Ito ay nangangailangan ng request change(s) ng mga kalahok at maaaring ang iba ay tanggapin o tanggihan sila, na makakaapekto sa huling detalye ng kalendaryo ng pagtitipon.

Habang kayo ay nagbabasa, sana subukan niyo ang bagong “request a change” na feature sa live site at ibahagi ang inyong ideya at feedback sa komento sa ibaba. Ako ay sumasagot sa talakayan sa ibaba, at maaari din kayong makipag-ugnayan sa akin sa @reifman sa Twitter. Ako ay laging bukas sa mga bagong tampok na mga ideya para sa Meeting Planner pati na rin sa mga mungkahi para sa mga susunod na episode ng mga serye.

Bilang paalala, ang lahat ng mga code para sa Meeting Planner ay nakasulat sa Yii2 Framework para sa PHP Kung gusto mong matuto nang iba pa tungkol sa Yii2, tingnan ang aming parallel series Programming Sa Yii2.

Magsimula na tayo.

Ang Paggawa ng Request Changes

Isang Mataas na Bundok na Aakyatin

Bukod sa meeting view at mga scheduling feature, ang Request Changes ay nangangailangan ng mas maraming oras at bagong kowd kaysa sa iba pang mga feature sa proyektong ito.

Gaya ng nabanggit ko sa huling episode, ang paglalagay ng kowd sa lahat ng may pangunahing seguridad ay nangangailangan ng mas mahabang oras kaysa sa mabilis na prototyping, habang ang pagdidisenyo at paggawa ng feature naman na ito ay gumagamit ng napakaraming mga platform area:

  • Ang pagdidisenyo sa pamamagitan ng social engineering sa paghiling at paggawa ng pagbabago sa iskedyul.
  • Ang pananatiling simple ng UX sa paghingi ng pagbabago ay nakakatulong sa mga taong humiling at tumugon sa mga change request ng hindi nagugulo ang interface.
  • Ang pangangasiwa ng mga hiling para sa 1:1 na mga pagtitipon ay magiging madali, habang ang kowding para sa darating na multiple participants feature ay nangangailangan ng mas sopistikadong imprastraktura.
  • Ang pangangasiwa ng mga tugon sa mga request na may maraming kalahok.
  • Ang mga Email notification ng bago at mga kinanselang request, ang mga tinanggap at tinanggihan na mga tugon.
  • Ang pagbago ng kumpirmasyon ng pagtitipon at ang mga detalye ng kalendaryo kung ang mga tinanggap na request ay nakakaapekto ng iskedyul.

Kaya habang ang feature na ito ay hindi isang perpektong larawan ng pagbabago, narito ang mga screenshot ng eventual production server code pull.

Narito ang mga pagbabago sa umiiral na kowd:

Build Your Startup Request Scheduling Changes - Git Pull File Changes

At narito ang mga bagong file:

Build Your Startup Request Scheduling Changes - Git Pull New Files

Maraming bagong kowd ang kasama sa feature na ito.

Ang mga Table at ang mga Migration nito

Sa huli, nagpasya akong gumawa ng arkitekturang nakapaloob sa dalawang table. Ang una ay ang Requests:

Narito ang mga hindi nagbabagong elemento na magpapaliwanag sa modelo nang mas malalim:

May dalawang paraan para baguhin ang oras: TIME_ADJUST_ABIT, i.e. pagitan ng mga minuto o mga oras ng mas maaga o mas huli sa napiling oras, o TIME_ADJUST_OTHER, o ibang oras ng pagtitipon.

At ang ikalawang table ay ang RequestResponses:

Ang ibig sabihin nito, kung sino ang humiling ng pagbabago, kung sino ang tumugon dito at kung ano ang tugon dito: accept o decline.

Ang pangalawang table ay kailangan para sa maramihang participant environment.

Ang Paghiling ng Pagbabago

Ang magtitipon na mga organizer at mga kahalok ay maaaring magkaroon ng access sa Request Changes sa pamamagitan ng dropdown Options menu na aming ginawa sa huling episode:

Build Your Startup Request Scheduling Changes - Options Menu Request Changes

Ang Request Change Form

Ang RequestController.php's actionCreate() ay nagpapakita ng form kung saan nagmumula ang mga request change ng isang user.

Build Your Startup Request Scheduling Changes - Request a Change Form

At dito nagsisimula ang kumplikasyon. Ano ang mga uri ng pagbabago na maaaring hilingin ng mga kalahok?

  • Gusto mo bang magtipon ng mas maaga o mamaya pa?              
  • Gusto mo bang magtipon sa ng ibang oras?
  • Gusto mo bang magtipon sa ibang lugar?

Tandaan: Hindi ko pa ipinapatupad ang kakayanan ng paglalagay ng mga bagong lugar at oras – kasalukuyan,  maaari kang mamili ng bagong petsa at lugar mula sa mga ibinigay na opsyon noong panahon ng pagpaplano.

Ang Dropdown ng Earlier at Later Times

Ang kowd para lumikha ng dropdown list ay masalimuot. Ginawa ko ito upang makapili kayo ng mas maaga ng dalawa at kalahating oras o mas huli, na may 15-minutong pagitan na malapit sa orihinal na oras at 30-minutong pagitan pagkatapos nito:

Pinuno ko ang $altTimesList ng mga key ng bawat posibleng oras na akma sa time zone ng user. At ginamit ko ang ksort() para ibukod ang dropdown ng mga naunang oras upang makita ang mga ito bago ang mga huling oras.

Isa sa mga tagapayo ng Meeting Planner (mayroon lang akong isa sa mga sandaling ito), ay iminungkahing ipakita ang kasalakuyang napiling oras ng pagtitipon, na ginawa ko sa ibaba. Ako din ay naglagay ng separator na may opsyon na hindi gumana sa dropdown. Ito ay hinihiwalay ang mas maagang oras mula sa huling oras ngunit ito ay di maaaring piliin:

Build Your Startup Request Scheduling Changes - Enhanced Request Form with Separator

Narito ang kowd ng dropdown, na nagpapakita kung paano di gagana ang separator batay sa $currentStart index key nito:

At kung ang mga kalahok ay nais pumili ng ibang oras, mayroong JQuery para palitan ang mga dropdown, isa pang kumplikado sa paggawa ng mga form:

Narito ang /frontend/web/js/request.js:

Narito ang anyo ng form na may mga nakatagong alternatibong oras:

Build Your Startup Request Scheduling Changes - Selecting a different place

Ang iba’t-ibang lugar ay pinagsama-sama sa iisang dropdown list ng mga lugar (tulad ng nakikita niyo sa itaas, na itinatampok sa larawan).

Ang Pag-aayos ng Request

Matapos magawa ang request, ipinababatid namin sa requestor na ang request ay ipinapaalam sa iba pang kalahok ng pagtitipon.  At sa tuwing may mga aktibong request para sa pagtitipon, mayroon link para makita ang mga ito:

Build Your Startup Request Scheduling Changes - Meeting page View Requests

Napagpasiyahan ko na ito ay magiging isang simple at maayos na paraan para ma-access ang mga request. 

Ang Listahan ng mga Meeting Request

Narito ang listahan ng mga request para sa isang pagtitipon, na kadalasan ay iisa lang:

Build Your Startup Request Scheduling Changes - List of Meeting Requests

Ang Request::buildSubject() ay lumilikha ng string sa itaas na batay sa nilalaman ng request, i.e. pagbabago ng oras at/o lugar:

Ang function na ito ay paulit-ulit din na ginagamit sa mga email notification.

Mayroon din na mga limitasyon ang RequestController.php kung saan ang mga gumagamit ay hindi pinahihintulutang humiling ng higit pa sa isang request kada pagtitipon:

Narito ang view request page na nagpapakita ng limitasyon:

Build Your Startup Request Scheduling Changes - Viewing a Request

Kung ito ay sarili mong request, maaari mong Kanselahin ang Iyong Request.

Tulad ng nakikita mo, napakaraming iba’t-ibang UX functionality para makagawa nito. At hindi ko pa ipinapakita sa inyo kung paano tumugon ang ibang tao maliban sa requestor.

Ang Request at Response Notification Emails

Sa proseso ng paggawa ng mga feature na ito, napagpasiyahan kong lumikha ng generic_html at mga generic_text email template pati na rin ang isang function na maaaring gamitin muli, ang Request::notify(). Ito ay ginagamit upang madaling maihatid ang iba’t-ibang uri ng mga anunsyo sa loob ng Meeting Planner.

Narito ang paraan ng Request::create() para sa paghahanda ng email

Ang $content array ay awtomatikong lumalabas para sa subject ng email, heading ng message at talata, habang ang $button array ay ginagamit para sa anumang command button tulad ng Respond to Request o View Meeting.

Narito ang paraan ng notify(), na katulad sa earlier send() at finalize() actions na nagpapadala ng email:

Ang generic_html.php layout ay batay sa simpleng textual update template na aking tinalakay sa mga tutoryal tungkol sa email template. Ito ay nagbibigay ng isang mahusay na format upang maipaalam sa mga kalahok sa pamamagitan ng email gamit ang ilang mga talata.

Narito ang generic_html.php view file na pinagsamang $content at $button data.  Ito ay sumusuri sa ikalawa at ikatlong talata, e.g. $p2, $p3 at $button data:

Narito ang halimbawa ng isang notipikasyon na hiniling ni Rob Smith sa akin upang palitan ang oras at lugar ng aming pagtitipon (na nagmula sa kowd sa itaas):

Build Your Startup Request Scheduling Changes - Email Notification of Requested Change

Ang Tumugon sa Kahilingan

Kapag pinindot ko ang Respond to Request, ako ay mapupunta sa RequestResponse Controller's actionCreate() method:

Build Your Startup Request Scheduling Changes - Respond to Request Form - Accept or Decline

Sa buong panahon ng request UX, isinama ko ang kakayanan ng mga tao na sumulat ng mga tala na magbibigay ng konteksto para sa mga hiling at mga tugon.

Ang isang hamon ng form na ito ay tukuyin kung paano mangangasiwa ng mga tugon sa iba’t-ibang mga controller method batay sa submit button na pinindot. Sa madaling salita, ang pagkakakilanlan sa pagitan ng iba’t-ibang mga submit POST button click.

Narito ang /frontend/views/request-response/_form.php:

Lubhang kailangang maglagay ako ng name values na 'accept' o 'reject' sa bawat pindutan. Pagkatapos, ito ay ipinapadala bilang posted value tulad ng ipinapakita:

Kung ang taga-tugon ay tinanggap o tinanggihan ang request, makakakita sila ng isang flash message at sila ay padadalhan ng email. At ang pagtitipon ay hindi na magpapakita ng anumang aktibong mga request:

Build Your Startup Request Scheduling Changes - Meeting page after Request accepted

Narito ang Requested Change Accepted notification email:

Build Your Startup Request Scheduling Changes - Email notification of requested change being accepted

Marami ang nagaganap sa Request::accept() na nasa ibaba:

Bago ipadala ang email, ang iskedyul ng pagtitipon ay magbabago upang ipakita ang bagong petsa/oras at/o ang bagong lugar.  Pagkatapos ipadala ang email, ang pagtitipon ay aayusin. Ito ay magpapadala ng bagong update tungkol sa pagtitipon na may kasamang updated calendar file sa lahat ng mga kalahok:

Build Your Startup Request Scheduling Changes - Updating Meeting Notice

Ano ang Susunod?

Sana ay nasiyahan kayo sa tutoryal na ito.  Ang paggawa ng feature na ito ay natapos nang mas matagal sa aking inaasahan ngunit maganda naman ang kinalabasan. Sa tingin ko, ito ay nagdagdag ng elemento sa paggawa ng iskedyul gamit ang Meeting Planner na hindi mapapantayan ng ibang mga serbisyo.

Kung hindi mo pa nasusubukan, halina’t gumawa ng iskedyul ng iyong unang pagtitipon sa pamamagitan ng Meeting Planner. Patuloy pa din akong gumagawa ng hindi kapani-kapaniwalang progresibo sa beta release, kahit na maraming bagay ang nakakagambala (ang kowding ay mahirap):

Ako din ay nagpaplanong gumawa ng tutoryal tungkol sa crowdfunding, kaya pakiusap sundan at bisitahin ang aming WeFunder Meeting Planner page.

Mangyaring ibahagi ang inyong mga komento sa ibaba. Ako ay laging bukas sa bagong mga tampok na ideya at mga paksa sa mga susunod na tutoryal. Maaari niyo din akong maabot sa @reifman.

Manatiling nakatutok sa lahat ng ito at sa iba pang mga darating na tutoryal sa pamamagitan ng panonood ng Building Your Startup With PHP series.  At siguraduhing panoorin ang aming Programming ng Yii2 Series (Envato Tuts+).

Related Links

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.