DXLExport, XSLTransform для Web-service

[lmike]

вот не читаете про хсл, и не смотрите примеров здесь...
вопервых

<xsl:stylesheet version="1.1" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:ldn="http://www.lotus.com/dxl" xmlns:fo="http://www.w3.org/1999/XSL/Format" exclude-result-prefixes="fo">

это для фопа, обращаем внимания на неймспэсы исходного и выходного
обращение в сучностям ДХЛ только через префикс!, типа

<xsl:template match="ldn:document">

или

<xsl:template match="ldn:document/*[name()!='item']"/>

 <xsl:template match="ldn:item">
<xsl:variable name="fname" select="ldn:object/ldn:file/@name"/>
<xsl:variable name="fdata" select="ldn:object/ldn:file/ldn:filedata/text()"/>

 

[garrick]

Ну, а как-то так:

Dim s As String
s = {<ApplicationFile xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" si:noNamespaceSchemaLocation="Front_Request.xsd">}
s = s + "<ApplicationsList><lastname>" + document.GetItemValue("F")(0) + "</lastname>"

ну, и т.п.

 

[divankin]

Не пойму, а Web Service Consumer вы уже создали? Или вы проверяли связь с вебсервисом сторонними средствами?

По идее схема взаимодействия должна быть такой:
1. Получаете от провайдера wsdl, как файл или ссылку.
2. По этому wsdl создаете Web Service Consumer
3. Лотус сам для вас генерит метод(-ы), класс(-ы) входных параметров и класс(-ы) ответа.
4. Создаете объект класса входных параметров и заполняете его данными.
5. Вызываете созданный метод, передав туда параметром созданный объект
6. Получаете ответ

Все вышеперечисленное удалось сделать?

 

[Eugen]

Не пойму, а Web Service Consumer вы уже создали? Или вы проверяли связь с вебсервисом сторонними средствами?

По идее схема взаимодействия должна быть такой:
1. Получаете от провайдера wsdl, как файл или ссылку.
2. По этому wsdl создаете Web Service Consumer
3. Лотус сам для вас генерит метод(-ы), класс(-ы) входных параметров и класс(-ы) ответа.
4. Создаете объект класса входных параметров и заполняете его данными.
5. Вызываете созданный метод, передав туда параметром созданный объект
6. Получаете ответ

Все вышеперечисленное удалось сделать?

Да, это все сделано. Теперь надо в этот Web Service Consumer передать xml с нужной структурой.

 

[divankin]

Чем вам такой вариант не нравится?

xml = {<?xml version="1.0" encoding="utf-8"?>}
xml = xml + {<ApplicationFile xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Front_Request.xsd">}
xml = xml + {<ApplicationsList>}
xml = xml + {<lastname>} + doc.getItemValue("lastname")(0) + {</lastname>}
xml = xml + {<firstname>} + doc.getItemValue("firstname")(0) + {</firstname>}
xml = xml + {</ApplicationsList>}
xml = xml + {</ApplicationFile>}

Быстро и просто.

Вот разбирать удобнее будет через DOM ( классы NotesDOM...)

P.S. В указанный пример надо еще добавить замену спецсимволов на их аналоги в XML

 

[garrick]

Чем вам такой вариант не нравится?

xml = {<?xml version="1.0" encoding="utf-8"?>}...

Быстро и просто.

Во! Я так сразу и сказал. И работать будет в разы быстрее.

 

[nvyush]

Divankin
garrick
Свой первый веб-сервис так и делал. Когда возникла более сложная задача, делал на xsl. Из плюсов — xsl в настроечном документе, при изменении спецификации в код лезть не нужно. Из минусов — нужно знать xsl.
По поводу "в разы быстрее" — а Вы проверяли или с потолка взято?

 

[divankin]

Divankin
garrick
Свой первый веб-сервис так и делал. Когда возникла более сложная задача, делал на xsl. Из плюсов — xsl в настроечном документе, при изменении спецификации в код лезть не нужно. Из минусов — нужно знать xsl.
По поводу "в разы быстрее" — а Вы проверяли или с потолка взято?

Если не знаешь изначально всей сложности задачи (а так бывает в 95% случаев), лучше сначала сделать простое решение. Возможно, потом придется переписать все заново. Но во-первых, есть сравнительно большая вероятность, что не придется, а во-вторых, не всегда удается угадать с какой стороны придут проблемы.
Ваш вариант тоже потребует изменения кода, если в какой-то момент окажется, что новые данные нужно брать из связанных документов, к тому же из других баз.
Это своего рода искуство спрогнозировать, в какую сторону будет развиваться задача в последствии.

Ну, а по поводу "в разы быстрее".
Конечно, такой код будет выполнять быстрее, чем выгрузка в DXL, преобразование XSLT и парсинг в строку. Но наверняка самой долгой операцией все равно будет вызов вебсервиса и получение ответа от него.

 

[garrick]

Из плюсов — xsl в настроечном документе, при изменении спецификации в код лезть не нужно. Из минусов — нужно знать xsl.

Какая разница где править? Ну, разве что база с закрытым дизайном. А c XSL потом удобно будет XML ответ от web-сервиса в читабельный формат перевести или даже несколько разных, но это другая история.

По поводу "в разы быстрее" — а Вы проверяли или с потолка взято?

С потолка. Но я уверен в этом и даже никак проверять или тестировать это не буду.

 

[nvyush]

С потолка. Но я уверен в этом и даже никак проверять или тестировать это не буду.

А я когда-то давно проверял. Никаких "в разы быстрее" не обнаружил, даже наоборот, но это от задачи зависит.

 

[Eugen]

Честно говоря не хочется "зашивать" все в код. В идеале хотелось бы разобраться либо с двойной трансформацией, либо объединить 2 xsl. 2 трансформера почему то запускаться упорно не хотят. По каждому xsl в отдельности все работает отлично, а оба сразу не хотят и все тут. Помогите пожалуйста.

Да, и код при этом выглядит примерно так:

Dim s As New NotesSession
Dim exporter As NotesDXLExporter
Set exporter = s.CreateDXLExporter(doc)
Set transformer1 = s.Createxsltransformer(exporter, xsl_1)
Set transformer2 = s.Createxsltransformer(transformer1, xsl_2, xml)
Call exporter.Process()

Добавлено

Возможно, ошибка в xsl, гляньте exporter.Log

С xsl все нормально.


Повторюсь, сейчас код выглядит так:

	Set stream= s.Createstream()
Call stream.Truncate()

Set exporter = s.CreateDXLExporter(doc, stream)
Call exporter.Process()
Set transform=s.Createxsltransformer(stream, xsl_1, stream)
Call transform.Process()

Set transformer=s.Createxsltransformer(stream, xsl_2, xml)
Call transformer.Process()

 

[garrick]

У вас входящий и исходящий Stream один и тот же.

 

[lmike]

почему 2-а xsl?

 

[Eugen]

У вас входящий и исходящий Stream один и тот же.

с разными стримами ошибка та же.

почему 2-а xsl?

один копирует содержимое корня, второй приводит xml к нужному виду. Просто моих знаний xslt не хватает, чтобы объединить их.

 

[nvyush]

Eugen
Process() нужно вызывать один раз (только у экспортера) и стрим там вообще не нужен, ещё раз посмотрите мой пример.

 

[Eugen]

Eugen
Process() нужно вызывать один раз (только у экспортера) и стрим там вообще не нужен, ещё раз посмотрите мой пример.

У меня просто сначала он не заработал(видимо что то не так сделал). Сейчас все ок, спасибо большое.

 

[garrick]

Из своей базы знаний (по личному опыту):...

И вот после всего этого кто-то ещё будет говорить, что DXLExporter - это правильный подход что бы сформировать простенький XML заранее известной структуры?

 

[NickProstoNick]

И вот после всего этого кто-то ещё будет говорить, что DXLExporter - это правильный подход что бы сформировать простенький XML заранее известной структуры?

одно дело создавать xml руками и другое дело - получить xml из объекта

 

[lmike]

И вот после всего этого кто-то ещё будет говорить, что DXLExporter - это правильный подход что бы сформировать простенький XML заранее известной структуры?

бага/фича возникает не совсем в штатной ситуации, да и потом - хардкодить на LS - дурной тон. Надо понимать, что есть общедоступные форматы обмена данными и специфичные...
ХМЛ общедоступен и разработать шаблон для конвертации может гораздо больший круг людей, чем разобраться в коде на ЛС (да еще с нахаркоденными стрингами)

Добавлено: простой пример - тотже ФОП... для создания обработчика нужен программер низкой/средней квалификации (для java), для создания хсл - просто знания хсл
для работы с iText - нужно набаянить кучу кода, чтобы получить гибкую схему и здесь квалификация д.б. выше + нужны знания в предметной области (LDN). Либо получится одноразовая кака

 

[garrick]

хардкодить на LS - дурной тон

Так расссуждать, мы договоримся до того, что формы следует "рисовать" в XML и загружать их в базу через DXL, а делать их в LDD - дурной тон.

ХМЛ общедоступен и разработать шаблон для конвертации может гораздо больший круг людей

В вашей организации есть специальные XML разработчики, которые будут делать это?

тотже ФОП... для создания обработчика нужен программер низкой/средней квалификации (для java), для создания хсл - просто знания хсл

А мне кажтся, в данном случае, для создания XSL требуются весьма нетривиальные знания не просто XSL, а специального XSL-FO. И опять же см. вопрос выше - "В вашей организации есть специальные XML разработчики..."

Добавлено:

одно дело создавать xml руками и другое дело - получить xml из объекта

Это смотря какие задачи перед собой ставить. Одно дело - чисто спортивный интерес, другое - сделать вовремя и чтоб работало.