Hello again, ok, "couple of days" was just "couple of hours". mustache.xq for BaseX now passes all tests and supports the same as mustache.xq for MarkLogic. Please check out at [1]. Feedback is very welcome.
Cheers, Dirk [1] https://github.com/dirkk/mustache.xq On Mon, Nov 19, 2012 at 6:18 PM, Dirk Kirsten <d...@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.a...@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.kvasni...@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 <d...@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.kvasni...@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 <m...@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(.)), " ") >>> > > >>> > > I hope this helps feel free to discuss this issue more :) >>> > > >>> > > Michael >>> > > >>> > > >>> > > >>> > > Am 17.11.2012 um 19:27 schrieb Daniel Kvasnička < >>> daniel.kvasni...@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@mailman.uni-konstanz.de >>> > >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >>> > > >>> > >>> > _______________________________________________ >>> > BaseX-Talk mailing list >>> > BaseX-Talk@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@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 > -- 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@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
