cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: [ANN] GUIapplication for Offline Processing
Date Wed, 10 Mar 2004 12:48:41 GMT
Simon Mieth wrote:

>On Thu, 04 Mar 2004 09:06:17 +0000
>Upayavira <> wrote:
>>Okay, Simon, sorry for my delay in replying.
>>Here's my idea of what I'd like to see.
>>Firstly, I'd ___love___ to see a really thin GUI, with no
>>editors (or a really cut down notepad style editor) living
>>within Cocoon CVS, and packaged with Cocoon .This GUI
>>should make use of as much of Cocoon's code as poss, e.g.
>>its loader, Avalon, etc, to minimise the amount of new
>>code that is added because of it.
>>If that can be pluggable (preferably using an Avalon style
>>component system), that would be great.
>>I think that this GUI, if it can be simple enough so that
>>it will be easily maintainable by other Cocoon committers
>>as well as Simon, would significantly reduce the entry
>>barrier to using Cocoon in offline mode, and could
>>increase its use in that area quite substantially.
>>Anything more, e.g. OpenOffice editor plugins, etc, that
>>might require more significant library dependencies, etc,
>>can live in the "to be created" Cocoon-Tools CVS
>>repository. Maybe it could be the thing that causes that
>>repository to be set up.
>>What do you all make of this as an approach?
>>Regards, Upayavira
>Hi Upayavira,
Sorry for delay...

>well, so i unterstand it should show the uri-list an
>options/Dialogs to edit the main CocoonBean settings and
>At the moment I'm on thinking over how i should rewrite the
>application to more flexibility. I tried a Component System
>on some parts and would use such thing more and before
>imitate a Avalon framework, maybe it is better to use it.
The less code, the less maintenance, the better. If you can use Avalon 
stuff, that'd be great.

>For what I have in mind it is important to be separated from
>Cocoon and I wont like to give up this, but if I switch to
>usable Component-system it might be possible to use Dialogs
>and Import/Export-filter and the same BeanCofigurationHolder
> for a pure CLIgui. A BeanConfigurationHolder is  necessary,
>because the current Bean has all setters, but only some
>getters, but to configure all options and storing back to
>cli.xconf getters are needed.
Okay. The BeanConfigurationHolder is necessary for the mo, but the 
CocoonBean should be reworked to be a proper bean, so that you can query 
on everything. I just haven't needed this myself.

>In many cases my application and a pure CLIgui will use the
>same components, so if is interest there is a way.
>I would call my app just more  a cocoon-tool and would be
>glad if some will use it (but not yet, I will change many
Yes - in bothi its cut down, and fully fledged forms, it'll be very useful.

>Ok, some other things I have in mind during looking at
>the CLI today. The current CLI-loader has the option to add
>more then one "jar.repository" to the classloader. Is there
>a reasen why it not point to tools/jetty/lib and have
>servlet.jar in the classpath?
>The following change to 
>solves the often first problem in using the CLI,without
>"copy" ;-).
Adding servlet.jar in some ways avoids the problem, rather than solving 
it. Running the CLI _should not need_ any classes that depend upon 
servlet.jar, and thus it should not be needed. The more thorough 
approach would be to remove this dependency. Maybe I'm ready to take 
that on sometime soon. I'll be encouraged to do so if I see good stuff 
coming from you!!!

>I have separated the Cocoon-processing and publishing for me
>and looked which jars are needed for CLIgui, I got just the
>idea why not put jsch.jar (scp) and commons-net.jar (ftp) to
>the ant libs and give so the possibility to use publishing
>with ant and processing with your ant-task. The CLIgui could
>setup the publishsettings and write a ant-buildfile. 
That'd be fab. Especially seeing as we already include Ant.

>If the
>CLIgui should publish to it can simple use the same libs and
>then there would only be on more jar for the GUI (i would
>suggest to use jgoodies- Formlayout and Looks for esay and
>better GUi-building, if so the there where +2 jars
Okay. We'd need to get others to check these licences, but otherwise, 
sounds great!

>I'm interested in the GUI thing,
Me too!

Regards, Upayavira

View raw message