Когда то на заре своей работы в WEB среде я написал свой шаблонизатор, парсился регспами, вставляя заместо себя модули, подключаемые к шаблонизатору... Было круто, объектно и удобно...
Потом проникся XML+XSLT, потом много чем еще.
Исходя из своего опыта могу сказать следующее, по пунктам:
1) Если требуется "простенький" шаблонизатор, надо юзать php и не морочить себе голову, ибо он очень просто решает большинство проблем, код приемственен и ему проще обучить, чем обучать php + шаблонизатор ( в этом случае к знаниям php + чтотоSQL + html + css добавляется необходимость знания шаблонизатора
2) Если требуется MVC, то лучше всего юзать XML + XSL - ибо это по стандарту и ОЧЕНЬ мощно. Со скоростью проблем нет, чтобы там не говорили. Но стоит юзать лишь на PHP >=5 ( изза процессора преобразований, ибо саблотрон это жесть с большой буквы )
3) Если требуется модульность, что бывает в случае, когда у вас мощная CMS и XML-ом вот ну ни как не обойтись ( очень мало вероятно при грамотном подходе и с умением вставлять результат выполнения ф-й на PHP ) то тогда да - шаблонизатор.
Единтсвенно, когда шаблонизатор может быть более оправдан чем XSL преобразование - это в случае ОЧЕНЬ большого и сложного проекта, где обширная CMS и много людей, отвечающих за программинг например, ибо уменее правильно писать на XSL - это достаточно редкий скилл. XSL по своей витиеватости очень похож на регекспы и башка частенько трещит у неподготовленного ( да и у подготовленного тоже ). В этом случае кастомный вариант лучше - ибо он обычно четко структизирован и документирован, и имеет меньше сущностей - т.е. код на нем для данной группы разработчиков будет более легким и лаконичным.
Однако я против "стандартных" тепмлейторов, ибо считаю что под серъезный проект лучше написать "свой" кстомный. Почему? изза лаконичности и заточенности. Всежтаки публичные шаблонизаторы не отличаются лаконичностью, ибо уходят в сторону универсальности. И это правильно ;)
Как я уже писал когда-то, надо всегда смотреть на что ориентирован сайт.
Большинство современных сайтов без JS будут не только не подобающе работать,
они не будут работать вовсе.
Делать надо исходя из затрат на поддержку при
отключении JS. Есть старое правило - "Цель оправдывает средства".
Если Ваш сайт использует JS для каких-то не сильно сложных преобразований,
и теоритически он можети запросто без него обойтись, ну например реализован просмотр
галереи изображений через JS, однако можно сделать, чтобы при щелчке по preview
картинка открывалась просто в новом окне, а при наличае JS запускалась бы галерея просмотра - то тогда да - совсем просто реализовать такой вариант, и его надо и стоит делать.
Если Вы планируете, что сайт может быть просмотрен через мобильное устройство - то
в этом случае тоже надо учитывать возможность отключения JS.
Если же нет, и Вы планируете что просмотр данного сайта будет идти через PC
или же сайт вообще является веб аппликацией - то смысл убиваться за то, чтобы работало без JS нет вообще. Вы много видели браузеров на компьютерах, где отключен JS? Другое дело, что хорошим тоном было бы предупредить человека про JS, если же это все такие случилось.
А можно маленький вопрос?
А зачем так сложно?
Уж если делать простенький XML парсер - достаточно реализовать обыкновенный SAX parser и ВСЕ!
Безо всякой магии :)
Я не в коем случае не хочу сказать что сделано чтото плохо - конечно нет. Но просто существует гораздо более простой спосою. Под PHP я парсер не написал - не надо было, а вот под JS пожалуйста пример:
proto.saxParser = function() {
}
proto.saxParser.prototype.parse = function( dom, ignoreParent ) {
if ( ignoreParent ) {
if ( dom.documentElement ) {
this.parseRecursive( dom.documentElement );
} else if ( dom.tagName ) {
for ( var i = dom.firstChild; i; i = i.nextSibling ) this.parseRecursive( i );
}
}
else this.parseRecursive( dom, ignoreParent );
}
proto.saxParser.prototype.parseRecursive = function( dom ) {
if ( dom.documentElement ) {
this.startDocument( dom );
this.parseRecursive( dom.documentElement );
this.endDocument();
} else if ( dom.tagName ) {
this.startElement( dom );
for ( var i = dom.firstChild; i; i = i.nextSibling ) this.parseRecursive( i );
this.endElement( dom );
}
else this.characters( dom );
}
Вообще мне очень понравился подход людей к статье. Господа вроде [andorro] даже не смогли уловить смысл, но зато критик столько, просто река :) Учитесь мыслить нестандартно, и понимать смысл того, что автор хотел донести, даже если не нравится стиль изложения.
Или Вы всегда все буквально понимаете? И Толстой - плохой писатель, потому что Дарья Донцова не в пример легче читается? :) Не смешите.
Человек написал очень правильную статью, о том, что надо уметь думать. И пропускать все "так надо" и "так модно" через собственную голову и опыт. Кроме того, есть еще бизнес, а в бизнесе, как известно существует еще и "так выгодно" :D
Грустно только от того, что так много людей, которые непоняв мысли, причем ни одной, брызжут слюной, рассуждают о том, что в бедной семье мясок шмотками, не влезающими в сковородку не жарят :D Мне жалко Вас. Вы так и останетесь однородной серой массой потребительсокго класса, живущих и делающих, как говорят "специалисты" ;)
В принципе, согласен.
Не соглашусь с тем, что проверять надо с отключенным JS - если сайт изначально пишется как динамический и все такое, то АБСОЛЮТНО никчему проверять его с отключеным js - он не должен и не будет работать. Если у пользователя отключен js и он заходит на такой сайт - его право.
Другое дело если сайт подается как кроссконтентный - тогда да, вспомогательная навигация на js может отпадать.
Что касается верстки DIV-ам или же TABLE - я считаю что использовать надо СОГЛАСНО задаче, а не потому что TABLE плохо, а DIV - хорошо. Зачастую DIV-ный дизайн является картиночным, т.е. если потребуется потом сделать гдето резиновость или же добавить какойто блок - разъедется очень много элесентов в отличае от TABLE-дизайна. Какой выбирать - авбирать Вам ) Если сайт - это визитка - тогда можно div, если же сложный портал с большим количеством неупорядоченного контента - я бы не советовал - ну да это мое ИМХО.
Диск кэшируется? Может быть Вы имеете ввиду буффера для дисковых устройств? Они в любом случае есть и кэшируются в память, их вручную нужно выставлять в большинстве случаев, чтобы использовалось бОльшее количество памяти под буфер
интересно ))) как больше оперативки связано с бОльшим дисковым кэшем? :D
Я бы сказал что кэша больше - это да. При большом количестве оперативки дисковый кэш вполне можно отключить вовсе - тогда действительно жрать меньше станет.
Вполне хороший и читаемый код. Я предпочитаю немного другую нотацию вида
abc {
}
и отбивать внутри по TAB ( 8 или 5 пробелов ) - но это мое личное так сказать )
Читается вполне, единственное чтобы я в данном случае посоветовал - выровнять >> по одной позиции, и цифирки тоже со скобками - потому как когда такое пишется столбечное, то приятней глазу, когда столбики ровно идут - хотя конечно ИМХО.
А вот мне всегда инетересно было... а зачем это все?
т.е. грамотный верстальшик без сложных проблем сделает такое чудо - ибо очень часто попадается. Здесь вроде да, удобно и т.д. и т.п., тока вот демку которую я поглядел - она статична, не резиновая, а от статичности вроде давно уже все октказались? или нет?
А вот без статичности я не видел css-ок - обычно при верстке именно в неее - в резиновость все и упирсается, а разместить n блков div-а с фиксированными размерами с моей точки зрения достаточно просто даже не для профи CSS.
Это не критика, просто реально интересно зачем? Если не сочтете сложным - объясните?
ну полностью устраивать система не может ) это факт. просто многие
говорят что wm - что плохая что глючит - я даже пожалуй соглашусь что для рядового пользователя так. Я проковырялся по куче форумов, составил список всех твиков кторые мне нужны. отсроил их в коммуникаторе, настроил. угрохал наверное неделю - и вот результат. А если честно мне было бы очень любопытно про это прочитать. Если напишите, дайте сдесь хотябы кросс постинг
А все таки? Чем WM так плоха? вот у мнея стоит 6-ка с реско и питерскими прибамбасами.
Работает шустро, иногда подглючивает - ну это может раз в месяц гдето - перегружать приходится. Коммуникатор Cruise 128 метров. что я делую не так? Работа в основном - веб браузер аська телефон и активно GPS.
Ну начнем с того что у нас разлоченный айфон стоит нифига не 500 ) а как раз 20ку ))
Во вторых WM - да, но и приложений там просто на порядок больше - с любым минусом всегда идет плюс ;)
А в третьих я все таки прежде всего в девайсе ценю функциональность а не стразы от Сваровски ;) Isn't it?
Я чегото не понял видимо... а зачем вообще какието JS для генерации и вытаскивания якорей? передать то что чтото нужно обновить можно элемнетарно через теже гетпеременные если не устраивает якорь.
Затем все очень просто:
[html]
[body]
....
[/body]
[/html]
гдето внутри есть наши участки, кторые грузятся аяксом, кто запрещает на стороне сервера разобрать нужные переменные и добавить в конец страницы либо в инициализатор onload JS с вызовом подгрузки нужного контента?
Или я не правильно задачу понял?
По сравнению с темже HTC Touch Cruise, где за 20 тыров можно поиметь полноценный девайс с 3G, WiFi, кучей приложений, GPS навигацией, полностью настраиваемой системой под себя, радио и т.д. и т.п.
Господи!!!!
Почему так криво то??? Какая нафиг подсветка синтаксиса, если оно простое то схавать не может?!!! Охренеть можно.... Раз в 5 минут и так криво!!! :D :D :D Я понимаю что надо предпросмотр юзать - но некогда мне - быстро написал пример и отправил.... Блин! Господа владельцы сайта, давайте я вам дам код для текстарии?? :D
http://www.zvon.org/xxl/XPathTutorial/General_rus/examples.html
сам XSLT
http://www.zvon.org/xxl/XSLTutorial/Output_rus/index.htm
Не забудь перед прочтением прочитать все по XML - ибо он - основа.
Потом проникся XML+XSLT, потом много чем еще.
Исходя из своего опыта могу сказать следующее, по пунктам:
1) Если требуется "простенький" шаблонизатор, надо юзать php и не морочить себе голову, ибо он очень просто решает большинство проблем, код приемственен и ему проще обучить, чем обучать php + шаблонизатор ( в этом случае к знаниям php + чтотоSQL + html + css добавляется необходимость знания шаблонизатора
2) Если требуется MVC, то лучше всего юзать XML + XSL - ибо это по стандарту и ОЧЕНЬ мощно. Со скоростью проблем нет, чтобы там не говорили. Но стоит юзать лишь на PHP >=5 ( изза процессора преобразований, ибо саблотрон это жесть с большой буквы )
3) Если требуется модульность, что бывает в случае, когда у вас мощная CMS и XML-ом вот ну ни как не обойтись ( очень мало вероятно при грамотном подходе и с умением вставлять результат выполнения ф-й на PHP ) то тогда да - шаблонизатор.
Единтсвенно, когда шаблонизатор может быть более оправдан чем XSL преобразование - это в случае ОЧЕНЬ большого и сложного проекта, где обширная CMS и много людей, отвечающих за программинг например, ибо уменее правильно писать на XSL - это достаточно редкий скилл. XSL по своей витиеватости очень похож на регекспы и башка частенько трещит у неподготовленного ( да и у подготовленного тоже ). В этом случае кастомный вариант лучше - ибо он обычно четко структизирован и документирован, и имеет меньше сущностей - т.е. код на нем для данной группы разработчиков будет более легким и лаконичным.
Однако я против "стандартных" тепмлейторов, ибо считаю что под серъезный проект лучше написать "свой" кстомный. Почему? изза лаконичности и заточенности. Всежтаки публичные шаблонизаторы не отличаются лаконичностью, ибо уходят в сторону универсальности. И это правильно ;)
Большинство современных сайтов без JS будут не только не подобающе работать,
они не будут работать вовсе.
Делать надо исходя из затрат на поддержку при
отключении JS. Есть старое правило - "Цель оправдывает средства".
Если Ваш сайт использует JS для каких-то не сильно сложных преобразований,
и теоритически он можети запросто без него обойтись, ну например реализован просмотр
галереи изображений через JS, однако можно сделать, чтобы при щелчке по preview
картинка открывалась просто в новом окне, а при наличае JS запускалась бы галерея просмотра - то тогда да - совсем просто реализовать такой вариант, и его надо и стоит делать.
Если Вы планируете, что сайт может быть просмотрен через мобильное устройство - то
в этом случае тоже надо учитывать возможность отключения JS.
Если же нет, и Вы планируете что просмотр данного сайта будет идти через PC
или же сайт вообще является веб аппликацией - то смысл убиваться за то, чтобы работало без JS нет вообще. Вы много видели браузеров на компьютерах, где отключен JS? Другое дело, что хорошим тоном было бы предупредить человека про JS, если же это все такие случилось.
А зачем так сложно?
Уж если делать простенький XML парсер - достаточно реализовать обыкновенный SAX parser и ВСЕ!
Безо всякой магии :)
Я не в коем случае не хочу сказать что сделано чтото плохо - конечно нет. Но просто существует гораздо более простой спосою. Под PHP я парсер не написал - не надо было, а вот под JS пожалуйста пример:
proto.saxParser = function() {
}
proto.saxParser.prototype.parse = function( dom, ignoreParent ) {
if ( ignoreParent ) {
if ( dom.documentElement ) {
this.parseRecursive( dom.documentElement );
} else if ( dom.tagName ) {
for ( var i = dom.firstChild; i; i = i.nextSibling ) this.parseRecursive( i );
}
}
else this.parseRecursive( dom, ignoreParent );
}
proto.saxParser.prototype.parseRecursive = function( dom ) {
if ( dom.documentElement ) {
this.startDocument( dom );
this.parseRecursive( dom.documentElement );
this.endDocument();
} else if ( dom.tagName ) {
this.startElement( dom );
for ( var i = dom.firstChild; i; i = i.nextSibling ) this.parseRecursive( i );
this.endElement( dom );
}
else this.characters( dom );
}
proto.saxParser.prototype.startDocument = function( doc ) {
}
proto.saxParser.prototype.startElement = function( el ) {
}
proto.saxParser.prototype.endElement = function( el ) {
}
proto.saxParser.prototype.characters = function( el ) {
}
proto.saxParser.prototype.endDocument = function() {
}
Все :) Весь парсер. Смысл я думаю объяснять не надо ) С задачей XML => Array справляется на ура и очень быстро )
Или Вы всегда все буквально понимаете? И Толстой - плохой писатель, потому что Дарья Донцова не в пример легче читается? :) Не смешите.
Человек написал очень правильную статью, о том, что надо уметь думать. И пропускать все "так надо" и "так модно" через собственную голову и опыт. Кроме того, есть еще бизнес, а в бизнесе, как известно существует еще и "так выгодно" :D
Грустно только от того, что так много людей, которые непоняв мысли, причем ни одной, брызжут слюной, рассуждают о том, что в бедной семье мясок шмотками, не влезающими в сковородку не жарят :D Мне жалко Вас. Вы так и останетесь однородной серой массой потребительсокго класса, живущих и делающих, как говорят "специалисты" ;)
Не соглашусь с тем, что проверять надо с отключенным JS - если сайт изначально пишется как динамический и все такое, то АБСОЛЮТНО никчему проверять его с отключеным js - он не должен и не будет работать. Если у пользователя отключен js и он заходит на такой сайт - его право.
Другое дело если сайт подается как кроссконтентный - тогда да, вспомогательная навигация на js может отпадать.
Что касается верстки DIV-ам или же TABLE - я считаю что использовать надо СОГЛАСНО задаче, а не потому что TABLE плохо, а DIV - хорошо. Зачастую DIV-ный дизайн является картиночным, т.е. если потребуется потом сделать гдето резиновость или же добавить какойто блок - разъедется очень много элесентов в отличае от TABLE-дизайна. Какой выбирать - авбирать Вам ) Если сайт - это визитка - тогда можно div, если же сложный портал с большим количеством неупорядоченного контента - я бы не советовал - ну да это мое ИМХО.
Я бы сказал что кэша больше - это да. При большом количестве оперативки дисковый кэш вполне можно отключить вовсе - тогда действительно жрать меньше станет.
abc {
}
и отбивать внутри по TAB ( 8 или 5 пробелов ) - но это мое личное так сказать )
Читается вполне, единственное чтобы я в данном случае посоветовал - выровнять >> по одной позиции, и цифирки тоже со скобками - потому как когда такое пишется столбечное, то приятней глазу, когда столбики ровно идут - хотя конечно ИМХО.
т.е. грамотный верстальшик без сложных проблем сделает такое чудо - ибо очень часто попадается. Здесь вроде да, удобно и т.д. и т.п., тока вот демку которую я поглядел - она статична, не резиновая, а от статичности вроде давно уже все октказались? или нет?
А вот без статичности я не видел css-ок - обычно при верстке именно в неее - в резиновость все и упирсается, а разместить n блков div-а с фиксированными размерами с моей точки зрения достаточно просто даже не для профи CSS.
Это не критика, просто реально интересно зачем? Если не сочтете сложным - объясните?
говорят что wm - что плохая что глючит - я даже пожалуй соглашусь что для рядового пользователя так. Я проковырялся по куче форумов, составил список всех твиков кторые мне нужны. отсроил их в коммуникаторе, настроил. угрохал наверное неделю - и вот результат. А если честно мне было бы очень любопытно про это прочитать. Если напишите, дайте сдесь хотябы кросс постинг
Работает шустро, иногда подглючивает - ну это может раз в месяц гдето - перегружать приходится. Коммуникатор Cruise 128 метров. что я делую не так? Работа в основном - веб браузер аська телефон и активно GPS.
Во вторых WM - да, но и приложений там просто на порядок больше - с любым минусом всегда идет плюс ;)
А в третьих я все таки прежде всего в девайсе ценю функциональность а не стразы от Сваровски ;) Isn't it?
Затем все очень просто:
[html]
[body]
....
[/body]
[/html]
гдето внутри есть наши участки, кторые грузятся аяксом, кто запрещает на стороне сервера разобрать нужные переменные и добавить в конец страницы либо в инициализатор onload JS с вызовом подгрузки нужного контента?
Или я не правильно задачу понял?
Почему так криво то??? Какая нафиг подсветка синтаксиса, если оно простое то схавать не может?!!! Охренеть можно.... Раз в 5 минут и так криво!!! :D :D :D Я понимаю что надо предпросмотр юзать - но некогда мне - быстро написал пример и отправил.... Блин! Господа владельцы сайта, давайте я вам дам код для текстарии?? :D