alexprey:

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

http://screenshot.su/show.php?img=95deba2c2cb7997453428987a615ac...

думаю в игре мой ник будет так же отображаться

Это не беда. Одна строчка исправит подобное. С другой стороны защита от XSS-школоты есть, этого пока хватит.
Сейчас быстро напишу фильтры белого списка и тогда ты просто не сможешь иметь ник вроде <h1>User 3</h1>)
На самом деле тут и вправду моя оплошность. Подобная защита от XSS должна быть не на логине пользователя)

P.S. Как исправлю - юзерам, имеющим подобные ники придётся перерегистрироваться(

alexprey:

ZLOI_DED, нет про игру

Если про саму игру, то сервер встроенный. Запускается параметром -server, можно указать порт и так далее...
Пока можно зайти с клиента, используя логин и пароль. Сервер об этом пинганёт и больше ничего. Общего мира нет, даже игроков пока не сохраняет. Здесь сыро. Над ним почти не работал.

Если про сервер обновления и сбора статистики, то у меня есть подобная наработка, поэтому дня за четыре управлюсь с ним и с лаунчером...

alexprey:

ZLOI_DED, а как дела с сервером?

Ты про что? Про железо?

alexprey:

ZLOI_DED, изменение сложнее, разве нет?

Чисто теоритически, в первом случае тебе придётся проходить обе фазы. Тут я не могу говорить со 100%ной уверенностью. Но мне всё же кажется, что первый способ гораздо более муторен. Потом с ORM не все могут работать, а SQL - стандарт для веба. Внутренний SQL просто не будет иметь разных тонкостей (хотя для кого-то тонкостью будет отсутствие этих тонкостей :D). Как пример можно просто будет взять синтаксис MySQL и для этой СУБД вообще ничего не переводить... Хотя я пока до этого не добрался, поэтому время придёт - увидим...)

В любом случае. Сейчас пласт работ с сайтом я успешно с себя сбросил и теперь занимаюсь лаунчером.

alexprey:

ZLOI_DED:

А в моём случае этого транслейта нет и соответственно нет трудностей.

с чего это вдруг нету? синтаксис же разный у разных баз

Нет перевода Объект -> SQL и обратно. Есть перевод Internal SQL -> SQL и обратно. Объект и внутренний SQL совсем по разному переводятся. В первом случае нужно генерировать, а во втором - изменять.

alexprey:

ZLOI_DED:

Не надо ORM

а разве это не позволяет сделать то что ты хочешь?

Позволяет, но сложность ORM в транслейте объектов в SQL, что вызывает кучу трудностей со всякими JOIN'ами и прочим. А в моём случае этого транслейта нет и соответственно нет трудностей.

alexprey:

ZLOI_DED:

Ну а как иначе? Всеравно какие-то интерфейсы они должны иметь. Чтобы помещать товары в корзину, товары должны как-то обозначатся и юзеры, к которым в корзину товар этот помещается тоже... Тут у меня затык.

просто сделай зависимости, пускай модуль говорит что ему нужно, например для корзины UserModule, ProductModule. Вот и все. Если их нету, то крашай модуль.
ZLOI_DED:

Просто никогда не делай) Если хочешь сервер для чата? То спроси себя зачем тебе сервер для чата? Ведь он спокойно делается дедовским методом на аяксе.

медленно и грузит сервер.
ZLOI_DED:

И да. В будущем хочу привинтить к своей cms многосубдшность, и сделать db-layer, с драйверами и SQL-подязыком по типу DQL.

на самом деле это не шибко то и надо, но лучше стоит поискать готовые решения, ибо SQL очень тонкий язык, особенно у Oracle DB

То бишь в настройках модуля поля, требующие определённого типа данных, которые должен возвращать компонент другого модуля? Этот вариант действительно сработает, но только если тип статичен. То есть например у товара именно int id а не varchar и прочее..
А. Я кажись понял. Ты имел ввиду зависимости от конкретных модулей. Понимаешь, суть в том, чтобы модули были независимыми друг от друга. Разные имплементации - есть хорошо. Главное корзине - получить конкретные данные. А на то как они получены - насрать. Пусть ты их введёшь прямо в поле в настройках...

Тогда действительно отдельный сервер на яве или шарпе

Ну смотри. Внутренний язык запросов драйверами преобразуется в тот. который подойдёт конкретной СУБД со всеми тонкостями. По-моему это классная идея. Не надо ORM, просто дрова на разные СУБД и внутренний язык. Да, будет медленнее, но быстрее чем с ORM и покруче чем с тем, что есть) Вот такой блекджек)

Спасибо. Приятно общаться со знающим человеком)

alexprey:

ZLOI_DED:

Да. Конечно. Это же динамичный парсинг. В этот раз это вернёт true, в другой - false.

не обязательно компилировать в статичный текст ;) компилируй в чистый php
ZLOI_DED:

никогда не делай сервер на PHP, который например работает через php-cli.

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

Аа.. понял твою мысль. Ок. Попробую это реализовать.

Просто никогда не делай) Если хочешь сервер для чата? То спроси себя зачем тебе сервер для чата? Ведь он спокойно делается дедовским методом на аяксе. Я тоже пишу серьёзные не на php. Java.

Хаха)) Именно)

И да. В будущем хочу привинтить к своей cms многосубдшность, и сделать db-layer, с драйверами и SQL-подязыком по типу DQL.

alexprey:

Ага. Попробую решить в скором времени.

Ну а как иначе? Всеравно какие-то интерфейсы они должны иметь. Чтобы помещать товары в корзину, товары должны как-то обозначатся и юзеры, к которым в корзину товар этот помещается тоже... Тут у меня затык.

Понял. Ну смотри. Всё статично, так как зачем здесь динамичность?

Да. Конечно. Это же динамичный парсинг. В этот раз это вернёт true, в другой - false.

Так и создаю. Создаю модуль регистрации, делаю контроллер. модель. делаю шаблон, страницу регистрации. Готово.

Хех. Вот тут ты понимаешь, что без фунта 160 градусного саке это не поднять)

Да. Кстати. Раз уж всеравно заоффтопились - никогда не делай сервер на PHP, который например работает через php-cli. Это такой убогий кусок говна, что не просто потратишь время, а ещё будешь целый месяц хромать на полмозга)

alexprey:
Хмм... можно. Тогда придётся припилить ограничение по айпи по времени, чтобы не спамили.
Не знаю. У меня помечено... Вообщем посмотрю.

Так тут соль пораундово генерируется... здесь специально замедленная криптота.

В цмсине её нет... это модуль. А так, админа создаём через инсталлятор.

Про DI и IoC читал, когда яву изучать начал. Как раз чисто идеологически, здесь огромная беда. Сам подумай. Как ты хочешь делать корзину для интернет-магазина, когда она зависит от двух разных вещей? 1) система юзеров 2) система товаров

Всмысле некомпилируемый? Если конструкция некомпилится - он выдаст ошибку. Если написал где-то неправильно - увидишь, что всё неправильно. Смотри. Шаблонизатор довольно необычный у меня. Он по сути не разделяет всё по шаблонам, а формирует страницу, используя компоненты модулей, которые вызываются в конструкциях шаблона (страницы). То есть идёт от обратного. Мне эта идея приглянулась. Сам подумай. Если пользователю системы не даётся пхп, ему не обязательно его знать. Главное поставить нужные модули и всё. Пишешь страницы, используя конструкции и радуешься. По времени выходит очень щадяще. Если глянуть на вп, то это просто турбо-быстрая cms)

Если нужна помощь будет - обращайтесь)

Всмысле статично?

alexprey:

ZLOI_DED:

Сайт рабочий, а вот ты просто слепой. На главной специально сказано для таких как ты: "Хотим обратить внимание, что сайт всё ещё находится в разработке."

Да мне лишь бы только потыкать было куда. Да и зачем тогда тяп ляп и в продакшен? Мой вот до сих пор только локально гуляет и немного на альфе.
А так код посмотрел. Ну в целом, ладно не плохо, но шаблонизатор скучный, так же как и роутинг, да и от mvc ты немного местами отъехал. Ну и еще пару советов:

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

---

• Защита от XSS хитра, но в тоже время стара и может привести к непредвиденным последствиям, знай это
• твой криптоалгоритм не надежный, есть более надежные и простые способы

Ясно. Потому что фанаты требуют игру, а без сайта дальше делать не могу. Покажешь потом?
Знаю что отъехал. Знаю почему. Но сейчас просто нет времени всё это исправлять. Знаю что реализация модульности - фигня. Но это нужно сидеть и минимум месяц синим, чтобы продумать лучший способ, интерфейс для связи любых модулей.

Бутстрап пробовал. Хочу поддержать отечественного производителя ;) И да. Бутстрап требует JQuery.
Всмысле проверку при обычном входе?
Ок
Где?

Ок. Спасибо)
Ок. Можешь посоветовать что-нибудь?
Буду знать)

Вот это хороший ответ) Спасибо. Вот от такого диалога только позитив)

alexprey:

ZLOI_DED:

Хватит пытаться показать свой ум, <h1>User3</h1>

классическая проверка _/O\_

---

лол, а сайт то нифига не рабочий. Половина ссылок либо битые, либо просто ничего не делают

Сайт рабочий, а вот ты просто слепой. На главной специально сказано для таких как ты: "Хотим обратить внимание, что сайт всё ещё находится в разработке."

prog:
Ну и конечно же ты имеешь полную независимость от Mojang.

Я когда ты говорил про движок, имел ввиду наддвижок, несомненно возникающий над jME.

alexprey:

ZLOI_DED:

Знания HTML - уровень школа. Звучит. Какой мой убер-сайт? Что конкретно тебе режет глаза в HTML-коде?

все режет

Хватит пытаться показать свой ум, <h1>User3</h1>

alexprey:

ZLOI_DED:

Знания HTML - уровень школа. Звучит. Какой мой убер-сайт? Что конкретно тебе режет глаза в HTML-коде?

все режет

По моему опыту. Опытные всегда подсказывают менее опытным. А те, у кого с мозгами плохо отвечают на конкретные вопросы обобщённо и невнятно, хотя всегда критикуют. А желание критиковать берётся оттого, что сами ничего не умеют и чтобы не чувствовать себя полным быдлом надо кого-то чем-то унизить. Прости, но по нашему разговору я вижу это так.

nvc123:

ZLOI_DED:

чем же утверждение про разработку собственного движка глупо?

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

Согласен. Разрабатывают движки только старпёры, которые гадят в утки.
Аа.. Понял.

prog:

ZLOI_DED, по двум причинам

1. я не фанат Space Station 13, хотя сама идея мне интересна.
2. еще не запилен официальный Plugin API, а форж меня дико раздражает своей ресурсоемкостью, да и проблемы с совместимостью версий не очень приятны, даже если забить на форж и пользоваться чистым MCP.

P.S. Обрати внимание на две вещи: во-первых моя фраза была обращена не к тебе, а во-вторых утверждение про разработку собственного движка выглядит довольно глупо, в свете того, что мне отлично известно что такое jMonkeyEngine. К чему бы это?

Ну во-первых тебе придётся досконально разобраться в чужом коде раз. Второе, чем это "не круто", так это тем, что тот функционал, который требует игра тебе на том, что есть у движка майна не сделать... значит придётся вымудряться, что как всегда не есть хорошо. И это только начало...

ZardWar:

Опять Майнкоафт.

Нет. Тут ты не прав. Это совсем не майнкрафт. Если ты считаешь Space Station 13 майнкрафтом, то ты не играл в Space Station 13.
prog:

ZardWar, кстати, а это ведь мысль - взять майнкрафт в качестве базы и не выдумывать свой движок.

Да. Офигенная идея. Почему же ты ещё не сделал, раз это так легко?

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

VI глава - Acid Trip в царство мёртвых. Приятного просмотра)