Antonio Gallardo wrote:
Hi:
Was the fd:suggestion-list for cforms released in 2.1.8? I cannot
find samples of it at cocoon.zones. The suggestion list was part of
Sylvain's presentation in GT2005. At the same time, I am aware of the
decision to drop scritpaculous support in cocoon.
What is
Sylvain, thanks for replying! :-)
I had been playing with some of the AJAX client-side frameworks
suggested by you (scriptaculous and dojo) . I was looking the internals
to learn how they works and looking for what is cool, so we can
borrow for cocoon. ;-)
Scriptaculous is great, but I
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 55
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 55
Upayavira wrote:
What about using it to build a neat installer for Cocoon?
Could it handle the dependency resolution bit? That's the callenging bit.
We should keep installation and deployment separate.
I have nothing against tools that unpack and install core cocoon into a
specified dir,
Jorg Heymans wrote:
Upayavira wrote:
What about using it to build a neat installer for Cocoon?
Could it handle the dependency resolution bit? That's the callenging bit.
We should keep installation and deployment separate.
I have nothing against tools that unpack and install core
On 11/20/05 10:28 AM, Antonio Gallardo [EMAIL PROTECTED] wrote:
...
About Dojo, one of the concerns is that it takes longer initializing on
the client. Maybe it is just due the internet wire. Let me explain,
seems like dojo use a load on demand scheme to load the required JS
files, hence it
On 20.11.2005 16:13, Upayavira wrote:
What about using it to build a neat installer for Cocoon?
Could it handle the dependency resolution bit? That's the callenging bit.
We should keep installation and deployment separate.
I have nothing against tools that unpack and install core cocoon
Joerg Heinicke wrote:
On 20.11.2005 16:13, Upayavira wrote:
What about using it to build a neat installer for Cocoon?
Could it handle the dependency resolution bit? That's the
callenging bit.
We should keep installation and deployment separate.
I have nothing against tools that unpack
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 19 Nov 2005, Ralph Goers wrote:
Date: Sat, 19 Nov 2005 10:40:14 -0800
From: Ralph Goers [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Portal work
Carsten Ziegeler wrote:
It would be great if
Max Pfingsthorn wrote:
On 11/20/05 10:28 AM, Antonio Gallardo [EMAIL PROTECTED] wrote:
...
About Dojo, one of the concerns is that it takes longer initializing on
the client. Maybe it is just due the internet wire. Let me explain,
seems like dojo use a load on demand scheme to load the
Hello Cocooners,
Im desperately looking for Cocoon Core Documentation
of any kind. I have quite unsuccessfully tried to get a clue
from looking at the soure, but this whole sitemap processing seems quite
complex.
What I need to do and I will bug you with this in
detail for sure
Upayavira wrote:
It depends which version you are talking about 2.1 or 2.2. If we're
talking 2.2, then yes, Maven will do a lot of it. If we're talking 2.1
then no, Maven won't do any. In fact, we already have some code in the
whiteboard that can do the necessary dependency resolution with 2.1
Sylvain Wallez wrote:
Joerg Heinicke wrote:
Do you really want to add such an additional feature to 2.1 branch?
If we already have one (like Ugo's Guilder) we shall go with that
one. But I would not add anything new like an installer based on IzPack.
Ok...
IzPack has been under my
I asked something similar in the users
list some time ago but got no response, so youre my last chance ;)
As usual were storing information
in the AuthenticationContext. So far this information has been
written on disk with every request processed by the server.
Due to several
You should create a component that implements the required Avalon
interfaces and then declare it in cocoon.xconf. You will need to assign
it a role (faily simple - look at other components to see how they do
it). The code that uses the component then calls the component manager
to look up the
I haven't tried the technique you are using. I found it easier to create
an object with references to everything else my application needs and
store that in the session. The object then implements
HttpSessionBindingListener to detect that the session is being
destroyed. This does not require
Giacomo Pati wrote:
Yeah, it would. I'm not sure why this is the case. I find the portal to be
a
great way to build any website, whether it needs the features of a portal or
not.
I think it's probably because of a steep learing curve without the
necessary documentation. So I appreciate
Ralph Goers wrote:
You make some good points here and the behavior is certainly correct. It
seemed to me that the search layout was called for each layout as it was
being processed, but I could be wrong. The solution I added in 2.1 was
to essentially have the AspectRenderer and
Now as 2.1.8 is out, we should think about a 2.2 release. I think for a
2.2 release we should at least finish the following things:
- Finish the maven2 build
- Sync everything with 2.1.x (apply changes that were only applied to
2.1.x if appropriate)
- Separate samples from blocks
- Remove author
Sylvain Wallez wrote:
Joerg Heinicke wrote:
On 20.11.2005 16:13, Upayavira wrote:
What about using it to build a neat installer for Cocoon?
Could it handle the dependency resolution bit? That's the
callenging bit.
We should keep installation and deployment separate.
I have nothing
Thank you for your quick response :)
| You should create a component that implements the required Avalon
| interfaces and then declare it in cocoon.xconf. You will need to assign
| it a role (faily simple - look at other components to see how they do
| it). The code that uses the component then
Ralph Goers wrote:
Sylvain Wallez wrote:
Joerg Heinicke wrote:
Do you really want to add such an additional feature to 2.1 branch?
If we already have one (like Ugo's Guilder) we shall go with that
one. But I would not add anything new like an installer based on
IzPack.
Ok...
IzPack has
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
Hi,
Can someone take care of stop the bugzilla bug report and start a Jira
based bugreport?
I will like to do it myself, but I suspect I don't jave the permissions
to do that. :-)
Best Regards,
Antonio Gallardo.
[EMAIL PROTECTED] wrote:
Upayavira wrote:
Actually I interpret the communities response as too late for 2.1 and
too early for 2.2.
+1 !
We need to stop adding features to 2.1, and we've got a lot to fix
before we'll be able to work out what an installer should do on 2.2.
+1 !
So, don't forget it, just hold
Stefan Pietschmann wrote:
The elements in the pipeline shall have attributes like
map:transform type=xyz conf=someID/
I don't believe you can do that. Instead you need to either do:
map:components
map:transformers
map:transformer name=my-transformer
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-forms has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-forms has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-cron has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-cron has an issue affecting its community integration.
This issue
Carsten Ziegeler wrote:
Now as 2.1.8 is out, we should think about a 2.2 release. I think for a
2.2 release we should at least finish the following things:
- Finish the maven2 build
- Sync everything with 2.1.x (apply changes that were only applied to
2.1.x if appropriate)
- Separate samples
Le 20 nov. 05, à 18:14, Stefan Pietschmann a écrit :
...For this any documentation or tips would be great… I read that
Bertrand gave an introduction on the Cocoon internals at the
CocoonGT2005. Are there any docs from there perhaps?...
My presentation was not on internals but on
On Nov 21, 2005, at 12:16 AM, Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Now as 2.1.8 is out, we should think about a 2.2 release. I think
for a
2.2 release we should at least finish the following things:
- Finish the maven2 build
- Sync everything with 2.1.x (apply changes that were
Hi,all:
I am trying implement an application using CForm with Ajax.Now I have a
problem:
When form submit(using submit widget),the form will entirely refresh and
display the result,just like samples in form block.I just want to using Ajax to
make the entire process don't refresh.Here's
roy huang wrote:
Hi,all:
I am trying implement an application using CForm with Ajax.Now I have a
problem:
When form submit(using submit widget),the form will entirely refresh and
display the result,just like samples in form block.I just want to using Ajax
to make the entire
36 matches
Mail list logo
