RESTXQ: What to use for page layout / view templating?

> Hi folks, > > another thing I'm trying to solve while working on a XQuery web app. What kind of templating system do you use to separate HTML templates from the rest of your code? > > - XSLT - the only problem I have with this is performance. I tested the XSLT Module with Saxon 9 and a primitive page and it was more than 3x slower compared to pure XQuery templates (XQuery fn taking $model). Other than that I think it's the best built-in option. I actually don't have any users-per-second expectations and those templates will be quite small... do I overemphasize the perf. question? > > - pure XQuery - not aimed at templating at all and it shows I'm afraid... just can't come up with a solution that would be clean enough (plus HTML, JS & CSS highlighting withing xq files is not good at all, at least in Vim) > > - I looked at Mustache.xq and quite liked it - depends on MarkLogic though :( > > - Any hidden gem I haven't googled yet? > > Leaning towards XSLT right now... > Daniel > > -- > danielkvasnicka.net > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

> let $defaults := map {"Foo" := "Bar", "foo" := "bar", "Bar" := "Foo"} > let $options := map {"Foo" := "Override"} > let $options := map:new(($defaults, $options)) > return string-join(map:keys($options) ! (. || " := "|| $options(.)), "
")

Am 17.11.2012 um 19:27 schrieb Daniel Kvasnička <daniel.kvasnicka at me.com>: > Hi folks, > > another thing I'm trying to solve while working on a XQuery web app. What kind of templating system do you use to separate HTML templates from the rest of your code? > > - XSLT - the only problem I have with this is performance. I tested the XSLT Module with Saxon 9 and a primitive page and it was more than 3x slower compared to pure XQuery templates (XQuery fn taking $model). Other than that I think it's the best built-in option. I actually don't have any users-per-second expectations and those templates will be quite small... do I overemphasize the perf. question? > > - pure XQuery - not aimed at templating at all and it shows I'm afraid... just can't come up with a solution that would be clean enough (plus HTML, JS & CSS highlighting withing xq files is not good at all, at least in Vim) > > - I looked at Mustache.xq and quite liked it - depends on MarkLogic though :( > > - Any hidden gem I haven't googled yet? > > Leaning towards XSLT right now... > Daniel > > -- > danielkvasnicka.net > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

On Nov 19, 2012, at 9:47 , Michael Seiferle <ms at basex.org> wrote: > Hi Daniel, > > thanks a lot for your observations, I know moustache.{xq,js} as well, and I'd be thrilled if we eventually come up with our own BaseX compatible implementation :-) > > Anyway, until then, I'd like to let you know how we handle this at the moment: > We introduce a template module that accepts a map of options and some content. > Inside the template wrapping function, we wire our page elements with the map’s contents. > This proved to be rather flexible while still being lightweight enough to be out of the way most of the time. > > Please excuse the messed up highlighting: https://gist.github.com/e053068a41eb35e727bb > > We chose maps, as they make it especially easy to provide default values that can be easily overridden from calling functions by combining a map: >> let $defaults := map {"Foo" := "Bar", "foo" := "bar", "Bar" := "Foo"} >> let $options := map {"Foo" := "Override"} >> let $options := map:new(($defaults, $options)) >> return string-join(map:keys($options) ! (. || " := "|| $options(.)), "&#10;") > > I hope this helps feel free to discuss this issue more :) > > Michael > > > > Am 17.11.2012 um 19:27 schrieb Daniel Kvasnička <daniel.kvasnicka at me.com>: > >> Hi folks, >> >> another thing I'm trying to solve while working on a XQuery web app. What kind of templating system do you use to separate HTML templates from the rest of your code? >> >> - XSLT - the only problem I have with this is performance. I tested the XSLT Module with Saxon 9 and a primitive page and it was more than 3x slower compared to pure XQuery templates (XQuery fn taking $model). Other than that I think it's the best built-in option. I actually don't have any users-per-second expectations and those templates will be quite small... do I overemphasize the perf. question? >> >> - pure XQuery - not aimed at templating at all and it shows I'm afraid... just can't come up with a solution that would be clean enough (plus HTML, JS & CSS highlighting withing xq files is not good at all, at least in Vim) >> >> - I looked at Mustache.xq and quite liked it - depends on MarkLogic though :( >> >> - Any hidden gem I haven't googled yet? >> >> Leaning towards XSLT right now... >> Daniel >> >> -- >> danielkvasnicka.net >> >> _______________________________________________ >> BaseX-Talk mailing list >> BaseX-Talk at mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >

> Well, I've actually opted for a completely different solution - AngularJS > & RESTXQ & JsonML. Very cool so far! It actually makes BaseX only a service > layer and moves all UI composition and teplating to the client. > Originally I wanted to make a pure XRX solution but I don't see any easily > embeddable and widely supported XForms implementation on the market > (XSLTForms comes close but I see too many "buts" and "ifs"). > > Daniel > > -- > danielkvasnicka.net > > On Nov 19, 2012, at 9:47 , Michael Seiferle <ms at basex.org> wrote: > > > Hi Daniel, > > > > thanks a lot for your observations, I know moustache.{xq,js} as well, > and I'd be thrilled if we eventually come up with our own BaseX compatible > implementation :-) > > > > Anyway, until then, I'd like to let you know how we handle this at the > moment: > > We introduce a template module that accepts a map of options and some > content. > > Inside the template wrapping function, we wire our page elements with > the map’s contents. > > This proved to be rather flexible while still being lightweight enough > to be out of the way most of the time. > > > > Please excuse the messed up highlighting: > https://gist.github.com/e053068a41eb35e727bb > > > > We chose maps, as they make it especially easy to provide default values > that can be easily overridden from calling functions by combining a map: > >> let $defaults := map {"Foo" := "Bar", "foo" := "bar", "Bar" := "Foo"} > >> let $options := map {"Foo" := "Override"} > >> let $options := map:new(($defaults, $options)) > >> return string-join(map:keys($options) ! (. || " := "|| > $options(.)), "&#10;") > > > > I hope this helps feel free to discuss this issue more :) > > > > Michael > > > > > > > > Am 17.11.2012 um 19:27 schrieb Daniel Kvasnička <daniel.kvasnicka at me.com > >: > > > >> Hi folks, > >> > >> another thing I'm trying to solve while working on a XQuery web app. > What kind of templating system do you use to separate HTML templates from > the rest of your code? > >> > >> - XSLT - the only problem I have with this is performance. I tested the > XSLT Module with Saxon 9 and a primitive page and it was more than 3x > slower compared to pure XQuery templates (XQuery fn taking $model). Other > than that I think it's the best built-in option. I actually don't have any > users-per-second expectations and those templates will be quite small... do > I overemphasize the perf. question? > >> > >> - pure XQuery - not aimed at templating at all and it shows I'm > afraid... just can't come up with a solution that would be clean enough > (plus HTML, JS & CSS highlighting withing xq files is not good at all, at > least in Vim) > >> > >> - I looked at Mustache.xq and quite liked it - depends on MarkLogic > though :( > >> > >> - Any hidden gem I haven't googled yet? > >> > >> Leaning towards XSLT right now... > >> Daniel > >> > >> -- > >> danielkvasnicka.net > >> > >> _______________________________________________ > >> BaseX-Talk mailing list > >> BaseX-Talk at mailman.uni-konstanz.de > >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >

On Nov 19, 2012, at 10:08 , Dirk Kirsten <dk at basex.org> wrote: > This is quite an interesting approach (I didn't know about AngularJS before). . In the end it looks like AngularJS does exactly what XForms was created for. However, I see your point of no existing 100% satisfying XForms implementation as well. But there is one problem with this approach in comparison to pure XForms I'd like to mention, though. > XForms automatically does form validation on the client and server side, AngularJS in comparison is just validating on client side, i.e. you are responsible to validate it on server side. Depending on how much and what form elements you use this could significantly add work hours. Depending on the use case this might be negligible, but everyone thinking about the same problem should keep this in mind. And of course AngularJS puts some processing on the client, but I guess with nowadays JavaScript implementations in the browser this shouldn't be much of an issue. > > Cheers, > Dirk > > > On Mon, Nov 19, 2012 at 9:56 AM, Daniel Kvasnička <daniel.kvasnicka at me.com> wrote: > Well, I've actually opted for a completely different solution - AngularJS & RESTXQ & JsonML. Very cool so far! It actually makes BaseX only a service layer and moves all UI composition and teplating to the client. > Originally I wanted to make a pure XRX solution but I don't see any easily embeddable and widely supported XForms implementation on the market (XSLTForms comes close but I see too many "buts" and "ifs"). > > Daniel > > -- > danielkvasnicka.net > > On Nov 19, 2012, at 9:47 , Michael Seiferle <ms at basex.org> wrote: > > > Hi Daniel, > > > > thanks a lot for your observations, I know moustache.{xq,js} as well, and I'd be thrilled if we eventually come up with our own BaseX compatible implementation :-) > > > > Anyway, until then, I'd like to let you know how we handle this at the moment: > > We introduce a template module that accepts a map of options and some content. > > Inside the template wrapping function, we wire our page elements with the map’s contents. > > This proved to be rather flexible while still being lightweight enough to be out of the way most of the time. > > > > Please excuse the messed up highlighting: https://gist.github.com/e053068a41eb35e727bb > > > > We chose maps, as they make it especially easy to provide default values that can be easily overridden from calling functions by combining a map: > >> let $defaults := map {"Foo" := "Bar", "foo" := "bar", "Bar" := "Foo"} > >> let $options := map {"Foo" := "Override"} > >> let $options := map:new(($defaults, $options)) > >> return string-join(map:keys($options) ! (. || " := "|| $options(.)), "&#10;") > > > > I hope this helps feel free to discuss this issue more :) > > > > Michael > > > > > > > > Am 17.11.2012 um 19:27 schrieb Daniel Kvasnička <daniel.kvasnicka at me.com>: > > > >> Hi folks, > >> > >> another thing I'm trying to solve while working on a XQuery web app. What kind of templating system do you use to separate HTML templates from the rest of your code? > >> > >> - XSLT - the only problem I have with this is performance. I tested the XSLT Module with Saxon 9 and a primitive page and it was more than 3x slower compared to pure XQuery templates (XQuery fn taking $model). Other than that I think it's the best built-in option. I actually don't have any users-per-second expectations and those templates will be quite small... do I overemphasize the perf. question? > >> > >> - pure XQuery - not aimed at templating at all and it shows I'm afraid... just can't come up with a solution that would be clean enough (plus HTML, JS & CSS highlighting withing xq files is not good at all, at least in Vim) > >> > >> - I looked at Mustache.xq and quite liked it - depends on MarkLogic though :( > >> > >> - Any hidden gem I haven't googled yet? > >> > >> Leaning towards XSLT right now... > >> Daniel > >> > >> -- > >> danielkvasnicka.net > >> > >> _______________________________________________ > >> BaseX-Talk mailing list > >> BaseX-Talk at mailman.uni-konstanz.de > >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > > > -- > Dirk Kirsten, BaseX GmbH, http://basex.org > |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz > |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: > | Dr. Christian Grün, Alexander Holupirek, Michael Seiferle > `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22

> You're right with the validation issue. Still I think it's the best > solution compared to having HTML spilled all over XQuery code (no offence > anyone...) or having perf-heavy XSLT. > JsonML implementation in BaseX also kills namespace information (no ns > prefix prepended in my tests), as far as I tested. So this might be a > problem if I wanted to send and receive data with mixed namespaces. But > that can be worked around as well somehow... > Also I don't know what is the perf impact of BaseX's JsonML mapping but I > don't think it's too much of an issue. > > Daniel > > -- > danielkvasnicka.net > > On Nov 19, 2012, at 10:08 , Dirk Kirsten <dk at basex.org> wrote: > > > This is quite an interesting approach (I didn't know about AngularJS > before). . In the end it looks like AngularJS does exactly what XForms was > created for. However, I see your point of no existing 100% satisfying > XForms implementation as well. But there is one problem with this approach > in comparison to pure XForms I'd like to mention, though. > > XForms automatically does form validation on the client and server side, > AngularJS in comparison is just validating on client side, i.e. you are > responsible to validate it on server side. Depending on how much and what > form elements you use this could significantly add work hours. Depending on > the use case this might be negligible, but everyone thinking about the same > problem should keep this in mind. And of course AngularJS puts some > processing on the client, but I guess with nowadays JavaScript > implementations in the browser this shouldn't be much of an issue. > > > > Cheers, > > Dirk > > > > > > On Mon, Nov 19, 2012 at 9:56 AM, Daniel Kvasnička < > daniel.kvasnicka at me.com> wrote: > > Well, I've actually opted for a completely different solution - > AngularJS & RESTXQ & JsonML. Very cool so far! It actually makes BaseX only > a service layer and moves all UI composition and teplating to the client. > > Originally I wanted to make a pure XRX solution but I don't see any > easily embeddable and widely supported XForms implementation on the market > (XSLTForms comes close but I see too many "buts" and "ifs"). > > > > Daniel > > > > -- > > danielkvasnicka.net > > > > On Nov 19, 2012, at 9:47 , Michael Seiferle <ms at basex.org> wrote: > > > > > Hi Daniel, > > > > > > thanks a lot for your observations, I know moustache.{xq,js} as well, > and I'd be thrilled if we eventually come up with our own BaseX compatible > implementation :-) > > > > > > Anyway, until then, I'd like to let you know how we handle this at the > moment: > > > We introduce a template module that accepts a map of options and some > content. > > > Inside the template wrapping function, we wire our page elements with > the map’s contents. > > > This proved to be rather flexible while still being lightweight enough > to be out of the way most of the time. > > > > > > Please excuse the messed up highlighting: > https://gist.github.com/e053068a41eb35e727bb > > > > > > We chose maps, as they make it especially easy to provide default > values that can be easily overridden from calling functions by combining a > map: > > >> let $defaults := map {"Foo" := "Bar", "foo" := "bar", "Bar" := "Foo"} > > >> let $options := map {"Foo" := "Override"} > > >> let $options := map:new(($defaults, $options)) > > >> return string-join(map:keys($options) ! (. || " := "|| > $options(.)), "&#10;") > > > > > > I hope this helps feel free to discuss this issue more :) > > > > > > Michael > > > > > > > > > > > > Am 17.11.2012 um 19:27 schrieb Daniel Kvasnička < > daniel.kvasnicka at me.com>: > > > > > >> Hi folks, > > >> > > >> another thing I'm trying to solve while working on a XQuery web app. > What kind of templating system do you use to separate HTML templates from > the rest of your code? > > >> > > >> - XSLT - the only problem I have with this is performance. I tested > the XSLT Module with Saxon 9 and a primitive page and it was more than 3x > slower compared to pure XQuery templates (XQuery fn taking $model). Other > than that I think it's the best built-in option. I actually don't have any > users-per-second expectations and those templates will be quite small... do > I overemphasize the perf. question? > > >> > > >> - pure XQuery - not aimed at templating at all and it shows I'm > afraid... just can't come up with a solution that would be clean enough > (plus HTML, JS & CSS highlighting withing xq files is not good at all, at > least in Vim) > > >> > > >> - I looked at Mustache.xq and quite liked it - depends on MarkLogic > though :( > > >> > > >> - Any hidden gem I haven't googled yet? > > >> > > >> Leaning towards XSLT right now... > > >> Daniel > > >> > > >> -- > > >> danielkvasnicka.net > > >> > > >> _______________________________________________ > > >> BaseX-Talk mailing list > > >> BaseX-Talk at mailman.uni-konstanz.de > > >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > > > > > > _______________________________________________ > > BaseX-Talk mailing list > > BaseX-Talk at mailman.uni-konstanz.de > > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > > > > > > > -- > > Dirk Kirsten, BaseX GmbH, http://basex.org > > |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz > > |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: > > | Dr. Christian Grün, Alexander Holupirek, Michael Seiferle > > `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22 > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >

On Mon, Nov 19, 2012 at 1:56 PM, Andy Bunce <bunce.andy at gmail.com> wrote: > Hi Daniel, > I guess we are making the same journey. I have done quite of lot of server > side templating with BaseX. I have finally gone round to putting a brief > write up on my blog [1]. > > I have also been using Angularjs with BaseX and find it has a lot pluses. > I have been playing building a sample app to try to see how it scales. I > hope to put my findings on my blog soon. It also uses Oauth. > > /Andy > > [1] > http://cubeb.blogspot.com/2012/11/xquery-templating-engines-and-txq.html > > > On Mon, Nov 19, 2012 at 9:17 AM, Daniel Kvasnička <daniel.kvasnicka at me.com > > wrote: > >> You're right with the validation issue. Still I think it's the best >> solution compared to having HTML spilled all over XQuery code (no offence >> anyone...) or having perf-heavy XSLT. >> JsonML implementation in BaseX also kills namespace information (no ns >> prefix prepended in my tests), as far as I tested. So this might be a >> problem if I wanted to send and receive data with mixed namespaces. But >> that can be worked around as well somehow... >> Also I don't know what is the perf impact of BaseX's JsonML mapping but I >> don't think it's too much of an issue. >> >> Daniel >> >> -- >> danielkvasnicka.net >> >> On Nov 19, 2012, at 10:08 , Dirk Kirsten <dk at basex.org> wrote: >> >> > This is quite an interesting approach (I didn't know about AngularJS >> before). . In the end it looks like AngularJS does exactly what XForms was >> created for. However, I see your point of no existing 100% satisfying >> XForms implementation as well. But there is one problem with this approach >> in comparison to pure XForms I'd like to mention, though. >> > XForms automatically does form validation on the client and server >> side, AngularJS in comparison is just validating on client side, i.e. you >> are responsible to validate it on server side. Depending on how much and >> what form elements you use this could significantly add work hours. >> Depending on the use case this might be negligible, but everyone thinking >> about the same problem should keep this in mind. And of course AngularJS >> puts some processing on the client, but I guess with nowadays JavaScript >> implementations in the browser this shouldn't be much of an issue. >> > >> > Cheers, >> > Dirk >> > >> > >> > On Mon, Nov 19, 2012 at 9:56 AM, Daniel Kvasnička < >> daniel.kvasnicka at me.com> wrote: >> > Well, I've actually opted for a completely different solution - >> AngularJS & RESTXQ & JsonML. Very cool so far! It actually makes BaseX only >> a service layer and moves all UI composition and teplating to the client. >> > Originally I wanted to make a pure XRX solution but I don't see any >> easily embeddable and widely supported XForms implementation on the market >> (XSLTForms comes close but I see too many "buts" and "ifs"). >> > >> > Daniel >> > >> > -- >> > danielkvasnicka.net >> > >> > On Nov 19, 2012, at 9:47 , Michael Seiferle <ms at basex.org> wrote: >> > >> > > Hi Daniel, >> > > >> > > thanks a lot for your observations, I know moustache.{xq,js} as well, >> and I'd be thrilled if we eventually come up with our own BaseX compatible >> implementation :-) >> > > >> > > Anyway, until then, I'd like to let you know how we handle this at >> the moment: >> > > We introduce a template module that accepts a map of options and some >> content. >> > > Inside the template wrapping function, we wire our page elements with >> the map’s contents. >> > > This proved to be rather flexible while still being lightweight >> enough to be out of the way most of the time. >> > > >> > > Please excuse the messed up highlighting: >> https://gist.github.com/e053068a41eb35e727bb >> > > >> > > We chose maps, as they make it especially easy to provide default >> values that can be easily overridden from calling functions by combining a >> map: >> > >> let $defaults := map {"Foo" := "Bar", "foo" := "bar", "Bar" := "Foo"} >> > >> let $options := map {"Foo" := "Override"} >> > >> let $options := map:new(($defaults, $options)) >> > >> return string-join(map:keys($options) ! (. || " := "|| >> $options(.)), "&#10;") >> > > >> > > I hope this helps feel free to discuss this issue more :) >> > > >> > > Michael >> > > >> > > >> > > >> > > Am 17.11.2012 um 19:27 schrieb Daniel Kvasnička < >> daniel.kvasnicka at me.com>: >> > > >> > >> Hi folks, >> > >> >> > >> another thing I'm trying to solve while working on a XQuery web app. >> What kind of templating system do you use to separate HTML templates from >> the rest of your code? >> > >> >> > >> - XSLT - the only problem I have with this is performance. I tested >> the XSLT Module with Saxon 9 and a primitive page and it was more than 3x >> slower compared to pure XQuery templates (XQuery fn taking $model). Other >> than that I think it's the best built-in option. I actually don't have any >> users-per-second expectations and those templates will be quite small... do >> I overemphasize the perf. question? >> > >> >> > >> - pure XQuery - not aimed at templating at all and it shows I'm >> afraid... just can't come up with a solution that would be clean enough >> (plus HTML, JS & CSS highlighting withing xq files is not good at all, at >> least in Vim) >> > >> >> > >> - I looked at Mustache.xq and quite liked it - depends on MarkLogic >> though :( >> > >> >> > >> - Any hidden gem I haven't googled yet? >> > >> >> > >> Leaning towards XSLT right now... >> > >> Daniel >> > >> >> > >> -- >> > >> danielkvasnicka.net >> > >> >> > >> _______________________________________________ >> > >> BaseX-Talk mailing list >> > >> BaseX-Talk at mailman.uni-konstanz.de >> > >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >> > > >> > >> > _______________________________________________ >> > BaseX-Talk mailing list >> > BaseX-Talk at mailman.uni-konstanz.de >> > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >> > >> > >> > >> > -- >> > Dirk Kirsten, BaseX GmbH, http://basex.org >> > |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz >> > |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: >> > | Dr. Christian Grün, Alexander Holupirek, Michael Seiferle >> > `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22 >> >> _______________________________________________ >> BaseX-Talk mailing list >> BaseX-Talk at mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >> > >

On Mon, Nov 19, 2012 at 6:18 PM, Dirk Kirsten <dk at basex.org> wrote: > Hi all, > > inspired from this discussion I took a look at mustache.xq. I now forked > the implementation to be BaseX compatible. You can check out the source > code at [1]. Most basic stuff already works, so ~72% of the test cases > already pass. I'll take a look at the still failing tests in the next > couple of days. > I'd be thrilled if some of you give it a try as templating system. > Feedback is very welcome. > > Cheers, > Dirk > > [1] https://github.com/dirkk/mustache.xq > > > On Mon, Nov 19, 2012 at 1:56 PM, Andy Bunce <bunce.andy at gmail.com> wrote: > >> Hi Daniel, >> I guess we are making the same journey. I have done quite of lot of >> server side templating with BaseX. I have finally gone round to putting a >> brief write up on my blog [1]. >> >> I have also been using Angularjs with BaseX and find it has a lot pluses. >> I have been playing building a sample app to try to see how it scales. I >> hope to put my findings on my blog soon. It also uses Oauth. >> >> /Andy >> >> [1] >> http://cubeb.blogspot.com/2012/11/xquery-templating-engines-and-txq.html >> >> >> On Mon, Nov 19, 2012 at 9:17 AM, Daniel Kvasnička < >> daniel.kvasnicka at me.com> wrote: >> >>> You're right with the validation issue. Still I think it's the best >>> solution compared to having HTML spilled all over XQuery code (no offence >>> anyone...) or having perf-heavy XSLT. >>> JsonML implementation in BaseX also kills namespace information (no ns >>> prefix prepended in my tests), as far as I tested. So this might be a >>> problem if I wanted to send and receive data with mixed namespaces. But >>> that can be worked around as well somehow... >>> Also I don't know what is the perf impact of BaseX's JsonML mapping but >>> I don't think it's too much of an issue. >>> >>> Daniel >>> >>> -- >>> danielkvasnicka.net >>> >>> On Nov 19, 2012, at 10:08 , Dirk Kirsten <dk at basex.org> wrote: >>> >>> > This is quite an interesting approach (I didn't know about AngularJS >>> before). . In the end it looks like AngularJS does exactly what XForms was >>> created for. However, I see your point of no existing 100% satisfying >>> XForms implementation as well. But there is one problem with this approach >>> in comparison to pure XForms I'd like to mention, though. >>> > XForms automatically does form validation on the client and server >>> side, AngularJS in comparison is just validating on client side, i.e. you >>> are responsible to validate it on server side. Depending on how much and >>> what form elements you use this could significantly add work hours. >>> Depending on the use case this might be negligible, but everyone thinking >>> about the same problem should keep this in mind. And of course AngularJS >>> puts some processing on the client, but I guess with nowadays JavaScript >>> implementations in the browser this shouldn't be much of an issue. >>> > >>> > Cheers, >>> > Dirk >>> > >>> > >>> > On Mon, Nov 19, 2012 at 9:56 AM, Daniel Kvasnička < >>> daniel.kvasnicka at me.com> wrote: >>> > Well, I've actually opted for a completely different solution - >>> AngularJS & RESTXQ & JsonML. Very cool so far! It actually makes BaseX only >>> a service layer and moves all UI composition and teplating to the client. >>> > Originally I wanted to make a pure XRX solution but I don't see any >>> easily embeddable and widely supported XForms implementation on the market >>> (XSLTForms comes close but I see too many "buts" and "ifs"). >>> > >>> > Daniel >>> > >>> > -- >>> > danielkvasnicka.net >>> > >>> > On Nov 19, 2012, at 9:47 , Michael Seiferle <ms at basex.org> wrote: >>> > >>> > > Hi Daniel, >>> > > >>> > > thanks a lot for your observations, I know moustache.{xq,js} as >>> well, and I'd be thrilled if we eventually come up with our own BaseX >>> compatible implementation :-) >>> > > >>> > > Anyway, until then, I'd like to let you know how we handle this at >>> the moment: >>> > > We introduce a template module that accepts a map of options and >>> some content. >>> > > Inside the template wrapping function, we wire our page elements >>> with the map’s contents. >>> > > This proved to be rather flexible while still being lightweight >>> enough to be out of the way most of the time. >>> > > >>> > > Please excuse the messed up highlighting: >>> https://gist.github.com/e053068a41eb35e727bb >>> > > >>> > > We chose maps, as they make it especially easy to provide default >>> values that can be easily overridden from calling functions by combining a >>> map: >>> > >> let $defaults := map {"Foo" := "Bar", "foo" := "bar", "Bar" := >>> "Foo"} >>> > >> let $options := map {"Foo" := "Override"} >>> > >> let $options := map:new(($defaults, $options)) >>> > >> return string-join(map:keys($options) ! (. || " := "|| >>> $options(.)), "&#10;") >>> > > >>> > > I hope this helps feel free to discuss this issue more :) >>> > > >>> > > Michael >>> > > >>> > > >>> > > >>> > > Am 17.11.2012 um 19:27 schrieb Daniel Kvasnička < >>> daniel.kvasnicka at me.com>: >>> > > >>> > >> Hi folks, >>> > >> >>> > >> another thing I'm trying to solve while working on a XQuery web >>> app. What kind of templating system do you use to separate HTML templates >>> from the rest of your code? >>> > >> >>> > >> - XSLT - the only problem I have with this is performance. I tested >>> the XSLT Module with Saxon 9 and a primitive page and it was more than 3x >>> slower compared to pure XQuery templates (XQuery fn taking $model). Other >>> than that I think it's the best built-in option. I actually don't have any >>> users-per-second expectations and those templates will be quite small... do >>> I overemphasize the perf. question? >>> > >> >>> > >> - pure XQuery - not aimed at templating at all and it shows I'm >>> afraid... just can't come up with a solution that would be clean enough >>> (plus HTML, JS & CSS highlighting withing xq files is not good at all, at >>> least in Vim) >>> > >> >>> > >> - I looked at Mustache.xq and quite liked it - depends on MarkLogic >>> though :( >>> > >> >>> > >> - Any hidden gem I haven't googled yet? >>> > >> >>> > >> Leaning towards XSLT right now... >>> > >> Daniel >>> > >> >>> > >> -- >>> > >> danielkvasnicka.net >>> > >> >>> > >> _______________________________________________ >>> > >> BaseX-Talk mailing list >>> > >> BaseX-Talk at mailman.uni-konstanz.de >>> > >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >>> > > >>> > >>> > _______________________________________________ >>> > BaseX-Talk mailing list >>> > BaseX-Talk at mailman.uni-konstanz.de >>> > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >>> > >>> > >>> > >>> > -- >>> > Dirk Kirsten, BaseX GmbH, http://basex.org >>> > |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz >>> > |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: >>> > | Dr. Christian Grün, Alexander Holupirek, Michael Seiferle >>> > `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22 >>> >>> _______________________________________________ >>> BaseX-Talk mailing list >>> BaseX-Talk at mailman.uni-konstanz.de >>> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >>> >> >> > > > -- > Dirk Kirsten, BaseX GmbH, http://basex.org > |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz > |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: > | Dr. Christian Grün, Alexander Holupirek, Michael Seiferle > `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22 >