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:[EMAIL PROTECTED]] > > Sent: woensdag 12 december 2001 9:45 > > To: [EMAIL PROTECTED] > > Subject: RE: [RT] Managing Flow and Resources > > > > > -----Original Message----- > > > From: Tom Klaasen (TeleRelay) [mailto:[EMAIL PROTECTED]] > > > Sent: dinsdag 11 december 2001 10:08 > > > To: [EMAIL PROTECTED] > > > 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: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
