Re: genesis design

Reinout van Rees wrote:
> Daniel Nouri wrote:
> 
>>
>> So what about reading the destination files?
> 
> 
> We'll just use the existing pyparser.py from archgenxml. That's the only
> part of archgenxml that is almost 100% unittested :-) It'll probably be
> the generator's responsibility to check if files already exist and mix
> 'em a bit.

So with pyparser.py we really have two kinds of readers: One for the UML
model and one for Python source code:

1) UML -> internal model
2) Python code -> ?

I would suggest to make the second kind of reader one that interprets
the code and creates an internal model as well.  I think it makes sense
for the internal model to be able to have real code attached.  I guess
it's rather usual with UML tool users to write code into the UML model
and have it be placed in the generated code.  (Although I consider it
bad practice, but that's not the point.)  So that would be two cases for
 which to have actual code attached in the internal model.

So we'd ideally have this:

2) Python code -> internal model (nodes have code attached)

Both internal models would be mixed together to become the model that's
handed to the generator.  I don't think it should be the generator's
responsibility to find out what needs to be preserverd.  This way the
generator would get all cluttered up with functionality.

How would this mixing together work I hear you ask.  We need some way to
find out if we want to keep e.g. a certain method of a class.  Currently
in ArchGenXML this works with marker comments (##code-section).  Our
Python code reader (what pyparser.py currently does) would flag parts of
the "internal model" depending on whether they're in the marked area or
not.  So that when we mix the two models together, we get a model of
what the user really wants to be in the resulting code.

So the model representations of both parsers get mixed together:

1) UML -> internal model1
2) Python code -> internal model2

3) internal model1 + internal model2 -> model to be handed to generator

Targets (like Python, Archetypes, I hear some say Java) might support
step 2) and 3) or not.  So certain targets cannot read from source code,
they can only generate.

Hypothetically, we could at some point have this transformation:

4) internal model -> UML

This is probably one of the most difficult parts, because we need to
preserve visual properties in the XMI, like the coordinates of the UML
elements.

However this would allow us to generate UML models from source code,
which would rock.

>>> There are some configuration possibilities to steer this process. Of
>>> course some commandline or config file parameters for setting some
>>> global options. More directly important are the profiles and the
>>> generator.
>>
>>
>> I think you guys intended to use the CA for configuration?  Which I
>> think makes a lot of sense.  Plug in your own profile or stereotype
>> handler or whatever and off you go.
> 
> 
> CA, what's that?
> Pluggable: yes, amen.
> 
>> So profiles are a way to add special behaviour based on tagged values
>> and stereotypes?
> 
> 
> Not 100%. It's important to see this as a two-step process. Stereotypes
> only *indicate* something. "This is not a normal class, this is a
> Membrane class". The internalmodel ends up giving this item a different
> interface.

I don't see how the internal model would know which interface to apply?
 Or are we talking about one interface IStereotyped that has a name
argument maybe?

> Step two, the behaviour, has to be handled by the
> generator/tranformations. If there's no adapter to handle the special
> interface, handling will just fall back to that of a normal class (for
> instance).

If there's no adapter, this should probably raise TypeError, because I
think this should be treated as an error, really.

>> Why do profiles live in both profiles and generator?  From what I
>> understand, profiles are only configuration and documentation, whereas
>> the implementation is in the generator?
> 
> 
> I'd like to keep the profile a bit separate from the implementation. The
> profile is only configuration and documentation, right. The generator
> doesn't even need to read the profile. It just has to have the right
> adapters for the interfaces.

Could you please explain what exactly the profile configures if the
generator doesn't even read it.

>>>  All those little things like an '__init__.py' file in every
>>>  directory are handled by creating it on every incoming
>>>  'IPackage'. The adapter itself can of course query the package for
>>>  contained items and calling an appropriate adapter that gives back
>>>  an import line.
>>
>>
>> Query package for contained items and create import lines?  Could you
>> eloborate on what those imports are for?  Are they inside the
>> __init__.py?
> 
> 
> Just something like this (lifted from a 2.0.5 product):
> 
> def initialize(context):
>     # imports packages and types for registration
>     import JoinIn
>     import JoinInFolder
>     import PressRelease
>     import Publication
>     import IllustrationMixin
>     import NewsItemFolder
> 
> 
>>>  The great thing here is that *if* you've got a certain class of item
>>>  in the package for which you don't want an import line *then* you
>>>  just need to provide an adapter for that interface that keeps quiet
>>>  when asked for an import line.
>>
>>
>> I think I get it.  Every class contained in a package gets imported in
>> the __init__.py until it explicitely says it doesn't want to?
> 
> 
> yes. Elegant way (adapters!) of handling corner cases and exceptions.

OK.  But the corner case is really when you *want* to have your modules
imported in __init__.py.  So those modules should be raising their
hands, not those that don't want to be included.

>>> Internal model -- It can store most basic UML-like items. Stereotypes
>>> get turned into implemented interfaces, ready for the generator to use.
>>
>>
>> OK, I think i know what internal model does.
> 
> 
> Jens had an idea of having just one very generic class for the internal
> model instead of the "current" UML-like set of classes. I thought it to
> be a bad idea, but perhaps it's not so bad after all. So it might change
> :-) Perhaps the internal model will only be a reasonably thin adapter
> for a suitable external UML model reader.

Well, my opinion is that the internal model should really represent OO
programs.  I don't see how being generic here is helpful when we only
want to work with UML and OO programming languages?  I think that the
internal model needs to be able to have information (like code) attached
that may only matter to certain kinds of generators.  E.g. I don't care
for privateness of a method in a Python generator.

> Daniel, were you looking at existing UML python parsers? If gaphor's
> model would be usable, that would be worth something to me. Python UML
> tool plus genesis :-)

That would rock!  I will check out gaphor...

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