Hi, I've been working for the last time on a project on sourceforge called kika, that consists on a simple python script, and it's a sort of a plain text preproccessor that uses xml to define the proccessing to be done. I recently made a packaged release (deb and rpm) for linux.

I'm looking for some opinions about the project, to see if anyone thinks it's something that could actually be a usefull tool...

If anyone is interested on checking this out, the projects home page is:

http://kika.sourceforge.net/

And the sourceforge page is:

http://sourceforge.net/projects/kika/

Dani AI

Generated

Useful, concrete things to consider next for , and a response to points raised by .

If the goal is wider adoption, start by documenting a couple of short, real-world workflows (one simple, one slightly advanced). Show input, the minimal configuration required, and the exact output. People evaluate a tool by how quickly they can reproduce a small win. Add a one-paragraph “when to use this” checklist so readers can compare it to other approaches.

Ergonomics matter. If reviewers complain about verbosity or editability, provide two layers: a compact, user-friendly surface for common tasks and the more explicit format for power users. A tiny converter between them lets people start small and graduate to the full feature set when needed. Make the CLI predictable (stdin/stdout support, clear flags for variables and includes) so the tool composes well in shell pipelines.

Improve reliability by adding validation and automated tests. Use a mature parser and expose clear error messages with line/column info so users can fix templates quickly; libraries such as ElementTree or lxml are production-ready choices (ElementTree docs, lxml). Provide a schema (RelaxNG or XSD) for the configuration format so incorrect files fail fast.

For distribution and contributors: publish packaged releases to Python packaging infrastructure (use pyproject.toml, create wheels, and consider PyPI) and add a small test suite (pytest) plus CI to run it on each push. Include a CONTRIBUTING guide, examples directory, a clear license, and short release notes with each new version. Helpful references: Packaging Python projects and pytest docs.

These steps make the tool easier to evaluate, adopt, and contribute to, while addressing the usability concerns raised in the thread.

Recommended Answers

All 2 Replies

You're using XML to preprocess TeX files! TeX! There's already a way to preprocess TeX files; the TeX language itself! It has features for that! Why would you use this? Seriously.

Also, you have several problems: First, you're using XML. That makes things harder. Second, what's with the 'print' element? There's no need to wrap that text in any 'print' element.

Why are you using backslash codes like \n in XML text? Have you seen any other XML format do that?

It's easier to whip up a Perl script than to write out an XML file.

If anything, instead of XML, I'd do something along these lines:

%%
#hello $param1 $param2
@text
#endofhello
%%
Hello Mr. $param1,

@text

Sincerely, $param2
%%
#foobar $k
@text :: $x $y
#/foobar
%%
Listing of $k:

Item: $x\t Zing: $y
%%

Then

#hello Quux Khanbar

How are you doing?  Here are our Dingbats:

#foobar dingbats
Cat 7
Dog 9
Zephyr 23
toozaloo 19
Zamboni -3
#/foobar

#endofhello

gets processed into, well, you can figure it out.

I guess you're right in some things. I actually eliminated the print element cause it was absolutely useless, but the docs that are on the site describe an older version.

Also, tex is just an example, and the idea of using xml, is because it allows a clear visualisation of what is done. Also, the idea is to write the xml file once, and use it many times....

But, anyway, thanks for your opinion :cheesy:

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.