Ayavryk

Ayavryk
Рейтинг
209
Регистрация
11.10.2003
Devvver:
Не стоит так делать.

Ну если человек помешан на модном слове "семантика", то стоит.

a class="very-important-link"

Моя жена (тогда еще не жена) до сих пор вспоминает, как я подарил ей на день рождения воздушные шары.

Она шла по улице такая счастливая. И смотрела на эти глупые рыжие шарики.

Смурные прохожие смотрели на на нее недоуменно.

Люди разучились радоваться простым вещам.

Нет я не жадина. Там были и цветы и икра осетрина и ананасы в шампанском и .... Но что это было - ни я ни она не помним.

А воздушные шары я ей дарю до сих пор.

И она им радуется как ребенок.

И я тоже.

Теперь я ищу шоколадного деда мороза под НГ. Мечту ее детства. В ее городе этого не было. Только в мск. У богатых детей это было. А у нее нет. Богатые дети ели. А она так хотела. Но...

В общем, попробуйте угадать подсознанательное желание. Оно намного важнее всякой наносной лабуды. Это то самое, что никто никогда ни в каком форуме вам не подскажет. Только Она сама. Только Вы сами. Ищите, да обрящете.

Имхо.

T.R.O.N:
1. использовать постянно меняющееся имя поля. Рандом

Хм. Не догадался бы. Но как-то оно того. Имеет смысл наверное только в полях типа ajax suggest. Там все время путаница идет.

Рэндомные поля использовал только для защиты форм обратной связи от ботов.

loki.rus:
лучше попридержать. И "кризис" пройдет

Можно было бы придержать - придержал бы.

На днях стал ссылки продавать и Директом озадачился. Думал не придется. Хотя предлагали много.

LEOnidUKG:
ИМХО развить технически, это например подрубить Ajax для простых функций

Научи программера Ajax'у молиться...

Для контейнеру в котором наблюдается такой бардак добавьте style="position:relative". Если не поможет - добавьте последотательно во все контейнеры сверху вниз. Но вообще должно помочь с 99% вероятностью.

IE6 - броузер глючный, но стабильный. Все глюки собраны здесь: http://www.positioniseverything.net/explorer.html

Это - http://habrahabr.ru/blogs/webdev/31236/ тоже полезно знать

Извините, но интерфейс админки жуткий. Имхо обычная болезнь у опенсорсовских продуктов (Впрочем у продажных не лучше).

Вроде и функций у CMS никаких. А уже на главной странице оторопь берет - куда жамкать. Ну ладно мы здесь всякое видели, разберемся (если не лень будет), а как с нормальными юзерами? Плохо представляю как какая-нибудь секретарша будет заколачивать туда новости своей фирмы. Где там "Новости" спрятаны? Как их туда забить? А где вбиваются номера телефонов, которые в подвале? А как мыло исправить на страничке или цену у товара. Куда лезть? На первой странице админки - куча ненужной хрени, которую нужно надежно спрятать от глаз юзера. Чтобы не дай бог не снес то о чем он не должен знать. Зато самое важное и нужное повседневно - контент (новости, товары, статьи...) спрятан в одном из двадцати пунктов ничего не говорящего меню.

Ну и вообще. Имхо основные функции редактирования нужно выносить на фронтофис. А бэкофис открыть только для админов. При таком подходе любая секретарша, знающая Li.Ru найдет нужную страницу на фронтофисе и тыркнет в кнопку "исправить тект", "добавить новость" и бла-бла-бла

Вот такие печальные мысли возникают всякий раз когда вижу очередную CMS. Не понимаю. Почему все клонируют худшие варианты допотопных интерфейсов типа Nuke. Даже не хочется разбираться что у вас там хорошо или плохо в архитектуре.

Извините, если обидел.

Коля Дубр:
import/include - не знаю, будет ли он по HTTP работать, не пробовал

А я уже. На http://erum.ru правая колонка грузится через xsl:import, включеный в клиентское преобразование http://erum.ru/final.xsl Не пробовал подсасывать внешний XML, но сдается что с этим проблем быть не должно. Оптимизация там за уши притянута, но правую колонку роботы не видят.

Коля Дубр:
если проводить не одну трансформацию, а шаблонизировать отдельно вывод каждого модуля (плюсы - легкость кэширования, собственно "модульность", независимость частей приложения), преобразование на клиенте тоже все путает

. Не понял. По-моему здесь особых проблем нет. Сборка частично производится на сервере, частично на клиенте. Проходов может быть не два, а сколько угодно. И соответственно кэширование м.б. выполнено на любом проходе. Примерно такая схема, естественно без клиентского преобразования была на одном из сайтов которые я делал. Схему закладывал один из экс-яндексоидов. После этого я как раз на XSLT запал.

Коля Дубр:
Конкретно с комментариями - подозреваю, эффективней всего будет строить дерево тупо на пыхе, и отдавать XSLT уже готовое дерево, а не "плоский" список.

Не знаю. Я в программировании не силен. И обычно тупо делаю через SQL-запросы. Но похоже что - это наиболее ресурсоемкая операция. Так чего бы ее не пихнуть на клиента?

Коля Дубр:
Но да, не так красиво :)

Ну так это в XSLT самое главное - красота :)

Коля Дубр:
Были примеры, когда исходное дерево "подгонялось" под xhtml, но это, ИМХО, извращение.

Ну извращение конечно, но если бы не было проблем с парсингом в современных броузерах такой подход дает имхо некоторые преимущества, например.

- Можно отлаживать функционал и клиентские скрипты на прототипах. Не дожидаясь пока будет готов и утвержден окончательный дизайн.

- Всякие постоянные вставки можно реализовывать через подгрузку внешних XML или XSL файлов

- Достаточно нагруженные операции типа отображения деревьев форумов и блогов можно грузить на клиента а не на SQL Типа: http://erum.ru/article/18 (см. HTML код дерева обсуждения темы)

Ну и прочая

Федорыч:
Я имел ввиду не язык, а совковые СМСки.

Все мы когда-нибудь загнемся. А пока ничего - пьем, едим и нравимся девушкам. Не всем конечно.

Всего: 2264