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
|