Здравствуйте, гость ( Вход | Регистрация )

Свернуть

Новости

Форум Лучшее из галереи Уроки и статьи
07.12.2015 Выставочный зал: кошарик - персональная выставка
31.08.2015 Интересные ссылки для рисовальщиков
21.01.2015 Выставочный зал 2: Игрушки Олеси Гавриленко

27.12.2014 Выставочный зал: кошарик - персональная выставка
17.11.2014 Дуэль "Рыбки" - победитель Лисичка
05.11.2014 Конкурс иллюстраций "Снежная королева", до 31 января
30.10.2014 Дуэль "Рыбки" до 16 ноября
14.07.2014 Мастер-класс Мини-мишка в технике фелтинга
26.05.2013 Ау! Мы ищем таланты! – приглашаем модераторов!
tritonchiky.gif
tn_gallery_13577_860_101706.gif

06.01.2016 Виртуальный Музей: Русский живописец Василий Дмитриевич Поленов
28.12.2015 Виртуальный Музей: Нидерландский живописец Квентин Массейс
16.12.2015 Виртуальный Музей: Итальянский живописец Франче́ско Айец
17.11.2015 Виртуальный Музей: Луи Анкетен (Louis Anquetin)
11.11.2015 Виртуальный Музей: Русский живописец Алексей Иванович Корзухин
Файловый архив
06.09.2013 Прочее: Файлы к уроку "Чайная церемония"
05.09.2013 Журнал Art Tower: ArtTower Magazine #8
16.05.2013 Adobe Photoshop: Кисти: Reid Southen brush
16.05.2013 Adobe Photoshop: Кисти: Goro Fujita brush
16.05.2013 Adobe Photoshop: Кисти: Кисти для рисования в Photoshop
Блоги Новости в цифровом мире и мире дизайна
02.12.2014 Дама с каменьями: Вести с крыши 2
08.11.2014 Timenews: Вассерман: прежняя модель мировой экономики исчерпала себя
06.11.2014 Дама с каменьями: Приятные вести с крыши))) от Гаргула)
02.11.2014 Spell: Книги Дж. Кэмерон
22.10.2014 Vjaz: от ФУ до МА
25.11.2015 Комментарий от Foxx в Costa Rica Adventure Divers, Логотип для компании и рисунок на майку (maria_mer)
18.11.2015 Комментарий от maria_mer в Spellforce - майка, для фанов игры (maria_mer)
18.11.2015 Комментарий от maria_mer в Белая книга. Целитель - любительский прект (maria_mer)
09.04.2015 Комментарий от Romana в Книги Дж. Кэмерон (Spell)
08.04.2015 Комментарий от Romana в Я решил вернуться... (Элбирет)
16.03.2015 ФОТОФОРУМ-2015
01.01.2015 ARQUTE.com и ArtTalk.ru закрываются
19.01.2017 Конкурс дизайна логотипов
26.12.2016 ру/Ководство: О творческом развитии
14.10.2016 ру/Ководство: Разнообразие

 
Добавить ответ в эту темуОткрыть тему
> Введение в AS3 - часть 1, Общие понятия языка AS3
V
Des
сообщение 18.04.2009 - 08:01
Сообщение #1


тритониус
****

Звезда писателя I степениЗа вклад в развитие ArtTower.ru
Группа: Почетные граждане
Сообщений: 728
Регистрация: 9.12.2007
Из: Москва \ Питер
Пользователь №: 6553
дышу под водой
Галерея Блог


Симпатии:  68  


Предполагается, что читатель знаком как с общими понятиями программирования, такими, как программа, алгоритм, переменная, , константа, цикл, конструкции IF (...) THEN {...} ELSE {...}, арифметические операторы, булевское выражение, массив, функция, событие, обработчик события и др., так и с Action Script 2.

Тем, кто не чувствует себя готовым к изучению серьезного объектно-ориентированного языка программирования, порекомендую начать отсюда

Этот урок - обзорный. В нем описан концептуальный подход к программированию, который я полагаю оптимальным для программирования на Action Script 3, а также описаны основные отличия этой версии языка. Из практически необходимых вещей - понятие о программировании "на объектах".


1. Объекты, объекты, объекты.

Концепция Объектно-Ориентированного Программирования, самая прогрессивная из существующих, позволяет описать практически всё, что вообще можно описать словами. Если вы можете что-либо (явление, действие, сущность, объект, взаимодействие объектов и даже какой-нибудь вид хаоса) описать на естественном языке, нарисовать, представить - значит, вы можете описать это программно "на объектах". Это не значит, что ваш код будет работать. Вы можете допустить ошибку, компьютеру может не хватить производительности, или то, что вы решили описать-запрограммировать, слишком сложно и на описание его не хватит никакого разумного времени, или, наконец, вы можете описать объект так, что ваше описание действительно будет ему соответствовать, но будет напрочь неоптимально - ведь каждая задача допускает как минимум три решения, из которых правильно пятое... Но: если вы что-то можете описать хотя бы алгоритмически, т.е. еще не касаясь вопросов реализации на конкретном языке программирования - то сделано уже не пол-дела даже, а процентов 70.
В самом широком философском смысле этот факт ведёт к совершенно удивительным последствиям, но нас интересует - практика программирования.
Практически это означает, что разработку программы следует начинать с уяснения того, что мы описываем программно. А что в объектах, взаимосвязях между ними и действиях, с ними связанных, можно не описывать, поскольку - лишнее. И это, пожалуй, ключевая часть работы. После ее правильного выполнения код пишется "как по маслу" (если, конечно, вы владеете языком программирования в достаточной степени для свободного изложения своих мыслей почти без хелпа и мануала.
Итак, что же это за концепция, позволяющая описать что угодно и запрограммировать (потенциально, конечно) что угодно?
А все на самом деле весьма просто.
Есть три базовых принципа ООП. И есть реализация этих принципов на конкретном языке программирования и в конкретной вашей программе.
Вот они:
1. Объект = свойства + методы.
Любая сущность описывается абстрактным объектом (object). Объект - это набор свойств (properties) и методов (methods), описанный в классе (class) по определенным правилам - эти правила мы в дальнейшем подробно рассмотрим.
Если у нас есть класс с правильным описанием объекта, то мы можем создать его экземпляр (instance) и а) считывать и изменять значение тех его свойств, для которых это разрешено в "описании" объекта (классе) и б) вызывать (запускать на исполнение) те методы, которые "описаны" в этом классе.
На самом деле все немного сложнее, но для начального понимания этого хватит.
"Свойства", в сущности, являются набором переменных и констант, связанных с определенным объектом, а методы - набором связанных с ним функций.
Например:
Класс flash.display.MovieClip описывает обычный флэшевский ролик. Для него определено множество свойств (координаты x, y, ширина и высота width и htight, видимость visible, прозрачность alpha и др.) и методов (play(), stop(), gotoAndPlay(#) и т.п.). Кстати, для этого объекта отличия от AS2 не так уж и значительны, по крайней мере на первый-второй взгляд - только синтаксис изменился (в AS2 имена свойств начинались с "_").
Среди всех методов класса особенное место занимает метод-конструктор (constructor). Этот метод вызывается всегда при создании нового экземпляра объекта (в AS3 - оператором new). Например, когда мы создаем новый экземпляр написанного нами (т.е. - пользовательского (user)) класса MyRectangle, который создает прямоугольник с определенной шириной, высотой и определенного цвета, мы передаем ему три параметра, а конструктор класса присваивает их определенным свойствам (возможно - если мы так захотим и так опишем в классе - и недоступным "извне"):
var myRect:MyRectangle = new MyRectangle(100,75,0xFF0000);
мы можем написать класс так, чтобы наш прямоугольник сразу, при создании экземпляра, прорисовывался на сцене. Для этого нужно в конструктор класса добавить соответствующий код, который этот вывод на сцену и реализует. А можем - оставить наш прямоугольник ненарисованным до тех пор, пока не вызван метод, к примеру, drawing() , который тоже, конечно, нужно описать в классе.

Осталось сказать, что значением свойства (т.е. конкретными данными, хранящимися в том или ином свойстве) объекта может быть или значение определенного Простого Типа Данных (число, строка, булевское true/false), или... другой объект.
А об отличии и сходстве Типов Данных и Классов мы поговорим в другой раз...

2. Инкапсуляция - второй основной принцип ООП. Это странное слово означает, что если наши классы написаны правильно - то "снаружи" доступа к внутренним механизмам реализации - "внутренним" (private) свойствам и методам - нет. Нас не волнует, как именно "устроен" класс, когда мы с ним работаем - т.е. используем в программе. Реализацией класса мы занимаемся только когда и если его разрабатываем. А при использовании нашего (или готового - а AS3 поставляется с огромным количеством уже готовых классов, которые и составляют сущность этого языка) нас не волнует, да мы и не можем узнать, "что у него внутри" и как именно реализован тот или иной метод. Нам это и не нужно - нам ведь нужно только знать, как использовать этот объект, что с ним можно делать и чего нельзя. Т.е. - никакой лишней информации в голове программиста... в идеале, по крайней мере.

3. Наследование - еще один основополагающий принцип. Он означает следующее: если у нас есть класс А (например), то мы можем легко и непринужденно написать класс B, который будет являться наследником класса А, т.е.: обладать всеми свойствами и методами класса А и, может быть, в плюс к этому и своими особенными свойствами.
Классический пример - геометрические фигуры.
Напр., у нас есть (мы написали) класс my.Geom, описывающий геометрическую плоскую фигуру (свойства ее) вообще. Т.е. "забили" в него такие свойства, как площадь и периметр, не описывая свойств конкретных фигур. А в дальнейшем можем создать классы треугольника и прямоугольника, уже в них описав, как именно вычисляются эти свойства.
Если для этого простейшего примера (нередко, впрочем, используемого) вся иерархия классов представляет из себя один класс-"родитель" и двух "наследников", то в других случаях иерархии могут составлять "деревья" из десятков классов.
Наследование - не просто "ключевая идея". Она уже "вшита" в AS3 - ибо любой класс является наследником основного (базового) класса - класса Object. Кстати, у этого базового класса (естественно, уже встроенного в язык) есть и свойства, и методы, которые, естественно, будут доступны для любого объекта в AS3.
С наследованием также связан механизм интерфейсов (interfaces), который помогает разделить фазы создания программного обеспечения, а при работе в команде над одним проектом - разделить работу. Но об этом мы поговорим в другом уроке. Пока нам вполне хватит понятия об обычном наследовании.
А то, что от одного класса можно унаследовать не один, а множество классов-наследников, называется полиморфизмом - и это тоже не особенность AS3, а базовая концепция ООП.

Собственно... и все. Вот так просто... пока мы говорим о концепции. Реализация же этой концепции уже не так тривиальна. Однако усвоив основное, уже проще двигаться дальше.

2. Как ООП реализуется в Action Script 3?

В AS3, в отличие от AS2, концепция ООП использована полностью и явно. Т.е.: все, что находится и происходит в нашем флэш-ролике - описано объектами, их свойствами и методами. На каждую мелочь есть свой класс-объект, а если нет - то мы должны его написать и только потом использовать.
В этом смысле AS3 - строгий язык. Но строгость эта позволяет избавиться от многих несообразностей, путаницы и "странноостей", присущих AS2 - более гибкому на небольших проектах, но "вязкому" и неудобному при попытке создать что-то большое.

Написание программы на AS3 должно происходить следующим образом:
а. уяснение сущностей и взаимосвязей между ними
б. планирование реализации, т.е. выбор встроенных (имеющихся в языке) классов и\или описание тех, которые нужно будет написать.
В этом же пункте продумываем иерархию \ наследование классов.
в. написание нужных классов, иногда - с "заглушками" (т.е. не реализованными, "зарезервированными" методами и свойствами)
г. написание основной программы, т.е. описания на AS3 того, какие экземпляры объектов в какой момент порождаются, какие свойства используются и какие методы вызываются в какой последовательности.
д. тестирование, дописывание нереализованного кода вместе с правкой соответствующих мест основной программы.
Готовая программа получается после некоторого числа повторений пунктов в - д... в идеале - без возвращения к пунктам а и б.

"Основная программа" в AS3 реализуется как "основной класс документа". Т.е. в сущности весь основной код AS3 - это метод-конструктор "основного класса документа".
"Основной класс документа" (main document class) - это класс, который создается компилятором автоматически при генерации (компиляции) флэш-проекта и конструктор которого автоматически вызывается сразу после того, как весь ролик загружен. Очень грубая аналогия на AS2 - это код в первом фрейме сцены в ролике, который загружается с помощью прелоадера.

В первое Время принять как данность, что все - объект, не так-то просто. Зато потом наступает просветление и свобода самовыражения smile.gif
Например, сразу стоит усвоить, что не только прямоугольник, ролик, кнопка или линия - объекты, но и - запрос на соединение с сервером, с которого подгружается картинка, или эффект размытия, или свойства ролика (качество отображения, частота кадров, ...) - тоже экземпляры объектов. И даже реакцией на нажатие\отпускание клавиши мыши или загрузку ролика является объект-событие, причем его порождение, "движение" по иерархии объектов сцены и прекращение этого движения "отслеживается" другим экземпляром объекта - слушателем (EventListener).


3. Файлы, папки, пакеты.

В AS3 можно (к сожалению, IMHO) писать код "как раньше" - "в кадрах". Но я категорически не советую этого делать. Если ваш код можно без проблем написать "в кадрах" на AS3 - используйте AS2, программирование на AS3 в случае простого баннера или заставки не нужно, излишне, и вы только зря потратите Время и нервы на отладку такого кода.
AS3 нацелен на средние и крупные проекты и серьезный подход к написанию кода, AS2 в большей степени - на небольшие веб-графические работы и на новичков в программировании. Да, возможно на AS2 написать флэш-портал с видеоконференциями - но зачем? Да, можно баннер о двух картинках и трех текстах оформить кодом на AS3 - но зачем?
Оговорюсь: конечно, есть исключения. Например, когда вы используете свободно распространяемый класс на AS3 с каким-нибудь интересным эффектом. Или когда правите\дорабатываете чужой код. Или когда ваш "простенький" баннер требует особенной производительности - по оценкам самой Adobe, которые, кстати, не расходятся с моими собственными наблюдениями, AS3 \ AVM2 в 10 раз превосходит AS2 \ AVM1 по производительности, что особенно сказывается при большом количестве растровой графики и растровых эффектов и, конечно, при работе с трехмеркой на Flash.

Правильный исходный код на AS3 - это код классов, включая main document class, распределенный по пакетам (packages).
Я не буду давать формальное определение "пакета" (package), поскольку для этого пришлось бы давать такое "продвинутое" понятие, как "пространство имен" (namespace). Попробую объяснить "на пальцах": packeges - это организация исходного кода по усмотрению программиста, заключающаяся в том, что все классы (т.е., как мы помним, "описания объектов") объединяются в "категории", "подкатегории", ...
Объединение это происходит как "внешне" (распределением файлов по директориям, поддиректориям, ...), так и в самих файлах, а именно: все классы описываются в пакетах. Т.е. файл класса MyClass, который в AS2 выглядел бы как
CODE
class MyClass {
...
}


В AS3 будет выглядеть как:

CODE
package my.pack {
// ...
/*
здесь можно (и нужно)заимпортировать нужные нам классы,
чтобы в дальнейшем использовать их,
не обращаясь к ним "полным именем"
*/
// ...
public class MyClass {
}
// ...
/*
Здесь могут быть описаны "внутренние" (internal) классы пакета.
Надеюсь, что в наших уроках мы дойдем до изложения того,
что означает "внутренний" класс в отличие от "доступного извне"
(public) smile.gif
*/
// ...
}


При этом файл MyClass.as, содержащий пакет my.pack, должен лежать в подпапке "./my/pack/", считая от той директории, в которой лежит основной класс документа (main document class).
Путь же к основному классу документа указывается в свойствах документа *.fla

Например, если основной документ my.fla лежит в директории C:\Flash\, а myprogram.as - основной класс документа (основная программа - путь к классу документа указывается также в свойствах документа fla, если такой класс не найден в файлах, указанных в соответствующих полях свойств документа *.fla - ничего не выйдет, компилятор "ругнется" да и все), лежащий прямо в папке "С:\Flash\", то файл MyGallery.as, в котором в пакете gallery описан класс MyGallery, должен лежать в директории "C:\Flash\gallery\" и выглядеть как:
CODE
package gallery {
public class MyGallery {

}
}


Если же основной класс документа будет лежать в подпапке "C:\Flash\myprogram", а файл MyGallery.as - в подпапке "C:\Flash\myprogram\gallery", то название пакета должно измениться на myprogram.gallery
Имя пакета + (через точку, конечно) имя класса = полное имя класса, по которому можно к нему обращаться, не импортируя его.
Таким же образом - пакетами - организованы и "входящие в комплект поставки" классы самого AS3. Напр., класс MovieClip имеет полным именем - flash.display.MovieClip , класс URLRequest - flash.net.URLRequest
По полному имени класса всегда можно определить, в какой подпапке лежит его описание (по отношению к одному из путей, указанных в classpath - это в свойствах основного документа *.fla) и обратиться к нему из программы, напр.:

private var myMC:flash.display.MovieClip;
private var tmr:flash.utils.Timer = new flash.utils.Timer();

Конечно, это неудобно. Поэтому классы импортируют - один раз указывают, какие классы будут использованы в пакете или в классе, который мы пишем.
Например:
CODE
package {
// импортируем нужные классы
import flash.display.Sprite;
import flash.display.MovieClip;
// ...
public class MyClass {
// ...используем "короткие" имена классов - без имени пакета
private var myMC:MovieClip;
}
}


Можно импортировать отдельные классы, как в коде выше, а можно - сразу весь пакет. Например, если мы используем большинство классов пакетов flash.net и flash.events, то имеет смысл не "перечислять" их по одному в разделе импорта классов, а импортировать весь пакет:

CODE
package my.desLoad {
//..
//..
import flash.events.*;
import flash.net.*;

class desLoaderQueue {
// ..
}
}


Здесь я скажу об одном из отличий Основных Типов Данных от Классов (как встроенных, так и пользовательских): особенность Типов Данных в том, что их никогда не нужно импортировать - всегда можно использовать "короткое" имя класса, описывающего соответствующий Тип Данных.
К ним относятся:
Boolean, int, Null, Number, String, uint, void, Object
Из них int и uint (целое и беззнаковое целое) - новые в AS3 (по отношению к AS2) Типы Данных, а void теперь пишется по-другому - со строчной буквы.
К основным Типам Данных относится также Array (массив), Date (дата), XML (репрезентация XML-документа), Math (реализующий основные математические функции), Error (ошибки) и некоторые другие. О них также говорят, что они относятся к классам Высшего Уровня (Top-Level Classes).

4. Оформим?

Код на объектах принято писать с комментариями, причем есть даже рекомендации о том, как именно оформлять комментарии, и по определенным соглашениям, касающимся имен переменных, классов, методов и т.д. Комментирование кода - это даже не традиция, это практически требование, которое необходимо выполнять.
Основные правила документирования кода таковы:
В каждом файле *.as принято писать комментарий, содержащий описание того, для чего этот пакет (или include - "вставка") предназначен, в начале класса - описание его функциональности, переменных и констант, методов с указанием передаваемых им аргументов, даты создания\изменения, копирайтом \ ссылкой на сайт и контактными данными.
Свойства класса, в особенности "public" - т.е. те, значение которых может быть изменено "извне" без обращения к специальному методу ("сеттеру") этого же класса, "расшифровываются" комментариями в обязательном порядке.
Свойства класса, которые не принадлежат к основным типам, должны быть закомментированы особенно подробно, а переменные-массивы снабжаются комментарием, в котором описано, к какому Типу Данных или Классу принадлежат (по логике работы класса) элементы этого массива - в т.ч. если они могут быть разнотипными.
Код методов снабжается описанием их функциональности и передаваемых аргументов - в особенности это относится к методам-конструкторам класса.
Основной код программы тоже должен быть откомментирован и пояснен везде, где он только чуть-чуть отличается от полностью тривиального (конечно, полностью тривиальный код комментировать незачем; если у вас вся программа - две кнопки, то комментировать добавление каждого объекта-"слушателя" совершенно ни к чему - это тоже считается не комильфо)

Отедельное внимание стоит уделить названиям переменных. Я не буду приводить ссылку на полные рекомендации по оформлению AS-кода от Adobe, поскольку больше 90% написанного там вам пока будет непонятно и только запутает, но несколько общих рекомендаций-требований перечислю:
- не пользуйтесь сокращениями, кроме самых общепринятых (num = number, util - utility, obj = object, tf = textfield, mc = movieclip, w = width, h = heilght, ID = id = identificator). Вы сами через неделю проклянете все, разбирая, где вы назвали переменную mySqr, где - mySquare, а где - mySq.
- Имена пакетов пишутся со строчной буквы, имена классов - одним или несколькими словами с разделением заглавными. Напр., пакет mypackage, класс mypackage.MyClass
- В остальном - не так важно, какая именно система именований вами используется, лишь бы это была понятная, ясная и единообразная для одного хотя бы проекта система. Например, я для себя принял, что имена private-свойств класса начинаются с "_", аргументы, передваемые методу - с "a_", а имена public-свойств начинаются со строчной буквы.
Со временем у вас, скорее всего, сложится своя система именования всего и вся в AS3, удобная вам и понятная другим. Если вы, конечно, не бросите это безнадежное дело - программирование smile.gif

5. И еще одна общая концепция.

Когда вы писали код на AS2 - будь то красивый эффект для баннера или заставка-меню для "шапки" сайта, или даже динамический сайт с хранением данных в XML-файле - вы вряд ли задумывались о концептуальной организации работы с данными. Самым простым правилом, которые вы, возможно, слышали, было знаменитое виртовское название книги "Алгоритмы + структуры данных = программы" - и этой классики программирования вполне хватало для задач уровня AS2.
Однако вы уже, может быть, почувствовали особенность программирования на объектах, состоящую в строгой (и, надо сказать, в строгости этой - красивой) организации исходного кода. Такая организация направлена не только на быстрое и эффективное создание конкретной программы, но и на многократное использование одного и того же кода, как вами же, так и другими программистами, если вы решите поделиться с ними своими наработками, или - при работе в команде программистов.

Обдумывая проект будущей программы (это этапы а) и б) из п. 2), стоит помнить о т.н. "тройке": данные, обработка, визуализация. Эта "тройка", кстати, - одна из самых общих концепций для любого языка программирования. Иногда ее заменяют на "данные - действие - реакция", но в сущности это то же самое, только другими словами.
Это означает, что функционально код стоит разделить на три глобальные составляющие:
1) данные и способы их хранения (получения) в программе - т.е. структуры данных, или ответ на вопрос "что мы обрабатываем?"
Это определит основной набор классов, которые нам будут необходимы.
2) обработка данных в программе - т.е. ответ на вопросы "что мы делаем с данными? Как их преобразуем?"
Это в основном определит методы классов, которые мы запроектировали, и, может быть, некоторые классы, специально предназначенные только для обработки, но не для хранения каких-либо данных
3) как мы показываем пользователю то, что происходит в нашей программе.
Сюда относится и пользовательский интерфейс, и визуальные эффекты, и дизайн, и юзабилити. Эта часть "тройки" в Flash, исторически изначально нацеленного на визуализацию для веб, особенно важна.

Из этой "тройки" прямо следует и концепция "состояний сцены", которой лучше всего придерживаться при программировании на AS3. Заключается она в следующем:
если в AS2 (или, напр., в BASIC smile.gif ) мы не отслеживаем все, что происходит в ролике (в программе), не особенно волнуясь о том, что там именно происходит, когда нажата левая кнопка мыши и "отыгрывается" переход по MotionTween или просчитывается повреждение от "выстрела из бластера", то при программировании на AS3 стоит держать в голове идею о том, что всё, что происходит в ролике, полностью описывается текущим состоянием свойств объектов, которые в тот или иной момент (точнее - на том или ином фрейме) присутствуют в нем. Некоторые из них нам "подконтрольны" напрямую, некоторые - косвенно, но - факт: вся наша программистская задача состоит в том, чтобы описать
а) начальное состояние сцены
б) все промежуточные состояния сцены ("наборы свойств объектов", а если выражаться более формально - "пространство состояния сцены"), которые полностью нами могут быть описаны
в) все алгоритмы перехода от одного состояния сцены к другому (т.е. - алгоритмы изменения свойств объектов сцены).

Понимание этого уже дает многое, IMHO, будущему крутому флэшеру smile.gif

_________________________

Продолжение следует




____________________________________


Автором урока является Des.
Запрещается копирование и публикация урока на других сайтах без письменного согласия автора и размещения ссылок.


The tutorial is written by Des.
No part of this tutorial can be copied/pasted on any other website without the author's express written permission.


Сообщение отредактировал Des - 18.04.2009 - 13:48


--------------------
"Высшая мудрость - умение разговаривать с людьми" ((с) Ямамото Цунэтомо (Дзётё), "Хагакурэ")
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
F10
сообщение 23.12.2009 - 10:28
Сообщение #2






Группа: Туристы
Сообщений: 1
Регистрация: 23.12.2009
Пользователь №: 15009



Симпатии:  0  


Спасибо!
Продолжение будет?

Сообщение отредактировал F10 - 23.12.2009 - 10:29
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
Cheetah1
сообщение 1.02.2011 - 09:24
Сообщение #3






Группа: Туристы
Сообщений: 1
Регистрация: 1.02.2011
Пользователь №: 17724



Симпатии:  0  


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


--------------------
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения

Быстрый ответДобавить ответ в эту темуОткрыть тему
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 



- Текстовая версия форума Сейчас: 18.10.2017 - 04:48