Re: agx: Moving forward

Hi Reinout.

Reinout van Rees wrote:
> 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.

Let's rename all doctests that document a package to README.txt, which
is the convention for Zope 3.  I have overseen the intermodel.txt
doctests.  It looks pretty good, but then targets/python/target.txt is
very minimal, and it seems like it doesn't get the model right:

> To the first class we add three methods. The first one with arguments
> and keyword arguments.
> 
> 	>>> cm1 = target.ClassMethod(name='myMethod1',
> 	...               	       args=['arg1'],
> 	...                    	   kwargs = { 'kw1' : 'default',
> 	...                           		 'kw2' : None })  
> 	>>> c1.add(cm1)
> 
> The second one a simple without any arguments.
> 
> 	>>> cm2 = target.ClassMethod(name='myMethod2')
> 	>>> c1.add(cm2)

Looking at this, ClassMethod seems not really to be what we want.  Plus,
the API looks kinda tedious and the doctest itself is generally in a
poor shape.  We need to doctest (i.e., unittest) every single function
in the whole "Genesis".  Wake up lazy ArchGenXML programmers! ;-)

This is really just an example to help you understand what I dislike
about the current state the Genesis code is in.  50% of it is basically
garbage.  Why bring us to a state where we have to first clean up the
mess before we can get going?  I don't like this approach, and it kinda
feels like developing with ArchGenXML in general.  First you generate
all that mess, then you fix it, then you program what you actually want.

> 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 like the idea of having a prototype.  But getting something done
shouldn't be the driving force.  This smells too much like the approach
we had with ArchGenXML, i.e.  "get it done quickly".  If we don't land
proper interfaces and a proper architecture now, we'll have lots of work
more in the end.

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

See above.  I have a feeling that we want to discuss the architecture
(even if it's only to make it clear to everyone) and come up sane
interfaces and tests.  That's totally essential, IMO.

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

I'm not into code generation philosophy really. :-P

> 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'd be happy to drink that bottle with you, if you don't mind.  But in
the meantime, let's rip ArchGenXML use out of Genesis.  It doesn't fit,
it's really a tool for making Content Types for Archetypes, and believe
me- writing that code isn't really that much more work than having it
generated.

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

You end up spending your time fixing ArchGenXML, when all you want is to
create a program that does it right.  Why carry on with the burden of
extending the old ArchGenXML just so it fits our (ArchGenXML- wise)
unusual kind of code?

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

Arrgh.  A hacked up ArchGenXML just so I can work with Genesis.  Is that
really worth it?

> 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

I want all of them free :-D  Freedom to Genesis!!

I have some points that I still have to write down.  Eventually, after
you wrote your summary about what we have right now, I'd like to create
a new thread that discusses in detail the architectural stuff, and maybe
we can get some of the Zope3 devs involved as well.



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