Re: agx: Moving forward

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.  And then its raving use of newlines.  Or that it creates
docstrings for every of your methods, even if there's no documentation
yet, which clutters up the 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.

> I agree that there are no decent UML editors. Hopes are pinned on
> umbrello  and gaphor, I believe. :)
> 

>> On the Snowsprint I also realized that agx really is a terrible name.
>> Not just because of reasons mentioned before on this list but also
>> because it conflicts with "Ajax" when it's spoken out.  Or was that just
>> the way it was mispronounced? :-)  Anyway, let's move to 'genesis',
>> which I remember most people agreed to.
> 
> 
> Yes. I was quite disappointed the last time this came up. ArchGenXML is
> an  awful name, and AGX is an even more awful name. Having it be called 
> 'codename genesis' is just chickening out of making a decision. I think
> a  few people muttered something about religion, but in all honesty,
> it's a  generic word, and it's a good name, certainly unique in the
> zope/python  space as far as I know.
> 
> 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. :-)

>> 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.

>> It would also be nice to get support from you people, either by
>> contribution (that is, in the Right Way), or by sponsorship.  I
>> personally don't have the "immediate" need for agx, I only think that
>> it's an interesting project that deserves more attention, and I'd like
>> to fix that. :-)
> 
> 
> I agree. ArchGenXML (which I'd have abbreviated to AGX normally, but
> you  know, it's now doubly confusing... ARGH again) is usually the first
> thing  I show people about Plone. It's *the* thing that gets them to
> think Plone  isn't a technological black box, but something they can
> actually get value  out of without reading a book or two. It's really
> important. REALLY  important.
> 
> If we can bring that kind of benefit to a Zope 3 schemas-based world,
> that  will benefit not only Plone, but Zope 3 and other systems.
> 
>> There's a good chance that we get many people to contribute.  For that
>> ball to get rolling though, agx needs to get in better shape, so that we
>> can show it around.
> 
> 
> Agreed.
> 
> Two points I'd like to add:
> 
>  - Change the name. No, seriously - change it. :-)
> 
>  - 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.

Daniel



-------------------------------------------------------
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