RE: Cool (work)flow GUI editor
>[Vadim Gritsenko] > [Stefano Mazzocchi] > > It was sooo 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. Visual programming is very old, i.e., 1960's. (http://radio.weblogs.com/0119894/2003/04/23.html for pointers to some resources and blog entries) There is a level of detail and interactivity which is appropriate for different "sizes" of represented objects: High detail (e.g., expressions/lines of Java code) --> Representation only with all interaction done with the underlying code. Lower detail (e.g., web pages, business objects, web services calls) --> Visual manipulation via model without access to underlying code, property panels for configuration, drill-down to code or expressions Low detail (e.g., web applications, physical servers) --> Representation only with real-time updates and some interactivity (e.g., monitoring/management) For a platform like Cocoon, a visual representation with linkage or drill-down to locations in configuration files or source code would be the way to go. The representation would have to be regenerated with changes, but it would provide a visual overview. (This could probably even be done with SVG...) $0.02, -- PB
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
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]
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]
Antonio Gallardo wrote: Steven Noels dijo: 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 Portierhttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Cool (work)flow GUI editor
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: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
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)flow GUI editor]
Steven Noels dijo: > > > 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. > 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: Cool (work)flow GUI editor
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]
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 Noelshttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
RE: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Steven Noels wrote: > > > > 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." > > > > 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
Re: Cool (work)flow GUI editor
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 sooo 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
Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
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 sooo 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)
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."
Kidding aside, is my categorization more or less correct? Might be cool
to put on a slide once.
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org
Re: Cool (work)flow GUI editor
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 sooo 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.
Re: Cool (work)flow GUI editor
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
