Hungarian Translation updated

[Takó Kornél]

Hi Everybody!

This the updated Hungarian translation. Now it should be usable.

Takó Kornél



2011/7/8 <gnucash-devel-request at gnucash.org>

> Send gnucash-devel mailing list submissions to
>        gnucash-devel at gnucash.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> or, via email, send a message with subject or body 'help' to
>        gnucash-devel-request at gnucash.org
>
> You can reach the person managing the list at
>        gnucash-devel-owner at gnucash.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gnucash-devel digest..."
>
>
> Today's Topics:
>
>   1. Re: GnuCash Documentation 2.4.1 in .epub and .mobi format
>      (Geert Janssens)
>   2. Re: Reporting system and potentially Python (Geert Janssens)
>   3. Re: build check failure: POTFILES references non-existing
>      gnc-pricedb-static.c? (Geert Janssens)
>   4. Re: GnuCash Documentation 2.4.1 in .epub and .mobi format
>      (Geert Janssens)
>   5. Re: GnuCash Documentation 2.4.1 in .epub and .mobi format
>      (SASAKI Suguru)
>   6. Re: GnuCash Documentation 2.4.1 in .epub and .mobi format
>      (SASAKI Suguru)
>   7. Re: Reporting system and potentially Python (Tim M)
>   8. Re: Reporting system and potentially Python (John Ralls)
>   9. Re: Invoice Importer (Mike Evans)
>  10. Re: Reporting system and potentially Python (Tim M)
>  11. Re: Reporting system and potentially Python (John Ralls)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 8 Jul 2011 10:51:13 +0200
> From: Geert Janssens <janssens-geert at telenet.be>
> To: gnucash-devel at gnucash.org
> Subject: Re: GnuCash Documentation 2.4.1 in .epub and .mobi format
> Message-ID: <201107081051.13556.janssens-geert at telenet.be>
> Content-Type: Text/Plain;  charset="iso-8859-1"
>
> On donderdag 7 juli 2011, SASAKI Suguru wrote:
> > Hi,
> >
> > No one seems to be intereted in this, but
> No, no, I am interested, but I didn't have the time yet to respond. I'll
> see
> if I can pull your build system tweaks and merge them in the main
> repository.
>
> I personally like the possibility to generate more available formats.
>
> > I have pushed some tweakes in build system and push to
> >   https://github.com/sss/gnucash-docs/tree/2.4.1-in-epub-and-mobi
> > , and you can downloadn .epub / .mobi from
> >   https://github.com/sss/gnucash-docs/downloads .
> >
> > Thanks,
>
> Thanks for your work on this!
>
> Geert
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 8 Jul 2011 11:21:13 +0200
> From: Geert Janssens <janssens-geert at telenet.be>
> To: gnucash-devel at gnucash.org
> Subject: Re: Reporting system and potentially Python
> Message-ID: <201107081121.13905.janssens-geert at telenet.be>
> Content-Type: Text/Plain;  charset="iso-8859-1"
>
> On vrijdag 8 juli 2011, Tim M wrote:
> > What I'm looking for is this:
> >
> > Separate the act of actually gathering the data from the GnuCash database
> > from transforming it for display, so that the output can be made much
> more
> > interactive and easy to style and make 'pretty' :).  Use a well known
> > programming language to aggregate the data to make it easier to create
> new
> > reports which output different sets of data.
> >
> > I've thought about this a little bit, and here is what I am thinking.
>  Let
> > me know if this sounds un/reasonable or just plain incorrect.  (Note that
> I
> > am basing this off of not being familiar yet with how the current scheme
> > architecture actually manages pulling the data out of gnucash, so please
> > correct me where I am wrong or point out the significant flaws)
> >
> > 1. Create the 'new' reporting system alongside the existing one so that
> the
> > reports do not suffer until the existing functionality can be fully
> > replaced by the new system.  After all reports are replaced and working,
> > the old scheme code could be pulled.
> > 2. Create a set of libraries and/or use the existing gnucash libraries
> for
> > querying information from the database.  Based on the discussion, I
> presume
> > C or Objective C would be best and just avoid Python/Scheme altogether (I
> > am not sure how the scheme system actually performs the data queries
> right
> > now).  If all the necessary code is already in place, then this does not
> > require any work.
> > 3. Using these libraries, create the code for aggregating the data (also
> in
> > C or Objective C) for each report.  A single prototype report would be OK
> > to start.  Output the report data as structured XML.  The XML data should
> > adhere to an XML schema.
> > 4. For each report, create an XSLT file which will transform the data
> into
> > HTML/XHTML for display.
> > 5. A small amount of javascript would be needed to perform the actual
> XSLT
> > transformation but it would be pretty small.
> > 6. Style the page elements using CSS.  Also, I think the jqplot patch
> that
> > has been made could be migrated in to the new reporting system, as those
> > graphs look really nice.
> >
> >
> > I think there are several benefits to this approach:
> >
> > 1. Currently reports can only be exported as HTML.  By making the
> reporting
> > code export an XML data structure, reports could be easily exported from
> > GnuCash as XML (pre-transformation) or as HTML (post-transformation).
> > 2. Anyone could write their own XSLT transformation file to display the
> > data differently.
> Like pdf, using the fop transformer. An improvement that would also be
> greatly
> appreciated by users of the business features.
> We have already some experience with this transform in the gnucash-docs, so
> it
> would not be too difficult to apply that experience on the reports.
>
> So me too I like your ideas of starting with xml and the separation into
> XSLT,
> CSS and friends.
>
> > 3. The actual XSLT, HTML, and CSS code would be very easy to read and
> > modify by anyone familiar with it.  The backend reports would still be in
> > C/Objective C for compiling the data and as such require some coding
> > knowledge, but it would be much easier to start using than the existing
> > scheme code.
> This part is not clear to me. Do you mean that if Joe user wants to add a
> new
> report, he will have to write some C code, like for example to add a new
> data
> query ?
>
> I guess that would limit the extendability of the reports equally to having
> them in scheme.
>
> John's suggestion to find something sql-query like to gather data might be
> nicer, as would Yawar's proposal to go for a completely declarative report.
> Both mechanisms work generically with the raw data and would adapt easily
> to
> data format changes. By the way, GnuCash comes with a query framework for
> its
> data: qof-query. It mayor may not be suitable as a basis for the first
> suggestion.
>
> I'm tempted to say here that such a generic and easy to use interface could
> be
> implemented as a later improvement, but at the same time I have a feeling
> that
> such a decision should be taken early on, because it would greatly
> influence
> how everything gets implemented.
>
> > 4. The XSLT and CSS could be very easily modified and applied not only
> > inside of GnuCash, but a user could also take the XSLT and CSS scripts,
> > modify and apply them to the exported XML reports to give it their own
> look
> > without touching the GnuCash code base at all.  For example they might
> want
> > to style a report with a company logo or different colors or other
> > graphical elements.
> > 5a. In the future, it would be possible to provide multiple different
> XSLT
> > and/or CSS styles for the reports so users could select the appearance of
> > the reports. (If someone writes additional styles)
> > 5b. In the future, it would be possible to allow users to import their
> own
> > style sheets into GnuCash and apply them to the reports. (if someone
> writes
> > the code to manage the import and style selection)
> I already some kind of a theme foundry as part of the GnuCash website,
> where
> users can add stylesheets for others to use. Something in the lines of the
> online kde/gnome theme stores
>
> Geert
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 8 Jul 2011 12:40:31 +0200
> From: Geert Janssens <janssens-geert at telenet.be>
> To: gnucash-devel at gnucash.org
> Cc: Derek Atkins <warlord at mit.edu>
> Subject: Re: build check failure: POTFILES references non-existing
>        gnc-pricedb-static.c?
> Message-ID: <201107081240.31981.janssens-geert at telenet.be>
> Content-Type: Text/Plain;  charset="iso-8859-1"
>
> On donderdag 7 juli 2011, Derek Atkins wrote:
> > Hey,
> >
> > I just tried to build a clean build from a clean checkout of trunk on a
> > fresh Fedora-15 system.  In addition to two bugs I just filed I also ran
> > into another issue in "make check" on trunk:
> >
> > make[1]: Entering directory
> > `/home/warlord/src/gnucash/gnucash-svk/build/po' make[1]: *** No rule to
> > make target `../src/engine/gnc-pricedb-static.c', needed by
> `gnucash.pot'.
> >  Stop. make[1]: Leaving directory
> > `/home/warlord/src/gnucash/gnucash-svk/build/po' make: ***
> > [check-recursive] Error 1
> >
> > I cannot find gnc-pricedb-static.c in the sources, but it does appear to
> > be in POTFILES.in?
> >
> > Was this an oversight?  POTFILES.in was last modified on May 31st:
> > r20723:  gjanssens | 2011-05-31 09:07:30 -0400
> >
> > -derek
>  This has been fixed now.
>
> Geert
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 8 Jul 2011 12:50:33 +0200
> From: Geert Janssens <janssens-geert at telenet.be>
> To: gnucash-devel at gnucash.org
> Subject: Re: GnuCash Documentation 2.4.1 in .epub and .mobi format
> Message-ID: <201107081250.33470.janssens-geert at telenet.be>
> Content-Type: Text/Plain;  charset="iso-8859-1"
>
> On vrijdag 8 juli 2011, Geert Janssens wrote:
> > On donderdag 7 juli 2011, SASAKI Suguru wrote:
> > > Hi,
> > >
> > > No one seems to be intereted in this, but
> >
> > No, no, I am interested, but I didn't have the time yet to respond. I'll
> > see if I can pull your build system tweaks and merge them in the main
> > repository.
> >
> > I personally like the possibility to generate more available formats.
> >
> > > I have pushed some tweakes in build system and push to
> > >
> > >   https://github.com/sss/gnucash-docs/tree/2.4.1-in-epub-and-mobi
> > >
> > > , and you can downloadn .epub / .mobi from
> > >
> > >   https://github.com/sss/gnucash-docs/downloads .
> > >
> > > Thanks,
> >
> > Thanks for your work on this!
> >
> Ok, I have taken a closer look your your tweaks.
>
> I have a few questions:
> 1. I notice you use a ruby script to convert to epub. Why did you choose
> that
> instead of the standard docbook xsl transformation ? The epub stylesheet is
> not part of our repository because we never used it before, but it can be
> added easily.
>
> 2. The mobi format appears to be created using a conversion tool that is
> shipped with calibre on my Fedora system. This is fine in itself, but it
> would
> be useful if you could add a note about this in the README file. That would
> help people that want to generate mobi formatted documentation.
>
> Regards,
>
> Geert
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 8 Jul 2011 20:39:50 +0900
> From: SASAKI Suguru <sss.sonik at gmail.com>
> To: gnucash-devel at gnucash.org
> Subject: Re: GnuCash Documentation 2.4.1 in .epub and .mobi format
> Message-ID:
>        <CAE3X6mw1T-CPcSPQP44bBD+qrMFrWFp2Sq7Bn_hOV9c1S061TQ at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> Thanks for reviewing.
>
>
> 2011-07-08 Geert Janssens <janssens-geert at telenet.be>:
> > Ok, I have taken a closer look your your tweaks.
> >
> > I have a few questions:
> > 1. I notice you use a ruby script to convert to epub. Why did you choose
> that
> > instead of the standard docbook xsl transformation ? The epub stylesheet
> is
> > not part of our repository because we never used it before, but it can be
> > added easily.
>
> I know that we can convert DocBook to XHTML with standard XSLT,
> and then convert XHTML to EPUB with somthing like calbre.
>
> This Ruby script came from DocBook project(, and packaged as dbtoepub
> in Debian (sid)).
> README about this script at
> <URL:http://docbook.sourceforge.net/release/xsl/current/epub/README> says,
>
>  | These are XSL stylesheets for transforming DocBook XML document
>  | instances into .epub format.
>  | [...]
>  | An alpha-quality reference implementation (dbtoepub) for a DocBook to
> .epub
>  | converter (written in Ruby) is available under bin/.
>
> They say these scripts and XSL stylesheets are alpha-quality,
> but I think this is somewhat specialized for EPUB generation
> and we can get better results with these
> than going through DocBook -> XHTML -> EPUB on our own.
>
>
> > 2. The mobi format appears to be created using a conversion tool that is
> > shipped with calibre on my Fedora system. This is fine in itself, but it
> would
> > be useful if you could add a note about this in the README file. That
> would
> > help people that want to generate mobi formatted documentation.
>
> Exactly.
> We need some notes in README and some tweak in spec file for packaging.
> I'll work on that.
>
>
> Best regards,
>
> --
> SASAKI Suguru
>  mailto:sss.sonik at gmail.com
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 8 Jul 2011 20:46:17 +0900
> From: SASAKI Suguru <sss.sonik at gmail.com>
> To: gnucash-devel at gnucash.org
> Subject: Re: GnuCash Documentation 2.4.1 in .epub and .mobi format
> Message-ID:
>        <CAE3X6mwgvh72uwsmnm1rBDg0V4P0JfMgfS-Pz60SjMtOSoSZxg at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> I've misread one point.
>
> > Ok, I have taken a closer look your your tweaks.
> >
> > I have a few questions:
> > 1. I notice you use a ruby script to convert to epub. Why did you choose
> that
> > instead of the standard docbook xsl transformation ? The epub stylesheet
> is
> > not part of our repository because we never used it before, but it can be
> > added easily.
>
> Right.  If we'll merge stylesheets for EPUB into gnucash-doc repository,
> this Ruby script is not necessary, I guess.
>
> I'll investigate it as well.
>
>
> Regards,
>
> --
> SASAKI Suguru
>  mailto:sss.sonik at gmail.com
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 8 Jul 2011 07:20:27 -0500
> From: Tim M <tim at filmchicago.org>
> To: Geert Janssens <janssens-geert at telenet.be>
> Cc: gnucash-devel at gnucash.org
> Subject: Re: Reporting system and potentially Python
> Message-ID:
>        <CAM3W-Lr11xBaAGzV5pVsQjpvFfm=OBx4vmypQwp-DmKngeW7Bw at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> Yawar's suggestion is quite interesting, but the declarative XML you
> suggest
> is bordering the functionality of a web service.  I like the idea of having
> the XML declarations but there still then must be some way for the user to
> select individual accounts included in the report, which will require some
> communication between the reporting system and gnucash.
>
> I think a web service would actually be perfect for this, as this would
> then
> totally externalize the reporting infrastructure.  I'm not sure, however,
> exactly what implications this would have.  I would have to see how this
> can
> be handled - if a port can simply be opened and listened on for requests,
> or
> if it would require bundling some type of web service such as tomcat.  I
> would think it could be done just using a listening port but I haven't
> actually written a web service before so I'm not sure.  There are probably
> libraries already available which could handle the requests, otherwise we
> would have to roll our own.  Also, I wonder if we can make the actual
> requests with Javascript - the WSDL would eliminate the C -> Javascript
> access issues mentioned earlier.
>
>
> What this would require then would be to create a WSDL for the available
> methods and then similar to Yawar's suggestion, the report would make a
> request to the GnuCash web service for the information needed to generate
> the report, and the web service would return the results as XML.  At that
> point the XSLT would transform the XML data into HTML for display and
> voila,
> you have a report which has been generated entirely using code and methods
> externally accessible from GnuCash.
>
>
> Having a web service could make for some very interesting use cases such as
> generating reports directly inside a web page (such as if a business has an
> intranet where they want to be able to gather and view their financial
> data).  Also, it opens up the possibility of creating additional web
> service
> methods which not only read but also write data.  For example, a user could
> enter transactions from a web form and on submitting the form, the web
> service request is sent to GnuCash which adds the txn to the database for
> the appropriate account.
>
> Another use case for a read/write web service would be having a "GnuCash
> Server" which would mitigate the problems associated with having multiple
> clients reading and writing to gnucash at one time.  For example, GnuCash
> would sit on a dedicated system listening for web service requests.  Client
> machines running copies of GnuCash would then connect to the server (I
> think
> it could be implemented as just another interface to the data such as we
> have XML and DBI currently) to access the GnuCash data.  Finally, when a
> user action causes a insert/update/delete request, all user's requests
> would
> go through the central GnuCash server so they would not be able to access
> the file concurrently, thus preventing user collisions when editing the
> file.  This is of course very ambitious and wouldn't happen unless someone
> saw the need and implemented all of the functionality that would be needed
> in the web service, but you get the point.
>
> -Tim
>
> On Fri, Jul 8, 2011 at 4:21 AM, Geert Janssens <janssens-geert at telenet.be
> >wrote:
>
> > John's suggestion to find something sql-query like to gather data might
> be
> > nicer, as would Yawar's proposal to go for a completely declarative
> report.
> > Both mechanisms work generically with the raw data and would adapt easily
> > to
> > data format changes. By the way, GnuCash comes with a query framework for
> > its
> > data: qof-query. It mayor may not be suitable as a basis for the first
> > suggestion.
> >
> > I'm tempted to say here that such a generic and easy to use interface
> could
> > be
> > implemented as a later improvement, but at the same time I have a feeling
> > that
> > such a decision should be taken early on, because it would greatly
> > influence
> > how everything gets implemented.
> >
> > > 4. The XSLT and CSS could be very easily modified and applied not only
> > > inside of GnuCash, but a user could also take the XSLT and CSS scripts,
> > > modify and apply them to the exported XML reports to give it their own
> > look
> > > without touching the GnuCash code base at all.  For example they might
> > want
> > > to style a report with a company logo or different colors or other
> > > graphical elements.
> > > 5a. In the future, it would be possible to provide multiple different
> > XSLT
> > > and/or CSS styles for the reports so users could select the appearance
> of
> > > the reports. (If someone writes additional styles)
> > > 5b. In the future, it would be possible to allow users to import their
> > own
> > > style sheets into GnuCash and apply them to the reports. (if someone
> > writes
> > > the code to manage the import and style selection)
> > I already some kind of a theme foundry as part of the GnuCash website,
> > where
> > users can add stylesheets for others to use. Something in the lines of
> the
> > online kde/gnome theme stores
> >
> > Geert
> >
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 8 Jul 2011 09:44:03 -0400
> From: John Ralls <jralls at ceridwen.us>
> To: Tim M <tim at filmchicago.org>
> Cc: gnucash-devel at gnucash.org
> Subject: Re: Reporting system and potentially Python
> Message-ID: <D58153C1-2C5D-4085-A2AD-8781CB93C859 at ceridwen.us>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Jul 8, 2011, at 8:20 AM, Tim M wrote:
>
> > Yawar's suggestion is quite interesting, but the declarative XML you
> suggest is bordering the functionality of a web service.  I like the idea of
> having the XML declarations but there still then must be some way for the
> user to select individual accounts included in the report, which will
> require some communication between the reporting system and gnucash.
> >
> > I think a web service would actually be perfect for this, as this would
> then totally externalize the reporting infrastructure.  I'm not sure,
> however, exactly what implications this would have.  I would have to see how
> this can be handled - if a port can simply be opened and listened on for
> requests, or if it would require bundling some type of web service such as
> tomcat.  I would think it could be done just using a listening port but I
> haven't actually written a web service before so I'm not sure.  There are
> probably libraries already available which could handle the requests,
> otherwise we would have to roll our own.  Also, I wonder if we can make the
> actual requests with Javascript - the WSDL would eliminate the C ->
> Javascript access issues mentioned earlier.
> >
> >
> > What this would require then would be to create a WSDL for the available
> methods and then similar to Yawar's suggestion, the report would make a
> request to the GnuCash web service for the information needed to generate
> the report, and the web service would return the results as XML.  At that
> point the XSLT would transform the XML data into HTML for display and voila,
> you have a report which has been generated entirely using code and methods
> externally accessible from GnuCash.
> >
> >
> > Having a web service could make for some very interesting use cases such
> as generating reports directly inside a web page (such as if a business has
> an intranet where they want to be able to gather and view their financial
> data).  Also, it opens up the possibility of creating additional web service
> methods which not only read but also write data.  For example, a user could
> enter transactions from a web form and on submitting the form, the web
> service request is sent to GnuCash which adds the txn to the database for
> the appropriate account.
> >
> > Another use case for a read/write web service would be having a "GnuCash
> Server" which would mitigate the problems associated with having multiple
> clients reading and writing to gnucash at one time.  For example, GnuCash
> would sit on a dedicated system listening for web service requests.  Client
> machines running copies of GnuCash would then connect to the server (I think
> it could be implemented as just another interface to the data such as we
> have XML and DBI currently) to access the GnuCash data.  Finally, when a
> user action causes a insert/update/delete request, all user's requests would
> go through the central GnuCash server so they would not be able to access
> the file concurrently, thus preventing user collisions when editing the
> file.  This is of course very ambitious and wouldn't happen unless someone
> saw the need and implemented all of the functionality that would be needed
> in the web service, but you get the point.
> >
>
> This is in general a good plan, but you need to know that there's a reason
> for the engine code to be between the storage backends and the GUI and
> reporting system: It's the part that knows how to manage currencies and lots
> and invoices and such. In database applications that's called the business
> logic layer. Now it's true that a lot of what is in our engine belongs in
> the  database layer (the backend), but there's also a lot that can't go
> there because databases don't know how to do it. Fixing that is another
> long-term project.
>
> Reports, the GUI, and even the command-line are called the presentation
> layer. The presentation layer has to pass all of its requests through the
> business logic layer to ensure that all of the accounting rules are applied
> correctly; nothing but the business logic layer should talk to the database
> layer. That's the theory. The reality of Gnucash is that the engine API is
> so confusing and inflexible that the new DBI backend has tempted people to
> try querying the backend directly with SQL so that they can get the reports
> they want without having to spend the time to learn the engine's API.
>
> Geert mentioned the QofQuery class. I'm concerned that it's both too
> limited in function and too low-level (it's used by the engine to query data
> structures, so it may not apply business logic to its results) to work as a
> direct interface for a report service. It's worth studying, though, because
> modifying it might be the shortest path to getting a workable query
> interface.
>
> Regards,
> John Ralls
>
>
>
>
> ------------------------------
>
> Message: 9
> Date: Fri, 8 Jul 2011 14:56:52 +0100
> From: Mike Evans <mikee at saxicola.idps.co.uk>
> To: gnucash-devel at gnucash.org
> Subject: Re: Invoice Importer
> Message-ID: <201107081456.53222.mikee at saxicola.idps.co.uk>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> On Monday 13 Jun 2011 01:31:48 knew two gnucash wrote:
> > It didn't like the permissions the 1st round - said it could not open the
> > file.   Solved that  with some chmod + action and got:
> >
> > woop /usr/local/share/gnucash/python
> > Hello from python!
> > Entries for test, test2 and test3 show up that did not when the error was
> > 'can't open file'
> >
> > Alas, I do not see a change in the menus.
> >
> > So - what am I missing?
> >
> Sorry for the delayed reply I've not been monitoring the list lately.
> You have edit your config.user file to enable the module.  Add the line:
>
> (gnc:module-load "gnucash/plugins/bi_import" 0)
>
> to it.  On linux this file is in  $HOME/.gnucash
>
>
> --
> GPG Key: 1024D/050895C2
> Keyserver: http://pgp.mit.edu/
> Search String: 0x050895C2
>
>
> ------------------------------
>
> Message: 10
> Date: Fri, 8 Jul 2011 09:24:21 -0500
> From: Tim M <tim at filmchicago.org>
> To: John Ralls <jralls at ceridwen.us>
> Cc: gnucash-devel at gnucash.org
> Subject: Re: Reporting system and potentially Python
> Message-ID:
>        <CAM3W-Lq4m5XDS_CvO4k0Ptgcm0b-VDbVR=Sqxgg1Poz1cxJNKg at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Jul 8, 2011 at 8:44 AM, John Ralls <jralls at ceridwen.us> wrote:
>
> >
> > This is in general a good plan, but you need to know that there's a
> reason
> > for the engine code to be between the storage backends and the GUI and
> > reporting system: It's the part that knows how to manage currencies and
> lots
> > and invoices and such. In database applications that's called the
> business
> > logic layer. Now it's true that a lot of what is in our engine belongs in
> > the  database layer (the backend), but there's also a lot that can't go
> > there because databases don't know how to do it. Fixing that is another
> > long-term project.
> >
> > Reports, the GUI, and even the command-line are called the presentation
> > layer. The presentation layer has to pass all of its requests through the
> > business logic layer to ensure that all of the accounting rules are
> applied
> > correctly; nothing but the business logic layer should talk to the
> database
> > layer. That's the theory. The reality of Gnucash is that the engine API
> is
> > so confusing and inflexible that the new DBI backend has tempted people
> to
> > try querying the backend directly with SQL so that they can get the
> reports
> > they want without having to spend the time to learn the engine's API.
> >
> > Geert mentioned the QofQuery class. I'm concerned that it's both too
> > limited in function and too low-level (it's used by the engine to query
> data
> > structures, so it may not apply business logic to its results) to work as
> a
> > direct interface for a report service. It's worth studying, though,
> because
> > modifying it might be the shortest path to getting a workable query
> > interface.
> >
> > Regards,
> > John Ralls
> >
> >
> John,
>
> Thank you for the clarification.
>
> I think we are on the same page.  Any sort of "web service" would act just
> as an interface to the outside (the Report system, or other third-party
> requests to the GnuCash web service) and then internally it would perform
> queries against the GnuCash DB via the engine code.  I never had any
> intention of querying the DB directly - I only intended to wrap the engine
> code (whether it be QofQuery or whatever else is appropriate).  The web
> service methods would only call the necessary engine code to query the
> data,
> and then wrap the results into the XML output and send it back to the
> client.
>
> Are you saying that it may be a problem to implement a web service to query
> the database using the engine code to generate the reports this way?  Isn't
> this what the scheme reports do now?  Otherwise how do they access the data
> to generate the reports?  I presume they do not access the DB directly but
> use the engine code to do it.
>
> As I see it, the web service should work more or less as follows:
> 1. A Report or other service issues a SOAP/REST request to the GnuCash web
> service.  The request must adhere to the GnuCash WSDL (anything not
> adhering
> to it will be ignored).
> 2. The GnuCash web service receives the request.
> 3. The web service queries the database using the GnuCash engine code.
> 4. The web service wraps the results from the engine code into an XML
> wrapper.
> 5. The web service sends the XML output back to the client.
> 6. The XSLT translation occurs on the client to display the data.
>
> Thanks,
> -Tim
>
>
> ------------------------------
>
> Message: 11
> Date: Fri, 8 Jul 2011 11:28:10 -0400
> From: John Ralls <jralls at ceridwen.us>
> To: Tim M <tim at filmchicago.org>
> Cc: "gnucash-devel at gnucash.org list" <gnucash-devel at gnucash.org>
> Subject: Re: Reporting system and potentially Python
> Message-ID: <C95C4CFE-D75E-4EF2-B139-6B633455DF10 at ceridwen.us>
> Content-Type: text/plain;       charset=us-ascii
>
>
> On Jul 8, 2011, at 10:24 AM, Tim M wrote:
>
> >
> >
> > On Fri, Jul 8, 2011 at 8:44 AM, John Ralls <jralls at ceridwen.us> wrote:
> >
> > This is in general a good plan, but you need to know that there's a
> reason for the engine code to be between the storage backends and the GUI
> and reporting system: It's the part that knows how to manage currencies and
> lots and invoices and such. In database applications that's called the
> business logic layer. Now it's true that a lot of what is in our engine
> belongs in the  database layer (the backend), but there's also a lot that
> can't go there because databases don't know how to do it. Fixing that is
> another long-term project.
> >
> > Reports, the GUI, and even the command-line are called the presentation
> layer. The presentation layer has to pass all of its requests through the
> business logic layer to ensure that all of the accounting rules are applied
> correctly; nothing but the business logic layer should talk to the database
> layer. That's the theory. The reality of Gnucash is that the engine API is
> so confusing and inflexible that the new DBI backend has tempted people to
> try querying the backend directly with SQL so that they can get the reports
> they want without having to spend the time to learn the engine's API.
> >
> > Geert mentioned the QofQuery class. I'm concerned that it's both too
> limited in function and too low-level (it's used by the engine to query data
> structures, so it may not apply business logic to its results) to work as a
> direct interface for a report service. It's worth studying, though, because
> modifying it might be the shortest path to getting a workable query
> interface.
> >
> > Regards,
> > John Ralls
> >
> >
> > John,
> >
> > Thank you for the clarification.
> >
> > I think we are on the same page.  Any sort of "web service" would act
> just as an interface to the outside (the Report system, or other third-party
> requests to the GnuCash web service) and then internally it would perform
> queries against the GnuCash DB via the engine code.  I never had any
> intention of querying the DB directly - I only intended to wrap the engine
> code (whether it be QofQuery or whatever else is appropriate).  The web
> service methods would only call the necessary engine code to query the data,
> and then wrap the results into the XML output and send it back to the
> client.
> >
> > Are you saying that it may be a problem to implement a web service to
> query the database using the engine code to generate the reports this way?
>  Isn't this what the scheme reports do now?  Otherwise how do they access
> the data to generate the reports?  I presume they do not access the DB
> directly but use the engine code to do it.
> >
> > As I see it, the web service should work more or less as follows:
> > 1. A Report or other service issues a SOAP/REST request to the GnuCash
> web service.  The request must adhere to the GnuCash WSDL (anything not
> adhering to it will be ignored).
> > 2. The GnuCash web service receives the request.
> > 3. The web service queries the database using the GnuCash engine code.
> > 4. The web service wraps the results from the engine code into an XML
> wrapper.
> > 5. The web service sends the XML output back to the client.
> > 6. The XSLT translation occurs on the client to display the data.
>
> Tim,
> You confused me with the line
> >>> I think it could be implemented as just another interface to the data
> such as we have XML and DBI currently
> Those are the database or storage layer interfaces that engine uses for
> persistence, not interfaces that presentation layer code should use.
>
> My concern with WSDL is that each Scheme report is a function which calls
> engine functions. There's no generalized query language or query interface
> AFAICT. I don't know anything about building a WSDL, but if it's like other
> query languages (e.g. SQL) it seems likely to me that there will be a pretty
> bad impedance mismatch in some areas.
>
> Also, as you've laid out the flow, it seems a bit heavyweight for the
> internal report generator. Rather than having to format an http request and
> setting up an IP listener in Gnucash (and consequent (x)inetd setup),
> wouldn't a socket interface that both the Report subsystem and the web
> server connect to?  Simplifying the report side further, once we have the
> code to handle general query strings and return XML, that interface can
> pretty easily be provided both as an API (returning a DOM tree to save
> writing/parsing overhead) and a socket interface for a SOAP/REST server --
> or anything else we dream up later -- to connect to.
>
> Regards,
> John Ralls
>
>
>
> ------------------------------
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>
> End of gnucash-devel Digest, Vol 100, Issue 10
> **********************************************
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hu.po
Type: text/x-gettext-translation
Size: 836395 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20110715/2d1c5c4e/attachment-0001.bin>