- 001
- 002
- 003
- 004
- 005
- 006
- 007
- 008
- 009
- 010
- 011
- 012
- 013
- 014
- 015
- 016
- 017
- 018
- 019
- 020
- 021
- 022
- 023
- 024
- 025
- 026
- 027
- 028
- 029
- 030
- 031
- 032
- 033
- 034
- 035
- 036
- 037
- 038
- 039
- 040
- 041
- 042
- 043
- 044
- 045
- 046
- 047
- 048
- 049
- 050
- 051
- 052
- 053
- 054
- 055
- 056
- 057
- 058
- 059
- 060
- 061
- 062
- 063
- 064
- 065
- 066
- 067
- 068
- 069
- 070
- 071
- 072
- 073
- 074
- 075
- 076
- 077
- 078
- 079
- 080
- 081
- 082
- 083
- 084
- 085
- 086
- 087
- 088
- 089
- 090
- 091
- 092
- 093
- 094
- 095
- 096
- 097
- 098
- 099
- 100
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Text.RegularExpressions;
using System.IO;
namespace SimpleLex
{
class Lexical
{
//Сюда передается путь к файлу конфигурации
public string Path = "";
//Определяем ключевые слова
string regular = "Color|Size|Name";
public void lexical()
{
//Создаем массив строк для дальнейшего заполнения
string[] conf = new string[1024];
//Переменная счетчик
int i = 0;
//Заполняем массив из файла
//Path мы присваиваем значение при создании
//объекта нашего класса.
conf = File.ReadAllLines(Path);
//Запускаем цикл чтения
while (conf.Length - 1 >= i)
{
// Создаем новый объект класса Regex
// и передаем ему в качестве конструктора
// cписок ключевых слов
Regex RegularExp = new Regex(regular);
//Начинаем поиск совпадений в текущей строке
Match match = RegularExp.Match(conf[i]);
while (match.Success)
{
//Ожидаем наличия совпадений
break;
//Если нашли то выпрыгиваем
}
switch (match.Value) // Смотрим что же мы обнаружили и вызываем соответствующий метод
{
case "Color":
//вызываем метод Color_
//и передаем ему текущую строку для разбора
//Предварительно удалив все пробелы с двух сторон
//если они были метод Trim()
Color_(conf[i].Trim());
i++;
break;
case "Size":
size_(conf[i].Trim());
i++;
break;
default:
//все другое пропускаем
i++;
break;
}
}
}
void Color_(string str)
{
int i = 0;
while (str.Substring(i,1)!= "=")
{
//Ищем разделитель в данном случае "="
i++;
}
//Находим и извлекаем нужную нам информацию
string value_ = str.Substring(i + 1, str.Length - (i+1)).Trim();
//Теперь все зависит от вашей фантазии хотите
//Создайте класс который будет устанавливать цвет шрифта
//И.т.д
Console.WriteLine(value_);
Console.ReadKey();
}
void size_(string str)
{
/*
* В этом методе я хочу показать как быть если вы используете
* в своем файле для каждой команды разные разделители
* в теории конечно можно все это засунуть в один метод
* Но я советую в дальнейшем если вы будите применять
* именно такую структуру передавать в метод тип разделителя
* и соответственно искать именно его другое дело если вы имеете
* различный формат входных данных как у нас параметр size имеет
* вид shize X=100,Y=500
*/
//Есть прекрасный метод
int i = 0;
while (str.Substring(i,1) != " ")
{
i++;
}
str = str.Substring(i, str.Length - i).Trim();
string[] commandMas = new string[3];
commandMas = str.Split(',');
Follow us!
А в шарпе разве нет ничего, кхм, более высокоуровневого?
XML поди?
тут об этом рассказано :)
Вот в qt и boost, имхо, правильный подход. Единый интерфейс для конфигов в xml/ini/json. Кому что нравится - тот то и юзает. Код от этого не меняется.
В Visual Studio есть xml schema для всех конфигов. Так что даже в xml-редакторе править такие конфиги вполне удобно: подсказки, автодополнение и пр.
Да, гуйня тоже есть для многих конфигов. Тыц-тыц мышкой - готово!
Но самое главное, - чаще всего вовсе не нужно заглядывать в эти конфиги и даже можно не подозревать об их существовании. Всё само генерируется в подалвющем большинстве случаев.
ЗЫ: я тоже обеими руками за более компактные форматы типа json/ini и вообще бинарные.
Есть один недостаток - есть сколько-то очень специфических возможностей, которые применимы только в контексте ДОМа. Но все равно, он гораздо лучше JSONа.
Что мешает записать селектор (ключ) и набор его атрибутов (значения) в виде JSON?
Ну, что-нибудь такое, например.
2. Что делать, если имена полей содержат пробелы (e.g.
"approx sales")?
3. Насколько просто понять, что закончился один документ и начался другой? Ведь порядок правил в css не фиксирован, их можно размещать в произвольном порядке.
А как в Прологе узнают, что програма закончилась? В ПаверЛум есть, например, специальное правило, которое управляет парсером, и инструктирует его сделать все выводы предшевстующие данному правилу, но можно и без него обойтись.
На счет имен полей - ну если бы CSS использовался бы не только в контексте DOM, то наверное этот момент исправили. В JSON есть тоже свои неприятности, например километровые строки, в которых нельзя делать переносы.
Опять же CSS именно, как конкретная реализация обладает недостатками, но в принципе, если эту идею доработать (а еще лучше, начать дорабатывать с Пролога и Ко), то возможностей и удобства поприбавилось бы.
написать где? в тексте передаваемого документа? Или в базе данных элементов?
Имея монгу, я тоже могу написать что-то вроде Безусловно, это тривиально можно было бы выразить без js-методов, использую лишь json.
> Имея монгу
А у меня есть конга, велосипед такой. При чем здесь это, это как-то меняет возможности формата JSON? Эта информация отсутствует в самом формате, чтобы ее от туда получить, нужно писать дополнительный код. Если его кто-то уже написал, то это не отменяет, а скорее подтверждает наличие такой необходимости.
Языков схем для жсона тоже несколько уже сделано. Стандарта тоже пока нет.
И ваще, раз уж мы в теме о Шарпике, то генерация набора классов делается в два клика мышкой. Десериализация из json - одна строка кода. А дальше - линком его, линком! Самый офигительный язык запросов.
Какие? Не, ну я и на питоне могу сделать в одно списковое выражение, но вот есть у меня json viewer, там бы эта штука не помешала.
Видимо wvxvw хочет юзать формат представления непосредственно, а не городить ксс-овер-жсон и графы-овер-хмл. И логика в этом есть ;)
>а не городить ксс-овер-жсон
Сравниваются ортогональные вещи.
Да и как вообще посчитать "описательную силу". Поделить описательную работу на обписанное расстояние?
Посмотреть, что данные конкретной задачи удобно ложатся на используемый формат. Где меньше ёбли - тот и имеет большую "описательную силу" для данной задачи.
А в общем смысле - серебряной пули всяко нет.
P.S. > Поделить описательную работу на обписанное расстояние?
Работу по описанию данных в нужном формате на расстояние до ближайшей либы ;)
> А в общем смысле - серебряной пули нет.
Нет-нет-нет, @wvxvw совсем недавно утвержал существование универсального формата непреодолимой выразительности, способного наилучшим образом представлять произвольные данные во всех случаях. Он просто ни с кем не делится своим открытием. Грусть.
Например, JSON не может выразить is-a отношение. Т.е. описав два объекта, например: { а: 1 } и { а: 1, б: 2 } мы не знаем, является ли второй объект разновидностью первого, или это просто совпадение. CSS может это сделать, если одно и то же правило будет применятся к обоим объектам.
В CSS не хватает возможности записывать селекторы на правой стороне выражения, но все механизмы к этому уже есть, просто нужно разрешить это делать. И тогда можно будет структуру представляеть более наглядно, хотя это и не обязательно. Например, из правила:
a b { whatever }
мы можем вывести факт существования элемента a, и его вложеного элемента b. Просто типичные CSS не описывают структуру, потому что за них это уже кто-то сделал, но это не говорит о том, что это в принципе не возможно.
Точно таким же образом структуру описывает Пролог, или КИФ / ПаверЛум и т.п.
У быдлокодеров
Но вот вручную править хмл и жсон довольно противно. Да и в жсоне комментов нет. И если не нужна иерархия больше одного-двух уровней - иниподобные форматы рулят.
Вернись на форум.
что мешает их в нужном порядке вываливать?
но сразу после этого мне и самому стало грустно, я даже всплакнул и налил себе водки.
Ага. Я тоже. Потом расстегнул ватник, выпустил медведя погулять, почистил калашников и сел играть на балалайке.
Спасиб, но я так тоже умею, хуячить xml через printf. Нафига вообще нужен формат сериализации, библиотеками для которого проще не пользоваться?
It looks like lxml serializes attributes in the order you set them
As of lxml 3.3.3 (perhaps also in earlier versions) you can pass an OrderedDict of attributes to the lxml.etree.(Sub)Element constructor and the order will be preserved when using lxml.etree.tostring(root)
Сейчас поковырял свои сырцы конца 2012
приехали
Втроенный не умеет, там только словарики принимаются, понятно, почему OrderedDict не работает. Юзай потоковый интерфейс, там уж наверняка порядок соблюдается. В жабе громоздко, но зато всё работает из коробки.
Не работает же: http://ideone.com/6l6C6i
Это чтобы ГЦ не простаивал?
Regex с одним и тем же паттерном создаётся на каждой итерации цикла заново. То же греем ГЦ.
Сакральный смысл наличия этого цикла мною так и не понят.
О методе String.IndexOf аффтырь не слышал.
Это не сишарп, это вижуал си дот нет. Большая разница!