Older blog entries for dsnopek (starting at number 3)

28 Aug 2003 (updated 28 Aug 2003 at 16:05 UTC) »

In my never ending attempt refactor Xmldoom, it is turning into a monster. Here is the layout I envision for the future.

Move Definition.py and Parser.py into a new Definition/ module. These two are so tied together anyway. Then create a Compile/ (or "Compiler"?) module that contains the contents of SQL.py split into SQL.py and Compile.py. We can then include a parser/generator for a now-imaginary XML format for the compiled code. I am also considering eliminating Config.py and putting the SQL config stuff in the new Compile/ module. This would open up the possibily for moving the backend specific config into loadable modules like in Output/. The only problem is where to move the API config stuff since it is needed by both Output/ and PyRE.py.

This would make the following structure:

Xmldoom/
Xmldoom/Definition/ # dealing with the XML database definition
Xmldoom/Definition/Parser.py # parsing the XML
Xmldoom/Definition/Definition.py # the abstract in-memory version
Xmldoom/Definition/__init__.py # connects the parser and definition
Xmldoom/Compiler/SQL.py # the SQL query building code
Xmldoom/Compiler/Compiler.py # turns a definition into our compiled format
Xmldoom/Compiler/Parser.py # XML parser for the XML compiled format
Xmldoom/Compiler/__init__.py # connects all the parts into simple functions
Xmldoom/Output/ # does code generation
Xmldoom/PyRE.py # runtime engine (maybe make into directory?)

This would break the the whole Xmldoom process into distinct packages in the source tree:

Definition --> Compiler --> PyRE

- or -

Definition --> Compiler --> Output

Each part would, of course, have its own internal process and interaction of its modules that may be non-linear. But the new design would have the advantage of organizing all the major parts into there distinctly linear relationship.

This code base slowly turning from a convoluted mess into a coding masterpeice!

    This diary entry exists only to test my new Advogato client.  Its written in
XML-RPC & Python that allows me to write plain text, which will be converted
into equivantent HTML.  My diary needs are simple, I require no formatting
(other than lists, tabs and white space), I want to use Vim to compose my
entries, and I must be able to enter XML/HTML tags as literals.

Here is some test XML, that I hope will get formatted properly:
   <document>
     <paragraph> My, What a wonderful paragraph you have there? </paragraph>
     <paragraph> I thought so too! !! !     ;-)    ! !! </paragraph>
   <document>

Hey look!  A list:

  • test
</ul></ul>

26 Aug 2003 (updated 26 Aug 2003 at 21:45 UTC) »

I was trying to test my new script by posting a diary entry but instead posted the script itself. Eliminated to hide my password.

I have been working on the RMA database at work, and have discovered the following features need to be add to Xmldoom:

1. Enumeration support. This means that the existing <column ...> col_name </column> tags need to be changed to <column name="col_name" .../> so that we can support syntax like:

<enumeration name="status"> <item value="open"/> <item value="closed"/> </enumeration>

2. Argument lists. Currently arguments only accept single values. You should be able to pass a list of arguments for a where clause that get AND'd or OR'd together. I see a new tag <argument-list mode="..." />.

3. Optional arguments. So that we don't have to make all sorts of methods like: "FindItemBySerial" and "FindItemBySerialAndStatus". We could just define "FindItemBySerial" with an optional status argument. This would seriously improve usability.

4. Named arguments. Add an optional 'name="..."' to all argument types (single and list). This way we can support "keyword arguments" for all languages that support them, namely Python. Arguments add by default (ie. not with an <argument ...> tag) should either use the column name or provide a superflous <argument ...> tag inorder to name it.

5. More complex <where> usage. Currently we can only set-up where clauses that are all AND'd together. I want to support nested AND and OR clauses. Proposed usage:

<where mode="AND"> <constraint column="status" comparison="IS" value="Closed"/> <constraint column="status" comparison="IS" value="Denied"/> </where>

This is just what I thought of today. I guess I have my work cut out for me!

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!