Kamal wrote:
Reinhard Pötz wrote:
Kamal Bhatt wrote:
Those anyone have any thoughts? There is nothing overly unusual
about my applications, it is just a standard application with
single block and no extra code. The only thing unusual about it is
I am using map:mount at the sitemap level.
Ch
Kamal wrote:
Reinhard Pötz wrote:
Kamal Bhatt wrote:
Those anyone have any thoughts? There is nothing overly unusual
about my applications, it is just a standard application with
single block and no extra code. The only thing unusual about it is
I am using map:mount at the sitemap level.
Ch
Thanks all. Sorry for confusing everyone - I wasn't thinking. You are of course
right, this is exactly how XSLT is supposed to work!
And to Warrell: The BBC are not officially using Cocoon yet, we're just
trialling some projects with it to see how it works :-)
Heather
-Original Message--
Hi Heather,
nothing strange here. It is eaxctly how XSLT works.
Your templat (fragment) says:
a) at the root of the document to be processed, start a "p" element.
b) then add anything form processing (*)
c) then end the "p" element opened above
d) then add the constant rest ()
(*) This temp
Hi Heather,
Remember that XSLT is a set of rules to apply to your input XML document.
You have defined a rule whose output will triggered when the root of your
input XML document Since all XML documents have a root then your template
will fire and output the HTML that you have defined.
No odd beh
Hi Heather,
I don't correctly understand your problem. In in an XSLT you put some
html (or any other XML) not in the xsl: namespace, it will go into the
output, is the way it has to work.
For example :
The name is
And bla bla bla
The correct output for an input like :
Simone
Hi,
I'm a newbie. Using Cocoon 2.1.11 and the following simple pipeline:
I noticed some strange XSLT behaviour where, on a failed template match,
the XSL appears to reference *itself* as the input XML doc. In other
words, let's say I have this xsl temp
Reinhard Pötz wrote:
Kamal Bhatt wrote:
Those anyone have any thoughts? There is nothing overly unusual
about my applications, it is just a standard application with single
block and no extra code. The only thing unusual about it is I am
using map:mount at the sitemap level.
Cheers.
This is
Kamal Bhatt wrote:
> Hi,
> Can you please confirm that map:mount will make it into the next
> version of Cocoon? This will greatly influence whether we migrate to
> Cocoon 2.2 or not.
Kamal, we are only thinking about deprecating map:mount. That means,
even if we decide to deprecate map:mount in C2
Kamal Bhatt wrote:
Those anyone have any thoughts? There is nothing overly unusual about
my applications, it is just a standard application with single block
and no extra code. The only thing unusual about it is I am using
map:mount at the sitemap level.
Cheers.
This is partially fixed. On t
Hi,
we have a web page containing 3 cforms. The 2 first/upper cforms are using
session values which are set in the 3rd cforms. The initial page is using
default values.
When we submit the form in the 3rd cform, we wish to update the 2 other
cforms. The problem is that the 3rd cform is generated a
Hi,
Can you please confirm that map:mount will make it into the next version
of Cocoon? This will greatly influence whether we migrate to Cocoon 2.2
or not.
Cheers.
Grzegorz Kossakowski wrote:
Kamal pisze:
We are actively discussing idea of deprecating map:mount
functionality but no decisio
Kamal Bhatt wrote:
Hi,
I am trying to deploy Cocoon 2.2 and an error on deployment. There
doesn't seem to be anything useful in the logs:
[#|2008-04-22T16:03:28.000+1000|INFO|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=19;_ThreadName=Timer-5;|PWC1412:
WebModule[/apps/ccn2
13 matches
Mail list logo
