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 Wed, 14 Feb 2007 19:34:05 GMT
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).

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.

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.

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.

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.

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".  :-)

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