On Thu, 04 Mar 2004 09:06:17 +0000
Upayavira <[EMAIL PROTECTED]> 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,
well, so i unterstand it should show the uri-list an
options/Dialogs to edit the main CocoonBean settings and
Uri-elements.
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.
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.
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
things)
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 cocoon.sh
CLI_LIBRARIES="-Dloader.jar.repositories=$COCOON_LIB${PATHS
EP}${COCOON_HOME}/tools/jetty/lib"
solves the often first problem in using the CLI,without
"copy" ;-).
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. 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
(BSD-license)).
I'm interested in the GUI thing,
Best Regards,
Simon
