directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: Class + Class Helper Pattern
Date Fri, 16 Feb 2007 02:21:51 GMT
Ole Ersoy wrote:
> -----------------------------------------------------
> As far as content,  I type in XML (is there a schema?)
> and it 
> transforms 
> to XHTML with CSS?
> -----------------------------------------------------
>
> Yes - There is a schema.  And that schema is used to
> generate an ecore model.  
>
> The ecore model generates an editor.
>
> So you could just use the editor to write the
> documentation.
>
> Or type it in as XML straight up.
>
> So a maven archetype is used to create a project
> with a sample xml file.
>
> Just edit that file.  And then run the mojo and it
> will
> generate the documentation plugin, with the css,
> eclipse specific files, etc.
>
> Almost done - Hang in there!  :-)
>
>
> -----------------------------------------------------
>   
>> Can you help me with this one question:  Is this a
>> stupid idea? (If true 
>> -> I will proceed to the beer camp to immediately
>> prune contaminated 
>> brain cells.)
>>     
>>> Could be more friendly in terms of describing what
>>> each StructuralFeature on each ecore element is
>>>       
>> for...
>>     
> -----------------------------------------------------
>
> Proceed to Beer Camp!  It's a great idea, but Beer
> Camp goodddd :-)
>
> I think it would help a lot if you wrote a little
> guide on what to look for in terms of coupling.
>
> I'm sure there are some general "Anti Patterns" to
> look for.
>
> If I were to use a "Challenge" "Solution" cookbook for
> it, I would list a whole bunch of "Coupling"
> challenges that could be made more elegant according
> to some pattern (These may or may not exist in the
> code base), and then show how the Graph Tool helps
> illuminate how to go about refactoring.  This would be
> good for illustrating how to avoid these in the future
> too.
>
> When I write the test guide, I'm going to recommend
> the Class + Class Helper pattern.
>
> That way all classes either depend on their helper, or
> a Utility Library.
>
> There will be a corresponding test generator pattern /
> pattern for writing the tests.
>
> If this pattern were used throughout, it would make
> "Anti-Pattern" coupling non-existant I would think.
>
> Could be that there are other patterns that would suit
> the particular sub project even better though.  The
> Class + Class Helper pattern is just an example,
> although it does make automatic test generation that
> covers all methods possible.
>
> Personally I prefer writing a little "Challenge" and
> then coding something that takes care of it.
>
> OH - There's this EMF article on how to use GEF and
> EMF to automatically generate a database schema
> diagram.
>
> http://www.eclipse.org/articles/Article-GEF-editor/gef-schema-editor.html
>
> If you run the sample you'll see it does the layout
> for you automatically.
>
> Something like this would be cool for first drawing a
> package diagram showing the coupling between the
> packages, and then letting developers drill in to
> evaluate the couplings.
>
> You'll probably like this page:
>
> http://wiki.eclipse.org/index.php/GEF_Articles
>
> One of the articles shows you how to create a UML
> diagram with GEF.
>
> http://www.eclipse.org/articles/Article-GEF-Draw2d/GEF-Draw2d.html
>
> Incidentally - In XML Schema Annotations are used to
> document the Schema.
>
> If you generate an Ecore model from the Maven XML
> Schema, which is documented using annotations, you'll
> see how they translate into documentation on Ecore.
>
> Then you know how to document ecore models.
>
> Now you can could generate a diagram like the one
> shown in the UML draw2d tutorial, to make the
> documentation more elegant.  HTML UML diagram would be
> straight forward too, and if the dynamic layout
> algorithm were implemented with some dojo toolkit fx
> code, it would make a very sexy documentation plugin
> addition.
>
> Make sure non of these makes you loose focus on the
> Beer Though :-)
>   
I'm afraid the beer has made me loose on these...
(will comment later)
John
> Cheer
> - Ole
>
>
>   

>
>
>
>
> --- "John E. Conlon" <jconlon@verticon.com> wrote:
>
>   
>> Ole Ersoy wrote:
>>     
>>> John,
>>>
>>> I think you are my type of dud :-)
>>>
>>> You know that last eclipse newsgroup post in your
>>> mail?
>>>
>>>
>>>       
> http://dev.eclipse.org/newslists/news.eclipse.technology.ecp/msg00089.html
>   
>>> This is the type of platform I'm targeting.
>>>
>>> Except for Tuscany DAS's (Pure ones hopefully,
>>> independent of Hibernate, although Hibernate is
>>>       
>> really
>>     
>>> good).
>>>   
>>>       
>> When When When ???
>>     
>>> Did you notice how they talked about JSF?  I wrote
>>>       
>> a
>>     
>>> client side JS Framework on Top of Dojo Toolkit
>>>       
>> (And
>>     
>>> donated it to myfacers), so that Server Side and
>>> Client Side can be very much decoupled and only
>>>       
>> pass
>>     
>>> JSON strings back and forth.
>>>
>>> Check it:
>>>
>>>       
> http://people.apache.org/~matzew/dojo.presentation.zip
>   
> http://www.mail-archive.com/dev@myfaces.apache.org/msg18916.html
>   
>>> This way the client side Javascript components and
>>>       
>> the
>>     
>>> server side components can be generated and will
>>> mirror eachother.
>>>   
>>>       
>> Yep saw that.  Must admit that I am not a javascript
>> guy, but it 
>> provides the functionality needed now.  I'm betting
>> on XForms and XQuery 
>> to pull out in the stretch.
>>     
>>> OH - Documentation generation:
>>>
>>> If you had a chance to look at the Contributor
>>>       
>> Guide
>>     
>>> eclipse plugin you'll see there's a lot of
>>>       
>> symmetry
>>     
>>> between the recipes and the checklists.
>>>   
>>>       
>> It's loaded and I have looked at it.  Nice
>> documentation vehicle.
>>     
>>> Right now I'm writing a Maven plugin to generate
>>>       
>> the
>>     
>>> whole guide...driving it off of a checklist.xml
>>> document.  This way it requires minimal
>>>       
>> maintenance
>>     
>>> and it's just a matter of adding more content, and
>>> everyhting else is generated.
>>>   
>>>       
>> As far as content,  I type in XML (is there a
>> schema?) and it transforms 
>> to XHTML with CSS?
>>     
>>> Eclipse Infocenter TOC's can then be used to
>>>       
>> stitch
>>     
>>> together many non-primary TOC's to form a whole
>>>       
>> book.
>>     
>>> I'm hoping to have the plugin done by the end of
>>> today.  Then it can be a starting point for
>>> documentation and code generation at the same
>>>       
>> time.
>>     
>>> The Ecore Model Editor is pretty good once you get
>>> used to it though.  It's strictly for the model
>>>       
>> part
>>     
>>> of a 
>>> Presentation - Application - Business -
>>>       
>> Integration -
>>     
>>> Persistance Layered architecture.
>>>   
>>>       
>> I think so too - to build the models once one if
>> familiar with it they 
>> would just do it by hand with the editor.  I just
>> wanted the Graphics 
>> for documenting the model with a standard UML look
>> and feel. 
>>
>> Which reminds me of something else, (knowing your a
>> man of many 
>> languages and are fond of documentation - and
>> 'automation maniac'. :-)
>>
>> I have recently experimented with a tool called
>> Guess.
>> http://graphexploration.cond.org/
>>
>>
>> When I worked for what is now called Nortel Networks
>> I managed a team of 
>> programmer consultants that used tools like Guess
>> (Those tools were not 
>> free then and had less functionality than Guess.) to
>> map large ISP 
>> networks.  I am now interested in turning a tool
>> like this inward to 
>> give us a way to display and potentially explore
>> coupling problems 
>> between ADS subprojects. 
>>
>> Can you help me with this one question:  Is this a
>> stupid idea? (If true 
>> -> I will proceed to the beer camp to immediately
>> prune contaminated 
>> brain cells.)
>>     
>>> Could be more friendly in terms of describing what
>>> each StructuralFeature on each ecore element is
>>>       
>> for...
>>     
>>> For the most part though - I think my favorite
>>>       
>> camp is
>>     
>>> "The Beer Camp".  :-)
>>>   
>>>       
>> Has to be German beer though,
>>
>> John
>>     
>>> Cheers,
>>> - Ole
>>>
>>>
>>> --- "John E. Conlon" <jconlon@verticon.com> wrote:
>>>
>>>   
>>>       
>>>> Ole Ersoy wrote:
>>>>     
>>>>         
>>>>> I think this may have some:
>>>>>
>>>>> http://www.andromda.org/
>>>>>
>>>>> >From the description it's my wet dream in
>>>>>       
>>>>>           
>>>> cyberspace.
>>>>     
>>>>         
>>>>> I started drooling uncontrollably when I saw it.
>>>>>
>>>>> Then there's this:
>>>>>
>>>>>       
>>>>>           
> http://amateras.sourceforge.jp/cgi-bin/fswiki_en/wiki.cgi?page=AmaterasUML
>   
>>>   
>>>       
>>>>> I've only skimmed though...
>>>>>
>>>>> And this:
>>>>>
>>>>>
>>>>>       
>>>>>           
> http://wiki.eclipse.org/index.php/GMF_New_and_Noteworthy
>   
>>>   
>>>       
>>>>>   
>>>>>       
>>>>>           
>>>> Bingo GMF!
>>>> http://www.eclipse.org/gmf/gallery/index.php
>>>>
>>>> Okay here is the process:
>>>> Service Requirements -> Design -> Artifact
>>>> (component) creation-> 
>>>> Warehousing (Repos) -> Deployment -> Component
>>>> dependency matrix 
>>>> ->Execution -> Service fulfillment!
>>>>
>>>> The big problem is documentation.  It is needed
>>>> throughout the chain.  
>>>> Needed to always answer the archetypical question
>>>>         
>> -
>>     
>>>> WTF? 
>>>>
>>>> But when is doco created? Before or after the
>>>> artifact is built, stored, 
>>>> deployed or run?   We need it up front and
>>>>         
>> through
>>     
>>>> out the lifecycle and 
>>>> it can't get stale.  Artifact with out docs is no
>>>> good, can't be 
>>>> maintained.  Doc without artifact, what's the
>>>>         
>> point?
>>     
>>>>  One school of 
>>>> thought is to do the documentation then the code,
>>>> second school says the 
>>>> code then the documentation, third school says
>>>> generate docs from code, 
>>>> and forth says generate code from docs.  (Fifth
>>>> school drinks beer.)
>>>>
>>>> Fun times!  The third and the forth camps are
>>>> converging, and the gap is 
>>>> closer (touching?) now than ever.
>>>>
>>>>         
> === message truncated ===
>
>
>
>  
> ____________________________________________________________________________________
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com
>
>
>   


Mime
View raw message