От скоро правя един сайт на колега от форума за Обяви - Laravel stack - от 0. Админ панела е MIT html template, фронт енда също. В началото изглежда просто - няколко контролера, модела, админ контролери с друг неймспейс, 5-6 вюта ( идентични) и това е. Да ама на пръв поглед изглежда много просто, но като се замислиш, сайта е завършен на 90%, но -> просто просто, колко да е просто, едни обяви нали...
Моделите по мои сметки бяха 5-7. Да ама, нали на потребителя трябва да е удобно. Да има състояния, тип доставки, ТИП на обявата , dashboard panel, статус активни / неактивни, редакции, качвания на изображения, оферти , лични съобщения, области, любими обяви, и разни други неща. Та, от 5-7 контролера, накрая излязоха ей толкова. Също толкова има и в \Admin
И моделите
Действаш по HTML темплейта, който е предоставен, изглежда окей, казваш си не е много работа, ще режеш разни елементи, ще нагласяш - те елементите си ги има в демото на темплейта, няма да има ядове. Да ама не - вмомента в който почнеш да режеш сайта на components/ views и нещата винаги се омазват някъде -> дали някой div.row, дали някой контейнер, дали нещо друго стои на грешно място -> изключително не си прецених времето, за колко време ще се оправя с view-тата.
Та пак бях преценил, че 5-8 вюта, които са идентични ще бъдат достатъчни. Е, нещата изглеждат така:
И тук не броим админ вютата, които са малко повече, защото всички имат редакция.
Доста са идентични някои, защото рендерират обяви, обаче пък трябва да има SEO, трябва да минеш по тези страници и да рендерираш някакви данни по мета в хедъра.
Преживявам го някак, бая писане падна да се нагласят нещата в що годе приличен вид. В един момент обаче се замисляш, че ти трябват Middleware-и и то не само isAdminMiddleware и isAuth middleware. По security reasons -> Дали потребителя може да редактира дадена обява, дали може да чете съобщението, дали може да праща оферта, дали офертата е приключила и т.н. и т.н... Сложете още 5-7 middleware, които ги закачаш по рутовете. Че иначе ще е резил някой да намери такъв пропуск в сигурността - сменяш id-то на съобщението и на юзера и четеш друго съобщение.. Not Gonna Happen buddy. Та към писането добавяме и няколко middleware от тоя род
Рутинга и web.php файла, отговарящ за адресите. Админ рутинга е лесен, понеже се възползваш от готиния ларавел, и можеш да си действаш с Grouped Routes by middleware и да ползваш ресурс контролери.
Хубаво де, ама при Front end routes не можеш да ползваш ресурс контролери на повечето места, защото адресите са специфични, има custom неща при имената, пък и потребителя не му трябва да редактира повечето неща във фронт енда.
Та рутинга от 20-тина преценени за фронт енда, стана около 40 , с различните GET/POST/PUT/ и т.н..
Прибавяме разни валидации, custom message components, дали нещо е успешно, дали не е, качване на файлове, оправяне на директории, триене на файлове след като нещо се изтрие и т.н... Добавете още време. Като се добави и няколко бъга, които ти отнемат време да ги откриеш, или неща, които се чудиш как ще стане -> за справка личните съобщения бяха най-голямата мъка. Лесна работа нали, модел Message, и модел Conversation, message пази съобщението и conversation_id, пък Conversation пази sender_id, receiver_id -> хубаво, написах го, само че какво се получава -> потребителя натиска на съобщение, изпраща го, онзи го получава, дотук всичко работи, само че вмомента в който натисне втори път на съобщение до дадения потребител -> създава нов Conversation.
Колко му е една проверка нали, е ето колко:
И това е що годе the Laravel Eloquent Way, без raw DB:Query
Друго, което отне бая време -> разни проверки по views -> дали потребителя е логнат, ако е логнат еди какво си, ако не е друго, дали може да изпраща оферта до себе си, дали може да рипортва собствена обява и т.н.. И понеже нещата в един момент стават големи, колкото и да се мъчиш да ги опроставяш и да разделяш по компоненти -> грешки винаги има, трябва да обикаляш по файловете и да преглеждаш за разни малко проблемчета -> пък дали нещо има релация, дали няма, дали потребителя има добавени обяви в любими, ако няма да не гърми сайта, и т.н.. и т.н...
Та на пръв поглед едно лесно проектче, може да отнеме бая време, бях преценил нещата за седмица, две, пък мина около месец. Lesson learned. Спазваш конвенции, гледаш имената да са на английски, променливите евентуално ще ги чете друг човек, пак да са адекватни, да има коментари тук там ако кода не е self explaining и т.н..
Моделите по мои сметки бяха 5-7. Да ама, нали на потребителя трябва да е удобно. Да има състояния, тип доставки, ТИП на обявата , dashboard panel, статус активни / неактивни, редакции, качвания на изображения, оферти , лични съобщения, области, любими обяви, и разни други неща. Та, от 5-7 контролера, накрая излязоха ей толкова. Също толкова има и в \Admin
И моделите
Действаш по HTML темплейта, който е предоставен, изглежда окей, казваш си не е много работа, ще режеш разни елементи, ще нагласяш - те елементите си ги има в демото на темплейта, няма да има ядове. Да ама не - вмомента в който почнеш да режеш сайта на components/ views и нещата винаги се омазват някъде -> дали някой div.row, дали някой контейнер, дали нещо друго стои на грешно място -> изключително не си прецених времето, за колко време ще се оправя с view-тата.
Та пак бях преценил, че 5-8 вюта, които са идентични ще бъдат достатъчни. Е, нещата изглеждат така:
И тук не броим админ вютата, които са малко повече, защото всички имат редакция.
Доста са идентични някои, защото рендерират обяви, обаче пък трябва да има SEO, трябва да минеш по тези страници и да рендерираш някакви данни по мета в хедъра.
Преживявам го някак, бая писане падна да се нагласят нещата в що годе приличен вид. В един момент обаче се замисляш, че ти трябват Middleware-и и то не само isAdminMiddleware и isAuth middleware. По security reasons -> Дали потребителя може да редактира дадена обява, дали може да чете съобщението, дали може да праща оферта, дали офертата е приключила и т.н. и т.н... Сложете още 5-7 middleware, които ги закачаш по рутовете. Че иначе ще е резил някой да намери такъв пропуск в сигурността - сменяш id-то на съобщението и на юзера и четеш друго съобщение.. Not Gonna Happen buddy. Та към писането добавяме и няколко middleware от тоя род
Рутинга и web.php файла, отговарящ за адресите. Админ рутинга е лесен, понеже се възползваш от готиния ларавел, и можеш да си действаш с Grouped Routes by middleware и да ползваш ресурс контролери.
Хубаво де, ама при Front end routes не можеш да ползваш ресурс контролери на повечето места, защото адресите са специфични, има custom неща при имената, пък и потребителя не му трябва да редактира повечето неща във фронт енда.
Та рутинга от 20-тина преценени за фронт енда, стана около 40 , с различните GET/POST/PUT/ и т.н..
Прибавяме разни валидации, custom message components, дали нещо е успешно, дали не е, качване на файлове, оправяне на директории, триене на файлове след като нещо се изтрие и т.н... Добавете още време. Като се добави и няколко бъга, които ти отнемат време да ги откриеш, или неща, които се чудиш как ще стане -> за справка личните съобщения бяха най-голямата мъка. Лесна работа нали, модел Message, и модел Conversation, message пази съобщението и conversation_id, пък Conversation пази sender_id, receiver_id -> хубаво, написах го, само че какво се получава -> потребителя натиска на съобщение, изпраща го, онзи го получава, дотук всичко работи, само че вмомента в който натисне втори път на съобщение до дадения потребител -> създава нов Conversation.
Колко му е една проверка нали, е ето колко:
И това е що годе the Laravel Eloquent Way, без raw DB:Query
Друго, което отне бая време -> разни проверки по views -> дали потребителя е логнат, ако е логнат еди какво си, ако не е друго, дали може да изпраща оферта до себе си, дали може да рипортва собствена обява и т.н.. И понеже нещата в един момент стават големи, колкото и да се мъчиш да ги опроставяш и да разделяш по компоненти -> грешки винаги има, трябва да обикаляш по файловете и да преглеждаш за разни малко проблемчета -> пък дали нещо има релация, дали няма, дали потребителя има добавени обяви в любими, ако няма да не гърми сайта, и т.н.. и т.н...
Та на пръв поглед едно лесно проектче, може да отнеме бая време, бях преценил нещата за седмица, две, пък мина около месец. Lesson learned. Спазваш конвенции, гледаш имената да са на английски, променливите евентуално ще ги чете друг човек, пак да са адекватни, да има коментари тук там ако кода не е self explaining и т.н..
Последно редактирано:
