directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole_er...@yahoo.com>
Subject Re: Class + Class Helper Pattern
Date Fri, 16 Feb 2007 02:05:07 GMT
-----------------------------------------------------
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 :-)

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