Bertrand Delacretaz wrote:
Le 27 avr. 05, à 16:41, Daniel Fagerstrom a écrit :
...Then we need a name for sitemap blocks. I propose to call them
cocoonlets...
Frankly, I don't like the name - most of these -let names sound bad
to me.
But I don't think the names component block and sitemap
Sylvain Wallez wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Our current (controversial ;) ) plan is to consider the sitemap and
the component aspect of the original block proposal as separate
concerns and (at least initially) solve them separately.
Damn, I skipped this whole thread
[EMAIL PROTECTED] wrote:
Author: cziegeler
Date: Mon May 2 06:32:24 2005
New Revision: 165628
URL: http://svn.apache.org/viewcvs?rev=165628view=rev
Log:
Protocols can be defined on a per sitemap configuration
Modified:
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
snip/
I had some problems getting the root context right when working on the
BlockManager which I solved by redefining the source resolver in the
block manager's own service manager. So I'm interested in some more
details about exactly what
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
snip/
The problem I had still remain, the context from the defining sitemap
rather than the using sitemap is still used. I could modify the code to
use the context from the EnvironmentHelper instead.
What exactly do you need? The Context object
Sylvain Wallez wrote:
So I propose to remove @author tags with people names from all our
source files.
+1
Additionally, if you agree with removing names, do you want source files
to have:
[ x ] no @author tag at all,
[ ] @author The Cocoon development team
[ ] @author . (something else)
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
I need the context object. Take a look at
o.a.c.components.blocks.BlockManager.initialize(). I need to set the
context-root to the root directory of the block to get the source
resolver to work in the right way. A block is supposed
Leszek Gawron wrote:
Leszek Gawron wrote:
Vadim Gritsenko wrote:
snip/
Why FOM_Request is in jx in the first place? I understand why it is
in old jxtg in Cocoon 2.1, but new version should be flow independent.
The flow independence we talked about was to make JXTG work without
needing to call
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
snip/
The accessors do not solve the problem with
$cocoon/request/requestAttribute or $cocoon/request/requestParameter
(preferably $cocoon/request/attributes/someAttribute and
$cocoon/request/parameters/someParameter)
We could provide some kind
Leszek Gawron wrote:
right now we have:
registerInstruction(template, StartTemplate.class.getName());
registerInstruction(forEach, StartForEach.class.getName());
registerInstruction(if, StartIf.class.getName());
registerInstruction(choose, StartChoose.class.getName());
registerInstruction(when,
Leszek Gawron wrote:
ouzo a quick question
ouzo does SitemapTestCase support .xconf inclusions in 2.2?
ouzo just as standard cocoon.xconf does?
Yes it does, I tried to get it as similar to ordinary Cocoon execution
as possible. You can take a look at how it is used for the VPC test
cases under
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
Sylvain refactored the environment handling in flow to simplify it,
but it also lead to some back incompatibilities that we had long
heated discussions about this in the begining of this year, check the
archive. The varoious changes
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
snip/
Are you certain about that it doesn't work for properties? I can't
test right now, but looking at
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/scratchpad/java/org/apache/cocoon/environment/TemplateObjectModelHelper.java?rev
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
I would prefer to have the template configuration in a separate file,
not in cocoon.xconf. AFAICS there is no point in making the
instructions Avalon components. It would be enough to have a
configuration file that connnects the instruction name
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
snip/
IMO we should make the Request interface bean friendly and add the
methods:
Map getParameters();
Map getAttributes();
You won't reach those as collection in HttpServletRequest
http://java.sun.com
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Ok, only the InstructionFactory is a component, that is better. Is
there any point in leting the InstructionFactory be a component?
Only the fact that I had to store the configuration somewhere and with
cocoon.xconf I had the proper tools at hand
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
snip/
Like:
instructions targetNamespace=jx
instruction name=for class=StartFor/
instruction name=for class=StartFor/
instruction name=for class=StartFor/
/instructions
instructions targetNamespace=ft
instruction name
In the current #{$cocoon/request/request/protocol} thread we (again)
discuss problems with the environment access in JXTG. The problems comes
from that we have copied part of the servlet api in our environment
abstraction and that it contains methods of the type Object
getAttribute(String),
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
snip/
to implement cforms instructions instead of jx-macros.xml file which
looks quite ugly because of hacks that had to be made to implement it.
This will also speed up forms processing.
I'm afraid that I'm not going
Leszek Gawron wrote:
I have refactored JXTG recently so now instructions like jx:for, jx:if
are defined in separate file:
src/block/template/java/org/apache/cocoon/template/template-instructions.xml
Right now we are rendering forms in jxtg using a macro file which is
kind of ugly IMO - see
Reinhard Poetz wrote:
Can it be that difficult to stream a string as SAX events in JXTemplate,
or did I overlook a simpler solution?
- implement your own streamer object with a toSAX method
- pass a streamer object to JXTemplate
- assign this object to a variable
- call the toSAX method and
Sylvain Wallez wrote:
Leszek Gawron wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Can it be that difficult to stream a string as SAX events in
JXTemplate, or did I overlook a simpler solution?
- implement your own streamer object with a toSAX method
- pass
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
Can you elaborate? What should be the view model
The view model should IMO be a (minimal) read only subset of
o.a.c.forms.formmodel.Widget and ContainerWidget, preferably POJO
friendly. From such a view point the widget hierarchy is a simple
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
As Vadim pointed out in an earlier discussion this is done in Java
faces:
http://java.sun.com/j2ee/javaserverfaces/1.1_01/docs/api/javax/faces/context/ExternalContext.html
So what I propose is that we extend o.a.c.environment.Request with:
Map
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
In the current #{$cocoon/request/request/protocol} thread we (again)
discuss problems with the environment access in JXTG. The problems
comes from that we have copied part of the servlet api in our
environment abstraction and that it contains
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
snip/
Depending on how it's done, it can be a good thing. IMHO,
public XMLizable getLabel();
seems like a right approach to me; and templating language should be
more than happy to work with XMLizable objects, so to render a label
you don't need
To simplify and make the environment handling in flow, jxtg, modules and
possibly other places more coherent, I propose that we extend the Cocoon
environment apis with some utility methods that makes the environment
more reflection friendly. See
More specifically I propose is that we extend
o.a.c.environment.Request with:
Map getAttributes();
Map getParameters();
Map getHeaders();
and o.a.c.environment.Session and o.a.c.environment.Context with:
Map getAttributes();
[+1] Go ahead and implement the environment extensions proposed
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
More specifically I propose is that we extend
o.a.c.environment.Request with:
Map getAttributes();
Map getParameters();
Map getHeaders();
What about cookies? (There is Map getCookieMap() but naming convention
is different).
It would be natural
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
snip/
How above Request interface additions will relate to methods already
added to 2.2 interface:
Object getAttribute(String name, int scope);
Object searchAttribute(String name);
Enumeration getAttributeNames(int scope);
void
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
More specifically I propose is that we extend
o.a.c.environment.Request with:
Map getAttributes();
Map getParameters();
Map getHeaders();
What about cookies? (There is Map getCookieMap() but naming
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
I missed that discussion. Anyway, IMO global request scope is nearly
never a good idea. As discussed in that thread, people are into an
unplesant suprise if they use global request scope for e.g. aggregation.
Furthermore one introduce quite
Mark Leicester wrote:
snip/
The blogs tend to give a much more exciting, future-oriented view of
Cocoon than the mailing lists, which I suppose are dealing with more
mundane, day-to-day issues.
Are you actually reading dev-list, about all core parts of Cocoon has
been proposed and designed on
interafaces depend on abstract Request, Session and Context
classes will make it rather easy to implement whatever we decide for the
request attributes.
/Daniel
Daniel Fagerstrom wrote:
To simplify and make the environment handling in flow, jxtg, modules
and possibly other places more coherent, I propose
Cocoon 2.2 into Google this
is easily the first (only?) summary you will find.
My opinion is that there is a lot of Cocoon related activity on the
web - not just in the mailing lists. I'm looking at ways of
aggregating it all together.
Regards,
Mark
On 16 May 2005, at 08:51, Daniel Fagerstrom
Reinhard Poetz wrote:
Sylvain Wallez wrote:
snip/
Ah no, forgot to say: this requires to use JXTemplate and the
forms-template-as-jx-macros.
Today I've run some load tests that compare Cocoon Forms using
jx-macros and the FormsTransformer. The transformer is *considerably*
faster (~ factor of
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
snip/
Ah no, forgot to say: this requires to use JXTemplate and the
forms-template-as-jx-macros.
Today I've run some load tests that compare Cocoon Forms using
jx-macros and the FormsTransformer
Leszek Gawron wrote:
Leszek Gawron wrote:
I have refactored JXTG recently so now instructions like jx:for, jx:if
are defined in separate file:
src/block/template/java/org/apache/cocoon/template/template-instructions.xml
Right now we are rendering forms in jxtg using a macro file which is
kind
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
snip/
The template and the macros should be much faster the second time
they are execute, otherwise there is some problem with template
caching. Do you have any numbers on that?
yes they are but macro execution takes still
Sylvain Wallez wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
snip/
-o0 Imports 0o-
Imports are used mainly for separating macro definitions from
template itself. Issues:
1. Template URI is resolved at runtime. We could skip this although
this does not bring much
Sylvain Wallez wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
AFAICS there is a lot of time spent in the macro execution methods
and especially in
org.apache.cocoon.template.jxtg.script.Invoker.toDOMNodeList()
ha!. That is a really important information.
Invoker.toDOMNodeList is used
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
We have an important performance penality here because the import
URI isn't static and therefore can only be resolved a runtime and
can potentially point to a different template at each run.
Two solutions to overcome
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
If the null check for value at line 79 in Set is changed to a null
test for this.value we get the behaviour that we should have IMO.
I would assume that the various jx:set for helper methods that has
the return type void eavluates to null
Reinhard Poetz wrote:
Yesterday I tried to upgrade to the latest Cocoon and found out that
jxpath expressions don't work, e.g. #{$cocoon/request/protocol.
Ideas?
Aren't you following the list ;)
http://marc.theaimsgroup.com/?t=11157358322r=1w=2. It is a well
known problem, the environment
Sylvain Wallez wrote:
snip/
This is something I already outlined in several blog entries ([1] and
[2]): the community is about collective thinking and supporting ideas
proposed by people. The one(s) that actually implement the idea are
those that either have time or most need it, and the result
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
/**
* JS wrapper for Cocoon's request object.
* p
* Request emparameters/em are also present as properties on
this object.
* Note that this is different from codeFOM_Context/code and
codeFOM_Session/code
* that do the same
Need more info to be able to help. Somwhere in your script you access a
value in a jx:set that cannot be evaluated by jxpath, maybe you are
calling an extension function, not sure though. Can you isolate the
expression it happens for.
It seem like commons-beanutils not is found, maybe you
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Need more info to be able to help. Somwhere in your script
I don't use a custom macro, only jx-macro.xml
Ok.
you access a
value in a jx:set that cannot be evaluated by jxpath, maybe you are
calling an extension function, not sure though. Can you
Sylvain proposed [1] to base blocks on the OSGi service platform [2][3].
After having studied it in more detail I'm completely convinced that it
is the way to go.
OSGi
The OSGi service platform is a standarized, component oriented,
computing environment for networked services. It handled
of it load these bundles, but wouldn't be
able to run them due to a lack of servlet container.
Don't know what servlet contract Eclipse use, but as it is a OSGi
container any implementation of the OSGi HTTP service should be possible
to use.
Regards, Upayavira
Daniel Fagerstrom wrote:
snip/
The Cocoon
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Sylvain proposed [1] to base blocks on the OSGi service platform
[2][3]. After having studied it in more detail I'm completely
convinced that it is the way to go.
Alternatives
So GBeans seem like the only serious alternative. I don't
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Ok, but I still need to know the content of the value attribute to the
jx:set that creates the problem to be able to help. From the
stacktrace it seem like something goes wrong when JXPath uses
reflection on the value.
The debugger showed
Thor Heinrichs-Wolpert wrote:
Daniel:
Check out RIO, which is a QoS oriented system based upon Jini. It has
either completed its relicensing or will have completed its relicensing
to use the Apache 2.0 license. This is the infrastructure used in
Sun's RFID initiative and in their
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
The Cocoon servlet bundle
-
At last we need to have a Cocoon servlet bundle it looks up the Cocoon
service and a HTTP service [10] (both Tomcat and Jetty implementations
are available), embeds the Cocoon service
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
IMO, OSGi seem to be the best choice for kernel for Cocoon's block
architecture and there is (if I haven't missed something important) a
low risk, incremental and evolutionary way to get there.
Hmm, I'm currently
Carsten Ziegeler wrote:
Torsten Curdt wrote:
Ok ...so the guys from http://100days.de
will be sponsering the meeting room on sunday.
They provide free internet access, a projector
and even some coffee :)
Nice! But upto now there are only three of us (Reinhard,
you and me) and I'm wondering
(was: [RT] Micro kernel based Cocoon)
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
snip/
We should move 2.2 out the
door as soon as possible and target real blocks for a later release.
So, try out OSGi if you want, but please not in the trunk.
snip/
And AFAIU it's out of discussion that the
Leszek Gawron wrote:
snip/
I tried to find any starters for eclipse's OSGi implementation. Not a
single useful page. If we are to make users read OSGi specification,
then seek for help in external projects that are hardly documented we
get the same problem in a fancy new outfit.
OSGi is a
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
- breaking up the monolitic Cocoon
- getting over the Java jar hell
- making development of Cocoon extensions outside of the
Cocoon project much easier (why there are hardly any Cocoon based
projects out, except Daisy, Lenya, Forrest and two
Carsten Ziegeler wrote:
snip/
I'm currently still missing the *big picture*. What are blocks, how does
Cocoon look like with them. Can I develop something without blocks? What
do I have to learn? And so on. This might be because I didn't have so
much time for Cocoon in the last weeks, don't
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
snip/
IMO we should find a less demanding and more realistic attitude for
Cocoon releases, so that we can go towards release early, release
often.
Planning what should be part of the next major release seem harmfull,
as the relase can stall
Ralph Goers wrote:
Daniel Fagerstrom wrote:
snip/
Planning what should be part of the next major release seem harmfull,
as the relase can stall forever if there is a difference between what
we would like to have in the release and what we actually are
implementing.
I don't think I
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
All current blocks, the core and libraries that are used by several
bundles are packaged as bundles. These are deployed in a OSGi kernel.
During development the Cocoon bundles can be deployed within the OSGi
kernel of Eclipse together
Sylvain Wallez wrote:
Reinhard Poetz wrote:
AFAIU only some work on cForms is missing (flowscript API and
repeater binding)
That's far from the only work to do IMO, as there are a lot of
semi-finished core features. Some that come to mind: refactored object
model,
Here the main
Sylvain Wallez wrote:
snip/
We should also consider if blocks should be _similar_ to Eclipse
plugins, of if they should _be_ such plugins, which would remove us a
log of work, both for code, docs and support.
I have read some Eclipse docu, but it is not obvious to me what Eclipse
plugins
Carsten Ziegeler wrote:
Ralph Goers wrote:
I doubt many will switch until 2.2 is stable - i.e we've had a few
releases of it. I would recommend that we continue doing maintenance on
2.1 until at least a stable 2.2.0 is released and possibly a release or
two later. That doesn't mean that
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
--- o0o ---
Probably I'm missing important aspects, but I fail to see what the split
into trunk and stable have bought us, except for less testing,
disruption and possibly sloopier coding
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
That is a reason for increasing minor version, but not for maintaining
parallell branches for years.
If we don't maintain the old 2.1.x branch, what about all its users?
Do you want to force them to migrate to 2.2? That's simply
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
snip/
We should also consider if blocks should be _similar_ to Eclipse
plugins, of if they should _be_ such plugins, which would remove us
a log of work, both for code, docs and support.
I have read some Eclipse docu
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Reinhard Poetz wrote:
AFAIU only some work on cForms is missing (flowscript API and
repeater binding)
That's far from the only work to do IMO, as there are a lot of
semi-finished core features. Some that come to mind
Ralph Goers wrote:
Bertrand Delacretaz wrote:
Le 22 mai 05, à 20:24, Daniel Fagerstrom a écrit :
...It would require quite a lot of work to give a fair overview of
what we have discussed about this in the last three or so years. You
find some info in http://wiki.apache.org/cocoon/Blocks
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
On that point, I proposed to write a new implementation of the
flowscript implementation. This is certainly not a total rewrite, but
a refactoring of the existing code to have an overally consistent
object model
David Casal wrote:
Hi again,
On 25 May 2005, at 10:39, David Casal wrote:
If you read this far, I owe you a beer. Please get creative with your
answers, comic-book style.
*tumbleweed*
Any suggestions as to whether I should post these questions on a new
thread, or perhaps in cocoon-users,
Leszek Gawron wrote:
Reinhard Poetz wrote:
Should we move the stylesheets
I would help a lot to be able to deploy cocoon with no additional
files at all. What do you say if we moved cocoon logo and default
stylesheets (the ones styling error pages etc.) to some jar (either
existing or a
David Casal wrote:
snip/
how do you see the common user approaching the development of new
webapp, considering they might not have a senior level of development
experience? Could you illustrate your ideal use case scenario?
snip/
We haven't discussed use case scenarious in a more systematic
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
snip/
A basic scenario
1. A soon to become Cocoon user, downloads the start kit
distribution from our site.
It contains the (OSGi) kernel, the Cocoon service block (containing
the Cocoon core), a Cocoon servlet block
Bertrand Delacretaz wrote:
Le 26 mai 05, à 15:35, Steven Noels a écrit :
...That said, next week I'll be back, and if we have our Solaris zone
set up and I have access to it (Antonio?), I'll set up MySQL 4.1 +
Daisy 1.3M2 on that zone...
Cool. I cannot help ATM but this sounds good.
+1
Nathaniel Alfred wrote:
-Original Message-
From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 26. Mai 2005 15:42
To: dev@cocoon.apache.org
Subject: Re: [RT] Block usage
a block deployer block
Basically the block deployer will be a stand-alone
Leszek Gawron wrote:
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
snip/
It's a pity we cannot move .xconf files into jars.
Why can't we?
AFAIR due to the fact that resource:/ protocol is not as functional as
file:/ (no directiories
Leszek Gawron wrote:
Reinhard Poetz wrote:
... but there needs some work to enable the blocks:/ protocol,
component management and block-aware flowscript (e.g.
cocoon.blocks.blockA.myFunc())
There is a block:/ protocol in OSGi. I haven't read OSGi specification
though - I saw it in
Bertrand Delacretaz wrote:
Le 27 mai 05, à 03:24, Antonio Gallardo a écrit :
...If I becomes the root of our zone,
then I will be glad to provide all the necessary support to materialize
this effort...
Great, thanks!
+1 :)
I've not used solaris yet but I've worked with many different
:
http://www.jisc.ac.uk/index.cfm?name=techwatch_home
On 26 May 2005, at 13:34, Daniel Fagerstrom wrote:
snip
4. The user can chose between following a number of different wizard
like tutorials, e.g.: Minimal Cocoon app, documentation site
(Forrest), portal, CMS site (Lenya or Daisy), Spring based
Leszek Gawron wrote:
What do you say if we extend JXTemplateGenerator ExpressionContext with
namespaces support? Every namespace that is registered on the jxtg
template could also be registered at JXPathContext.
Sound usefull, any idea about how to implement it?
/Daniel
BURGHARD Éric wrote:
just for information,
i've achieved some template migration from jxtg (2.2-dev) to
xslt 2.0 (saxon8) and record a 7 to 10 factor speed increase on the same
pages (cache desactivated).
If you want to help making JXTG faster you need to submit more
information. We need
Antonio Gallardo wrote:
snip/
IMHO, that means Logkit is dead.
Is time to moving setup log4j as our default logging package.
Is that OK?
Antonio,
Logkit has been dead for quite some time and we have long discussions
about changing logging package a couple of times every year. The last
one
BURGHARD Éric wrote:
An important point: which JXTG are you using? The original one, or the
new implementation in trunk?
It's a quite old now 2.2-dev, so i think this is not the refactored one. I
will try to update to current trunk, and retest.
We use macros and sometime evalBody (i've
BURGHARD Éric wrote:
Daniel Fagerstrom wrote:
If you want to help making JXTG faster you need to submit more
information. We need examples that reproduce this behaviour with the
JXTG template and the corresponding XSLT. We also need to know exactly
what version of 2.2 you used. How did you
Antonio Gallardo wrote:
On Mar, 31 de Mayo de 2005, 13:53, Daniel Fagerstrom dijo:
Antonio Gallardo wrote:
snip/
IMHO, that means Logkit is dead.
Is time to moving setup log4j as our default logging package.
Is that OK?
Antonio,
Logkit has been dead for quite some time
Peter Hunsberger wrote:
On 5/31/05, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
BURGHARD Éric wrote:
Daniel Fagerstrom wrote:
If you want to help making JXTG faster you need to submit more
information. We need examples that reproduce this behaviour with the
JXTG template
Reinhard Poetz wrote:
Reinhard Poetz wrote:
http://wiki.apache.org/general/SummerOfCode2005#cocoon-refdoc
http://wiki.apache.org/general/SummerOfCode2005#cocoon-flowscript-serialization.
Do we have something else on our wishlists (some fancy cforms
features, etc.)?
Web service
Reinhard Poetz wrote:
Leszek Gawron wrote:
1. we still have not touched the subject of attribute driven template
language. it would nicely suit as a project that could be finished
till the end of summer.
2. cforms reusable widget repository...
yes, I like both ideas! Who wants to mentor
Leszek Gawron wrote:
Reinhard Poetz wrote:
Leszek Gawron wrote:
1. we still have not touched the subject of attribute driven
template language. it would nicely suit as a project that could be
finished till the end of summer.
2. cforms reusable widget repository...
yes, I like both
Reinhard Poetz wrote:
Vishal Nagota wrote:
Dear Sir,
I'm very much intrested in working for apache. I was thinking a lot
about the project on which I could work on but nothing good came to my
mind. The project which I liked the most among the projects given by
you is cocoon-cforms-library.
Sylvain Wallez wrote:
Steven Noels wrote:
I'll call it a night, but http://cocoon.zones.apache.org/daisy/ is
live - still a crude and empty setup, however.
Awesome! Thanks Steven!
+1000 :)
A Cocoon based documentation CMS on ASF hardware at last! Was it six
years ago Stefano started to
Sylvain Wallez wrote:
Hi all,
Now that thanks to Steven we have a nice Cocoon-based ASF-hosted CMS, we
have to (and want to) use it!
AFAIU by reading the recent discussions, a difficult point is the xdoc
format used by Cocoon's internal publishing system.
So what about considering xdoc
I have added a first, hopefully working, version of the sitemap aspect
of real blocks to the trunk. No functionality to get components (not
even VPCs) yet from the blocks.
Examples can be found in:
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
I have added a first, hopefully working, version of the sitemap aspect
of real blocks to the trunk. No functionality to get components (not
even VPCs) yet from the blocks.
Many thanks mate!!! I will give you feedback on the issues that I can
I have started to experiment with OSGi, and this far it seem rather
promising. I hope to be able to check in something in whiteboard rather
soon.
--- o0o ---
A problem however is that our organization (or rather lack of
organization) of packages in blocks, in some cases
Ralph Goers wrote:
Ben Pope wrote:
It makes very little sense to mark it stable without it actually being
what is generally considered (by this community) as stable.
You might as well just throw away all semantics, I doubt there are
many people here who want to release something whose API
I have committed some initial osgi code in whiteboard (whiteboard/osgi)
so that we can start experiment with a microkernel based Cocoon,
http://marc.theaimsgroup.com/?t=11165964683r=1w=2.
This far we have the following:
OSGi
I decided to use the OSGi framework from
401 - 500 of 1344 matches
Mail list logo
