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 Thu, 15 Feb 2007 23:40:46 GMT
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.
>>
>> When standard metadata is used properly we can do a
>> lot with industry 
>> standard tools.  (We can even send information
>> through wires. ;-) )
>> When documentation is precise enough it becomes
>> machine readable.  (Is a 
>> computer language, like Java just human readable
>> metadata,  or 
>> documentation? Its both.)
>>
>> Unfortunately  the EMF model editor does not do
>> enough visually to 
>> communicate the ideas behind the model.  (The
>> modeled ideas.)  But the 
>> graphics modeling framework GMF stuff does. (A
>> friend from TogetherJ 
>> told me about this stuff but I forgot.)
>>
>> Wouldn't it be nice to have one tool that does it
>> all?  With EMF and GMF 
>> I think we do.
>>
>> Look at this viewpoint of a Eclipse plugin (ie-OSGi
>> bundle) component 
>> environment. 
>> http://www.eclipse.org/gmf/gallery/pde.png
>>
>> It is a view of the component dependency matrix!
>>
>> That is THE documentation picture one needs to
>> present to application 
>> administrators.  Remember -> WTF? (ie - What is The
>> Function. ;-) ) It 
>> is made possible because all artifacts within the
>> dependency matrix are 
>> using standard containers.   OSGi Bundles, Jars,
>> Zips,Files, Bits.  The 
>> difference between each in this artifact container
>> hierarchy is 
>> metadata. I can do more with the higher level
>> artifact containers than I 
>> can with the lower ones because of it.
>>
>> I had a container conversation recently with someone
>> and I mentioned 
>> that most projects are using many different kinds of
>> containers. They 
>> are used so often the developers don't give them a
>> second thought.   
>> Even this email thread started out with the issue of
>> container (class) 
>> testing.  Interesting you also combined it with
>> container (aka artifact) 
>> design documentation as well. 
>>
>> Your interest in JPackage and APT/YUM for container
>> deployment and 
>> dependency matrix support is also an example. 
>>
>> If one adheres to standard containers, one can take
>> advantage of all the 
>> work being done on those containers.  It's the
>> network effect.
>>
>> Maven is a  managed container (repo) of containers.
>> The maven folks are 
>> now working to better leverage the new metadata now
>> available in OSGi 
>> bundles - not only for the automatic metadata
>> creation at package time 
>> but within the distribution repos as well.  One
>> track of research is 
>> OBR.  OBR is the equivalent to APT/YUM but for OSGi
>> bundles.  
>>
>>     
> http://cwiki.apache.org/FELIX/osgi-bundle-repository-obr.html
>   
>> Let's face it - the final destination for our
>> containers is another one 
>> - the JVM container.  But we need something in
>> between that though to 
>> handle the dependency matrix.  Two ways to approach
>> it - we either build 
>> it ourselves or use a standard container.
>>
>> Eclipse is moving into the enterprise.   Friendly
>> competition I think 
>> (With LDAPStudio ApacheDS is moving to the desktop).
>>
>>
>> Check out this guy's email thread (and the one that
>> follows it up one)  
>> I saw them today while looking through the links
>> that you sent.
>>
>> I think they really summarize the 'generic'
>> enterprise requirements 
>> fairly well. 
>>
>>     
> http://dev.eclipse.org/newslists/news.eclipse.technology.ecp/msg00089.html
>   
>> thanks for all the insights,
>>
>> warm regards,
>> John
>>
>>
>>
>>
>>     
>>> I see class diagram pictures in there that appear
>>>       
>> to
>>     
>>> be the diagram equivalent of the ecore
>>>       
>> editor...but
>>     
>>> have only skimmed...
>>>
>>>
>>>
>>> --- "John E. Conlon" <jconlon@verticon.com> wrote:
>>>
>>>   
>>>       
>>>> No graphics drawing tools with UML like symbols?
>>>>
>>>> Ole Ersoy wrote:
>>>>     
>>>>         
>>>>> Sorry...at the beginning it should say:
>>>>>
>>>>> If you open the .ecore model
>>>>> in a 
>>>>>
>>>>> TEXT/XML 
>>>>>
>>>>> editor you can strip out
>>>>> all the EClassifiers.
>>>>>
>>>>>
>>>>> --- Ole Ersoy <ole_ersoy@yahoo.com> wrote:
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>>>> John,
>>>>>>
>>>>>> If you open the .ecore model
>>>>>> in an editor you can strip out
>>>>>> all the EClassifiers.
>>>>>>
>>>>>> Then you are just left with an EPackage.
>>>>>>
>>>>>> This is what the New Ecore Model wizard will
>>>>>>             
> === message truncated ===
>
>
>
>  
> ____________________________________________________________________________________
> Be a PS3 game guru.
> Get your game face on with the latest PS3 news and previews at Yahoo! Games.
> http://videogames.yahoo.com/platform?platform=120121
>
>
>   


Mime
View raw message