Личная страница пользователя...

[JohnLemon]

Здравствуйте, можете подсказать как реализовать личную страницу пользователя с фоткой, то есть что бы у каждого юзера была своя фотка и сссылка на фотку желательно сохранялась в документе тоже? Сейчас загружаю через компонент file Download, в документ пользователя, который создается с привязкой через notes name, в данном варианте не понимаю как получить ссылку на док и записать ее в тоже в поле для дальнейшего использования. Подскажите как лучше это все реализовать или ссылочкой помогите плз ) ?

 

[alexas1]

Сейчас загружаю через компонент file Download, в документ пользователя, который создается с привязкой через notes name,

Круто!
А чем RT поле, в хепаге, показывающей "документ пользователя", не устраивает?
Если там ничо нет - драг-енд-дропишь туда, из проводника Win например, фотку и сохраняешь док в базе.
Можешь играть двумя полями: одно, computed - для показа, другое - для редактирования.
Ну и, одно скрываешь, другое показываешь. Или редактируешь (драг-енд-дропишь) в модальном окошке с RTE.
А док юзверя можешь взять из вида с доками пользователя по ключу name (по первой сорт. колонке).

 

[JohnLemon]

Блин RT поле не пробовал, но мне кажется это как то не почеловечески ). А есть ссылка как это сделать? как скрыть кнопки у рт поля? Просто потом может понадобиться что то в роде аватарки, и т.д. Да и я боюсь рт, данные не потерять бы, пока не очень понимаю как они работают ).

 

[alexas1]

как скрыть кнопки у рт поля

<xp:inputRichText id="inputRichText1">
<xp:this.dojoAttributes>
<xp:dojoAttribute name="toolbar">
<xp:this.value><![CDATA[#{javascript:var customToolbar="[]";
return customToolbar;}]]></xp:this.value>
</xp:dojoAttribute>
</xp:this.dojoAttributes></xp:inputRichText>

 

[NickProstoNick]

Никаких RT-полей.
Фотки только отдельным файлом и ссылкой.

Достучаться до фотки можно через вид.
Первая сортированная колонка (ключ) lotus-имя.. желательно короткое, но уникальное.
А в url-картинки ссылка в формате "/<вид>/<ключ>/$File/<имя файла>"
Это вариант хорошо сработает, если файлы будут закачиваться с одним именем.
Если имена файлов будут оставляться оригинальные - то придется лукапить

 

[alexas1]

Никаких RT-полей.

Почему?

 

[NickProstoNick]

потому что RT-полю свойственно ломаться, если поле сохраняется в WEB и в толстом клиенте.
Ну и по хорошему - а зачем хранить фото в RT-поле?
Говорю из личного опыта - со временем понадобится хранить несколько копий фотографии разных размеров.
И как быть в этом случае?

 

[JohnLemon]

Ну и по хорошему - а зачем хранить фото в RT-поле?

Вот и мне не нравиться, но не могу понять где хранить, как сохранять и как получить ссылку на фотку. Хтелось бы хранить просто в какой нибудь папке. Просто бредово как то, а если нужна будет галерея, делать тупо кучу доков ?

Никаких RT-полей.

Подскажи плз как их избежать ? Если можно ссылочкой на пример)

 

[NickProstoNick]

Ссылки на пример нет. Самый простой вариант - обычные атачи, но не эмбэдэд! Тут по сути будет RT-поле, но его можно будет удалить. Только аккуратно, потому как при удалении RT-поля удалятся и атачи. А дальше светишь фотку тегом img. Ссылку я тебе описывал выше.
Если надо грузить пачку-фоток и сохранять в директорию - тут все немного сложней. Тут надо писать отдельную страницу-загрузчик.
Надо ловить событие на сервере и детачить файлы в нужную тебе директорию.
Конечно можно и не ловить событие, запускать агент после загрузки фоток. Тут уж сам решай.
Еще одна проблема - загрузка пачки файлов. IE не позволяет выделять пачку файлов. Тут надо отдельный модуль на флеше. В инете есть уже готовые решения, но мне они не подошли. Я переписал по своему.

 

[rinsk]

IE не позволяет выделять пачку файлов.

Уточнение - IE9 и ниже.

 

[NickProstoNick]

Уточнение - IE9 и ниже.

Если в компании найдется хоть один, с таким софтом - все остальное не важно )))
Но в общем согласен

 

[JohnLemon]

Я так понимаю сохранения в РТ поле все равно неизбежно ?

 

[rinsk]

потому что RT-полю свойственно ломаться, если поле сохраняется в WEB и в толстом клиенте.

имхо в xpage перемудрили с еммбед картинками и аттачами...
link removed

 

[NickProstoNick]

имхо в xpage перемудрили с еммбед картинками и аттачами...
link removed

Это не эммбед, а аттачи.
И это не новшество xPages.
И кроме того, файлы в базе - зло! Объем и тормоза!
А пользователю не всегда расскажешь, что нельзя большие фотки слать.
У нас, к примеру, есть любители слать фотку по 12-16МБ. А если умножить это на 2500-3000 пользователей, которые пришлют хотя бы по одной фотографии... что с базой станет?
Нет, ну конечно можно включить DAOS, но тут возникают свои нюансы с бекапированием и восстановлением

 

[rinsk]

@NickProstoNick, при всем уважении - реч идет о том, что в xPages перемудрили с URL аттачей и так же внедренных картинок. Из за этого те же внедренные картинки и бьются и режутся в обычном клиенте, а аттачи вылетают из РТ поля. Во всяком случае у меня - при работе с штатным едитором.
Если исключить вмешательство LN клиента - то все работает вполне корректно. В том числе несколько (2-3) РТ полей для картинок аватара разных размеров.

И кроме того, файлы в базе - зло! Объем и тормоза!

Имхо тема для отдельной ветки

 

[JohnLemon]

Дак все таки может кто нибудь подсказать как сохранить картинку что бы она не никуда потом не пропала на ssjs ??

 

[NickProstoNick]

@NickProstoNick, при всем уважении - реч идет о том, что в xPages перемудрили с URL аттачей и так же внедренных картинок. Из за этого те же внедренные картинки и бьются и режутся в обычном клиенте, а аттачи вылетают из РТ поля. Во всяком случае у меня - при работе с штатным едитором.
Если исключить вмешательство LN клиента - то все работает вполне корректно. В том числе несколько (2-3) РТ полей для картинок аватара разных размеров.

Имхо тема для отдельной ветки

тут даже не о чем говорить. Говорю из личного опыта.
Для своих нужд разрабатывали фото-видео -галерею. Объем загруженных файлов превышает 64ГБ.
Ни для кого не секрет, что базы Lotus ОЧЕНЬ плохо работают при объемах близких к 64Гб. Ну и опять же... полезная нагрузка базы. Давай сравним две базы... 64Гб с фотками и 64Гб текстовых данных (с теми же путями к фотографиям ).
Кроме того - большие объемы файлов сильно сказываются на скорости загрузки и обработки страницы. С этой целью делаются превью фотографий меньшего размера, а это еще +к общему объему.

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

 

[NickProstoNick]

Дак все таки может кто нибудь подсказать как сохранить картинку что бы она не никуда потом не пропала на ssjs ??

Я пользуюсь SWFUpload. В интернете много информации по этому поводу.
Я сохраняю файл по событию beforeRenderResponse.

Код

var con = facesContext.getExternalContext();
var response = con.getResponse();
var request:com.sun.faces.context.MyHttpServletRequestWrapper = con.getRequest();
var map:java.util.Map = request.getParameterMap();
var fileDataName = "Filedata"; //name of the POST request parameter that contains the file
var fileData:com.ibm.xsp.http.UploadedFile = map.get( fileDataName );
var tempFile:java.io.File = fileData.getServerFile();
var correctedFile = new java.io.File( tempFile.getParentFile().getAbsolutePath() + java.io.File.separator + fileData.getClientFileName() );
var success = tempFile.renameTo(correctedFile); //rtFiles is a rich text item on a notesdocument of your chosing
 
// сохраняю файл в новый документ.
var docParent: NotesDocument = database.getDocumentByUNID( param['id'] )
var doc: NotesDocument = database.createDocument()
var rtFiles: NotesRichTextItem = doc.createRichTextItem( "body" )
doc.replaceItemValue( "Form", "Post" )
doc.replaceItemValue( "Type", "photo" )
doc.replaceItemValue( "FileName", correctedFile.getName() )
doc.replaceItemValue( "Description", correctedFile.getName() )
doc.replaceItemValue( "onProcess", "1" )
rtFiles.embedObject(lotus.domino.local.EmbeddedObject.EMBED_ATTACHMENT, "", correctedFile.getAbsolutePath(), null);
doc.makeResponse( docParent )
doc.computeWithForm( false, false )
doc.save( true, false, true )
 
correctedFile.renameTo(tempFile);
 
//response.setStatus(200);
var writer = response.getWriter();
response.setContentType("text/xml");
response.setHeader("Cache-Control", "no-cache");
writer.write( doc.getUniversalID() );
 
facesContext.responseComplete();
//return

Но тут можно написать копирование фала сразу в нужную директорию.
Если на сервере Windows - думаю можно попробовать ActiveXObject.
Но я бы стал копать в сторону Managed Beans.

 

[NickProstoNick]

можно попробовать

Ссылка скрыта от гостей

Один нюанс сохранения файлов на диск - директория с файлами должна располагаться в WEB-директории сервере Lotus! иначе по hhtp файлы грузиться не будут.
Чтоб снизить нагрузку на http - у меня развернут ftp-сервер и все файлы грузятся по ftp. В таком случае директория должна находиться на ftp

 

[rinsk]

фото-видео -галерею

Если не использовать DAOS - то это точно в базах домино хранить не стоит. И даже с DAOS - есть ограничение на саму базу daoscat.nsf.

Давай сравним две базы... 64Гб с фотками и 64Гб текстовых данных (с теми же путями к фотографиям ).

Это известное ограничение архитектуры - кто то с этим спорит ?))

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

В общем то об этом и идет разговор - у чел явно не мильон аватаров))) И в данном контексте было уточнение - почему "бьются" РТ поля. И в каждом конкретном случае есть разные варианты решения задачи - где то внедренные картинки - где то аттачи. А где то и на DICOM сервере