очень редко встречаются задачи в которых на 100% разбираешься с технологией во время решения задачи. просто задача требует только части знаний о какой-то технологии. xslt — не исключение.
понятия не имею. но от этого ресурсы компьютера опера потреблять меньше не стала. конечно, если я не пользуюсь этим «довеском», моя опера будет потреблять меньше памяти, чем у человека, которые ее использует.
p.s. не могу понять, почему люди против того, чтобы они имели выбор набора функциональности ПО?? вы думаете, что всем капец как нужен полный набор софта???
и теперь вы ответьте быстро, при офисный пакет у вас полностью установлен или только то, чем вы пользуетесь?? если используете линукс — у вас весь набор пакетов??
не станет, если будет не просто удалена функциональность, а появится возможность ее не ставить тем, кому она не нужна. например, еще на этапе установки. а кому надо — пусть оставляет и радуется.
по моим наблюдениям ( ~ 4-5 лет опыта работы с xml & xslt), с производительностью проблем не возникает, при условии правильного использования конструкций языка (реже использовать for-each, на пример ) и знания механизмов работы. Как и любой другой язык поддается оптимизации.
Если необходимо обрабатывать файлы большого размера (>1 Gb), то можно использовать Intel® XML Software Suite.
но надо учитывать, что различные парсеры(или при работе на разных языках) по-разному работают, например — при работе с xml & xslt на .Net — шаблоны собираются в сборки и остаются загружеными(даже если не все шаблоны используются) — если я не ошибаюсь.
Насчет «необычности» языка — он просто другой. Для программистов на Java, C++, C#, такие языки как javascript, perl, python — тоже покажутся очень странными.
в институте/университете человек должен научиться учиться. а если повезет - и приобрести определенные знания.
.. но не зависимо от того, как учился студент в университете - он в общем случае, будет развитее того, кто не закончил. как бы не доказывали, не приводили случаи из жизни - факт. те кто не закончили - имеют узкий кругозор и могут стать только исполнителями. даже если они овладели определенными прикладными техногиями.
... был неоднократно свидетелем, когда хорошего исполнителя (без высшего образования) ставили на руководящую должность... плачевно все заканчивалось.
+1. забавно, как все сразу стараются лично пожелать скорейшего выздровления, что-то советуют и т.д. Вряд ли они так же прониклись бы горем(?) другого человека ... т.е. явно тут гуманностью и добротой не пахнет... а просто в ноги падают... жалкие люди ... имхо, я лично его не знаю, и так же не знаю что именно случилось и кто в этом виноват, поэтому - никому не стану ничего желать, равно как и глумиться.
считаю этот комментарий максимально приближенным к правильному, имхо :
1) если не видеть картину в целом, то нет смысла разрабатывать "что-то там", что есть часть от целого. ведь в процессе разработки необходимо принимать решения, на которые влияет общая архитектура, цели и т.д.
2) как можно знать при подходе "снизу-вверх", что результат приближается к заказываемому?? т.е. "сейчас мы реализуем прикольную фичу, а потом подумаем зачем она нам нужна"?
3) часто заказчик сам слабо представляет себе "как оно должно работать". и понимание/видение картины в целом - избавляет от необходимости каждую мелочь уточнять с заказчиком.
4) согласен, что не обязательно каждый из разработчиком обязан "видеть картину целиком". но ведение проекта(управление/проектирование/управление требованиями) требует этого.
5) еще один "плюс" в пользу метода "сверху-вниз" - возможность на раннем этапе определить противоречие в архитектуре или выбрать наиболее оптимальное решение.
в php использовал xml& xslt. были некоторые проблемы ( не работала функция index-of(),empty(),..) с xpath. но пенять особо не на кого, т.к. dom в php хоть и относительно давно, но все равно не полностью поддерживается и не очень стабилен. хорошо, что хоть наиболее распространённые функции реализованы.
решал проблему альтернативными xpath запросами. иногда полученное решение теряло изящность технологии,имхо.
чтобы не писать xslt-файлы огромных размеров можно пользоваться директивами xsl:import & xsl:include. если правильно использовать технологию(xslt), то очень гибко и удобно получается. уже около 3-х лет работаю с ней и всегда какие-нибудь нюансы узнаю.
будет как с mp3-плеерами, китайцы выбросят на рынок множество подобных устройств(подобного дизайна) и продукция эппла затеряется... т.к. другим (кроме дизайна) она не отличается. ... имхо.
использую подобным образом. только преобразовывается в xHTML. все данные после выборки из базы преобразуются в xml, а дальше с помощью php применяются xsl-шаблоны. а клиенту передается только xHTML + js + css.
никаких сложностей. разве-что, из-за js, т.к. все работает через ajax.
... и как заметил denver, переменные определять можно, и передавать в templates(только в именованый) как параметры, а вот возвращать - по-моему нельзя.
p.s. не могу понять, почему люди против того, чтобы они имели выбор набора функциональности ПО?? вы думаете, что всем капец как нужен полный набор софта???
и теперь вы ответьте быстро, при офисный пакет у вас полностью установлен или только то, чем вы пользуетесь?? если используете линукс — у вас весь набор пакетов??
Если необходимо обрабатывать файлы большого размера (>1 Gb), то можно использовать Intel® XML Software Suite.
но надо учитывать, что различные парсеры(или при работе на разных языках) по-разному работают, например — при работе с xml & xslt на .Net — шаблоны собираются в сборки и остаются загружеными(даже если не все шаблоны используются) — если я не ошибаюсь.
Насчет «необычности» языка — он просто другой. Для программистов на Java, C++, C#, такие языки как javascript, perl, python — тоже покажутся очень странными.
.. но не зависимо от того, как учился студент в университете - он в общем случае, будет развитее того, кто не закончил. как бы не доказывали, не приводили случаи из жизни - факт. те кто не закончили - имеют узкий кругозор и могут стать только исполнителями. даже если они овладели определенными прикладными техногиями.
... был неоднократно свидетелем, когда хорошего исполнителя (без высшего образования) ставили на руководящую должность... плачевно все заканчивалось.
jamiro.xmg[at].gmail.[dot]com
1) если не видеть картину в целом, то нет смысла разрабатывать "что-то там", что есть часть от целого. ведь в процессе разработки необходимо принимать решения, на которые влияет общая архитектура, цели и т.д.
2) как можно знать при подходе "снизу-вверх", что результат приближается к заказываемому?? т.е. "сейчас мы реализуем прикольную фичу, а потом подумаем зачем она нам нужна"?
3) часто заказчик сам слабо представляет себе "как оно должно работать". и понимание/видение картины в целом - избавляет от необходимости каждую мелочь уточнять с заказчиком.
4) согласен, что не обязательно каждый из разработчиком обязан "видеть картину целиком". но ведение проекта(управление/проектирование/управление требованиями) требует этого.
5) еще один "плюс" в пользу метода "сверху-вниз" - возможность на раннем этапе определить противоречие в архитектуре или выбрать наиболее оптимальное решение.
решал проблему альтернативными xpath запросами. иногда полученное решение теряло изящность технологии,имхо.
http://www.lbook.com.ua/ru/lBOOK/lBook%20eReader%20V3
+ ссылка на обсуждение Sony's PRS-505 eBook-reader и электронных читалок в общем.
p.s. сам хочу приобрести себе подобное устройство, вот и присматриваюсь к разным моделям. хотя цена на них пока еще не маленькая.
никаких сложностей. разве-что, из-за js, т.к. все работает через ajax.
... и как заметил denver, переменные определять можно, и передавать в templates(только в именованый) как параметры, а вот возвращать - по-моему нельзя.