Kent Johnson wrote:
> Ognen Duzlevski wrote:
>> I appreciate your comments. Basically, the reason why this code generator
>> exists is the fact that I do not want to hard-code the resulting xml in
>> any way. The users of the web/db framework of which this solution is part of
>> might like the "web page" definition I offer them, but, some might want to
>> extend it.
>> While dom allows me to traverse an xml hierarchy - it does not allow me to
>> give "meaning" to the tags. The only way to do that (for me) is to represent
>> the tags as classes with containers containing other classes (tags) and so
>> on. Since
>> I do not know ahead of time what the tags will be - I need to generate the
>> code
>> to actually handle them.
>>
>> Can you suggest a better approach or did you already do that and I just
>> missed
>> it? :)
>
> Instead of generating Python code and importing it, you could create the
> classes directly. You would still have your own language but no code
> generator.
While I agree that this is much better than code generation, why not go
a step further?
Your "description language" could be as well a subset of the Python language.
So you could get rid of the parser, too. Add the "meaning" simply by creating
subclasses in Python.
This approach has the disadvantage of a slightly more complicated syntax of
the definition files. However, the advantage is that this syntax would be
valid Python code, so everyone who's learning it will also learn a small piece
of Python, and thus reusable knowlege. Learning a special newly invented
language (so-called "DSL" - domain specific language) is *not* resuable
knowledge.
The second advantage is a greater flexibility. You can use real Python code
to model some more complex "definition files". Otherwise, you'll have to
enhance your definition language for every new feature or meta-feature
you introduce. In this case, your own language would become more and more
messy over time. Why don't you take a great, well-designed, simple, general
purpose language which already exist? ... such as Python ;-)
However, this is a completely different strategy: You wouldn't parse the
defintion files. Instead, your definition files are Python modules which
your application imports. This can be a security risk if you want these
modules to be edited "online". However, if your definition files are only
put into a directory of the server, i.e. if you handle them just as your
Python sources anyway, this won't be a disadvantage. (Instead, if would be
a great advantage!)
So you have to decide yourself: Do you really need the description files
to be read in on-the-fly? Then stick with your own language. Are your
definition files more like modules/extensions which are installes together
with the source files? Then just *make* them source files, too, i.e.
realize your "description files" simply as Python modules.
Greets,
Volker
--
Volker Grabsch
---<<(())>>---
\frac{\left|\vartheta_0\times\{\ell,\kappa\in\Re\}\right|}{\sqrt
[G]{-\Gamma(\alpha)\cdot\mathcal{B}^{\left[\oint\!c_\hbar\right]}}}
--
http://mail.python.org/mailman/listinfo/python-list
