exist-open — Open discussion

Re: [Exist-open] XProc (Calabash) Status?

[Ari N. <ari...@gm...>]

Hi Gary,

You don't actually save anything before the pipeline is finished, unless 
$debug is set.

The manifest listing the XSLTs is first read into a sequence. That 
sequence is then used in a recursive function for the actual transforms, 
one XSLT at a time, for as long as there is an XSLT left in the 
sequence. The output from one recursion is used as the input to the next.

Plus, since I may have to feed steps with parameters, there's stuff in 
there to handle parameters set in the manifest.

You can test it using the XSLT-pipelines example repo at 
https://github.com/sgmlguru/xslt-pipelines. The example works both in 
XProc on the file system and in eXist using XQuery.

Oh, and I spoke about the pipelined XSLT approach at Balisage last year: 
https://www.balisage.net/Proceedings/vol25/html/Nordstrom01/BalisageVol25-Nordstrom01.html.

Best,

/Ari

On 2021-04-01 01:27, Gary Kopp wrote:
>
> Thanks for the suggestion, Ari. Let’s see if I understand your 
> approach, now that I’ve looked at your code. It seems the interface 
> between pipeline steps is a temporary document stored in the database 
> in one step, and read in the next step using an explicit URI. Am I 
> seeing that right?
>
> --Gary
>
> *From:* Ari Nordström <ari...@gm...>
> *Sent:* Wednesday, March 31, 2021 4:31 PM
> *To:* Gary Kopp <ge...@ru...>
> *Cc:* exist-open <exi...@li...>
> *Subject:* Re: [Exist-open] XProc (Calabash) Status?
>
> Hi,
>
> I think Norm is busy with work and real life, but I know the Calabash 
> XProc 3.0 version is in the works. You should look into Morgana XProc 
> for XProc 3.0 support in the meantime.
>
> As for running a sequence of XQueries with one providing the input to 
> the next, I assume you'd want to do it in an eXist context? If so, 
> XProc remains a rather painful option as it's not well supported.
>
> I'd go with an XQ wrapper instead. I did something very similar to run 
> XSLT stylesheets in sequence in eXist. I had done it in XProc and 
> Calabash on the file system but getting XProc to work in eXist proved 
> to be too much of a pain so I reimplemented the pipeline in XQ instead.
>
> My XProc and XQuery are both on GitHub: 
> https://github.com/sgmlguru/xproc-batch 
> <https://github.com/sgmlguru/xproc-batch>
>
> It should be fairly uncomplicated to modify the XQuery to run XQueries 
> instead.
>
> Best,
>
> /Ari
>
> On Wed, 31 Mar 2021, 21:38 Gary Kopp, <ge...@ru... 
> <mailto:ge...@ru...>> wrote:
>
>     The last update to xquery-xproc-xmlcalabash-module was about a
>     year ago. The README itemizes some current limitations. I would
>     like to know if the following limitations are still applicable,
>     and if so can you suggest any workarounds:
>
>     “Function signature will change soon to accept XML for /pipeline/,
>     /output/, as well as specify input/output/parameter ports and
>     options... for now it's primitive”
>
>     |“p:xquery| has no context with eXist, this is a big limitation,
>     but there are several ways around this”
>
>     I’m new to XProc, and have a lot of studying and experimentation
>     to do. All I really want to accomplish is to link multiple XQuery
>     scripts together so that the XML generated in one script is used
>     as input in a FLWOR in the next script, without explicitly
>     creating temporary documents in the database. I’m _/assuming/_
>     that is possible with XProc, but please correct me if I’m wrong
>     and I’ll abandon this line of attack. Thanks!
>
>     --Gary Kopp
>
>     _______________________________________________
>     Exist-open mailing list
>     Exi...@li...
>     <mailto:Exi...@li...>
>     https://lists.sourceforge.net/lists/listinfo/exist-open
>     <https://lists.sourceforge.net/lists/listinfo/exist-open>
>

Re: [Exist-open] XProc (Calabash) Status?

[Gary K. <ge...@ru...>]

Thanks for the suggestion, Ari. Let’s see if I understand your approach, now that I’ve looked at your code. It seems the interface between pipeline steps is a temporary document stored in the database in one step, and read in the next step using an explicit URI. Am I seeing that right?

 

--Gary

 

From: Ari Nordström <ari...@gm...> 
Sent: Wednesday, March 31, 2021 4:31 PM
To: Gary Kopp <ge...@ru...>
Cc: exist-open <exi...@li...>
Subject: Re: [Exist-open] XProc (Calabash) Status?

 

Hi,

 

I think Norm is busy with work and real life, but I know the Calabash XProc 3.0 version is in the works. You should look into Morgana XProc for XProc 3.0 support in the meantime.

 

As for running a sequence of XQueries with one providing the input to the next, I assume you'd want to do it in an eXist context? If so, XProc remains a rather painful option as it's not well supported. 

 

I'd go with an XQ wrapper instead. I did something very similar to run XSLT stylesheets in sequence in eXist. I had done it in XProc and Calabash on the file system but getting XProc to work in eXist proved to be too much of a pain so I reimplemented the pipeline in XQ instead.

 

My XProc and XQuery are both on GitHub: https://github.com/sgmlguru/xproc-batch

 

It should be fairly uncomplicated to modify the XQuery to run XQueries instead.

 

Best,

 

/Ari

 

On Wed, 31 Mar 2021, 21:38 Gary Kopp, <ge...@ru... <mailto:ge...@ru...> > wrote:

The last update to xquery-xproc-xmlcalabash-module was about a year ago. The README itemizes some current limitations. I would like to know if the following limitations are still applicable, and if so can you suggest any workarounds:

 

“Function signature will change soon to accept XML for pipeline, output, as well as specify input/output/parameter ports and options... for now it's primitive”

 

“p:xquery has no context with eXist, this is a big limitation, but there are several ways around this”

 

I’m new to XProc, and have a lot of studying and experimentation to do. All I really want to accomplish is to link multiple XQuery scripts together so that the XML generated in one script is used as input in a FLWOR in the next script, without explicitly creating temporary documents in the database. I’m _assuming_ that is possible with XProc, but please correct me if I’m wrong and I’ll abandon this line of attack. Thanks!

 

--Gary Kopp

 

 

_______________________________________________
Exist-open mailing list
Exi...@li... <mailto:Exi...@li...> 
https://lists.sourceforge.net/lists/listinfo/exist-open

Re: [Exist-open] XProc (Calabash) Status?

[Ari N. <ari...@gm...>]

Hi,

I think Norm is busy with work and real life, but I know the Calabash XProc
3.0 version is in the works. You should look into Morgana XProc for XProc
3.0 support in the meantime.

As for running a sequence of XQueries with one providing the input to the
next, I assume you'd want to do it in an eXist context? If so, XProc
remains a rather painful option as it's not well supported.

I'd go with an XQ wrapper instead. I did something very similar to run XSLT
stylesheets in sequence in eXist. I had done it in XProc and Calabash on
the file system but getting XProc to work in eXist proved to be too much of
a pain so I reimplemented the pipeline in XQ instead.

My XProc and XQuery are both on GitHub:
https://github.com/sgmlguru/xproc-batch

It should be fairly uncomplicated to modify the XQuery to run XQueries
instead.

Best,

/Ari


On Wed, 31 Mar 2021, 21:38 Gary Kopp, <ge...@ru...> wrote:

> The last update to xquery-xproc-xmlcalabash-module was about a year ago.
> The README itemizes some current limitations. I would like to know if the
> following limitations are still applicable, and if so can you suggest any
> workarounds:
>
>
>
> “Function signature will change soon to accept XML for *pipeline*,
> *output*, as well as specify input/output/parameter ports and options...
> for now it's primitive”
>
>
>
> “p:xquery has no context with eXist, this is a big limitation, but there
> are several ways around this”
>
>
>
> I’m new to XProc, and have a lot of studying and experimentation to do.
> All I really want to accomplish is to link multiple XQuery scripts together
> so that the XML generated in one script is used as input in a FLWOR in the
> next script, without explicitly creating temporary documents in the
> database. I’m _*assuming*_ that is possible with XProc, but please
> correct me if I’m wrong and I’ll abandon this line of attack. Thanks!
>
>
>
> --Gary Kopp
>
>
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

[Exist-open] XProc (Calabash) Status?

[Gary K. <ge...@ru...>]

The last update to xquery-xproc-xmlcalabash-module was about a year ago. The
README itemizes some current limitations. I would like to know if the
following limitations are still applicable, and if so can you suggest any
workarounds:

 

"Function signature will change soon to accept XML for pipeline, output, as
well as specify input/output/parameter ports and options... for now it's
primitive"

 

"p:xquery has no context with eXist, this is a big limitation, but there are
several ways around this"

 

I'm new to XProc, and have a lot of studying and experimentation to do. All
I really want to accomplish is to link multiple XQuery scripts together so
that the XML generated in one script is used as input in a FLWOR in the next
script, without explicitly creating temporary documents in the database. I'm
_assuming_ that is possible with XProc, but please correct me if I'm wrong
and I'll abandon this line of attack. Thanks!

 

--Gary Kopp

 

 

Re: [Exist-open] Current Status of XForms?

[Finian O'B. <fin...@gm...>]

Joern,
I agree with your observations - I've always thought
XML/XQuery/XSLT/eXist/RestXQ/XForms provided a really elegant
development solution. That over the course of almost a decade I
converted from simple eXist/HTML to eXist/Orbeon, then to
eXist/betterForm and finally back to a "homebrew" eXist/Orbeon setup
is, I think, a token of my commitment! And I appreciate what you say
about the heaviness of both betterForm and Orbeon, which is why I
suggested looking at alternatives.
Thank you for the links to your work on Fore - I will look at it more
carefully. I thought you had stopped work on it, because I had been
following links from the old betterForm pages. More power to your
elbow.
Finian
On Tue, 2021-03-30 at 12:35 +0200, Joern Turner wrote:
> Finian,
> 
> On Sun, Mar 28, 2021 at 10:01 AM Finian O'Boyle <
> fin...@gm...> wrote:
> > Hi Gary,
> > 
> > All of my applications within eXist use XForms. I developed them
> > using betterForm, but when support for it was removed from eXist, I
> > converted them all to Orbeon using the Community Edition. I chose
> > it because it implements W3C XForms standard and because it
> > supports a wide range of form elements, but most importantly it is
> > under current maintenance. I run eXist 5.2.0 and Orbeon 19.2 CE,
> > but do so in a way in which they both run independently within the
> > same servlet container - in my case I use eXist's Jetty, but it is
> > also possible to use Tomcat.
> > 
> > Orbeon and eXist work together to render XForms by using cross-
> > context communication within the servlet container: the Orbeon
> > developers call this separate deployment. Requests to eXist for an
> > XForms page are intercepted by a servlet filter within eXist's
> > context and are passed to Orbeon. The XForms/XHTML markup is
> > transformed into an XHTML web page with links to supporting
> > JavaScript and CSS. This page is returned to the browser from
> > eXist, and the JavaScript/CSS requests are serviced by the servlet
> > filter.
> > 
> > Configuring this scenario requires a small number of changes within
> > both eXist and Orbeon. To summarise them for eXist you need to:
> > 
> > 1. Amend web.xml to add a servlet filter and mappings to intercept
> > XForms pages
> > 2. Copy orbeon-xforms-filter.jar to eXist's /lib directory
> > 3. Disable betterFORM globally if it is included in your version of
> > eXist
> > 
> > For Orbeon you need to:
> > 
> > 1. Download the latest version of Orbeon CE and place orbeon.war in
> > the servlet container
> > 2. Disable the Orbeon Form Runner login service defined within
> > web.xml
> > 3. Create properties-local.xml to configure Orbeon to accept
> > requests from eXist
> > 
> > When I set it up I created a page that fits into the standard eXist
> > documentation explaining in detail how to effect these changes. I
> > can let you have that if you're interested.
> > 
> > 
> A lot of setup right? And it was similar with betterFORM which had
> quite the same architecture as Orbeon. Also here the problems start
> as the provided (generated) JS, CSS code for understandable reasons
> has to commit to a certain client-side framework and provide a
> complete set of controls. The conceptual mapping from abstract UI
> control in XForms to real-world controls caused another complexity.
> Which is all fine and good as long as you don't need that special
> control that's not provided or not in the form you'd like. All in all
> the architectures of Orbeon and betterFORM are quite heavy though
> very powerful. But they come to a significant cost in terms of
> knowledge and maintenance. 
>  
> > Having said all of that, if I were starting from scratch I would
> > consider the alternatives to XForms. Although I have found
> > eXist/XForms very flexible and easy to use, it seems to me to be
> > something of an edge-case these days. I'm sure people here would
> > have ideas as to more modern technologies.
> XForms and eXist-db of course fit extremely well as you're dealing
> with XML through the whole stack without any mapping whatsoever. That
> in itself is IMO a big selling point.
> As for the 'more modern' technologies - the XForms architecture is
> still outstanding in the area of form processing IMHO but it could be
> dedusted ;) Fore is an attempt to do that purely client-side (but
> with server-side validation support) in native browser technologies
> plus XPath/XQuery 3
> Yep - it's beta
> Joern
> > Finian
> > 
> > On Sat, 2021-03-27 at 18:52 -0600, Gary Kopp wrote:
> > > While I’m an experienced Java programmer, I am new to eXist,
> > > XQuery, and XForms. I wish to create an eXist XForms web
> > > application and right now I need a little guidance on where to
> > > start. I’ve installed the eXist demo apps, which includes an
> > > XForms restxq application. Of course it doesn’t work out of the
> > > box because no XForms processors are installed, neither
> > > betterform nor XSLTForms. Which should I install – or rather,
> > > which currently works? Betterform is no longer included with the
> > > eXist distribution. It is available for download from Sourceforge
> > > as betterform-install-5.0rc5.jar but I can’t find any actual
> > > instructions for installation/configuration. Should I bother with
> > > it? As far as XSLTForms goes, I wanted to see a sample of a
> > > client-side page, and the documentation provides a link to
> > > hello.xml for this, but that page doesn’t seem to exist anywhere.
> > > Any help here?
> > >  
> > > While I’m at, I guess I could consider Orbeon Forms (community
> > > edition). It deprecated eXist support, but I’m guessing it’s
> > > still in the code. Any success/failure stories to share?
> > >  
> > > Thanks in advance from a newbie.
> > >  
> > > --Gary Kopp
> > >  
> > >  _______________________________________________Exist-open
> > > mailing lis...@li...
> > > https://lists.sourceforge.net/lists/listinfo/exist-open
> > 
> > _______________________________________________
> > 
> > Exist-open mailing list
> > 
> > Exi...@li...
> > 
> > https://lists.sourceforge.net/lists/listinfo/exist-open
> > 

Re: [Exist-open] Current Status of XForms?

[Joern T. <joe...@gm...>]

Finian,

On Sun, Mar 28, 2021 at 10:01 AM Finian O'Boyle <fin...@gm...>
wrote:

> Hi Gary,
>
> All of my applications within eXist use XForms. I developed them using
> betterForm, but when support for it was removed from eXist, I converted
> them all to Orbeon using the Community Edition. I chose it because it
> implements W3C XForms standard and because it supports a wide range of form
> elements, but most importantly it is under current maintenance. I run eXist
> 5.2.0 and Orbeon 19.2 CE, but do so in a way in which they both run
> independently within the same servlet container - in my case I use eXist's
> Jetty, but it is also possible to use Tomcat.
>
> Orbeon and eXist work together to render XForms by using cross-context
> communication within the servlet container: the Orbeon developers call this
> separate deployment. Requests to eXist for an XForms page are intercepted
> by a servlet filter within eXist's context and are passed to Orbeon. The
> XForms/XHTML markup is transformed into an XHTML web page with links to
> supporting JavaScript and CSS. This page is returned to the browser from
> eXist, and the JavaScript/CSS requests are serviced by the servlet filter.
>
> Configuring this scenario requires a small number of changes within both
> eXist and Orbeon. To summarise them for eXist you need to:
>
> 1. Amend web.xml to add a servlet filter and mappings to intercept XForms
> pages
> 2. Copy orbeon-xforms-filter.jar to eXist's /lib directory
> 3. Disable betterFORM globally if it is included in your version of eXist
>
> For Orbeon you need to:
>
> 1. Download the latest version of Orbeon CE and place orbeon.war in the
> servlet container
> 2. Disable the Orbeon Form Runner login service defined within web.xml
> 3. Create properties-local.xml to configure Orbeon to accept requests from
> eXist
>
> When I set it up I created a page that fits into the standard eXist
> documentation explaining in detail how to effect these changes. I can let
> you have that if you're interested.
>
> A lot of setup right? And it was similar with betterFORM which had quite
the same architecture as Orbeon. Also here the problems start as the
provided (generated) JS, CSS code for understandable reasons has to commit
to a certain client-side framework and provide a complete set of controls.
The conceptual mapping from abstract UI control in XForms to real-world
controls caused another complexity. Which is all fine and good as long as
you don't need that special control that's not provided or not in the form
you'd like. All in all the architectures of Orbeon and betterFORM are quite
heavy though very powerful. But they come to a significant cost in terms of
knowledge and maintenance.


> Having said all of that, if I were starting from scratch I would consider
> the alternatives to XForms. Although I have found eXist/XForms very
> flexible and easy to use, it seems to me to be something of an edge-case
> these days. I'm sure people here would have ideas as to more modern
> technologies.
>
XForms and eXist-db of course fit extremely well as you're dealing with XML
through the whole stack without any mapping whatsoever. That in itself is
IMO a big selling point.

As for the 'more modern' technologies - the XForms architecture is still
outstanding in the area of form processing IMHO but it could be dedusted ;)
Fore is an attempt to do that purely client-side (but with server-side
validation support) in native browser technologies plus XPath/XQuery 3

Yep - it's beta

Joern


> Finian
>
>
> On Sat, 2021-03-27 at 18:52 -0600, Gary Kopp wrote:
>
> While I’m an experienced Java programmer, I am new to eXist, XQuery, and
> XForms. I wish to create an eXist XForms web application and right now I
> need a little guidance on where to start. I’ve installed the eXist demo
> apps, which includes an XForms restxq application. Of course it doesn’t
> work out of the box because no XForms processors are installed, neither
> betterform nor XSLTForms. Which should I install – or rather, which
> currently works? Betterform is no longer included with the eXist
> distribution. It is available for download from Sourceforge as
> betterform-install-5.0rc5.jar but I can’t find any actual instructions for
> installation/configuration. Should I bother with it? As far as XSLTForms
> goes, I wanted to see a sample of a client-side page, and the documentation
> provides a link to hello.xml for this, but that page doesn’t seem to exist
> anywhere. Any help here?
>
>
>
> While I’m at, I guess I could consider Orbeon Forms (community edition).
> It deprecated eXist support, but I’m guessing it’s still in the code. Any
> success/failure stories to share?
>
>
>
> Thanks in advance from a newbie.
>
>
>
> --Gary Kopp
>
>
>
>
>
> _______________________________________________
>
> Exist-open mailing list
>
> Exi...@li...
>
>
> https://lists.sourceforge.net/lists/listinfo/exist-open
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

Re: [Exist-open] Current Status of XForms?

[Omar S. <Oma...@oe...>]

We try to maintain and extend MerMEId[1], which was developed using 
Orbeon forms some years ago. We created a specialized Docker image[2] 
for MerMEId. As the XForms are quite complex we opted to use Orbeon and 
not port them to some other solution.
You can probably adapt this to your needs.
It has a few pecularities
* We use Orbeon 2018 CE as our XFroms seem to cause problems with more
   recent Versions, but the setup would be the same.
* The MerMEId exist app is hardcoded as the default app, something you
   Probably want to change
* There are some "magic" XFroms paths/collectionms that need to be set
   in configuration files when adding Orbeon to the exist container
* exist does not run in the /exist servlet context but as / context.
   This was once supported but now for example Dashboard has problems
   with login in this configuration.
I am in the process of getting the Orbeon XForms examples to work on 
exist[3].

Best regards
Omar Siam

[1]https://github.com/edirom/mermeid
[2]https://hub.docker.com/r/edirom/mermeid
[3]https://github.com/acdh-oeaw/orbeon-xforms-examples-for-exist-db

Re: [Exist-open] Modern Alternatives to XForms?

[Joe W. <jo...@gm...>]

The link to Alain's declarative4all project is:

  https://github.com/AlainCouthures/declarative4all

The latest build of xsltforms can be found therein, at:

  https://github.com/AlainCouthures/declarative4all
/raw/master/public/direct/xsltforms.zip

Alain reads exist-open, but questions about xsltforms are best directed to
the xsltforms-support mailing list:

  https://sourceforge.net/projects/xsltforms/lists/xsltforms-support

On Mon, Mar 29, 2021 at 7:58 AM Habs <ge...@us...> wrote:

> Hello Folks
>
> XsltForms (and lately its evolution within Declarative4All) is well
> developed and 'mature'.
>
> It is client side and in any case has worked very well for us for many,
> many years.
>
> Regards
> Habs
>

Re: [Exist-open] Modern Alternatives to XForms?

[Habs <ge...@us...>]

On Mon, 29 Mar 2021, Joern Turner wrote:

> Gary,
>
> it might interest you that i'm currently developing a forms alternative to
> be used with eXist-db. It's a purely client-side implementation in web
> components that follows the lines of XForms 2.0. The intend is to replace
> betterFORM functionally as this was abandoned and is no longer available.
> However we still have long-term projects relying on XForms that need a
> perspective in the longer run. As i was responsible for betterFORM i felt
> the need to come up with a replacement.
>
> It provides the ability to work with your XML on the client-side by using
> the great fontoXPath library with XPath/XQuery 3.x support.
>
> Github: https://github.com/Jinntec/Fore
> npmjs: https://www.npmjs.com/package/@jinntec/fore
>
> Warning: it's still in beta
>
> hth,


Hello Folks

XsltForms (and lately its evolution within Declarative4All) is well 
developed and 'mature'.

It is client side and in any case has worked very well for us for many, 
many years.

Regards
Habs

--- Sent using Alpine/Pine, probably the best MUA ---

Tox Chat Id:
9F10AC64260ADEBAEA017ACB71B7CD2E962596FC4293025C0F79D77FFEB4CE5C7B0BED41D925
https://tox.chat/

Re: [Exist-open] Modern Alternatives to XForms?

[Joern T. <joe...@gm...>]

Gary,

it might interest you that i'm currently developing a forms alternative to
be used with eXist-db. It's a purely client-side implementation in web
components that follows the lines of XForms 2.0. The intend is to replace
betterFORM functionally as this was abandoned and is no longer available.
However we still have long-term projects relying on XForms that need a
perspective in the longer run. As i was responsible for betterFORM i felt
the need to come up with a replacement.

It provides the ability to work with your XML on the client-side by using
the great fontoXPath library with XPath/XQuery 3.x support.

Github: https://github.com/Jinntec/Fore
npmjs: https://www.npmjs.com/package/@jinntec/fore

Warning: it's still in beta

hth,

Joern

On Sun, Mar 28, 2021 at 7:54 PM Gary Kopp <ge...@ru...> wrote:

> In a separate thread I enquired about the current approaches to using
> XForms with eXist. Finian gave me an extremely helpful response explaining
> how to use Orbeon Forms community edition, which I’m seriously considering.
> He ended his reply with:
>
>
>
> “Having said all of that, if I were starting from scratch I would consider
> the alternatives to XForms. Although I have found eXist/XForms very
> flexible and easy to use, it seems to me to be something of an edge-case
> these days. I'm sure people here would have ideas as to more modern
> technologies.”
>
>
>
> For me, that begs the question – what are some recommended modern
> alternatives to XForms? A Google search returned less than helpful lists of
> commercial solutions. What I’m looking for is open source solutions that
> are relatively easy to integrate with eXist and produce UIs with as little
> effort as possible.
>
>
>
> Your suggestions would be appreciated!
>
>
>
> --Gary Kopp
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

Re: [Exist-open] Modern Alternatives to XForms?

[Paolo Di P. <pao...@gm...>]

I’m an old  forms developer, having used Chiba and then betterform at the
beginning of Y2000.
It’s sad to say that xforms didn’t have the acceptance from the community
as we all hoped in those days.

I think that, apart from the commercial solution today on the market, all
of that referring to the original approach, there is the need of a
completely new approach   ‘Mobile first’, where the from-end implementation
should keep in count the development of an approach for a small device.

It’s not a problem of being responsive: it’s not enough: there should be
the need to integrate something similar to react-native.

Maybe there should. Be the need for a completely new xforms spe by the W3C,
integrating also with the new versions of ecmascript and it’s functional
approach.

This is my personal opinion and a suggestion for W3C.

Paolo

Il giorno dom 28 mar 2021 alle 19:54 Gary Kopp <ge...@ru...> ha
scritto:

> In a separate thread I enquired about the current approaches to using
> XForms with eXist. Finian gave me an extremely helpful response explaining
> how to use Orbeon Forms community edition, which I’m seriously considering.
> He ended his reply with:
>
>
>
> “Having said all of that, if I were starting from scratch I would consider
> the alternatives to XForms. Although I have found eXist/XForms very
> flexible and easy to use, it seems to me to be something of an edge-case
> these days. I'm sure people here would have ideas as to more modern
> technologies.”
>
>
>
> For me, that begs the question – what are some recommended modern
> alternatives to XForms? A Google search returned less than helpful lists of
> commercial solutions. What I’m looking for is open source solutions that
> are relatively easy to integrate with eXist and produce UIs with as little
> effort as possible.
>
>
>
> Your suggestions would be appreciated!
>
>
>
> --Gary Kopp
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>
-- 

Paolo Di Pietro

+39 348 602 2637

[Exist-open] Modern Alternatives to XForms?

[Gary K. <ge...@ru...>]

In a separate thread I enquired about the current approaches to using XForms
with eXist. Finian gave me an extremely helpful response explaining how to
use Orbeon Forms community edition, which I'm seriously considering. He
ended his reply with:

 

"Having said all of that, if I were starting from scratch I would consider
the alternatives to XForms. Although I have found eXist/XForms very flexible
and easy to use, it seems to me to be something of an edge-case these days.
I'm sure people here would have ideas as to more modern technologies."

 

For me, that begs the question - what are some recommended modern
alternatives to XForms? A Google search returned less than helpful lists of
commercial solutions. What I'm looking for is open source solutions that are
relatively easy to integrate with eXist and produce UIs with as little
effort as possible.

 

Your suggestions would be appreciated!

 

--Gary Kopp

Re: [Exist-open] Current Status of XForms?

[Finian O'B. <fin...@gm...>]

Hi Gary,

All of my applications within eXist use XForms. I developed them using
betterForm, but when support for it was removed from eXist, I converted
them all to Orbeon using the Community Edition. I chose it because it
implements W3C XForms standard and because it supports a wide range of
form elements, but most importantly it is under current maintenance. I
run eXist 5.2.0 and Orbeon 19.2 CE, but do so in a way in which they
both run independently within the same servlet container - in my case I
use eXist's Jetty, but it is also possible to use Tomcat.

Orbeon and eXist work together to render XForms by using cross-context
communication within the servlet container: the Orbeon developers call
this separate deployment. Requests to eXist for an XForms page are
intercepted by a servlet filter within eXist's context and are passed
to Orbeon. The XForms/XHTML markup is transformed into an XHTML web
page with links to supporting JavaScript and CSS. This page is returned
to the browser from eXist, and the JavaScript/CSS requests are serviced
by the servlet filter.

Configuring this scenario requires a small number of changes within
both eXist and Orbeon. To summarise them for eXist you need to:

1. Amend web.xml to add a servlet filter and mappings to intercept
XForms pages
2. Copy orbeon-xforms-filter.jar to eXist's /lib directory
3. Disable betterFORM globally if it is included in your version of
eXist

For Orbeon you need to:

1. Download the latest version of Orbeon CE and place orbeon.war in the
servlet container
2. Disable the Orbeon Form Runner login service defined within web.xml
3. Create properties-local.xml to configure Orbeon to accept requests
from eXist

When I set it up I created a page that fits into the standard eXist
documentation explaining in detail how to effect these changes. I can
let you have that if you're interested.

Having said all of that, if I were starting from scratch I would
consider the alternatives to XForms. Although I have found eXist/XForms
very flexible and easy to use, it seems to me to be something of an
edge-case these days. I'm sure people here would have ideas as to more
modern technologies.

Finian


On Sat, 2021-03-27 at 18:52 -0600, Gary Kopp wrote:
> While I’m an experienced Java programmer, I am new to eXist, XQuery,
> and XForms. I wish to create an eXist XForms web application and
> right now I need a little guidance on where to start. I’ve installed
> the eXist demo apps, which includes an XForms restxq application. Of
> course it doesn’t work out of the box because no XForms processors
> are installed, neither betterform nor XSLTForms. Which should I
> install – or rather, which currently works? Betterform is no longer
> included with the eXist distribution. It is available for download
> from Sourceforge as betterform-install-5.0rc5.jar but I can’t find
> any actual instructions for installation/configuration. Should I
> bother with it? As far as XSLTForms goes, I wanted to see a sample of
> a client-side page, and the documentation provides a link to
> hello.xml for this, but that page doesn’t seem to exist anywhere. Any
> help here?
>  
> While I’m at, I guess I could consider Orbeon Forms (community
> edition). It deprecated eXist support, but I’m guessing it’s still in
> the code. Any success/failure stories to share?
>  
> Thanks in advance from a newbie.
>  
> --Gary Kopp
>  
>  
> _______________________________________________Exist-open mailing 
> lis...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
> 

Re: [Exist-open] Warning about eXist Crypto module

[Christian W. <cwi...@gm...>]

Dear Joe,

Thanks for the heads up.  Unfortunately this does not solve the problem 
for me.

I am depending on the crypto module for github webhooks via Winona 
Salesky's excellent github-xq module. I usually develop on a local 
server, then push the changes to the github repository and have the 
webhook deliver it to the production server.  So far this was excellent 
to quickly deliver bugfixes etc, but I can't use it that way at the 
moment :-(

Christian

P.S.  Yes, I know I should not use the 5.3.0 SNAPSHOT in production, it 
started as a test that (otherwise) turned out so well that I decided to 
go with it.  Until I discovered the crypto problem....  CW

On 28/03/2021 11.13, Joe Wicentowski wrote:
> Hi Christian,
>
> Juri gave us a promising update on Olaf's work on the crypto module in 
> last week's Community Call, including a link to a pre-built xar that 
> can be used for testing with eXist 5.x. The link to the notes from 
> each call can be found linked from 
> https://github.com/eXist-db/exist#open-community-calls 
> <https://github.com/eXist-db/exist#open-community-calls>.
>
> I'm curious, which crypto functions are critical for your work?
>
> Joe
>
> On Sat, Mar 27, 2021 at 9:40 PM Christian Wittern <cwi...@gm... 
> <mailto:cwi...@gm...>> wrote:
>
>     Dear Joe,
>
>     While trying out the most recent snapshot (in order to take
>     advantage of the fixed bug re astral CJK characters), I realized
>     that there is a problem with the crypto module and then remembered
>     this post from a few months ago.  My question now is:
>
>     Is there a way I can work around these problems and use the crypto
>     module right now?
>
>     Is anybody working on this?  I certainly would appreciate this
>     being resolved...
>
>     All the best,
>
>     Christian
>
>     On 01/12/2020 04.49, Joe Wicentowski wrote:
>>     Hi all,
>>
>>     Following up on today's Community Call, users of the eXist Crypto
>>     Module should be warned about problems in the current release of
>>     the package, 5.3.0:
>>
>>     https://github.com/eXist-db/crypto-exist-java-lib/issues/33
>>     <https://github.com/eXist-db/crypto-exist-java-lib/issues/33>
>>
>>     The problems and next steps are described in the issue.
>>
>>     Joe
>>
>>
>>     _______________________________________________
>>     Exist-open mailing list
>>     Exi...@li...  <mailto:Exi...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/exist-open  <https://lists.sourceforge.net/lists/listinfo/exist-open>
>     _______________________________________________
>     Exist-open mailing list
>     Exi...@li...
>     <mailto:Exi...@li...>
>     https://lists.sourceforge.net/lists/listinfo/exist-open
>     <https://lists.sourceforge.net/lists/listinfo/exist-open>
>

Re: [Exist-open] Warning about eXist Crypto module

[Joe W. <jo...@gm...>]

Hi Christian,

Juri gave us a promising update on Olaf's work on the crypto module in last
week's Community Call, including a link to a pre-built xar that can be used
for testing with eXist 5.x. The link to the notes from each call can be
found linked from https://github.com/eXist-db/exist#open-community-calls.

I'm curious, which crypto functions are critical for your work?

Joe

On Sat, Mar 27, 2021 at 9:40 PM Christian Wittern <cwi...@gm...>
wrote:

> Dear Joe,
>
> While trying out the most recent snapshot (in order to take advantage of
> the fixed bug re astral CJK characters), I realized that there is a problem
> with the crypto module and then remembered this post from a few months
> ago.  My question now is:
>
> Is there a way I can work around these problems and use the crypto module
> right now?
>
> Is anybody working on this?  I certainly would appreciate this being
> resolved...
>
> All the best,
>
> Christian
> On 01/12/2020 04.49, Joe Wicentowski wrote:
>
> Hi all,
>
> Following up on today's Community Call, users of the eXist Crypto Module
> should be warned about problems in the current release of the
> package, 5.3.0:
>
>   https://github.com/eXist-db/crypto-exist-java-lib/issues/33
>
> The problems and next steps are described in the issue.
>
> Joe
>
>
> _______________________________________________
> Exist-open mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/exist-open
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

Re: [Exist-open] Warning about eXist Crypto module

[Christian W. <cwi...@gm...>]

Dear Joe,

While trying out the most recent snapshot (in order to take advantage of 
the fixed bug re astral CJK characters), I realized that there is a 
problem with the crypto module and then remembered this post from a few 
months ago.  My question now is:

Is there a way I can work around these problems and use the crypto 
module right now?

Is anybody working on this?  I certainly would appreciate this being 
resolved...

All the best,

Christian

On 01/12/2020 04.49, Joe Wicentowski wrote:
> Hi all,
>
> Following up on today's Community Call, users of the eXist Crypto 
> Module should be warned about problems in the current release of the 
> package, 5.3.0:
>
> https://github.com/eXist-db/crypto-exist-java-lib/issues/33 
> <https://github.com/eXist-db/crypto-exist-java-lib/issues/33>
>
> The problems and next steps are described in the issue.
>
> Joe
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open

[Exist-open] Current Status of XForms?

[Gary K. <ge...@ru...>]

While I'm an experienced Java programmer, I am new to eXist, XQuery, and
XForms. I wish to create an eXist XForms web application and right now I
need a little guidance on where to start. I've installed the eXist demo
apps, which includes an XForms restxq application. Of course it doesn't work
out of the box because no XForms processors are installed, neither
betterform nor XSLTForms. Which should I install - or rather, which
currently works? Betterform is no longer included with the eXist
distribution. It is available for download from Sourceforge as
betterform-install-5.0rc5.jar but I can't find any actual instructions for
installation/configuration. Should I bother with it? As far as XSLTForms
goes, I wanted to see a sample of a client-side page, and the documentation
provides a link to hello.xml for this, but that page doesn't seem to exist
anywhere. Any help here?

 

While I'm at, I guess I could consider Orbeon Forms (community edition). It
deprecated eXist support, but I'm guessing it's still in the code. Any
success/failure stories to share?

 

Thanks in advance from a newbie.

 

--Gary Kopp

 

 

[Exist-open] eXist 4.5.0 & Journal log files amount limit exceeded

[Kuukka-Härmä R. <Rii...@fi...>]

Hi,

Any advice how to recover from this situation:

2021-03-23 13:51:18,493 [qtp395257482-764] ERROR (TransactionManager.java [lambda$beginTransaction$0]:103) - Failed to create transaction. Error writing to log
file.
org.exist.storage.journal.JournalException: Journal can only support 32767 log files
        at org.exist.storage.journal.Journal.writeToLog(Journal.java:341) ~[exist.jar:4.5.0]
        at org.exist.storage.journal.JournalManager.journal(JournalManager.java:86) ~[exist.jar:4.5.0]
        at org.exist.storage.txn.TransactionManager.lambda$beginTransaction$0(TransactionManager.java:101) ~[exist.jar:4.5.0]
        at org.exist.storage.txn.TransactionManager.withLock(TransactionManager.java:333) [exist.jar:4.5.0]
        at org.exist.storage.txn.TransactionManager.beginTransaction(TransactionManager.java:93) [exist.jar:4.5.0]
        at org.exist.xmlrpc.RpcConnection.withDb(RpcConnection.java:3927) [exist.jar:4.5.0]
        at org.exist.xmlrpc.RpcConnection.withDb(RpcConnection.java:3912) [exist.jar:4.5.0]
        at org.exist.xmlrpc.RpcConnection.retrieveFirstChunk(RpcConnection.java:2242) [exist.jar:4.5.0]
        at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_152]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_152]
....

Where these journal log-entries/files are written? How database can end up to situation where this file number is exceeded? This database instance is in slave-role in our setup.

configuration for recovery:
<recovery enabled="yes"  group-commit="no"   journal-dir="/data/eXist-4.5.0"  size="100M" sync-on-commit="no"  force-restart="no"  consistency-check="yes"/>

What is not done is that we do not take currently backups from this slave db nor have the consistency checkup task activated in scheduler. Could the exceeding of log entries be caused by that?

Any ideas how to recover (except the obvious clean exist install & restore backup), and to prevent this to happen?

BR, Riina

Re: [Exist-open] exist interfaces

[Adam R. <ad...@ex...>]

> For FusionStudio we built our API in XQuery using RestXQ and all
> communication back and forth is JSON (apart from retrieving/storing non-XML
> docs). If you want to see how we did it, the source code and links to the
> swagger API docs are available here -
> https://www.github.com/evolvedbinary/fusio-studio-api
>

Apologies, I made a typo in the link previously. It should have been -
https://github.com/evolvedbinary/fusion-studio-api





>
>
> On Mon, 15 Mar 2021, 11:17 Eduard Drenth, <ed...@fr...>
> wrote:
>
>> Dear all,
>>
>> For our language resources I am developing (ejb/cdi) services behind a
>> graphql interface. Data comes from several backends. Some of them already
>> have ejb/cdi/jpa code and setup which I can easily reuse.
>>
>> For exist I wonder how to connect to remote exist instances in an
>> efficient, future proof way. I already have working queries that output
>> json and can be called over https.
>>
>> As far as I can see, these are my options:
>>
>> 1) https calls => overhead, but already there, optimized and perhaps fast
>> enough
>> 2) http://exist-db.org/exist/apps/doc/devguide_xmlrpc => expensive? old
>> technology? maintained? json results supported?
>> 3) http://exist-db.org/exist/apps/doc/devguide_xmldb.xml => promoted as
>> the preferred way, sits on top of xmlrpc? json results supported?
>> 4) http://xqj.net/: feel like the way to go for me, but is it alive?
>>
>> Perhaps xmldb api is my best option, any thoughts or experiences on this
>> subject would be welcome...
>>
>> Regards, Eduard
>>
>>
>> --
>>
>> Eduard Drenth, Software Architekt
>>
>> ed...@fr...
>>
>> Doelestrjitte 8
>> 8911 DX  Ljouwert
>> +31 58 234 30 47
>> +31 62 094 34 28 (privé)
>>
>> skype: eduarddrenth
>> https://github.com/eduarddrenth
>> frisian.eu
>> gpg: https://pgp.surfnet.nl/pks/lookup?search=eduarddrenth
>>
>>
>> Op freed bin ik thús/wurkje ik minder
>>
>>
>>
>> _______________________________________________
>> Exist-open mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-open
>>
>

Re: [Exist-open] exist interfaces

[Joern T. <joe...@gm...>]

Eduard,

there a new child in town - look here: https://github.com/eeditiones/roaster

This implements OpenAPI for eXist-db and is a very slick approach to
quickly develop APIs and furthermore do so in an established standard.

Best,

Joern

On Tue, Mar 16, 2021 at 10:24 AM Eduard Drenth <ed...@fr...>
wrote:

> Thanks Adam, you bought me some time :-)
>
> -----Original Message-----
> *From*: Adam Retter <ad...@ex...
> <Adam%20Retter%20%3c...@ex...%3e>>
> *To*: Eduard Drenth <ed...@fr...
> <Eduard%20Drenth%20%3ce...@fr...%3e>>
> *Cc*: exi...@li... <Exi...@li...
> <%22e...@li...%22%20%3cE...@li...%3e>
> >
> *Subject*: Re: [Exist-open] exist interfaces
> *Date*: Tue, 16 Mar 2021 07:50:42 +0100
>
> Hi Eduard,
>
> I would suggest to stick with plain HTTP and build an API for yourself in
> XQuery that returns what you need (JSON if you like).
>
> To do this you have a number of choices but I think RESTXQ is a great fit
> here.
>
> For FusionStudio we built our API in XQuery using RestXQ and all
> communication back and forth is JSON (apart from retrieving/storing non-XML
> docs). If you want to see how we did it, the source code and links to the
> swagger API docs are available here -
> https://www.github.com/evolvedbinary/fusio-studio-api
>
>
>
> On Mon, 15 Mar 2021, 11:17 Eduard Drenth, <ed...@fr...>
> wrote:
>
> Dear all,
>
> For our language resources I am developing (ejb/cdi) services behind a
> graphql interface. Data comes from several backends. Some of them already
> have ejb/cdi/jpa code and setup which I can easily reuse.
>
> For exist I wonder how to connect to remote exist instances in an
> efficient, future proof way. I already have working queries that output
> json and can be called over https.
>
> As far as I can see, these are my options:
>
> 1) https calls => overhead, but already there, optimized and perhaps fast
> enough
> 2) http://exist-db.org/exist/apps/doc/devguide_xmlrpc => expensive? old
> technology? maintained? json results supported?
> 3) http://exist-db.org/exist/apps/doc/devguide_xmldb.xml => promoted as
> the preferred way, sits on top of xmlrpc? json results supported?
> 4) http://xqj.net/: feel like the way to go for me, but is it alive?
>
> Perhaps xmldb api is my best option, any thoughts or experiences on this
> subject would be welcome...
>
> Regards, Eduard
>
>
> --
>
>
> Eduard Drenth, Software Architekt
>
> ed...@fr...
>
> Doelestrjitte 8
> 8911 DX  Ljouwert
> +31 58 234 30 47
> +31 62 094 34 28 (privé)
>
> skype: eduarddrenth
> https://github.com/eduarddrenth
> frisian.eu
> gpg: https://pgp.surfnet.nl/pks/lookup?search=eduarddrenth
>
>
> Op freed bin ik thús/wurkje ik minder
>
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>
> --
>
> Eduard Drenth, Software Architekt
>
> ed...@fr...
>
> Doelestrjitte 8
> 8911 DX  Ljouwert
> +31 58 234 30 47
> +31 62 094 34 28 (privé)
>
> skype: eduarddrenth
> https://github.com/eduarddrenth
> frisian.eu
> gpg: https://pgp.surfnet.nl/pks/lookup?search=eduarddrenth
>
>
> Op freed bin ik thús/wurkje ik minder
>
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

Re: [Exist-open] exist interfaces

[Eduard D. <ed...@fr...>]

Thanks Adam, you bought me some time :-)
-----Original Message-----From: Adam Retter <ad...@ex...>To:
Eduard Drenth <ed...@fr...>Cc: 
exi...@li... <Exi...@li...>Subj
ect: Re: [Exist-open] exist interfacesDate: Tue, 16 Mar 2021 07:50:42
+0100
Hi Eduard,
I would suggest to stick with plain HTTP and build an API for yourself
in XQuery that returns what you need (JSON if you like).

To do this you have a number of choices but I think RESTXQ is a great
fit here.

For FusionStudio we built our API in XQuery using RestXQ and all
communication back and forth is JSON (apart from retrieving/storing
non-XML docs). If you want to see how we did it, the source code and
links to the swagger API docs are available here - 
https://www.github.com/evolvedbinary/fusio-studio-api



On Mon, 15 Mar 2021, 11:17 Eduard Drenth, <ed...@fr...>
wrote:
> 
> 
> 
> Dear all,
> 
> 
> 
> For our language resources I am developing (ejb/cdi) services behind
> a graphql interface. Data comes from several backends. Some of them
> already have ejb/cdi/jpa code and setup which I can easily reuse.
> 
> 
> 
> For exist I wonder how to connect to remote exist instances in an
> efficient, future proof way. I already have working queries that
> output json and can be called over https.
> 
> 
> 
> As far as I can see, these are my options:
> 
> 
> 
> 1) https calls => overhead, but already there, optimized and perhaps
> fast enough
> 2) http://exist-db.org/exist/apps/doc/devguide_xmlrpc => expensive?
> old technology? maintained? json results supported?
> 3) http://exist-db.org/exist/apps/doc/devguide_xmldb.xml => promoted
> as the preferred way, sits on top of xmlrpc? json results supported?
> 4) http://xqj.net/: feel like the way to go for me, but is it alive?
> 
> 
> 
> Perhaps xmldb api is my best option, any thoughts or experiences on
> this subject would be welcome...
> 
> 
> 
> Regards, Eduard
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Eduard Drenth, Software Architekt
> 
> 
> 
> ed...@fr...
> 
> 
> 
> Doelestrjitte 8
> 8911 DX  Ljouwert
> +31 58 234 30 47
> +31 62 094 34 28 (privé)
> 
> 
> 
> skype: eduarddrenth
> https://github.com/eduarddrenth
> frisian.eu
> gpg: https://pgp.surfnet.nl/pks/lookup?search=eduarddrenth
> 
> 
> 
> 
> 
> 
> 
> Op freed bin ik thús/wurkje ik minder
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 
> Exist-open mailing list
> 
> Exi...@li...
> 
> https://lists.sourceforge.net/lists/listinfo/exist-open
> 


-- 
Eduard Drenth, Software Architekt

ed...@fr...

Doelestrjitte 8
8911 DX  Ljouwert
+31 58 234 30 47
+31 62 094 34 28 (privé)

skype: eduarddrenth
https://github.com/eduarddrenth
frisian.eu
gpg: https://pgp.surfnet.nl/pks/lookup?search=eduarddrenth


Op freed bin ik thús/wurkje ik minder

Re: [Exist-open] exist interfaces

[Adam R. <ad...@ex...>]

Hi Eduard,

I would suggest to stick with plain HTTP and build an API for yourself in
XQuery that returns what you need (JSON if you like).

To do this you have a number of choices but I think RESTXQ is a great fit
here.

For FusionStudio we built our API in XQuery using RestXQ and all
communication back and forth is JSON (apart from retrieving/storing non-XML
docs). If you want to see how we did it, the source code and links to the
swagger API docs are available here -
https://www.github.com/evolvedbinary/fusio-studio-api



On Mon, 15 Mar 2021, 11:17 Eduard Drenth, <ed...@fr...> wrote:

> Dear all,
>
> For our language resources I am developing (ejb/cdi) services behind a
> graphql interface. Data comes from several backends. Some of them already
> have ejb/cdi/jpa code and setup which I can easily reuse.
>
> For exist I wonder how to connect to remote exist instances in an
> efficient, future proof way. I already have working queries that output
> json and can be called over https.
>
> As far as I can see, these are my options:
>
> 1) https calls => overhead, but already there, optimized and perhaps fast
> enough
> 2) http://exist-db.org/exist/apps/doc/devguide_xmlrpc => expensive? old
> technology? maintained? json results supported?
> 3) http://exist-db.org/exist/apps/doc/devguide_xmldb.xml => promoted as
> the preferred way, sits on top of xmlrpc? json results supported?
> 4) http://xqj.net/: feel like the way to go for me, but is it alive?
>
> Perhaps xmldb api is my best option, any thoughts or experiences on this
> subject would be welcome...
>
> Regards, Eduard
>
>
> --
>
> Eduard Drenth, Software Architekt
>
> ed...@fr...
>
> Doelestrjitte 8
> 8911 DX  Ljouwert
> +31 58 234 30 47
> +31 62 094 34 28 (privé)
>
> skype: eduarddrenth
> https://github.com/eduarddrenth
> frisian.eu
> gpg: https://pgp.surfnet.nl/pks/lookup?search=eduarddrenth
>
>
> Op freed bin ik thús/wurkje ik minder
>
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>

[Exist-open] exist interfaces

[Eduard D. <ed...@fr...>]

Dear all,

For our language resources I am developing (ejb/cdi) services behind a graphql interface. Data comes from several backends. Some of them already have ejb/cdi/jpa code and setup which I can easily reuse.

For exist I wonder how to connect to remote exist instances in an efficient, future proof way. I already have working queries that output json and can be called over https.

As far as I can see, these are my options:

1) https calls => overhead, but already there, optimized and perhaps fast enough
2) http://exist-db.org/exist/apps/doc/devguide_xmlrpc => expensive? old technology? maintained? json results supported?
3) http://exist-db.org/exist/apps/doc/devguide_xmldb.xml => promoted as the preferred way, sits on top of xmlrpc? json results supported?
4) http://xqj.net/: feel like the way to go for me, but is it alive?

Perhaps xmldb api is my best option, any thoughts or experiences on this subject would be welcome...

Regards, Eduard



--

Eduard Drenth, Software Architekt

ed...@fr...<mailto:ed...@fr...>

Doelestrjitte 8
8911 DX  Ljouwert
+31 58 234 30 47
+31 62 094 34 28 (privé)

skype: eduarddrenth
https://github.com/eduarddrenth
frisian.eu
gpg: https://pgp.surfnet.nl/pks/lookup?search=eduarddrenth


Op freed bin ik thús/wurkje ik minder

Re: [Exist-open] DB corruption and recovery

[Michael W. <wes...@ja...>]

Hi Sava,

My emergency backup script is:

#!/bin/sh
cd ~/exist
bin/run.sh org.exist.backup.ExportMain -x -d ~/backup/full-$1


I run this before removing any of the files in the DATA directory. There
are corrupt files, usually put into __lost_and_found__ in the generated
backup, so I know what to look for in the daily backups.

Hope this helps.

Take care.



2021年3月12日(金) 4:46 Sava Jurisic <sju...@mr...>:

> Hi All,
>
>
>
> I have been searching the mailing lists for sometime now and I just don’t
> see the answers.
>
>
>
> We have been using eXistDB from inception … so BIG thanks to everyone for
> great product.
>
>
>
> Currently, using exist 4.7.1 in Windows environment (Server / 10Pro /7 Pro)
>
>
>
> Overall, it is very stable with little to none issues.
>
>
>
> However, every now and then, Windows system “dies” (sometime it is power
> outage, sometime it is a user action like tripping over power cord, …etc).
>
>
>
> When this happens, most of the time eXistDB will corrupt.
>
>
>
> Good news, 80-90% of the time, self recovery works J
>
>
>
> Bed news – the rest of the time, we are stuck and we 100% rely on daily
> backups (which is OK)
>
>
>
> Problem is, if system crashes mid-day, there is no backup.
>
> -------------------------------
>
> So, we have been using Consistency-Check tool and sometimes it works.
>
>
>
> We have tried using one of Wolfgang’s recommendations to clear all *.log
> files under DATA and execute  “java -jar start.jar
> org.exist.backup.ExportMain -z -x “ …  but this would return “ERROR: Failed
> to open database: null”
>
> --------------------------------
>
>
>
> I am running out of ideas but we would need to have this resolved.
>
>
>
> ANY feedback will be MUCH appreciated!
>
>
>
> Thanks,
>
> Sava
>
>
>
>
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>


-- 
Michael Westbay
Writer/System Administrator
http://www.japanesebaseball.com/

[Exist-open] DB corruption and recovery

[Sava J. <sju...@mr...>]

Hi All,

 

I have been searching the mailing lists for sometime now and I just don't
see the answers.

 

We have been using eXistDB from inception . so BIG thanks to everyone for
great product.

 

Currently, using exist 4.7.1 in Windows environment (Server / 10Pro /7 Pro)

 

Overall, it is very stable with little to none issues.

 

However, every now and then, Windows system "dies" (sometime it is power
outage, sometime it is a user action like tripping over power cord, .etc). 

 

When this happens, most of the time eXistDB will corrupt.

 

Good news, 80-90% of the time, self recovery works J

 

Bed news - the rest of the time, we are stuck and we 100% rely on daily
backups (which is OK)

 

Problem is, if system crashes mid-day, there is no backup.

-------------------------------

So, we have been using Consistency-Check tool and sometimes it works.

 

We have tried using one of Wolfgang's recommendations to clear all *.log
files under DATA and execute  "java -jar start.jar
org.exist.backup.ExportMain -z -x " .  but this would return "ERROR: Failed
to open database: null"

--------------------------------

 

I am running out of ideas but we would need to have this resolved.

 

ANY feedback will be MUCH appreciated!

 

Thanks,

Sava