Project: Cocoon
Issue Type: Bug
Components: - Components: Sitemap
Affects Versions: 2.1.9
Reporter: Conal Tuohy
XSLT stylesheets which either import or include other stylesheets are cached
too aggressively: if you change an imported or included stylesheet
Type: Bug
Components: Blocks: Lucene
Versions: 2.1.8, 2.1.9
Reporter: Conal Tuohy
The LuceneIndexTransformer did not provide a way to over-ride the default
maxFieldLength value of a Lucene IndexWriter. Since the default value is 10k,
this means that large documents can
[ http://issues.apache.org/jira/browse/COCOON-1880?page=all ]
Conal Tuohy updated COCOON-1880:
Attachment: LuceneIndexTransformer.diff
The patch adds the facility to set a max-field-length parameter, in the same
way as all the other parameters. Also
Ross Gardler wrote:
Stefano Mazzocchi wrote:
I like the notion of
daisy - forrest - out
makes very good sense.
Now we just need to find a way to automate a little that
workflow, but
without introducing security vulnerabilities.
How about this (bullet summaries
Glen Ezkovich wrote:
You seem to be assuming this is a global configuration
issue. If I were to make this configurable I would do it on
template by template basis, since it seems that in the
general case this would not be necessary but in a special
case it might be expedient. Once you
Tim Larson wrote:
As part of my effort to keep whiteboard/forms mergeable,
I am fixing a bunch of Id's and ran across a minor issue.
How do we want to mark the version in xml files? There
is quite a variety+possibilities:
CVS $Id$
SVN $Id$
!--+
| $Id$
+--
Tim Larson wrote:
On Wed, Feb 02, 2005 at 10:35:03AM +1300, Conal Tuohy wrote:
Tim Larson wrote:
As part of my effort to keep whiteboard/forms mergeable,
snip/
Could we pick a style, and then I will make the files I
happen to touch match it?
What about a processing instruction
Daniel Fagerstrom wrote:
Instruction Inclusion
=
Now for the instructions (jx:forEach etc) we have the
question if they
should be choosed:
1. Programatically: There is an abstract base class with
common template
generator functionality. To implement e.g. JXTG
Il giorno 06/gen/05, alle 01:54, Daniel Fagerstrom ha scritto:
* where repository:{1}.x.y.z exists == XYZPipeline
We get the right pipeline by querying the repository instead of
encoding it in the URL. A further advantage is that the
rule becomes
listable as the where clause in the
Bertrand wrote:
For me, the template author just wants to say all table elements
must be copied with border=1 added, but he has no idea in
which order
the elements will appear in the source, and shouldn't have to care.
Does your for-each syntax allow this? I think it requires declarative
Leszek Gawron wrote:
I would like to add one feature to JXTG that would allow not
to promote
hacks like [1]. Example:
jx:macro name=fooBar
somecontent/some
/jx:macro
you can only invoke it by fooBar/
If I were able to do jx:invoke macro=fooBar/ I would be
able to pass
macro
Le 7 déc. 04, à 18:54, Sylvain Wallez a écrit :
...(hearing Stefano coming behind me, ready to shout FS!!! in my
ears...)
Nahh...his detector exploded yesterday, don't worry.
...Now going back to the annotated-HTML-to-XSL compiler that we
(Anyware) wrote many years ago, it allows
Miles wrote:
One concern though: Is that results variable a result set or just a
collection of data. If the former, how is the database connection
handled (closing or returning to the pool)? If the latter, how can
large result sets be returned without exhausting memory from a few
Coincidentally I'm just starting work on a templater too. I have been using JXTemplate
and I really like it, but a few things have frustrated me about it, too.
Perhaps it's unusual, but I really like it BECAUSE it's like XSLT, and I don't mind at
all that it's not like Java. The things I don't
Jorg Heymans wrote:
2)Should any effort towards documentation ATM go into improving its
*quality* or improving its
{searchability|updateability|scaleability|auto-generateability}
WDYT?
Personally, I think that Cocoon has a lot of good documentation, but
poorly/inconsistently organised.
the URL: http://svn.apache.org/
The following error was encountered:
* Zero Sized Reply
Squid did not receive any data for this request.
--
Conal Tuohy
/branches/BRANCH_2_1_X
Conal Tuohy wrote:
I can't access the SVN repository at http://svn.apache.org/
- or am I looking in the wrong place?
I'm accessing it through a proxy, so it's hard to say
exactly what happens, but my proxy reports a zero-length response:
ERROR
The requested URL
Pier Fumagalli wrote:
I was thinking about one thing... The one thing that troubles
us is the
request. That introduce a degree of variability that (i
don't know to
what degree), might be counter-productive to analyze and cache...
What about if we were doing subrequests, much like in
Antonio Fiol Bonnin wrote:
Thank you, Con, for your very interesting point of view. We were
working on (a) but I have told my team that we will be changing
approach in one hour if they do not see a clear end.
Other than that, I will look into pdftohtml (is it really html?).
Stefano Mazzocchi wrote:
What about using XSL:FO? Would be pretty cool to have the ability to
transform PDF into FO, basically reversing what FOP does. I know it
would be pretty painful to make it work with all kinds of
PDF, but for
reasonable ones it shouldn't be that hard (PDF is sort of a
Antonio Fiol Bonnín wrote:
a) Refactoring SimpleLuceneXMLIndexerImpl so that its private method
indexDocument is not private, and taking it to an external component.
b) Creating a PDFGenerator (in the cocoon sense of generator,
of course).
Option (a) seems to be giving us more headaches
Jorg Heymans wrote:
Recently there were 2 requests on the users list about accessing the
current pipeline structure.
snip/
Having this extra metadata would allow for components that
can produce
different output depending on how they are used in a pipeline
(but this
probably breaks a
-Original Message-
From: Leszek Gawron [mailto:[EMAIL PROTECTED]
assume you have a collection of Projects. Each project has a
project.description property. This property contains a string
that can
be parsed by a wiki parser and generate html out of it. How would you
implement
-Original Message-
From: Leszek Gawron
My question is: why do you call a wiki parser a model
aspect if in my
example I have to pass it for EVERY model? It looks more like a view
plugin really.
Where should you draw the line between model and view?
In the case of JXTG, it is
Peter Hunsberger wrote:
As others have said, one needs to step back and look at the overall
objective: what do you want Cocoon to do when you feed it a request
(either via http or CLI or whatever)? Figure out all the
high level use
cases and their interactions, step back, generalize and
Stefano wrote:
Conal Tuohy wrote:
It's [XML sitemap syntax] also potentially useful for validation.
Nop, wrong. There is no XMl validation language that can tell
you if the
sitemap is valid from a cocoon-logic point of view (for
example there
is no class file name datatype
Stefano Mazzocchi wrote:
without java and flow, the sitemap is far from being turing complete.
Well ... this is getting off the topic of the thread, but actually I
don't think is true. Maybe you are forgetting that you have recursion
with the cocoon: protcol. With URI matchers and selectors I
Stefano wrote:
The XML syntax makes sense only when you want to process the sitemap
iteself via pipeline (for example, to generate an SVG poster
of it via XSLT)
And makes sense if you want to prevent people from adding scripting
inside the pipelines (well, actions are kinda like
Carsten Ziegeler wrote:
A long time
ago, we agreed that if we change the sitemap syntax, we will
change the
version number of the sitemap namespace.
Is it really necessary to change the xml namespace? How does this help
developers?
If it's just a matter of being able to identify the version
Dave Brondsema wrote:
Note: the regex used in the 'spacify' template doesn't work.
How can I make the
replace() function work? Since it gives an error about the
function not being
found, I haven't tested the regex either: it's supposed to
put a space in before
capital letters (except for
Dave Brondsema wrote:
Note: the regex used in the 'spacify' template doesn't work.
How can I make the
replace() function work? Since it gives an error about the
function not being
found, I haven't tested the regex either: it's supposed to
put a space in before
capital letters (except for
Dave Brondsema wrote:
Note: the regex used in the 'spacify' template doesn't work.
How can I make the
replace() function work? Since it gives an error about the
function not being
found, I haven't tested the regex either: it's supposed to
put a space in before
capital letters (except for
On Sat, Apr 24, 2004 at 04:51:35PM -0700, Christopher Oliver wrote:
foo
jx:attribute name=bar namespace=http://www.bar.org;
value=${bar}/
jx:if test={$fubaz 1}
jx:attribute name=xyz value=100/
/jx:if
jx:forEach var=item items=${items}/
jx:attribute
I agree with Antonio about the utility of @author tags (I have also found them very
useful), and I also think that the ASF board's concerns about the dangers of
ownership are probably overblown.
I don't think the ASF should discourage developers from keeping useful metadata about
the code
I don't know if you can configure the xml serializer to drop a namespace
(seems unlikely, because such namespace might not be used until the end of
the document, for all the serializer knows, so it wouldn't be safe without
buffering the entire output document to check).
But typically you should
:18
To: [EMAIL PROTECTED]
Subject: Re: Cleaning up unused namespace declaration
On 8 Feb 2004, at 21:37, Conal Tuohy wrote:
I don't know if you can configure the xml serializer to drop a
namespace
(seems unlikely, because such namespace might not be used until the
end
Stefano Mazzocchi wrote:
snip/
I think that the ESQL logicsheet is the only really valuable and
unique thing that we have in XSP, so, yeah, I totally
understand your
concern.
Ryan Hoegg wrote:
Why not pull the ESQL stuff out and provide a stripped down
ESQLTransformer?
I haven't
Hi Sylvain
I've checked out your new attempt docnbsp.xsl and compared with the other
approaches in the text-wrap sample.
Your attempt is definitely superior to the current approach (no special
handling in the sample) implemented by raw.xsl, which uses just HTML pre.
The raw.xsl often leads to
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Saturday, 15 November 2003 04:57
To: [EMAIL PROTECTED]
Subject: Another attempt at wrapping code lines
snip/
I tried to find a CSS trick to add a mark at the beginning of a
continuation line, but CSS only has
First I want to say thanks to David for putting the text-wrap sample
together.
--- Additional Comments From [EMAIL PROTECTED]
2003-11-09 01:58 ---
Sorry for being destructive, but I do not see a real problem.
Or better said
this problem resulting from trying to handle all types of
Konstantin Piroumian wrote:
Had a look at the updated Cocoon site and it is great to see
that the layout
is now displayed correctly in IE.
Though, I don't quite understand why the left menu is still
that overcrowded
while we have a nice possibility in Forrest to group related
items into
Stefano wrote:
automatic harvesting scares the crap out of me, Conal.
This is conceptually no different to harvesting JavaDoc tags from Java
source.
I agree that there must be some kind of automatism going on, but the
topic creation is a human task and programs would do a
terrible job at
Nicola Ken Barozzi wrote:
We will probably be moving the Forrest DTD to XHTML2 in one
of the next
things to do. As you know, there are meta tags that are a
nice way of
adding additional info in the page.
http://academ.hvcc.edu/~kantopet/xhtml/index.php?page=xhtml+me
ta+content
Stefano Mazzocchi wrote:
I agree that there must be some kind of automatism going
on, but the
topic creation is a human task and programs would do a
terrible job at
doing this.
The example I gave assumed precisely that a human editor
had written a
namespace topic; the harvester
Bertrand Delacretaz wrote:
Some form of topic map would be useful to build what's
related info
though, which helps navigation and discovery a lot.
Stefano Mazzocchi wrote:
Yes, but such a topic maps would have to be human edited.
this is what
scares me. tools for ontology creation (like
Hi Alfred
Alfred Fuchs wrote:
Conal Tuohy wrote:
[...] Alternatively, if it really is necessary to call back
another pipeline, what about using a generic transformer like the
XIncludeTransformer?
I will explain, what I want to do:
(1) I have a website with a topic actual
Alfred Fuchs wrote:
in my expamle I extract the title of a HTML page in this way:
if title exist and title not empty, use it as title.
otherwise use the first h1 etc...
this is logic, simply done in a xslt, but hoe to do this in
a single xpath-query?
Rogier Peters wrote:
snip/
Googleing xml and relations quickly brought me another subject that I
haven't seen discussed much here - XML topic maps. On of the big
advantages of topic maps over my simple mapping is the amount of
semantics that topic maps allow. Topic maps allow one thing to be
Peter Hunsberger wrote:
Conal Tuohy [EMAIL PROTECTED] wrote:
string(/html/head/title[normalize-space()]|/html/body//h1[1])
The string() function returns the string value of the FIRST
NODE in the resulting nodeset.
Ahh, that would do the trick. I believe in some old implementations
Sylvain Wallez wrote:
Relating this to the newly introduced virtual components, we can
consider the view definition as a virtual serializer.
Example :
map:serializers
map:serializer type=xml src=oacs.XMLSerializer/
map:serializer type=pretty-xml
map:transform type=xslt
Stefano wrote:
If I have a resource like
http://blah.com/news/
and I want to edit, I could ask for
http://blah.com:/news/
http://edit.blah.com/news/
http://blah.com/news/?view=edit;
which are all 'orthogonal' ways of asking a different view
of the same
resource
Carsten wrote:
After the last changes to LuceneIndexTransformer, a fragment
of the code looks like this:
if (analyzerClassname == null)
analyzerClassname = this.analyzerClassname;
String sMergeFactor =
Stephan Michels wrote:
map:pipeline
[...]
map:continue type=petshop id={1}/
[...]
/map:pipeline
I think it's a potential source of confusion to have id attributes which
are not of type ID (i.e. they are not unique identifiers of elements in the
sitemap). Of course, I realise that id is
Marc Portier wrote:
The following might seem like nagging but I do share Sylvain's
eagerness to get names really right, so I'm wide open for other
alternatives and views...
I don't have a vote either :-) but I agree - names are a very important detail, so
I'll stick my nose in...
[C] A
54 matches
Mail list logo
