You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2003/07/30 18:48:54 UTC
Cool (work)flow GUI editor
http://blog.xesoft.com/jon.lipsky/blog/Java/?permalink=workflow_viewlets.html
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Cool (work)flow GUI editor
Posted by Vadim Gritsenko <va...@verizon.net>.
Nicola Ken Barozzi wrote:
> http://blog.xesoft.com/jon.lipsky/blog/Java/?permalink=workflow_viewlets.html
>
Have you seen one from the BEA's Workshop (8.1)? They've got workflow
editor and pageflow (struts app) gui editor.
Vadim
Re: Cool (work)flow GUI editor
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Stefano Mazzocchi dijo:
> why? visual programming is bullshit.
>
> It take half an hour to write a visual representation of something like
>
> if (blah) {
> dothis();
> } else {
> dothat();
> }
>
> Try.
I totally agree. I can add: MS Visual programming is ...(what yoou said :)
But, there are some nice tools as VisualAge C++ from IBM. It was very easy
and fast because it was OO oriented. I used it in 1995. Also in 1993-94 I
used a CASE system from a company called Westmount that was also very
fast. It was Relational oriented, in the age when OOA and OOD was a "weird
thing" for most of the people.
Best Regards,
Antonio Gallardo.
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Posted by Geoff Howard <co...@leverageweb.com>.
Steven Noels wrote:
>
> Kidding aside, is my categorization more or less correct? Might be cool
> to put on a slide once.
>
I can't speak to accuracy but a page in the docs explaining these
viewpoints could really help users make sense of docs and demos that
seem to point in different directions.
The two biggest design differences I notice are the transformer-centric
vs. generator-centric. Clearly this is not an either/or choice. But
explaining the difference between all these choices in an overview would
be really helpful.
Geoff
RE: Cocoon Schools of Development [was: Re: Cool (work)flowGUIeditor]
Posted by Reinhard Pötz <re...@gmx.net>.
From: Bruno Dumon
>
> On Fri, 2003-08-01 at 11:15, Reinhard Pötz wrote:
> > > For the actual code see
> > > http://nagoya.apache.org/bugzilla/show_> bug.cgi?id=21900
> >
> > Marc, why don't you put Apples it into scratchpad?
>
> >From the practical side of things: is there much difference between
> scratchpad and an unstable block? The current patch Marc
> prepared is set up as a block. Among other things, this makes
> it easy to add things to cocoon.xconf as part of the build (I
> don't think scratchpad supports that?).
A block is fine too - I just wondered why Marc hasn't checked it in into
the CVS. In the meantime Steven told me that Marc didn't had the karma
to do it.
Reinhard
RE: Cocoon Schools of Development [was: Re: Cool (work)flow
GUIeditor]
Posted by Bruno Dumon <br...@outerthought.org>.
On Fri, 2003-08-01 at 11:15, Reinhard Pötz wrote:
> > For the actual code see
> > http://nagoya.apache.org/bugzilla/show_> bug.cgi?id=21900
>
> Marc, why don't you put Apples it into scratchpad?
>>From the practical side of things: is there much difference between
scratchpad and an unstable block? The current patch Marc prepared is set
up as a block. Among other things, this makes it easy to add things to
cocoon.xconf as part of the build (I don't think scratchpad supports
that?).
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
RE: Cocoon Schools of Development [was: Re: Cool (work)flow GUIeditor]
Posted by Reinhard Pötz <re...@gmx.net>.
From: Steven Noels
> On 1/08/2003 11:15 Reinhard Pötz wrote:
> >
> >>For the actual code see
> >>http://nagoya.apache.org/bugzilla/show_> bug.cgi?id=21900
> >
> >
> > Marc, why don't you put Apples it into scratchpad?
>
> Karma request is in process, he isn't listed in the avail file yet.
Ah, thanks! I thought that those things have already happend.
Reinhard
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUIeditor]
Posted by Steven Noels <st...@outerthought.org>.
On 1/08/2003 11:15 Reinhard Pötz wrote:
>
>>For the actual code see
>>http://nagoya.apache.org/bugzilla/show_> bug.cgi?id=21900
>
>
> Marc, why don't you put Apples it into scratchpad?
Karma request is in process, he isn't listed in the avail file yet.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
RE: Cocoon Schools of Development [was: Re: Cool (work)flow GUIeditor]
Posted by Reinhard Pötz <re...@gmx.net>.
> For the actual code see
> http://nagoya.apache.org/bugzilla/show_> bug.cgi?id=21900
Marc, why don't you put Apples it into scratchpad?
Cheers,
Reinhard
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUI
editor]
Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2003-07-31 at 15:30, Antonio Gallardo wrote:
<snip/>
>
> Seriously, where I can find more about "Apples" and "Dywel"? It is being
> be part of Cocoon?
Apples is Marc's try at creating an implementation of the "generalized
flow" ideas he's been spreading the last couple of weeks.
Basically it is the same as flowscript, but your flows are written in
Java and lack continuations. So you have to implement your own logic for
figuring out the current state each time you get a request entering your
"apple".
What you do get for free (compared to e.g. using actions) is an
interaction-based storage area (namely the instance variables in your
apple), which is way better and easier than using the session to store
parameters for a certain flow. It also allows you to pass data to the
view layer in a flowscript-compatible way, and the integration with the
sitemap is nicer.
For the actual code see
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21900
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
RE: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Marc Portier wrote:
>
> [Dywel]
> is Carsten's personal attempt at the form-handling-thing
>
> - he announced it first here:
> http://radio.weblogs.com/0107211/2003/07/10.html#a134
> - and is now active in the woody discussions to see which parts
> of woody could serve his vision
> - I think he's more or less still in the early stages of design
> and prototype (just like woody in fact)
> - his blog somewhat provides a basis for follow up on the status
> - he is best placed to correct/augment where needed
Thanks Marc! You saved me a little bit of typing!
Yes, Dywel is a test do build a framework for building webapps on
top of Cocoon. I have some rough concepts and a simple nonfunctional
prototyp :) running, and as put above I want to reuse as much
as possible.
I spent the last nights with looking at the persistence layer, the next
thing (perhaps at the weeking) is the state handling. I plan to
have something similar like Apples seems to be. So perhaps I can
use something from there as well.
As soon as I have something more usable I will make it available
somewhere put I guess not in the cocoon cvs first.
That has to be a community decision.
Carsten
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Posted by Marc Portier <mp...@outerthought.org>.
Antonio Gallardo wrote:
> Steven Noels dijo:
>
<snip />
>>Kidding aside, is my categorization more or less correct? Might be cool
>>to put on a slide once.
>
>
> Seriously, where I can find more about "Apples" and "Dywel"? It is being
> be part of Cocoon?
>
[Dywel]
is Carsten's personal attempt at the form-handling-thing
- he announced it first here:
http://radio.weblogs.com/0107211/2003/07/10.html#a134
- and is now active in the woody discussions to see which parts
of woody could serve his vision
- I think he's more or less still in the early stages of design
and prototype (just like woody in fact)
- his blog somewhat provides a basis for follow up on the status
- he is best placed to correct/augment where needed
[Apples]
is my first throw at building a flow implementation framework
that would allow for classic Java/Avalon components to be holding
the business logic of your flow aware use cases.
- most of the ideas behind it were first expressed here:
http://wiki.cocoondev.org/Wiki.jsp?page=GeneralizedFlow
- As for the code itself: I wrapped it up as an
alpha-cocoon-block which for now can be found here:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21900
- A guide into this initial design and usage is here:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105913410112209&w=2
- feel free to ask questions on any of this
as for community impact / adoption / participation: this is to
date largely dreamware and tryout stuff ... your comments and
participation are welcome
I think this kind of research helps out in getting a better
understanding, and can generate some sensible refactorings by
taking a different view to things
if / when / how / why all of this ever gets adopted by the
community (and becomes really a 'school') is not to be predicted,
we did however have a recent thread that expressed the commitment
from all sides to make sure these alternatives are not to become
a basis for fragmentation of the group-effort, but rather
supporting and goaled at integration and unification
HTH,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Steven Noels dijo:
> <interlude advise="don't take this too seriously">
>
> More stupidity being put forward, I would humbly suggest to explicitely
> name the methodologies:
>
> 1) 'Barbara', in kind remembrance of B. Post
> 2) 'Carsten, the Early Years'
> 3) 'SchemoVidiuChrismatron'
> 4) 'Species' - since Apples and Pears are way to generic already, and
> it's what Darwin was all about
> 5) 'Rag' - since Dywel really sounds like a mop in Dutch if slightly
> misspelled
>
> ... in order to be able to ask a Cocoonie: what religion are you in?
> "Oh, I used to be an early CultofBarbara groupie, but now I tend to
> worship the mighty SchemoVidiuChrismatron."
I think many of us started believing in the Cult of Barbara. After all for
many of us that never saw a "hairy beasts" as XSLT and Cocoon. I think
this was the easier way to start using Cocoon. Many of us saw this: XSP is
easy to learn and Java is well known, I can believe in this cult. We can
call this also "The beginning", because of us started using Cocoon trying
to find better ways of development. :)
After ending the 1 application while learning Cocoon and some hard battles
with the "hairy beasts". The beasts started to be tamed for us. Then we
started losing our faith in the cult of Barbara, because we saw how
dificult will be mantain the new scripting lang. called XSP. :(
At that time many of us started the exodus and at the beginning was the
cult of 'Carsten, the Early Years'. Then is the "The transformers". :)
There was a time (before Flow) that the idea was use transformers and
actions for every thing. But this showed also problems related to database
intensive applications. I never being part of this. :( But the transformer
idea remain as a good legacy for the next generations.
</interlude>
> Kidding aside, is my categorization more or less correct? Might be cool
> to put on a slide once.
Seriously, where I can find more about "Apples" and "Dywel"? It is being
be part of Cocoon?
Best Regards,
Antonio Gallardo
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Steven Noels dijo:
>> 5) 'Rag' - since Dywel really sounds like a mop in Dutch if slightly
>> misspelled
Hey, Dywel is a full british name:-)
>From carsten blog:
http://www.britannia.com/bios/ebk/dyweldm.html
Best Regards,
Antonio Gallardo
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Posted by Steven Noels <st...@outerthought.org>.
On 31/07/2003 14:23 Steven Noels wrote:
> 1) 'Barbara', in kind remembrance of B. Post
> 2) 'Carsten, the Early Years'
> 3) 'SchemoVidiuChrismatron'
> 4) 'Species' - since Apples and Pears are way to generic already, and
> it's what Darwin was all about
> 5) 'Rag' - since Dywel really sounds like a mop in Dutch if slightly
> misspelled
and Bruno reminds me of Schools I forgot about:
- the "who said I shouldn't use Tomcat filters to manage Hibernate
sessions" school, "just be happy that I don't system.exec() a shell
script to do the same"
- the "look at me calculating a CRC checksum of a creditcard number
using XPath" school of XMLForms
I'm signing off for this afternoon, so I'll stop nagging the list with
frivolous mails - don't you worry. ;-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
RE: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Steven Noels wrote:
>
> <interlude advise="don't take this too seriously">
>
> More stupidity being put forward, I would humbly suggest to explicitely
> name the methodologies:
>
> 1) 'Barbara', in kind remembrance of B. Post
> 2) 'Carsten, the Early Years'
> 3) 'SchemoVidiuChrismatron'
> 4) 'Species' - since Apples and Pears are way to generic already, and
> it's what Darwin was all about
> 5) 'Rag' - since Dywel really sounds like a mop in Dutch if slightly
> misspelled
>
> ... in order to be able to ask a Cocoonie: what religion are you in?
> "Oh, I used to be an early CultofBarbara groupie, but now I tend to
> worship the mighty SchemoVidiuChrismatron."
>
> </interlude>
>
> Kidding aside, is my categorization more or less correct? Might be cool
> to put on a slide once.
>
More or less :) perhaps it's not correct to but my name together with
actions at 2), we all know who checked in the Action interface...
Serious: what about a humour page on our web site with nice and funny
things like these? Especially I like 'SchemoVidiuChrismatron' !
Carsten
Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Posted by Steven Noels <st...@outerthought.org>.
On 31/07/2003 13:35 Stefano Mazzocchi wrote:
> On Wednesday, Jul 30, 2003, at 18:48 Europe/Rome, Nicola Ken Barozzi
> wrote:
>
>>
>> http://blog.xesoft.com/jon.lipsky/blog/Java/
>> ?permalink=workflow_viewlets.html
>
>
> did you guys ever programmed java with JavaStudio? it was a nice little
> app that sun released in the early java days. it was visual programming
> of java code thru LabView style drag-drop-link of javabeans.
Yep. Sugar candy appealing to lusers like myself. :-)
> It was sooooooo cool when you saw a demo.
>
> Horrible to work with it.
>
> why? visual programming is bullshit.
>
> It take half an hour to write a visual representation of something like
>
> if (blah) {
> dothis();
> } else {
> dothat();
> }
Still, I found the demos pretty valuable with the process variables
being explicitely being created in a separate pane. Makes one think more
about what he is doing.
The nice thing of such a GUI is that it enforces people to make use of
the exposed API, and makes hacks around it, reaching for areas where
scripting authors shouldn't come, a bit more difficult.
- 0 -
I just had a discussion in the car with Bruno about where Apples is
heading (basically he bringing me uptodate - thank you Bruno), and my
layman's conclusion is that different schools of development style are
emerging when building webapps with Cocoon.
1) glueing together ready-made available components using XSPs and the
bag of available Actions
2) Actions and custom Avalon-Cocoon components, which tend to overload
the sitemap with programmatic constructions in the long run
3) 'Webcontinuations flow with Javascript', where people depend on the
availability of Javascript wrappers for common libraries (JDBC, OR
frameworks, ...) - with the challenge of coming up with decent JS
libraries to make sure one doesn't have to reach at too many Java stuff
using 'Packages' - the really cool thing is of course the instant
gratification of save/reload/test
4) 'Apples' which shifts the encapsulation of business and service
components back to full-blown Java, with a simple Apple class calling
upon them while exposing flow decisions in a very lighweight manner in
order to call the correct pipelines
5) 'Dywel' which seems to be going after Struts practices with a nice
dash of Avalonization to go with that
3) and 4) being heavily dependent on the JXTransformer approach (which
is a Good Thing IMHO)
How we are going to manage and support these five schools of thought, I
honestly don't know (not even if we need to be worried altogether), but
I envision some some white-bearded guy is already chuckling in his
corner (http://strongbrains.com/images/darwin.jpg)
<interlude advise="don't take this too seriously">
More stupidity being put forward, I would humbly suggest to explicitely
name the methodologies:
1) 'Barbara', in kind remembrance of B. Post
2) 'Carsten, the Early Years'
3) 'SchemoVidiuChrismatron'
4) 'Species' - since Apples and Pears are way to generic already, and
it's what Darwin was all about
5) 'Rag' - since Dywel really sounds like a mop in Dutch if slightly
misspelled
... in order to be able to ask a Cocoonie: what religion are you in?
"Oh, I used to be an early CultofBarbara groupie, but now I tend to
worship the mighty SchemoVidiuChrismatron."
</interlude>
Kidding aside, is my categorization more or less correct? Might be cool
to put on a slide once.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Cool (work)flow GUI editor
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Jul 31, 2003, at 14:31 Europe/Rome, Vadim Gritsenko wrote:
> Stefano Mazzocchi wrote:
>> why? visual programming is bullshit.
>
> Not if it supports full round trip, nonvisual -> visual -> nonvisual.
> It's much easier to quickly understand what's going on in the workflow
> by lookng at the picture instead of looking at the workflow markup
> (and it's much more complex to do roundtrip if your source is
> javascript).
You are right, roundtripping makes a huge difference and you are right
again saying that it is much harder to write a "script->graphic" parser
than a graphic->script one, still not impossible.
--
Stefano.
Re: Cool (work)flow GUI editor
Posted by Vadim Gritsenko <va...@verizon.net>.
Stefano Mazzocchi wrote:
>
> On Wednesday, Jul 30, 2003, at 18:48 Europe/Rome, Nicola Ken Barozzi
> wrote:
>
>>
>> http://blog.xesoft.com/jon.lipsky/blog/Java/
>> ?permalink=workflow_viewlets.html
>
>
> did you guys ever programmed java with JavaStudio? it was a nice
> little app that sun released in the early java days. it was visual
> programming of java code thru LabView style drag-drop-link of javabeans.
It was a monster :)
> It was sooooooo cool when you saw a demo.
>
> Horrible to work with it.
>
> why? visual programming is bullshit.
Not if it supports full round trip, nonvisual -> visual -> nonvisual.
It's much easier to quickly understand what's going on in the workflow
by lookng at the picture instead of looking at the workflow markup (and
it's much more complex to do roundtrip if your source is javascript).
Vadim
Re: Cool (work)flow GUI editor
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Jul 30, 2003, at 18:48 Europe/Rome, Nicola Ken Barozzi
wrote:
>
> http://blog.xesoft.com/jon.lipsky/blog/Java/
> ?permalink=workflow_viewlets.html
did you guys ever programmed java with JavaStudio? it was a nice little
app that sun released in the early java days. it was visual programming
of java code thru LabView style drag-drop-link of javabeans.
It was sooooooo cool when you saw a demo.
Horrible to work with it.
why? visual programming is bullshit.
It take half an hour to write a visual representation of something like
if (blah) {
dothis();
} else {
dothat();
}
Try.
--
Stefano.