Re: agx: Moving forward

On Mon, 06 Feb 2006 02:01:34 -0000, Daniel Nouri  
<[email protected]> wrote:

> Martin Aspeli wrote:
>> On Mon, 06 Feb 2006 00:40:35 -0000, Daniel Nouri
>> <[email protected]> wrote:
>>
>>> I dislike working with ArchGenXML.  Partially because of the code it
>>> generates (which hardly obeys PEP 8), and the poor maintainability of
>>> the program itself that originates from its monolithic model.  Another
>>> reason is that I don't like working with Java applications for creating
>>> my model, but I can live with that.
>>
>>
>> Can you be a bit more specific what's ugly about the code it generates?
>> I  believe that in the later versions, the code is fairly good.
>
> One thing that scares me is that with ArchGenXML every class has its own
> module.

This is fairly common practice with Archetypes anyway. In fact, nearly  
every project I've seen has its own .py file for each class. I suppose if  
you have a lot of mixin-classes etc. that may not be optimal, but for most  
content type scenarios, this tends to make it easier to browse the code in  
my experience.

>  And then its raving use of newlines.

mmmm.... I'm normally quite picky about whitespace, and deo is normally  
the worst. Deo has made a few fixes lately, and I made some earlier. It  
doesn't offend me so much any more.

> Or that it creates
> docstrings for every of your methods, even if there's no documentation
> yet, which clutters up the code.

I think this is great. You should be filling in those docstrings. I have  
nightmares about the kind of third party products that don't make proper  
use of docstrings.

If they're there and look ugly to you, go fill them in. AGX will leave the  
comments alone if you modify them in code.

> Some problems I have with ArchGenXML
> generated code arguably originate in how people use it.  This file of
> the agx (soon-to-be 'genesis') project itself is a good example of some
> of the problems mentioned:
>
> http://svn.plone.org/svn/collective/agx/trunk/transformations/python/pyattributeadapter.py
>
> Files like this don't really help.

Well sure, but it's obviously a file that isn't finished. How can you  
judge a CASE tool by people leaving unfinished files around?

The two things that annoy me the most the with the code AGX generates are:

  - Excessive use of comments. Having the full GPL header at the top of  
every file is pointless (it's not a legal requirement). I know you can  
override this, but I'd like it not to be the default.

  - A few of those ugly getattr() things, but then again I don't know any  
way around that without putting a lot more burden on the user knowing what  
to inherit schemata, interfaces etc. from.


>> I'd drop any and all reference to Arch or XML in the title if at all
>> possible. Stupid names have been known to hold back good ideas before.  
>> :)
>
> I think we already agreed on this.  I put the renaming of agx to genesis
>  to the top of my TODO list. :-)

Last I heard, the "compromise" was to call it "AGX Codename Gensis", which  
I think achieves exactly the opposite of reducing confusion. :)

>>> I have some thoughts about concrete parts of current agx I want to
>>> repair, some of which I already mentioned.  Since noone is using agx
>>> yet, I don't think anyone will be hurt by my changes on trunk.  I will
>>> try to document my decisions, so that people can share their opinion.
>>
>>
>> agx? You mean "AGX Codename Gensis" ARGH!
>
> With agx I mean the soon-to-be genesis.

Why not just start calling it Genesis right now, then? If Jensens, Phil,  
Reinout et. al. agree?

>>  - There are several XMI parsers listed on sourceforge, I believe even
>> one  or two python ones. We should be using these if possible, not roll
>> our  own. Do we really want to maintain something ourselves? Is this fun
>> code  to write? Do we need the flexibility of our own *parser*? I'm
>> guessing no  on all three counts.
>
> I'd definitely rather take existing (reliable) libraries than roll our
> own thing.  I'll take a look at existing XMI parsers.
>
> One thing I'm wondering is where Skeletor might actually fit in.  I have
> looked at Skeletor only briefly, so I wonder if anyone could explain to
> me in a few words how adaptable (*buzz*) Skeletor is and where we could
> plug it in.

+1 for investigating these things properly before going off to write more  
code :-)

Martin

-- 
(muted)



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642