gorinich

да, конечно. я ведь не о PHP говорил. я говорил о базе данных домино, эта формула для лотуса. в каждом сообщении я писал, что эту формулу нужно вставить в колонку таблицы вместо выводимых файлов. откройте вашу базу данных в лотус дизайнере, найдите там вашу вьюшку, в ней найдите колонку, где, как вы ожидали, будут выводиться файлы. и вместо того, что у нее там есть сейчас (я думаю, там указано поле, в которое вкладывались файлы), вставьте эту формулу. не забудьте изменить тип содержимого колонки с "поле" на "формула". код php вообще менять не нужно. у вас в лотусиной таблице проблема, а не в php. и менять в формуле ничего не нужно (типа, "/$collon/"). скопируйте и вставьте то, что я давал.

я тож в ff не вижу отличий

по порядку: : "/" - отсекаем все текущие вложенные пути до доменного имени. : @WebDbName - это полный путь к текущей базе данных при доступе через веб (безусловно, на домино сервере должна работать настроенная задача http. иначе, в наших манипуляциях вообще нет никакого смысла). пример: база данных расположена по пути 'C:\Program Files\Lotus\Data\Sites\files.nsf'. В этом случае функция @WebDbName вернет стринг 'Sites/files.nsf', что и будет веб адресом для открытия этой базы данных. : "/0/" - это универсальное имя вьюшки (таблицы). веб путь к данным домино формируются следующим образом: [доменное имя]/[путь к базе данных внутри директории данных сервера]/[имя файла базы данных]/[вид или таблица, содержащая необходимый нам документ с данными]/[уникальный идентификатор документа или ключ из первой сортированной колонки]/[имя поля в документе]/[данные]. '0' - это системная таблица, содержащая все документы базы. она неявно присутствует во всех базах данных. из нее доступ к документу можно получить только по униду. ее можно перебить, явно создав вид с именем '0'. : @Text(@DocumentUniqueId) - это уникальный идентификатор документа, представленный в виде текста (по умолчанию, идентификатор возвращается в виде объекта). как получить? вот так и получить функция его вам вернет. вообще-то, я написал готовую формулу. просто копи/пасте сделайте в колонку, и все. : "/$file/" - имя поля, содержащее все вложения документа, это я писал в предыдущем посте. : @AttachmentNames - эта функция вернет список имен всех вложений документа. поскольку этот список в нашем случае является одним из суммируемых текстовых значений формулы, на выходе мы получим список ссылок на все вложения одного документа (сложения списков в этом случае работают по такому примеру: a + b;c + d;e;f = abd;ace;acf). эту формулу следует разместить как значение колонки. тогда через ODBC вы достанете массив путей к соответствующим вложениям. можно в колонке сразу задать тег ссылки, чтоб потом меньше париться с обработкой полученных значений. например, так: "<a href=\"/"+@WebDbName+"/0/"+@Text(@DocumentUniqueId)+"/$file/"+@AttachmentNames+"\">"+@AttachmentNames+" ("+@Text(@AttachmentLengths)+"</a>". тут появилась новая функция: @AttachmentLengths - числовой список размеров вложений документа в байтах.

вложения в базах домино возможны только в ричтекстовых полях. ричтекстовые поля не могут высвечивать свое содержимое в таблицах (вьюшках). также, если вы собираетесь получать доступ к вложенным файлам через веб, для вас файлы вообще не будут находиться в полях (точнее, все вложения из всех полей будут в едином системном поле '$File'). итого, чтобы решить вашу задачу, вам нужно в колонке таблицы, где вы выводили файлы вложений, прописать конструкцию ссылки на вложения. путь к вложениям выглядит следующим образом: "/"+@WebDbName+"/0/"+@Text(@DocumentUniqueId)+"/$file/"+@AttachmentNames

"Отражение лишнее,.." - вообще-то, сайт о воде. остальное можно признать объективным, спасибо. В принципе, шапку я не придумал. мне кажется, это простая работа, сделанная в вордовском ВордАрте. Она взята из одного из постеров, который распространяет хозяин у себя по району. Согласно предыдущей критике, выжимаю из владельца нормальные фоты, в том числе отцентрированные фоты карниза над входом для новой шапки. Пока с этим проблема по природным причинам. Сделаю, попрошу переоценить

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

ну, и зачем здесь сайт выкладывали, если всю критику сходу отвергаете? к таблицам плюс: <i></i> : пустые тэги. видимо, для отступов между линками, но это как-то дико <p><br /> : первый символ во всех параграфах с метками - перенос строки. а стили зачем тогда? скорость в киеве нормальная, грузится комфортно.

а проблема-то в чем? и где проблемный вариант?

на каждой странице двум пунктам (одному слева, одному сверху), который обозначает линк на текущую страницу, присваиваем индивидуальный класс (допустим, "curL" левому пункту и "curT" верхнему). в css описываем стиль этих классов: цвет - color:#rrggbb; подчеркивание - text-decoration:none; кружочек - list-style-image:url('путь к файлу'); левое меню собираем в список (<ul><li>...)

чуть поправил, спасибо!

to Justnewone, still swamp, eVErl@Sting: хорошо, спасибо. буду настаивать на чистых фотах оборудования и стен с графити. кодировка - реальная лажа, отдельное спасибо. про украину: он выходец отсюда и для него это некий символ там, мы этот момент обсуждали. выход: я наверное сделаю английскую страницу для той ссылки на украину.

ок, принято, спасибо. а как с версткой и доступностью хоста?

Всем привет. Пожалуйста, оцените сайт. Сделал для своего американского дяди, для его семейного бизнеса. То есть, сайт маленькой частной конторы, сугубо бизнесовый. Я до сих пор не дизайнер, потому сильно за дизайн не критикуйте (вернее, его отсутствие), но оценку все же прошу полную. Оцените плиз: - впечатление от внешности - верстку, стили - юзабельность, вменяемость - доступность Ссылка: http://oleksawater.com/ Буду благодарен за любую критику, огрызаться не буду.

в футере надпись "ООО "ЗАЛКОН" © 2010" съезжает вверх. в ie8 нормально, в опере половина вылезла с футера, в хроме и сафари вообще убежала вверх под новости. у вас во внешней таблице объединение правых ячеек при том, что в левом столбце верхняя ячейка безразмерная по высоте, нижняя фиксированная. либо перекроите таблицу так, чтоб футер был в одной строке по всей ширине, либо в нижней левой ячейке отталкивайтесь от нижней границы, а не от верхней. вот так: было: <td height="100px" valign="top"> <div style="margin-top:29px;"> <p style="color:#999999" id="footernew" align="left">ООО "ЗАЛКОН" © 2010 <br /> стало: <td height="100" valign="bottom"> <div style="margin-bottom:29px;"> <p style="color:#999999" id="footernew" align="left">ООО "ЗАЛКОН" © 2010 <br />

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

во-первых: весь код пишется вручную. ширина 300px выставляется вручную. маргины не подбираются, как вы пишете, а четко считаются: [фиксированная ширина среднего блока]/2. в наших примерах еще плюс стабильные 3 вправо 4 влево пикселя на совместимость с ie6 не зависимо от ширины среднего блока. во-вторых: это еще как-то можно за минус засчитать. но неужели у вас объекты в дивах будут без отступов от краев? ок, накидал еще вариант. абсолютно без отступов где бы то ни было: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <title>Untitled</title> <style type="text/css"> body{margin:0;padding:0;} .d1{position:absolute;left:0;width:50%;} .d1 div{margin-right:150px;background:orange;} .d2{margin:0 auto;width:300px;background:yellow;} .d3{position:absolute;right:0;width:50%;} .d3 div{margin-left:150px;background:orange;} </style> </head> <body> <div class="d1"><div>блок-контент 1</div></div> <div class="d3"><div>блок-контент 3</div></div> <div class="d2">блок-контент 2 (ширина задана,фикс)</div> </body> </html>также проверено во всех браузерах, включая ie6. надеюсь, тоже чем-нибудь не понравится...

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

to sigma77: в ie6 среднего блока нет

допустим, вот такой вариант: Код<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html> <head> <title>Untitled</title> <style type="text/css"> body{margin:3px;padding:0;} .d1{float:left;margin-left:-154px;width:50%;} .d1 div{margin-left:154px;background:orange;} .d2{margin:0 auto;width:300px;background:yellow;} .d3{float:right;margin-right:-153px;width:50%;} .d3 div{margin-right:153px;background:orange;} </style> </head> <body> <div class="d1"><div>блок-контент 1</div></div> <div class="d3"><div>блок-контент 3</div></div> <div class="d2">блок-контент 2 (ширина задана,фикс)</div> </body> </html> проверено во всех браузерах, включая ie6.to airscape: очень странные слова. абсолютное непонимание темы я наблюдаю. указание стандарта - это инфа от вас, на каком вообще языке вы ответ хотите получить. вы же спрашивали не в принципе, как сейчас пишете, вам нужен был конкретный работающий код. если вам нужен был ответ на заборе, то сказали бы хотя бы это.

могу. требуется ТС. сейчас всплыло, что человеку требуется не совсем то, что он описал. если крайние блоки должны не ресайзиться от центра до краев в зависимости от контента, а иметь размер от центрального блока до краев, это верстается совсем иначе. требуется уточнение от автора темы.

отвечаю по пунктам: 1. из-за кратости не указав стандарт, вы получите ответ не в том стандарте, на котором пишете. 2. это работает годами в старых стандартах. посмотрите, что будет с таким объявлением величин в xhtml. 3. способ отмены обтекания вы выбрали красивый. однако, мы стараемся код минимализировать. ie6 не понимает xhtml. это единственный недостаток моего примера. хотите, напишу под старый стандарт. 4. я не использовал танцы с бубнами. так это выглядит для тех, кто не понимает сути происходящего. -150px (не -180 или чего еще) потому, что вы поставили в задаче фиксированный размер центрального блока в 300px. отсюда, смещение от центра левого блока на 150px влево, правого на 150px вправо. левому смещение необходимо задать явно. я думал, это понятно. 5. "не универсальный способ, потому что есть какие-то конечные величины в маргинах" - мне показалось, что в самой постановке присутствует фиксированная величина. уберете фиксацию ширины центра, отпадет необходимость фиксированного смещения влево. ну да ладно 6. "Кроме того, крайние блоки не тянуться до краёв (блоки 1,3) как это предполагалось." это уж совсем интересно. именно что тянутся! тянутся в зависимости от своего наполнения аж до самих краев. если вы хотели сказать, что они должны иметь размер от центрального блока до самого края, то это более простая задача. уберите вложенные <span> и пишите текст крайних блоков прямо в их дивах. будет вам сразу размер крайних блоков до краев. за свои более чем 10 лет верстки я неплохо себе представляю, что и как можно сверстать таблицами. к сведению, это начальный уровень верстки, мы все через это проходили. его наследие и не позволяет легко верстать блоками (мне в том числе, привычная логика - злая вещь). однако, я говорил не о статичной одноразовой верстке страницы (это в прошлом), а о динамичной, гибкой, управляемой. видимо, пока у вас нет такой необходимости. еще, мне кажется плохо, когда человек считает, что какие-то методы и свойства имеют свое конкретное предназначение, возможное использование их "не по назначению" это плохо. в этом случае, человек загоняет себя в некие отведенные рамки, о чем я говорил раньше. тогда, где найдется простор для полета фантазии? или фантазия - не для данной специализации? пользоваться нужно возможностями, а не предназначениями. тогда все получится легко и просто. сорри, больше оффтопить не буду если спросите вариант под старые браузеры - напишу.

вот мы и скатились к тому, чего я так хотел избежать (писал в первом посте). эта тема не о выборе платформы, и даже не о плюсах/минусах домино. я хотел найти разработчиков на этой системе для обмена опытом. если вашу тему развить, то я согласен с предметной частью вашего поста, но не согласен с результативной. если домино так не популярен как веб платформа, на то действительно есть серьезные причины. однако, из этого не следует, что он ничего из себя не представляет. кстати, вы ошибаетесь, что он не взорвал аудиторию, в свое время взрыв был ошеломляющий. домино более двадцати лет, это единственная не реляционная база данных, дожившая до наших дней и успешно развивающаяся по сей день уже под флагом IBM (последний серьезный релиз был год назад). то, что из-за него фирма Лотус была куплена с потрохами АйБиеМом (замечу, не в состоянии банкротства), тоже что-то значит. я думаю, основное отсутствие популярности в вебе потому, что http для domino не основная задача. она была реализована в свое время как дань моде для расширения сферы влияния. поскольку даже сам производитель не заявляет о домино как о веб платформе, домино даже не рассматривается сообществом, как один из вариантов. к тому же, у IBM имеются продукты, более специализированные именно для веба, зачем ему внутрення конкуренция? думаю, здесь кроется корень не популярности. конечно, не стоит поднимать такую махину ради пары сайтов. для провайдеров это уже имело бы смысл, но не раскрученность платформы не даст достаточного количества клиентов (хотя у нас в киеве я знаю пару-тройку провайдеров с доминошной площадкой). идеальной платформой домино будет для каких-то масштабно-глобальных веб проектов. если проект базируется на множестве кластерных серверов, да еще если эти сервера находятся, скажем, в разных странах, если команда разработчиков сильно рассредоточена (всеядный механизм репликации/кластеризации домино является признанным лидером по этой части задач). тогда для реальных знатоков подобрать альтернативу будет уже не просто. по поводу прожорливости монстра, домино сервер у меня прекрасно живет на презентационном ноутбуке. согласен, для поддержки пары сотен тысяч зарегистрированных клиентов потребуется железяка помощнее у меня нет вопроса выбора веб платформы. домино - моя профессиональная среда, которая меня кормит. я не специализируюсь конкретно на веб разработках под домино. часто это офисные клиентские приложения. хотя, чем дальше, тем больше даже офисных приложений пишется с веб интерфейсом. заводить на своем сервере кучку веб/бд/меил серверов при наличии домино не имеет смысла. потому, здесь хотел обмениваться опытом именно по вебу под домино. кстати, у него нет сурового лицензирования, платный он для коммерческого использования. если вы в состоянии сами разобраться, пожалуйста. ломать, искать лицензионные ключи для установки, обходить регистрацию не придется. все открыто, никаких триалов. с любой инсталляцией идут полнейшие руководства пользователя, админа, разработчика (лучше любой справочной литературы).

<html> <head> <style> .content{ margin:0 auto; width:800px;/*ширина твоего сайта*/ } </style> </head> <body> <div class="content"> <!--вместо этой строки пишешь тело своей странички--> </div> </body> </html>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html profile="http://www.w3.org/2005/10/profile"> <head> <title>Untitled</title> <style> body{ margin:10px; padding:0; } </style> </head> <body> <div style="float:left;width:50%;margin-left:-150px;padding:1px 0;text-align:right;"><span style="border:solid 1px red;background:orange;">блок-контент 1</span></div> <div style="border:solid 1px red;background:yellow;float:left;width:300px;text-align:center;">блок-контент 2 (ширина задана,фикс)</div> <div style="padding:1px 0;text-align:left;"><span style="border:solid 1px red;background:orange;">блок-контент 3</span></div> </body> </html> 1. всегда нужно писать, в каком стандарте html вы верстаете (doctype). в разных стандартах разметка формируется по разному, разные браузеры разные стандарты по разному воспринимают 2. всегда в стилях следует писать, в каких единицах измерения вы указываете размеры/отступы (border:solid 1 red; - ошибка) 3. float включает обтекание объекта, он не говорит выстраиваться объекту в линию с обтекаемыми. в вашем случае два дива обтекаются третьим. третий див ничем не обтекается. поскольку вы ошибочно поставили обтекать и его, вам пришлось вставить совершенно ненужный див, отключающий обтекание. 4. блочная разметка действительно сыровата. но не в стандартах и браузерах, а пока что у вас. таблицами действительно проще и быстрей сверстать простую страницу с нуля. но вы попробуйте изменить страницу с табличной версткой и блочной. поменять местами объекты, изменить размер/позиционирование отдельного объекта в дизайне, создать что-то многослойное и динамичное. блочная верстка намного более гибкая, дающая намного больше возможностей верстальщику. пока вы не освоили всю ширину и возможности предоставленной свободы, действительно комфортней (проще, легче) находиться в более узких рамках. это имхо, абсолютно не в обиду. я сам этот мир только изучаю.

соль это способ организации данных в домино: все, что необходимо для работы конкретной прикладухи, находится в едином файле. все формы, страницы, папки, таблицы, все графические элементы, скрипты, библиотеки. все данные, накапливаемые в процессе функционирования, находятся там же. то есть, взял файлик, скопировал на флешку, перенес домой, и все работает. для разработки сайтов удобным является поддержка таблиц стилей, ява и яваскрипт библиотек с некоторым редактором. также сильно упрощает жизнь использование подформ (шареный кусок формы; типа, сделали две html подформы (хидер и футер), рассовали по всем страницам, и меняем только в одном месте), шареные поля (в поля можем загонять пути к ресурсам, навигаторы, любые вычисляемые данные), шареные колонки таблиц, мультиязычные элементы (типа, создав две формы под одним именем, указав у одной русский язык, у другой албанский, сервер сам покажет ту форму, которая соответствует языковой настройке браузера посетителя). на таблицах очень легко и быстро можно организовать что-то вроде гостевой, блогораздела, комментирования страниц (всего, что требует постить инфу). авторизация и профилирование пользователей также делается элементарно. кроме прочего, у домино очень мощная почтовая часть, которая также является неотъемлемой частью сервера баз данных (каждый почтовый ящик пользователя это также база данных определенного формата). то есть, любой почтовый функционал, необходимый сайту (рассылки, уведомления, напоминания, вплоть до полноценных личных почтовых ящиков с веб интерфейсом для зарегистрированных пользователей) делается в два щелчка. главное достоинство - домино работает на два фронта всегда: офисная сторона (ноутс) и внешняя (веб). ноутс - это доминошный клиент под винду, линукс или мак. для него и разрабатывают все кросс-платформенные прикладухи на домино, забывая о внешней стороне домино сервера. в случае использования домино в качестве веб сервера, на ноутс можно легко и очень функционально организовать бекэнд сайта любой сложности. контроль логов, постов, редактирование разделов, содержимого страниц, управление авторизацией и т.п. хотя все это можно и под веб написать, но это дольше и ресурсоемче. обычно, под веб на домино пишут упрощенные бекэнды. основная фигня в том, что при доступе к базе данных через http, домино сервер сам на автомате преобразовывает все формы, страницы и таблицы в html, и делает это очень неуклюже. потому, большинство так называемых домино разработчиков и говорят, что домино абсолютно не подходит для веб разработки. это самое большинство разработчиков ни html кода толком не знают, ни глубинного функционала домино. для меня главным в этом вопросе является то, что домино позволяет деактивировать его автоматическую ретрансляцию дизайна в html и выписать весь код вручную. а используя возможности домино структуры не по назначению, мы получаем чудесные вылизанные легко поддерживаемые веб приложения. я сейчас практически не пишу для ноутс клиента, создавая все нужные функции под веб. считается, что домино под веб абсолютно не приспособлен, что он настолько каструбатый, что сайты на нем все на одно лицо с торчащими во все стороны хвостами, которые невозможно скрыть. я считаю, что их не нужно создавать для того, чтоб потом нужно было скрывать. итого: домино - платформа многофункциональная. html это одна из множества его задач. основная задача домино - сервер не реляционных баз данных, на которой базируются все остальные задачи. насколько домино полнофункционален в качестве веб сервера не знаю, нет сравнительного опыта. здесь присутствуют айпишные листы, порты, восьмиуровневая система доступов с подключаемыми ролями, ssl3 (rc4, des), всевозможные переадресации, виртуальные домены и куча еще другого, мне хватает . как почтовый сервер он полнофункционален точно. все это варится в одной кухне, использует одну структуру данных, объектов, единую среду разработки. я совершенно не знаю, чем домино отличается от мускула, постгрейса, иис, вебсферы, аппач и всего остального. к моему искренне глубокому сожалению, я очень узкий специалист