не мешает

но хочется красиво :)

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

я ебаный перфекционист

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

та какой в пень оверинжинирингш

ничто не мешает после получения рабчего класса EppClient это всё отрефакторить, потому что будет понятно где что неудобно

у меня уже раскидано по методам конект, логин/логофф, работа с доменами/контактами и т.п

но оно блин без классов

в которых я хуево разбираюст

в процессе написания этого гема с этим разобраться,

а нахерачить все говно в кучу я мог еще час назад

и, опять же, нужен ли тебе сразу гем?

да

как кусок другого проекта

что мешает для начала закинуть класс в файл и его require'рить?

еще раз. гнету классов у меня. методы одни

я хочу это все собрать красиво в классы

но я ооп плаваю

ещё раз: кинь все методы в новый класс, чтобы оно работало, а потом правь места где неудобно

красиво — это когда приятная api'шка которой можно беспроблемно пользоваться

блядь. еще раз говорю - у меня три разные сущности

с одинаковыми методами

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

а ты мне рекомендуешь нахерачить какой-то индусокод

ох

я блин пришел учиться и за советом

а говнокодить это кудато на битрикс с php

не наговнокодишь - не научишься

блядь. НЕ ХОЧУ Я ЕБУЧИЙ ГОВНОКОД

Есть даже книжка про это

ПИШИ КОД, БЛЯ

ок, делай сразу красиво

блядь.

я и спрашиваю КУАК

последние 15 минут

потому что плаваю в ООП

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

API к ООП отношения не имеет абсолютно. Если ты распишешь какие методы и как ты хочешь вызывать — тогда будет понятно что тебе сказать.

но вот чтобы client.DomainNew(blabla)

я если честно не понимаю что тут хочешь сделать.

самое простое — создать класс с одинаковыми методами и от него отнаследовать твои сущности

client = EPP::Client.new(host/port) client.domain_check(domainname) { self.login(login/pass) -> {open socket, read, send, read} self.check(domainname) ->{open socket, read, send, read} self.logount -> {open socket, read, send, read} }

вот уже ближе к помощи )

модули тебе здесь нафиг не нужны

а про модули я не говорил

я говорил что это гемный модуль

точне даже не говорил

EPP::Client — класс Client модуля EPP

(ну и не стоит upcase'ом что-либо называть, если это не константа)

тоесть client = Epp::Client.new... а тогда Epp::Domain это будет совсем другая херня

и значит мне таки надо делать Client.check_comain

login/logout в API'шке тебе точно нужны? Почему не login/logout при каждом запросе?

логин/логофф при каждом запросе методами

невидимо для апи

внутри метода check_domain

ок

как и поднять/положить сокет

ну то есть как-то так? https://gist.github.com/ojab/1b7a178fb8e5b28e87ae9ea7699d6841

для начала

или всё же .check_domain у EppClient'a?

(опять же, рекомендую .check_domain, если будет неудобно — потом можно отрефакторить)

а как будет вызываться domain.check если взять за основу гист?

Domain.new(login, password, whatever).check

ойбля )

соответственно можно сделать Domain.new и потом его юзать для всяких манипуляций

не, лучше client.check_domain, тоесть все будет в пространстве клиента ерр

а если Epp::Client::Domain.check?

ERROR: S client not available

а где ты логинопароль собрался указывать?

и, опять же, :: — модуль

короче, как я понял мне надо сделать в классе Client require 'lib/connect.rb' где в нутри классе Client прописать мои методы коннекта , lib/login где логин/логофф и дальше мои файлы для домена/хоста/контакта

так?

тоесть текущие методы просто обернуть в class Client чтобы они собрались в один класс при компиляции, так?

зачем их вообще на файлы разбивать?

потому что блеать их ДОХУЯ

lib с текущими скриптами 18 килобайт текста

скрипт который их дергает еще несколько десятков

o_o

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

тоесть я в check_domain() смогу заюзать методы login из EPP::Connection ?

зачем их вообще на файлы разбивать?

если 3 сущности с одинаковыми методами, то ведь можно засунуть эти одинаковые методы в модуль и инклюдить его в классы?

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

https://gist.github.com/ojab/1b7a178fb8e5b28e87ae9ea7699d6841

если 3 сущности с одинаковыми методами, то ведь можно засунуть эти одинаковые методы в модуль и инклюдить его в классы?

но сущность же одна

вечер добрый, такой вопрос: подглядел на стэковерфлоу, что если создать темплейт (internet_access.html.erb) в папке лэйаутс , то это станет лейаутом для всех вьюх в папке internet access но на самом деле, он стал лейаутом на всех страницах как сделать так, чтобы этот темплейт был лейаутом только для вьюх из папки internet_access? скрин прилагаю

но сущность же одна

николай писал что 3 сущности

николай писал что 3 сущности

но мы же уже разобрались что одна, а не три

не, лучше client.check_domain, тоесть все будет в пространстве клиента ерр

понял, но в принципе так ведь делается?

николай писал что 3 сущности

методы одни и те же. а вот свойсвта у контакта, домена и хоста отличаются

вечер добрый, такой вопрос: подглядел на стэковерфлоу, что если создать темплейт (internet_access.html.erb) в папке лэйаутс , то это станет лейаутом для всех вьюх в папке internet access но на самом деле, он стал лейаутом на всех страницах как сделать так, чтобы этот темплейт был лейаутом только для вьюх из папки internet_access? скрин прилагаю

guides.rubyonrails.org/layouts_and_rendering.html -> 2.2.13 Finding Layouts

но вот так заинклюдить весь набор методов по модулям это хорошее решение

откуда у тебя столько кода получилось, непонятно

откуда у тебя столько кода получилось, непонятно

это XML ^)

распарсить ответ через нокогири и сформировать хеш

я гем допишу - выложу :)

спасибо, снов

а по поводу переменных класса - их советуют не использовать только из-за возможности подклассов менять эту переменную?

А у них есть какие-то реальные юзкейсы?

просто хранить в каждом экземпляре класса одинаковую переменную это как то странно