Re: genesis design

(I'm CCing this to Jim: This is about the successor of ArchGenXML[1].
Are you aware of/interested in this discussion?)

Reinout van Rees wrote:
> Daniel Nouri wrote:
> 
>> 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.
> 
> 
> The current (archgenxml) approach is that the output generator just
> queries for the existence of methods in the parsed files. And for some
> protected sections.
> 
> It only makes sense to put the parsed code into the internal model if we
> don't want the output model to be able to make a choice about inclusion.
> I don't know yet.

Does it matter if it's the generator ("output model"?) or the parser
that decides whether something goes in?  The code generating component
should probably be agnostic of the decision.  It should only be able to
write the UML representation (internal model) to actual code.

>> 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).
> 
> 
> Methods are always preserved if available. Because that's where most of
> the action is. Marker comments are for inserting an extra import
> statement in the header and so.
> 
>> 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.
> 
> 
> And which would be bloody hard. But I agree that you've at least got a
> fighting chance with genesis' architecture ;-)

Granted that it would be hard, given that there's lots of magic involved
when using UML tagged values in current ArchGenXML.  "source code ->
internal model" is not feasible for Archetypes generated code as we have
it.  But for Zope 3 code it would be comparatively easy, using Python's
own introspection and third party libraries (see Gaphor's plugins).
This would require us to restrain TGV magic for Zope 3 code generation.

>>> 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?
> 
> 
> That part of the code is actually implemented and working :-)

My point was that the internal model should be agnostic of marker
interfaces.  I suppose you mean the reader (parser) assigns these?

>>> 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.
> 
> 
> No. That goes against the adaptor architecture. Say you've used a
> stereotype to get special handling in one part of the generation step.
> That does not mean that you don't want to use more generic adapters in
> other parts of the generation process. That's the great strength of the
> approach, imho.

This is going into the details.  I probably misunderstood you, but
handling should fall back to that of a "normal class" because there's a
generic adapter that handles that.

>> Could you please explain what exactly the profile configures if the
>> generator doesn't even read it.
> 
> 
> The profiles make sure the internal model spits out
> INouriSpecialClass-marked classes when desired. The generator doesn't
> care how that class got that marker interface, it just looks up the best
> possible adapter for it.
> 
> Loose coupling!

Ah, the profile is read and applied by the parser, then.  I was asking
myself where the profile would play in.  The idea of seperating concerns
here is definitely good.

>>> 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.
> 
> 
> It sounds too big to me. The internal model is just a tiny layer between
> what gets put into it and the transformation/generation step that pulls
> stuff out. It's the pluggable component architecture adapter magic
> that'll have to pull the most weight here. The internal model should
> remain thin. (Hey, Jens wanted a one-class internal model - which might
> be a good idea after all).

"Pluggable component architecture adapter magic" sure sounds scary :-)

I'd suggest we use a UML representation for the "internal model", but
Jens, tell me -- how would your one-class internal model work?  This
sounds like you're coupling parser and generator after all.


Another thing I note is the sentiment among current genesis developers
(Jens, Phil, Reinout?) that "we already thought about it" during the
Castle Sprint 2005.  The design is considered done, and that's what
scares me away a bit, because I can't see into people's heads.  I hope
that next month's sprint[2] in Innsbruck will clarify this.

By the way, have you guys thought about inviting Jim to the sprint?


Daniel

[1] http://dev.plone.org/collective/browser/genesis/trunk/
[2] http://plone.org/events/sprints/goldenroof/



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