ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Pablo Rodriguez <oinos@gmx.es>
To: ntg-context@ntg.nl
Subject: Re: new module seeking approval: handlecsv
Date: Sun, 12 Nov 2017 17:32:23 +0100	[thread overview]
Message-ID: <b324aeb7-7c9f-32b5-0a3e-50b75a6d7888@gmx.es> (raw)
In-Reply-To: <CALBOmsYvWN+f8c7g99Sw2XBKUv2i3uFJmUA2DUOJxB02fFLrVA@mail.gmail.com>

On 11/12/2017 11:46 AM, Mojca Miklavec wrote:
> On 11 November 2017 at 21:32, Pablo Rodriguez wrote:
>> [...]
>> If the module is
>> tex/texmf-context/tex/context/modules/mkiv/m-database.mkiv, I think this
>> is only intended for typesetting the database contents.
> 
> Well, it parses CSV files and typesets them in an arbitrary way.

If the module is the same as
http://dl.contextgarden.net/myway/csv.pdf#page=4, having to generate
letters inside a command definition may be a real pain with it.

>> handlecsv enables document merging. With the first (stupid) sample that
>> comes to my mind:
>>
>>     \starttext
>>     \startbuffer
>>     \Name\ has completed the course {\em\Course}, achieving the
>>     following grade: \Grade.\page
>>     \stopbuffer
>>     \doloopforall{\getbuffer}
>>     \stoptext
> 
> Which is exactly what the other module supports. See page 4 of
>     http://dl.contextgarden.net/myway/csv.pdf

Enabling conditional text fragments inside the command definition
doesn’t seem an easy task.

It seems to be much easier to deploy in with the buffer approach (from
handlecsv).

>> Having to do that with before and after options would be a pain (in my
>> opinion).
>>
>> You may page through
>> https://github.com/ousia/handlecsv/blob/context-suite/doc/context/third/handlecsv/handlecsv.pdf
>> to see the features.
> 
> The old module doesn't support invoking columns by title and doesn't
> do any special filters. Another limitation might be that it uses #1,
> #2, ... which reaches it limits pretty soon, but I'm sure that could
> (should?) be fixed anyway.

The approach is different, because the needs are different.

Extending the original module is an option, but ConTeXt has plenty of
things to improve that could come first.

> And certainly the documentation by Jaroslav is much much better
> written than my poor mock-up.

Many thanks for the compliment. The documentation was written by me ;-).

I wrote the documentation after having used the module to create an
automatic document generation method at work. It is far from being
perfect, but it solves some issues.

Your documentation is clear. And your sample on
http://dl.contextgarden.net/myway/csv.pdf#page=7 shows which is the
proper scenarion for the module.

handlecsv was written with something different in mind. Not better or
worse, but simply diverse.

>> I wonder whether it makes sense to extend the built-in module by Hans.
>> If this wasn’t needed before, it may be not needed now.
> 
> This is an oxymoron.

Many thanks for your kindness in the objection :-), although I don’t
think there is a contradiction. I didn’t explain myself well.

> If the functionality is not needed: then why do we need that new
> module in the first place? :)

First, time devoted to ConTeXt is scarce and there are many areas for
improvements (I could name a few :-)).

Second, if the functionality wasn’t required *in that module*, does it
make sense to implement it now?

> What I want to encourage is one well-written and fully functional
> module rather than ending up with ten solutions, each one of them with
> its own set of bugs.

This should be similar to parallel text streams. Hans stated that he
would implement it, when there were a unified proposal.

I don’t think it makes sense to implement new features in the old module
before users start using the new module. Their approaches are totally
different.

> The MKII version of the database module admittedly has a number of
> issues, in particular when it comes to non-ascii.
Does it even make sense even to fix the issues the old module has for
MkII? (If no one had problems for years, new usage cases should deploy
MkIV.)

BTW, handlecsv doesn’t support MkII (only MkIV).

> There might be issues with MKIV as well, I haven't used it
> for a while because I now usually start with lua tables.

It is probably a better method, isn’t it?

> But all in all it would be much better to have some "perfectly
> working" built-in functionality to parse CSV files in my opinion.
Voltaire wrote « le mieux est l’ennemi du bien » (“the perfect is the
enemy of the good”), which is also a saying in Spanish.

I mean, the present m-database.mkiv is just fine for addding tables to
ConTeXt document. A sounder approach to document merging would be to use
SQL databases.

Betweeen those two needs, one can use handlecsv. But I realize that the
best option for some tasks is SQL (I cannot use it at work).

Pablo
-- 
http://www.ousia.tk
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

      reply	other threads:[~2017-11-12 16:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-08 19:46 Pablo Rodriguez
2017-11-11 19:01 ` Mojca Miklavec
2017-11-11 20:32   ` Pablo Rodriguez
2017-11-12 10:46     ` Mojca Miklavec
2017-11-12 16:32       ` Pablo Rodriguez [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b324aeb7-7c9f-32b5-0a3e-50b75a6d7888@gmx.es \
    --to=oinos@gmx.es \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).