Вопрос по LSO (Local Shared Objects)

[opex]

извеняюсь

fscommand ("exec", "any.exe\tparameter");

[opex]

Вот написал исходничек если я ошибаюсь (с передачай порамтра в 5 флеше ) то проблема с записью в xml решена

[urca]

2 орех:
может я чего-то не понимаю. что в твоем исходнике может помочь мне с записью в ХМЛ-конфиг??
Ничего что-то он не пишет...Я меня вообще-то 7-ка МХ. так что может изза этого???

А еще как оказалось КАЖДЫЙ юзер должен иметь возможность редактировать ХМЛ-конфиг.....
только обычный юзер может редактировать только 1-2 поля (снять/поставить объект на охрану) а АДМИН-ы (их около 3) - имеют full-contact.
точнее такая задумка... Но вот сделать пока не выходит.. ((
А можно ли как бы на сервере LSO в файл сохранять, а не на локальной тачке?


______________
"...но выйти вон и сам не прочь..."

[Dindin]

Не надо изобретать велосипед. Такие вещи делаются трехзвенкой - flash+PHP+mySQL. Flash вообще-то предназначен для разработки клиентских приложений и напрямую с сервером работать не может.

[urca]

Специально для DinDin-а
Я же уже говорил - МОЯ ФЛЭШЬ - ВЗАИМОДЕЙСТВУЕТ С ОСТАЛЬНЫМИ ПРИЛОЖЕНИЯМИ ТОЛЬКО ЧЕРЕЗ ХМЛ-конфигурационный файл!!!

при чем здесь MySql ????

Далее - серверная поддержка моего проекта будет (ой будет ли??) осуществляться на языке Perl.
То есть РНР - тоже не то, что надо!!!!!

Да, возможно ты и прав, что без помощи другой технологии не обойтись, но зачем тогда ты советуешь не 1, а 2????? Насколько я понимаю - Муsql - это для обработки баз данных. НО ВЕДЬ МОЯ БАЗА - ЭТО ХМЛ-файл!!! Ну не нужен здесь этот MySql (твой эСКуэЛь)!!!!

Ну клиентские приложения-то работают с сервером --
посылают и принимают данные!

Пшеропрошую за некоторую резкость.
______________________________
".....ты помнишь...."

[Dindin]

Подробно и пошагово.
1) Flash в чистом виде не предназначен для разработки серверных приложений. Его назначение - организация приложения-клиента (надеюсь, это споров не вызовет) Из этого следует:
2) любая попытка сохранить данные на сервере (не на локальной машине, а на сервере) требует использования внешнего модуля, который, собственно, и сохраняет данные. Вариантов внешнего модуля множество - CGI - скрипт (например на Perl), php-модуль, ASP - модуль, сервер приложений Macromedia ColdFusion, служба приложений Flash Remouting и так далее.
3) На собственном опыте (уверяю, не маленьком) я убедился, что любая попытка создать собственный формат данных в некотором файле (в твоём случае - это XML с определённой структурой) приводит к дальнейшей необходимости написания парсера для каждого нового приложения, которое будет работать с этим форматом данных. Я не спорю, что это один из вариантов, но в своё время я от него отказался именно по причине трудоёмкости дальнёшего расширения проекта. Для использования в Java, например, пришлось писать XML-парсер на Java, для обработки PHP-модулем - парсер на PHP. В итоге я лично пришёл к выводу, что mySQL -база является оптимальным выходом, поскольку большинство приложений (PHP, Java - в т.ч. JSP, ColdFusion, и т.д.) могут обращаться к базе напрямую, минуя дополнительные звенья, что значительно сокращает объём работ.
Так что совет использовать трёхзвенку это не мой каприз, а "опыт, сын ошибок трудных"
4)если ты всё-же решился работать с сервером через CGI - интерфейс посредством перловых скриптов, то мне не совсем понятно - в чём твоя проблема? Твоя задача - просто сформировать во Flash xml-документ и отправить его в cgi, где перловый скрипт просто запишет получившийся xml в заданную локацию. Правда, в этом случае, возникает проблема: для каждого следующего xml придётся задавать новую локацию (ах, как всё это легко решалось бы в mySQL - просто новая запись в таблице). Здесь уже всё зависит от твоей фантазии.Можно сортировать по папкам.Можно создавать каждый раз новые файлы с уникальными именами (можно даже дописывать новые конфигурации в тот же файл). Но здесь мого подводных камней - при дописывании в один файл для выборки данных придётся производить обработку всего xml-файла. То есть тот самый "принцип толстого клиента". При создани новых файлов необходимо задавать структуру соответствий пользователь - путь к файлу (опять напрашивается mySQL), которую тоже придётся где-то хранить.

Резюме: Как не крути, а более простого и удобного способа хранения структурированных данных в WEB, чем чем базы данных пока нет.

ЗЫ На резкозть я не обижаюсь, она, как правило плод недопонимания

[urca]

.. Что:
1) я и разрабатываю в осоновном клиентское приложение, просто как оказалось клиент имеет право редактировать конфиг-файл!
!!!2) - А вот это я и пытался выяснить - можно ли не использовать серверный модуль какой-либо технологии !!
3) Моя задача не для Веба делается, следовательно не будет попыток считать мой конфиг разноплановыми технологиями. И именно поэтому желательно обойтись минимумом технологий! (одно из требований - минимальная длина цепочки!)
!!!!!4) Хорошая ИДЕЯ!!!!!! - Вот так я наверное и поступлю!
_______________________
"....не покидать корабль!"