» MetaProducts Inquiry

Цитата:

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

А можно подробнее - как реализовать поиск по ссылкам? Пока наша идея - считать ссылку как документ и если в папке со ссылками идет поиск, то искать ключевые слова прямо в документах, на которые ведет ссылка.


Цитата:

Некоторое значение для меня имеет и объем архива, возможность редактировать HTML (здесь пока альтернативы CyberArticle нет),

У нас есть редактирование сохраненных страниц - визуальное. Нужно еще редактирование HTML кода?


Цитата:

возможность превратить экспортировать архив в хорошо организованную папку с веб-документами (опять CyberArticle).

У нас есть экспорт. Он не такой как нужно?


Цитата:

Недавно я встретил в инете программку-костыль, которая позволяет сохранять фрагменты документов из Оперы в ContentSaver.

А можно название программы? Спасибо!

OlegChernavin

Цитата:

Нужно еще редактирование HTML кода?

ну да, об этом здесь уже писали...

OlegChernavin
Можно ли добавить поиск в экспортируемых ехе-файлах?

twigs
А почему при большом количестве виртуальных папок начинается бардак?
И я не понял противопоставления виртуальных папок в CyberArticle и категорий в ContentSaverе. Правда я их серьезно не использовал, так что наверно представляю детали работы в них довольно поверхностно. Но как я понял в ContentSaverе есть две модели представления (хранения) данных. Первая - простое дерево в катором физически хранятся страницы. Вторая - категории (они же виртуальные папки) в которых хранятся ссылки на страницы в основном дереве.
Мне сейчас нравится идея оставить только виртуальные папки, а жесткую привязку страницы к папке выбросить. Но это пока общая идея, и когда и как она будет реализована (если будет), пока сказать нельзя.
Так что если у кого есть идеи, как должно быть организовано идеальное хранилище веб-страниц, пишите. Пригодится.

softes
ну вообще-то ехе-файл представляет из себя зип-архив, и поиск в нем возможен средствами winrar к примеру...

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

Ну, в принципе, можно и в .exe прикрутить поиск. Это будет не очень уж сложно.

Добавлено:
Просто мы пока не знаем, насколько часто используются такие экспортированные .exe файлы и насколько востребован будет такой поиск.

OlegChernavin

Цитата:

Просто мы пока не знаем, насколько часто используются такие экспортированные .exe файлы и насколько востребован будет такой поиск.

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

Спасибо!

anfilat
а можно узнать, что за логи у меня в папке
C:\Documents and Settings\user\Local Settings\Application Data\MetaProducts\Inquiry\logs
можно ли их грохнуть или они нужны для работы программы?
а то их уже 23 метра накопилось... а у меня на мусор аллергия

pop2ROOT
Пришли пожалуйста несколько последних, и грохай.

OlegChernavin
Олег, в Inquiry предусмотрено использование плагинов для автоматизации сохранения страниц. Приводимый в качестве примера сценарий по сайту еbay не использует все атрибуты, возможные в программе (я имею ввиду вкладку "Данные"). Не могли бы более подробно рассказать как задействовать указанные поля.

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

Жаль. Потому что данная возможность очень нужна потенциальным покупателям из корпоративного сектора. Существующие программы типа КонтентСейвера и НетСниппетса тоже не ахти. Более близок НетСниппетс. Если вы позиционируете свою программу как каталогизатор, то опция по автоматизации работы будет очень востребована, поскольку это будет представлять уже инструмент DataMining. И стоить он будет других денег.
Есть идеи на счёт технической реализации этого. Если интересует - могу прояснить.

Конечно интересует. Если там не трудно будет сделать, то появится уже в ближайшей версии. Спасибо!

Сначала кратко - постановка задачи. Текущая деятельность - маркетинговые исследования. Приходится анализировать материалы в ежедневном режиме по 20-30 сайтам. Много, но список их боле-менее ограничен. Соответственно, интересующие материалы сохраняются и предпринимается попытка всё это вогнать в корпоративную базу данных.

Идея решения подразделяется на две составляющие: 1) автоматизация занесения классифицирующих признаков и 2) передача сохранённой информации в общую базу данных.

1. Исходим из того, что список анализируемых сайтов ограничен. У каждого сайта есть своя, боле-менее постоянная во времени структура страницы, информация с которой и должна быть сохранена. Значит, проанализировав структуру страницы пользователь может указать в плагине набор правил, в соответствии с которым он может указать, что соответствует на странице каким классифицирующим полям. В кратце вот так.

2. Передача данных в общую базу данных. Если сохраняемые программой страницы сделать в формате XML, то проблем не будет. Грубо говоря, XML описывает поля классификации и одно поле - само содержание страницы. Думаю, это будет реализовать не так сложно.

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

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

Удачи в разработке нужной проги.

А что если попробовать Offline Explorer Pro в связке с TextPipe. Первый будет скачивать нужные сайты и передавать их второму, который имеет очень широкие возможности по обработке и преобразованию текстов.

Олег, если подходить с этой точки зрения, то зачем, мягко говоря, вы выпустили Inqury, если для реализации практически тех же задач можно использовать Офлайн с связке с другими программами? Это на сколько увеличится трудозатраты? Тогда проще всё ручками вбить в Inquiry да и делов!
Поэтому, если вы встроите некоторые возможности TextPipe в свою программу, то выиграете вы, а не они. И потом, можно чётко сформулировать цель, которую вы ставили при разработке Inquiry?!

AAG
Какая именно цель ставилась сказать трудно, но могу сказать как я ее понял. Inquiry (в девичестве Research Assistant) это инструмент для собирания (коллекционирования) информации из браузера. Собирается она с двумя целями - 1) чтоб не пропала при удалении оригинала с сайта, 2) чтоб ее можно было достаточно быстро найти, когда потребуется. Вопрос о дальнейшей обработке сохранненой массы страничек пока серьезно не рассматривался.
В общем это браузеро-зависимый ПИМ расчитанный на интерактивную работу одного человека с отдельными страницами, а не для автоматической обработки большого количества данных. Примерно так я для себя определяю разницу между Inquiry и Offline Explorer.
Хотя кажется вашу задачу можно вписать в Inquiry. Технология примерно такая - есть папка с набором страниц, при выполнении команды update страницы поочередно грузятся в webbrowser, после загрузки каждой страницы в нее внедряется и запускается ява-скрипт(ы). Это уже есть. Что надо добавить - возможность из яваскрипта запрашивать какие-то дополнительные данные у Inquiry и возможность возвращать не одну переменную как сейчас, а список имя переменной - ее значение. Плюс экспорт этого списка в XML. При этом основная нагрузка ложится на автора скриптов. Если такой вариант устраивает, то можно попробрвать сделать.

anfilat
Такой вариант полностью устраивает. Именно это я пытался донести. У textpipe всё-таки более глубокая обработка текста, а излишняя функциональность меня тоже не интересует, да и не готов за неё платить.

anfilat

Цитата:

twigs
А почему при большом количестве виртуальных папок начинается бардак?
И я не понял противопоставления виртуальных папок в CyberArticle и категорий в ContentSaverе. Правда я их серьезно не использовал, так что наверно представляю детали работы в них довольно поверхностно. Но как я понял в ContentSaverе есть две модели представления (хранения) данных. Первая - простое дерево в катором физически хранятся страницы. Вторая - категории (они же виртуальные папки) в которых хранятся ссылки на страницы в основном дереве.
Мне сейчас нравится идея оставить только виртуальные папки, а жесткую привязку страницы к папке выбросить. Но это пока общая идея, и когда и как она будет реализована (если будет), пока сказать нельзя.
Так что если у кого есть идеи, как должно быть организовано идеальное хранилище веб-страниц, пишите. Пригодится.

Разница между ContentSaver и CyberArticle - в количестве категорий, приходящихся на одну статью.
В CA есть дерево, где статьи разложены по папочкам, и аналогичное виртуальное дерево, где статьи разложены по виртуальным папочкам. ВСЁ. НА одну статью приходится ОДНА реальная и ОДНА виртуальная папка. НЕ больше. Кроме того, ты не можешь просто так положить реальную статью в виртуальную папку. Нужно писать название папки почти каждый раз (в контекстном меню названия виртуальных папок запоминаются ненадолго - если не ошибаюсь, до выхода из программы). В общем, сплошной геморрой и неудобство, хотя у китайской программы есть преимущества перед немецкой в других областях (к примеру, возможность преобразовать архив в настоящее дерево папок, редактирование HTML - пусть глюкавое, но оно есть и часто бывает полезно).
В CS одной и той же статье можно присвоить сразу несколько категорий. Кроме того, прекрасно реализован поиск по категориям. То есть в огромном архиве не составит труда найти статью. Поэтому и бардака нет. Это делает CS на данный момент самой удобной программой в плане поиска статей.
Что же касается реальных папок и нужны ли они. МНе кажется, что они желательны, хоть и не жизненно необходимы. Почему желательны? Потому что что при преобразовании архива в каталог с HTML-документами (как в CA) реальные папки сохраняются, а виртуальные - нет.

Теперь об идеальном хранилище. Мне кажется, важны такие вещи, как поиск (это главное!), возможность объединения архивов и конвертирования архивов в простой каталог с документами (и подкаталогами), редактирование HTML-кода (не обязательно, это скорее бзик). О таких вещах, как совместимость с браузерами, возможность сохраннеия фрагментов статей, не говорю - это само собой разумеется. Оптимизация архивов тоже сама собой разумеется.
Главное - поиск. ДЛя описка очень важны категории.

twigs
Поддерживаю.
Дополнительно добавлю (как я понимаю) - что такое виртуальные папки?! - не те же самые ли ключевые слова (параметры, способ каталогизации и т.д.)?!!! Это я таким образом подвожу к соприкасаемой задаче, изложенной выше

anfilat
Сохранение в Юникод работает хорошо. Но почему-то при экспорте "по-новомодному" сохраненных страниц/папок в формат .ехе, при открытии этого экзешника, наблюдается явление известное как "кракозябры" (в галерее тамбнейлов, оно же оглавление). При этом кодировка самих страниц - юникод. Вот бы еще само оглавление юникодить, а?

Просьба добавить возможность "включать" запрос сохранения (куда и под каким именем) в случае необходимости. Имеются в виду не подтверждения "такая-то страница сохранена туда-то" уже после сохранения, а перед ним, как при выборе из меню "save to another folder". Т.е., такая возможность фактически есть, сделать бы ее поближе, а то она глубоко запрятана. Например, раньше (в пред. версиях) выдавалось меню перед сохранением, если нажимать на кнопку в боковой панели (символ Энквайери). Или сделать доп. строку в контекстном меню браузера - "сохранить в ... папку" (наряду с существующим, которое переименовать в "сохранить в папку по умолчанию").

softes

Цитата:

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

Да про экспорт в exe в забыли, сейчас поправлю.


Цитата:

Просьба добавить возможность "включать" запрос сохранения (куда и под каким именем) в случае необходимости

Есть такое - Параметы\Интеграция\показывать окно диалога при использовании\Кнопка - сохранить

anfilat
Спасибо. Исчерпывающий ответ.

Но, чтобы на этом не останавливаться: может, в окне диалога перед сохранением, добавить (рядом с "удалить скрипты") и радио-батон "Конвертировать в Юникод"? Просто страницы на английском нет смысла (насколько понимаю) конвертить, а место сэкономится. А так - в настройках скрипты с Юникодом рядом, было бы и логично их в паре (как относящихся к преобразованию страниц) и в диалоге сохранения сделать.

softes
Страницы на английском можно в UTF-8 конвертить сколько угодно, они от этого не изменяются. Это одна из основных вкусностей UTF-8. А галочку в диалог добавить можно.

anfilat
Тогда замечательно. А я почему-то думал, что файлы в UTF-8 больше становятся.

Пожелания...
1. Хотелось бы видеть возможность сохранения страницы в разные категории(папки)
2. Более гибкие настройки сохранения графики - по размеру, по расширению, по шаблону. Очень актуально для страниц с большим количеством графики
3. Шаблоны настроек, что бы не менять их для каждой страницы заново.

dwnld

Цитата:

1. Хотелось бы видеть возможность сохранения страницы в разные категории(папки)

Пока думаем, как лучше сделать.

Цитата:

2. Более гибкие настройки сохранения графики - по размеру, по расширению, по шаблону. Очень актуально для страниц с большим количеством графики

Подробнее можно? Желательный сценарий к примеру.

Цитата:

3. Шаблоны настроек, что бы не менять их для каждой страницы заново.

Да вроде настроек немного, особо менять и нечего.

Цитата:

Подробнее можно? Желательный сценарий к примеру.

На нужной странице жмем сохранить страницу с MetaProducts Inquiry, далее вкладка Изображения, сейчас там есть только 2 варианта - выбрать все, очистить все. Если имеем для сохранения какую-нибудь страницу веб-галереи с большим количеством графики, то процесс выбора становится утомительным занятием. Если бы имелось скажем табличное представление, напр. колонка урл, расширение, размер и возможность их сортировки, то это бы сильно упростило задачу. Или же фильтр по шаблону, типа сохранить все, кроме *banners*, *adclick*, *.gif и т.п.
Но самое главное, чтобы это было возможно при сохранении в базу Inquiry, чтобы не раздувать ее почем зря всякими ненужными банерами и прочим мусором

Цитата:

Да вроде настроек немного, особо менять и нечего.

Вот тогда они и понадобятся
Коме того возникло еще несколько предложений:
1. Реализовать возможность брать при сохранении в базу названия не по титлу, а по урлу. В принципе через контекстное меню можно отсортировать по урл, но это неудобно. Удобнее было бы...
2. табличный вид закладок, чтобы иметь возможность сортировки по урлу, дате и тп щелчком по заголовку заголовку таблицы, как в эксплорере
3. возможность убрать хинты
4. возм увеличить эти мелкие скриншоты или убрать их совсем
5. проверку на дубликат при сохранении в базу
6. автоудаление закладки через какое-то время
7. в диалоге сохранения добавить чекбокс "открыть MetaProducts Inquiry Browser", чтобы сразу перейти в режим редактирования
ну вроде пока все, что пришло в голову
вспомню напишу еще.