cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sven Beauprez" <sven.beaup...@xume.be>
Subject RE: [RT] Managing Flow and Resources
Date Thu, 13 Dec 2001 07:25:40 GMT

There exists a free UML tool: argoUML (http://argouml.tigris.org/), extended by a commercial

version, called poseidonUML (http://www.gentleware.com/).

ArgoUML uses a very nice graph editing library, called GEF (http://gef.tigris.org/). I think
if 
you to build a flow editor, it wouldn't be a watse of time to check this out...

Here is way they say on their website:

The goal of the GEF project is to build a graph editing library that can be used to 
construct many, high-quality graph editing appications. Some of GEF's features are: 
*   A simple, concrete design that makes the framework easy to understand and 
    extend. 
*   Node-Port-Edge graph model that is powerful enough for the vast majority of 
    connectied graph applications. 
*   Model-View-Controller design based on the Swing Java UI library makes 
    GEF able to act as a UI to existing data structures, and also minimizing 
    learning time for developers familiar with Swing. 
*   High-quality user interactions for moving, resizeing, reshaping, etc. GEF also 
    supports several novel interactions such as the broom alignment tool and 
    secltion-action-buttons. 
*   Generic properties sheet based on JavaBeans introspection. 
*   XML-based file formats based on the PGML standard (soon to support SVG). 



I think if you want to write an editor, the easiest way would be to use GEF

On 12 Dec 2001 at 11:00, Tom Klaasen (TeleRelay) wrote:

> > -----Original Message-----
> > From: Steven Noels [mailto:stevenn@outerthought.org] 
> > Sent: woensdag 12 december 2001 9:45
> > To: cocoon-dev@xml.apache.org
> > Subject: RE: [RT] Managing Flow and Resources 
> >
> > > -----Original Message-----
> > > From: Tom Klaasen (TeleRelay) [mailto:tr-tklaasen@telerelay.com]
> > > Sent: dinsdag 11 december 2001 10:08
> > > To: cocoon-dev@xml.apache.org
> > > Subject: RE: [RT] Managing Flow and Resources
> > 
> > What an amusing gathering of ex-collaegues :-)
> > 
> > > However, XML allows you to enforce some limitations on the 
> > users. Java
> > > does not. As you can already see in the example above IMHO, 
> > it gets very
> > > difficult to cling to and enforce the SOC principle. The 
> > shopping-cart()
> > > function seems to be flow control, but the change-address() 
> > is already
> > > business logic IMO.
> > 
> > True, if and when there's some XML Schema or Schematron 
> > validation in-place.
> > Nothing which couldn't be done by an Scheme interpreter, I guess ;-)
> 
> Let's add some more languages to Cocoon, so that nobody knows all
> languages anymore, and developing on Cocoon _requires_ teams of 3 or 4
> people. And let's then try to roll Cocoon in into a company. 
> Not that I have something against Scheme in itself. But that was another
> thread, I thought.
> 
> > Semantical validation isn't something which is supported very 
> > well in XML,
> > Schematron being a (difficult) exception.
> > 
> > > Of course, the very intelligent programmers who are 
> > developing this from
> > > the start, will be able to enforce the SOC for themselves, 
> > but newcomers
> > > who learn by trial-and-error (as we all do) will have serious
> > > difficulties to grasp it, even if they want to. Me too (is this
> > > English?) had serious difficulties to grasp the SOC in 
> > Struts eg, and I
> > > even thought there wasn't one for quite a while. But then 
> > again, maybe
> > > that says more about my capabilities than anything ;-) 
> > Anyway, Struts is
> > > also based mainly on java-code, and genericity and SOC is 
> > very hard to
> > > achieve.
> > 
> > I agree with Tom that SoC enforcement should be done 
> > programmatically and not
> > by documenting best practices or hoping that developers will stick to
> > guidelines.
> 
> Nice summary.
>  
> > > If you're into Cocoon, you don't like GUI development (except maybe
> > > Bruno Dumon ;-)). It is a whole different world. So the 
> > chances are slim
> > > there will stand up anybody to make a GUI.
> > 
> > If we want to force flowmap-designers to stay away from the 
> > SoC-alarmzone, a
> > visual tool that generates Soc-compliant code is much better 
> > than the ultimate
> > freedom of a textfile with ECMAScript, Scheme or XML 
> > markup... using such a
> > GUI would force you to design the flow and gives you little 
> > opportunity to
> > mess with the syntax of the flowmap
> 
> I agree that having a decent GUI would facilitate things a lot. But I'm
> only suspicious as who is going to develop such a GUI. I've seen things
> happening on ant-dev eg, where they were going to develop a GUI, and it
> didn't go smooth to say the least.
>  
> > thinking about it... what about UML...? considering a flowmap 
> > to be something
> > like an activity diagram?
> 
> State diagrams should do the trick. This reminds me of the proposal of
> Diana (was it?) some weeks ago. She was working on a flowmap-like thing,
> and had it almost right imho, but was struggling with the syntax. I was
> hoping to hear more of her, but she seems to have disappeared?
> Anyway, UML: still have to find a decent 'free' UML tool. Nobody's going
> to use C2 if they have to pay $$$ for Rose or TogetherJ, just to be able
> to draw state diagrams. Not a very academic approach to the problem
> though ;)
> 
> > 
> > Regards,
> > 
> > Steven Noels
> > http://outerthought.org/
> > (+32)478 292900
> > 
> > ps: (Tom) this flowmap-approach reminds me of the idea of sticking a
> > rules-based engine inside Maven as a central switching board
> 
> Me not, to be honest :P I saw the switching board was more like the
> sitemap... but that's stuff for a private conversation, since our
> ex-collagues have already taken out too much dirty laundry ;)
> 
> tomK
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message