С классами можно нормально структурировать всё и изолировать код

Еще eval() не хватает, ага

С классами можно нормально структурировать всё и изолировать код

А со стурктурами, значит, нельзя?

Го++, а потом кое-какая компания подпирает костыли, делая их ++ #, и нахер такое даже даром

Учи гошку. Научишься писать на го - поймёшь, почему тут нет классов.

Го++, а потом кое-какая компания подпирает костыли, делая их ++ #, и нахер такое даже даром

Заметьте - это ваши не обоснованные догадки, мы говорили только про классы и наследование

Блин

Ну ребята

Следите за руками

"яхочучтобыкаквджаве"

Предположим, Гошка - новый си

Ну - предположим

да забаньте тролей

делов то

будет занятно, если все это добавят, ведь именно за эти вещи Го и хвалят его создатели)

Добавили классы в си - сделали ц++

тут каждый день набегают такие

ребята, когда в фасм классы завезут? я хочу структурировать код

Подперли костыли - сделали с#

@schors @onokonem спасите чат от затроллевания

да забаньте тролей

У меня банхаммера в этом чате нет

@schors @onokonem спасите чат от затроллевания

чокаво?

В го не хватает мощи у const.

чокаво?

я про тех товарищей что опять пришли топить за классы и прочее вот всякое

Переменную уровня пакета нельзя сделать readonly

Переменную уровня пакета нельзя сделать readonly

Лолшто?

я про тех товарищей что опять пришли топить за классы и прочее вот всякое

я тред просто не читал, так что лучше юзернеймы

это кирилл ща лучше скажет (ИМХО)

я тред просто не читал, так что лучше юзернеймы

но ты ж тоже без банхаммера тут, не?

но ты ж тоже без банхаммера тут, не?

с

Так, поименно, кого?

const могут быть только строки, инты, а структуры, интерфейсы, мапы и слайсы - нет

Так, поименно, кого?

Arch кажется

но ты ж тоже без банхаммера тут, не?

Тут полчата с банхаммером, мне тут исторически не хотят давать инструменты диктатуры

майк вроде опять

Когда го 2 выйдет?

/voteban

Тут полчата с банхаммером, мне тут исторически не хотят давать инструменты диктатуры

и создатель заходит примерно никогда)

Обоим сутки ro прописал

С классами можно нормально структурировать всё и изолировать код

[2]

Меня то за что

Тут полчата с банхаммером, мне тут исторически не хотят давать инструменты диктатуры

да и всего 7 человек с банхаммерами)

[2]

он вроде просто сказал про классы когда уже срач начался

Я тут бытом занят, но всегда готов

Пишите только, кого прибить

я тоже работу работаю обычно, но можно пинговать)

потом сервис для управлением терминацией звонков на freeswitch

оффтоп. freeswitch говорят хорошая штука?

Да, только документации по нему нет, все приходится методом тыка разбираться. Я даже книгу покупал, т.к. в интернете нет информации, что в ней. Все по крупинкам надо выковыривать

Могу скинуть книгу, если нужно

Могу скинуть книгу, если нужно

да я бы почитал. это вообще не мой профиль, но давно хочу свою АТСку сделать… для внутреннего пользования. и очень не хочу брать asterisk

Сип и интернет-телефония - это такой адок, я бы добровольно не связывался)

ну я из интереса. будет больно - брошу

Коллеги, я - новичёк в Go. Тупой вопрос. Кто-то работал с GORM+Gin? Проблема такая: Добавил BeforeSaveCallback на обновление\создание юзверей. В нём получаю хэш пароля и сохраняю в базёнку (Postgres). Проблема в том, что на метод UpdateUserHandler( хандлер Gin) сваливаются JSON не со всеми полями структуры User. Иногда пароль приходит, иногда нет. Суть проблемы в том, что из-за коллбэка Пароль у юзеров постоянно обновляется, т.к. в нём(коллбэке) не стоит проверки на previous данные. Вопрос, как после BindJSON(&user) в хандлере Gin'a или в коллбеке получить прошлую версию структуры? Хочется что-то типа ActiveModel::Dirty в Rails

Может кто-то помочь?

Не используй колбеки, сразу говорю

если тебе нужен апдейт сущности, получай поля, которые надо изменить и вручную их меняй

Я использую горм, но чисто как билдер запроса и байндер результата в структуру, все остальное - зло

если тебе нужен апдейт сущности, получай поля, которые надо изменить и вручную их меняй

А как быть если мы хотим сделать апдейт записи через json, в которой уже есть пароль md5, но в json пароль не передаем и он делает md5 от md5, потом что используем gin.Context.BindJson(модель), и не можем ручками вычленить аттрибут json?

Спасибо за ответ. Я, конечно, склонялся к такому, но как-то не кошерно получается. Я понимаю, что технологию новая, но всё же. Про коллбеки - согласен, но не хотел писать логику моделей в хандлерах. Может мне надо перестать думать как ООП'шник? ?

Дмитрий ну вынеси всю логику в какой-то UserService, получается, что ты размазываешь логику работы с данными и непонятно где, когда, куда и почему-то что-то приходит и куда девается.

Ещё более глупый вопрос ? А если таких полей штук 40? По каким-либо историческим причинам? Что ты тогда предпринимать будешь? Тоже руками? Или какая-то БиблиотекаПолезныхУтилит есть в Go?

ERROR: S client not available

Про то, как мд5 от мд5 берется - я тут вообще не въехал, честно

Дмитрий ну вынеси всю логику в какой-то UserService, получается, что ты размазываешь логику работы с данными и непонятно где, когда, куда и почему-то что-то приходит и куда девается.

Это я уже осознал и сделал

Про то, как мд5 от мд5 берется - я тут вообще не въехал, честно

Наверное проще код будет показать, если удобно

Да, сейчас покажем)

func (h *Handler) UpdateUser(c *gin.Context) { var err error id, err := strconv.Atoi(c.Param("id")) if err != nil { c.JSON(http.StatusBadRequest, gin.H{"status": http.StatusBadRequest, "error": err.Error()}) return } user, err := h.UserService.User(id) if err != nil { c.JSON(http.StatusBadRequest, gin.H{"status": http.StatusBadRequest, "error": err.Error()}) return } if err := c.BindJSON(&user); err != nil { c.JSON(http.StatusBadRequest, gin.H{"status": http.StatusBadRequest, "error": err.Error()}) return } err = h.UserService.SaveUser(user) if err != nil { c.JSON(http.StatusBadRequest, gin.H{"status": http.StatusBadRequest, "error": err.Error()}) return } c.JSON(http.StatusOK, gin.H{"status": http.StatusOK, "data": user}) }

Это Хандлер, наверное лучше ссылкой отправить, нежели тут?)

Дмитрий , вообще практика показывает, что пытаться создавать универсальные модели для базы данных, запросов и ответов - плохая затея. Потому, что быстро выясняется, что для фронта какие-то поля нельзя отдавать, при обновлении надо над другими полями какие-то манипуляции проводить

А вот и наша модель с коллбеком

type User struct { gorm.Model State string `json:"state" sql:"DEFAULT:'not_activated'"` Email string `valid:"required" json:"email"` Password string `json:"password"` PhoneNumber string `valid:"required" json:"phonenumber"` LimitDate time.Time `json:"limitdate"` Comment string `json:"comment"` Role string `json:"role" sql:"DEFAULT:'specialist'"` CompanyID uint `json:"companyID"` } func (user *User) BeforeSave(scope *gorm.Scope) (err error) { if pw, err := bcrypt.GenerateFromPassword([]byte(user.Password), 0); err == nil { scope.SetColumn("password", string(pw)) } return }

@mykytanikitenko Согласен, но, как я сказал, я в этой технологии - новичёк) Я привык на Rails создавать кучу абстракций, вот и сюда попытылся перенести это мышление

создаете структуру UpdateUserRequest, в которой есть только поля, которые приходят с фронтенда, к ней и байндите жсон

создаете структуру UpdateUserRequest, в которой есть только поля, которые приходят с фронтенда, к ней и байндите жсон

func (h *Handler) UpdateUser(c *gin.Context) { var err error dirtyUser := models.User{} id, err := strconv.Atoi(c.Param("id")) if err != nil { c.JSON(http.StatusBadRequest, gin.H{"status": http.StatusBadRequest, "error": err.Error()}) return } user, err := h.UserService.User(id) if err != nil { c.JSON(http.StatusBadRequest, gin.H{"status": http.StatusBadRequest, "error": err.Error()}) return } if err := c.BindJSON(&user); err != nil { c.JSON(http.StatusBadRequest, gin.H{"status": http.StatusBadRequest, "error": err.Error()}) return } c.BindJSON(&dirtyUser) if dirtyUser.Password != "" { user.Password = h.UserService.GetMD5Hash(dirtyUser.Password) } err = h.UserService.SaveUser(user) if err != nil { c.JSON(http.StatusBadRequest, gin.H{"status": http.StatusBadRequest, "error": err.Error()}) return } c.JSON(http.StatusOK, gin.H{"status": http.StatusOK, "data": user}) }

Повторюсь, а что делать, если вдруг таких полей будет ну очень много?

Понятно, что это не очень хорошо, но мой опыт говорит, что такое возможно, что ты делаешь в таком случае?

Дело в том, что вы вручную вытаскиваете параметры, парсите их в инт - это дичь, честно

Вот так выглядит контроллер с большим количеством параметров у меня

https://pastebin.com/zj7qdqXD

Пришлось накостылять целый мвц-фреймворк, который получает параметры, байндит их к структуре, потом из контроллера дерает нужные методы, потом байндит результат из бд к вью-модели

Круть, в опенсурс планируешь выкидывать?

Да там сильно завязано на моем проекте, выносить его как отдельную либо напряжно, не говоря уже о том, что делалось на скорую руку и надо бы порефакторить

Ну ладно( Если не сложно, можешь хоть немного приподнять занавес архитектуры твоего костыля? Реально, ведь, интересно! Выглядит как декларативный синтаксис более-менее.

Ну там внутри тонна кода на рефлексии)

В качестве хттп-сервера я использую labstack/echo, но нигде в коде с контроллером напрямую к контексту хендлера не обращаюсь

создаете структуру UpdateUserRequest, в которой есть только поля, которые приходят с фронтенда, к ней и байндите жсон

вы в таких случаях обычно структуру где определяете внутри хэндлера анонимную, или держите какой нить models.go ?

лучше, конечно, публичную структуру, мне кажется

ну я и такие и такие юзаю… и пока не пришел к тому что какой то из подходов лучше. где то удобнее публичную, а где то наоборот лучше анонимную чтобы код не захламлять

вот и хотел услышать доводы какие нибудь за/против

Ну надо смотреть конкретно в код. Должно быть понятно, откуда данные берутся в какой-то структуре и куда они деваются, чтобы сохранялась линейность логики обработки данных. Это то, почему я сразу против коллбеков\хуков в горме.

оффтоп. freeswitch говорят хорошая штука?

под него на Go писать можно https://github.com/fiorix/go-eventsocket

Ну надо смотреть конкретно в код. Должно быть понятно, откуда данные берутся в какой-то структуре и куда они деваются, чтобы сохранялась линейность логики обработки данных. Это то, почему я сразу против коллбеков\хуков в горме.

ну я вообще reform юзаю

@rostel именно этой либой