Re: agx: Moving forward

Daniel Nouri wrote:
> 

Hi Daniel!

> After having checked out the trunk [1], I looked into the docs/
> directory to see that there was only one lonesome 'general-design.zuml'
> file there.  I like documentation in the form of written text very much.

There are a number of doctests around, don't fear. They're not in the 
doc/ directory, but in the individual directories. 
internalmodel/internalmodel.txt and so.

Most important is getting at least *some* sort of generation done. With 
a dummy model and with just one generated class. So that we have a basis 
to improve upon. I'm trying to get it done while traveling by train 
(train driven development), but it's slow going.

> I think that we really need to document our concepts before we move on.
> So that people that haven't yet been involved in the project (like I)
> get a chance of getting the picture more easily.

Making it easy to get the picture is important. I've got it partly in my 
head, but haven't written it down yet. There's something in a wiki 
buried deep on zope.org. Point accepted, I'll try and work on a good 
document this week.

> I see that some of the python code that is in agx has been written with
> the help of ArchGenXML.  I believe that this is a *very* bad idea.  I
> cannot see how this helps us in learning from ArchGenXML's mistakes, of
> which "my .zuml is enough in terms of documentation" is one.

I think it is a very good idea. What good is a code generation tool if 
it can't even generate it's own code?

Now, I don't generate it with current trunk archgenxml. I made a branch 
during the castle sprint and hamfistedly hacked some files to generate 
zope3 interfaces and so on. I'm gonna drink an entire bottle of wine the 
moment I can let genesis take over!

I'm the only one coding on it since the castle sprint and did it all 
with archgenxml generation. Sometimes it is a bit painful, as archgenxml 
isn't aimed at generating plain python code -- which I'm doing. So it is 
just as much a learning experience!

> There's also a lot of good ideas in agx.  And lots of potential.
> Because the idea is appealing to not only the Plone community but the
> whole of the Zope community.  And if we do it right, agx will grow
> beyond just Plone and Zope.

Agreed.

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

You might have noticed that I used "genesis" above :-)

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

Coordinate a bit with me, please, as I'm working on it about twice a 
week in the train back home. And don't overwrite the 
archgenxml-generated parts. If you use the 
https://svn.plone.org/svn/collective/agx/bundles/goldegg bundle, you 
also get the hacked-up archgenxml.

Note that only a few files (notably internalmodel/*.py) get generated, 
so many parts are safe for coding without archgenxml. I have no problem 
at all with keeping certain parts archgenxml-free :-D

Reinout

-- 
Reinout van Rees                       r.van.rees @ zestsoftware.nl
http://vanrees.org/weblog/                  http://zestsoftware.nl/
"Military engineers build missiles. Civil engineers build targets."



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