agx: Moving forward

Daniel Nouri <[email protected]>
Newsgroups gmane.comp.web.zope.plone.archetypes.devel
Message-ID <[email protected]>
Hello!

On the Snowsprint I realized that there's lots of interest in the
project that aims to rewrite ArchGenXML, namely agx.  I thought I'd take
a look to find out what the current state of agx is.

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.
:-) And I think that if you can't explain your software project in
written form, there's probably a problem with your design.  If for any
other reason you don't write the design of your project down, you'll get
into trouble sooner than later.  (Binary files don't count.)

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.  I think that
documentation in the form of README.txt or doctests in general might
also help with detecting design issues.

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

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.

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.

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.

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

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.

Daniel



[1] http://svn.plone.org/svn/collective/agx/trunk/



-------------------------------------------------------
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.