Sorry for delay...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 anThe less code, the less maintenance, the better. If you can use Avalon stuff, that'd be great.
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 fromOkay. 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.
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 theYes - in bothi its cut down, and fully fledged forms, it'll be very useful.
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 atAdding 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!!!
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 meThat'd be fab. Especially seeing as we already include Ant.
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 theOkay. We'd need to get others to check these licences, but otherwise, sounds great!
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,Me too!
Regards, Upayavira
