Re: [2.2] Simplifying configuration
Some thoughts (my opinion) about configuration. 1. Environment-related configuration should be banned inside the webapp directory (or WAR file). 2. Business-related configuration should be inside it. Developing it a little more you will see why I state that. a. The developer of an application (cocoon-based or any other) does not necessarily know about the production environment things like: - Host names and ports - Paths - Timeouts required (e.g by firewalls closing connections) or configured in other applications - Memory sizes - JVM parametrization b. The system administrator knows all of the above. c. Some of the above might have sensible defaults, which the developer knows. d. The developer usually knows the right values for business-related configuration. e. The system administrator does not know about business-related configuration, but... f. The system administrator could be asked to change some business-related configuration. For that, in our company we developed a simple component based on Commons Configuration and a policy for developers that solves all a-e points. There are basically two configuration sources: one of them supplied by the developer and one of them supplied by the administrator. The first one is, in our case, a XML file inside the WAR file, and the second one is the JNDI environment. We use Tomcat, so the JNDI environment is very easy to setup, i.e. you only have to add Environment ... / entries in the context XML file. It is probably quite difficult to achieve (a) to (e) for Cocoon, given the complexity of the configuration. But... wait! Most of it is business configuration. So... only non-business would need to be extracted to another configuration source. WDYT? -- Antonio
Re: Resurrecting COCOON-1066
2006/2/8, Jean-Baptiste Quenot [EMAIL PROTECTED]: As far as my LDAP knowledge goes, the DN is an entry identifier. Usually identifiers appear as attributes, so this is a good idea. OK. I'll start working on this. -- Antonio
Re: Resurrecting COCOON-1066
2006/2/9, Antonio Fiol Bonnín [EMAIL PROTECTED]: 2006/2/8, Jean-Baptiste Quenot [EMAIL PROTECTED]: As far as my LDAP knowledge goes, the DN is an entry identifier. Usually identifiers appear as attributes, so this is a good idea. OK. I'll start working on this. Done. Patch is uploaded on the bug page on Jira: http://issues.apache.org/jira/secure/attachment/12322783/LDAPTransformer.java.patch -- Antonio
Re: Resurrecting COCOON-1066
Is it better to output the DN as a XML element or as a XML attribute? WDYT? I personally prefer it as an XML attribute, as it is something a bit different from LDAP attributes (and that's probably why you can't simply specify an ldap:attributedn/ldap:attribute). The original poster patch added the DN as an XML element. -- Antonio 2006/2/8, Jean-Baptiste Quenot [EMAIL PROTECTED]: * Antonio Fiol Bonnín: I would be more than happy to: - create a new patch with the relevant parts of the original one Yes, please do it. I reopened https://issues.apache.org/jira/browse/COCOON-1066 -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Ajax and UTF-8 not working
Hello, I have made every possible attempt I can think of to make Ajax work in a UTF-8 environment. It plainly does not. I set form-encoding to UTF-8. HTML serializer is configured as follows: map:serializer logger=sitemap.serializer.html mime-type=text/html name=html4 pool-grow=4 pool-max=32 pool-min=4 src=org.apache.cocoon.serialization.HTMLSerializer doctype-public-//W3C//DTD HTML 4.01 Transitional//EN/doctype-public doctype-systemhttp://www.w3.org/TR/html4/loose.dtd/doctype-system encodingUTF-8/encoding /map:serializer The rest is done like in http://cocoon.apache.org/2.1/userdocs/ajax.html, i.e. ft:form-template ... ajax=true Use ft:repeater instead of ft:repeater-widget map:transform type=browser-update/ ... map:select type=ajax-request map:when test=true map:serialize type=xml/ /map:when map:otherwise map:serialize type=html4/ /map:otherwise /map:select The first page comes out well, but as soon as an ajax update for the repeater is received, all the accented characters go into a strange thing, and on the second round-trip, they get converted to a plain question mark ?. (Firefox browser) Disabling Ajax (removing ajax=true) makes the form work perfectly. I tried to change the serializer and try a o.a.c.components.serializers.XHTMLSerializer, and after changing the JVM default encoding to UTF-8, I got some javascript errors complaining about quot; in the middle of Javascript code. I am sure at least Sylvain must have tested this thoroughly, so I can't understand what is happening. Any ideas? -- Antonio
Resurrecting COCOON-1066
Hello, COCOON-1066 [1] was closed as duplicate because half of the description was somehow a duplicate of COCOON-1707 [2]. However, this only applied to a part of the issue, and COCOON-1707 is still open. The other part of the issue was ignored because noone else commented on it. This part is the one I would like to resurrect. dn-element: Provide element containing the DN for each entry returned in 'execute-query'. This is accomplished via 'dn-element' element that defaults to 'dn'. This element is only valid in 'execute-query'. In our application, we also need to know the DN for each entry returned in 'execute-query'. I had neglected to search Jira for it, and implemented a patch that creates a dn attribute on every entry received. It is very similar to the relevant part of the patch sent by the poster, only our patch - does not allow you to deactivate the feature (dn attribute is always on the output) - does not allow you to configure the attribute name (dn is always used) - it is an attribute and not an element I would be more than happy to: - create a new patch with the relevant parts of the original one - see one patch or the other integrated into Cocoon 2.1.9 if possible Thank you very much. [1] http://issues.apache.org/jira/browse/COCOON-1066?page=all [2] http://issues.apache.org/jira/browse/COCOON-1707?page=all -- Antonio Fiol
Re: Planning 2.2
2005/11/24, Pier Fumagalli [EMAIL PROTECTED]:
On 23 Nov 2005, at 21:34, Joerg Heinicke wrote:
On 23.11.2005 16:33, Antonio Fiol Bonnín wrote:
This can't possibly be what we need, as anyone would have done it
faster than me, but anyway, here it goes.
IIRC the problem was not the pure removal, but the mentioning of
the authors in a contrib file file.
svn blame http://svnbook.red-bean.com/en/1.0/re02.html
So, if I understood correctly, you would like to extract the history
of authors for every file:
#!/bin/bash
for i in $(find . -type f -not -name '*.svn-' | grep -v /\\.svn/)
do
echo $i
svn blame $i | awk '{print $2}' | sort | uniq
echo
done
But I find it hard to do it in a platform-independent way.
And if someone submits a patch, we can track the contribution in Jira.
I don't understand how this should work.
--
Antonio
Re: Contributors (was Re: Planning 2.2)
2005/11/25, Upayavira [EMAIL PROTECTED]:
Antonio Fiol Bonnín wrote:
2005/11/24, Pier Fumagalli [EMAIL PROTECTED]:
On 23 Nov 2005, at 21:34, Joerg Heinicke wrote:
On 23.11.2005 16:33, Antonio Fiol Bonnín wrote:
This can't possibly be what we need, as anyone would have done it
faster than me, but anyway, here it goes.
IIRC the problem was not the pure removal, but the mentioning of
the authors in a contrib file file.
svn blame http://svnbook.red-bean.com/en/1.0/re02.html
So, if I understood correctly, you would like to extract the history
of authors for every file:
#!/bin/bash
for i in $(find . -type f -not -name '*.svn-' | grep -v /\\.svn/)
do
echo $i
svn blame $i | awk '{print $2}' | sort | uniq
echo
done
But I find it hard to do it in a platform-independent way.
Well,
(a) I'm impressed with your little script
(b) it doesn't need to be platform independent - it will only be run
once.
(c) Actually, I wonder if this is something of a redherring. All it
will show us is the committers who have committed to CVS or SVN.
But we know that already. What we want to know is who has
contributed other than committers.
And if someone submits a patch, we can track the contribution in Jira.
I don't understand how this should work.
Well, we can use Jira to note contributions, and then manually copy them
into our contribution records. I imagine that is what Pier means.
Regards, Upayavira
I had missed the related ongoing thread (Re: author tags) when I sent
the e-mail with the script. It says basically the same as (c), that
is, that the committers are not the important info to gather. Even
some previous discussion (2004 to mid 2005) about the issue is
mentioned.
So I'm basically lost (again).
But thank you very much for your feedback...
I will try to get things clearer on the other thread.
--
Antonio
Re: Performances analysis
2005/11/25, Jean-Christophe Kermagoret [EMAIL PROTECTED]: Hello, I'm working on performances for the application of a client. And it's a little difficult to know which direction to take. I would like to define performance test guidelines that would permit to every cocoon developer to test its application and drive easily its own test. I read almost all the thread and documentation about performances, but I just found a few tips (and it's already a good thing). What I want is to analyze the cocoon code, and in more details, the cocoon portal block. To conclude, and because it's a reccurent question, I will create a wiki with all the information I will get here. Is there anybody that has already profiled Cocoon with JProfiler and JProbe. Are the results interesting ? What are the tools' limits ? Finally, what I'm looking for is a tool that will show me how many times a method is called, and how much it consumed. In a very naive approach, a simple log in each method would be helpful. A few times ago, somebody talked about AOP, have you heard about this thread ? I heard about JMX too, when people were thinking about removing instrumentation from 2.2. Has it been developed ? Thanks for all the tips. Hi, We're about to go live with our first important cocoon application. We created some JMeter tests and tested the scalability and stability of our webapp. Much like we do with other webapps, not cocoon based. We start with 1 JMeter thread (no thinking delays) and go up to as many threads as we need to reach our maximum defined mean response time for any request. This way, and with some statistics or load estimations based on previous experiences, we can see how well our apps scale. For stability, we simply set a certain load (usually 1-4 JMeter threads), and monitor some health params during a test which lasts a 6+ hours. Specifically about cocoon, I can only confirm that caching is a real must if you care about performance at all. Cache as many things as possible... and even more. For example, we had trouble because we are using the LDAP transformer, which is not cachable. We ended up storing the (xslt-transformed) LDAP results in a file, and updating them periodically in the background, so caching mechanisms are effective. Maybe there are better options, but this one worked for us. It's a completely different approach from yours, but I sincerely HTH, -- Antonio
Re: Planning 2.2
- Remove author tags +1, but who does it? Do we want to split the blocks among ourselves, or does anyone have enough time to do it all? This looks quite simple. Tedious but simple. If someone could explain exactly what to do (private e-mail is OK), it would be a way for me to make a first code contribution to cocoon. However, I would only be able to create a patch, that some committer would have to commit. Is that OK? -- Antonio
Re: Planning 2.2
2005/11/23, Sylvain Wallez [EMAIL PROTECTED]: Antonio Fiol Bonnín wrote: - Remove author tags +1, but who does it? Do we want to split the blocks among ourselves, or does anyone have enough time to do it all? This looks quite simple. Tedious but simple. If someone could explain exactly what to do (private e-mail is OK), it would be a way for me to make a first code contribution to cocoon. However, I would only be able to create a patch, that some committer would have to commit. Is that OK? IMO it would be better to contribute a script that automates this process. That would avoid both a giant patch and some potential merge problems if the code changes while you're removing the tags. My 0.02 euros... Sylvain You're right... If what we need is removing all @author tags in all javadoc on all .java files, and it is easily done (in an ant script): replaceregexp byline=true regexp pattern=\*([EMAIL PROTECTED])/ substitution expression=*/ fileset dir=. includes=**/*.java / /replaceregexp This can't possibly be what we need, as anyone would have done it faster than me, but anyway, here it goes. -- Antonio
Re: Planning 2.2
2005/11/23, Antonio Fiol Bonnín [EMAIL PROTECTED]: 2005/11/23, Sylvain Wallez [EMAIL PROTECTED]: Antonio Fiol Bonnín wrote: - Remove author tags +1, but who does it? Do we want to split the blocks among ourselves, or does anyone have enough time to do it all? This looks quite simple. Tedious but simple. If someone could explain exactly what to do (private e-mail is OK), it would be a way for me to make a first code contribution to cocoon. However, I would only be able to create a patch, that some committer would have to commit. Is that OK? IMO it would be better to contribute a script that automates this process. That would avoid both a giant patch and some potential merge problems if the code changes while you're removing the tags. My 0.02 euros... Sylvain You're right... If what we need is removing all @author tags in all javadoc on all .java files, and it is easily done (in an ant script): replaceregexp byline=true regexp pattern=\*([EMAIL PROTECTED])/ substitution expression=*/ fileset dir=. includes=**/*.java / /replaceregexp This can't possibly be what we need, as anyone would have done it faster than me, but anyway, here it goes. Please note it leaves the * at the beginning of the line (so it leaves a blank javadoc line). -- Antonio
Re: Help! Redirect to cocoon:/ always redirects to root sitemap
Try using src=./flow.xmap
It worked for me, and I sent an e-mail on that some time ago (I use 2.1.7).
--
Antonio
2005/11/23, Rob Berens [EMAIL PROTECTED]:
I just ported our application from cocoon 2.1.6 to 2.1.8.
Most things work fine, there only seems to be a problem with the cocoon:
protocol.
My root sitemap called sitemap.xmap contains the following fragment:
map:match pattern=flow/**
map:mount src=flow.xmap uri-prefix= check-reload=true
reload-method=synchron/
/map:match
So if a uri starts with flow, it is offered to the flow.xmap, which does
the following:
map:pipeline
map:match pattern=flow/*/**
map:redirect-to uri=cocoon:/{1}/flow/{2}/
/map:match
/map:pipeline
I.e. it swaps the first two components in the uri and redirects to itself.
(Some background: we have divided our webapp in publications which can be
recognized by te first name in the uri, flow is used to identify internal
requests originating from flow script (sendPage) and therefore we swap in
order to have the publication name in front again).
This worked with 2.1.6, but with 2.1.8 the redirect is done to the root
sitemap.xmap i.s.o. the current flow.xmap as can be seen from this fragment
of the sitemap log file:
DEBUG (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/PreparableMatchNode: Matcher 'wildcard' matched prepared
pattern 'flow/*/**' at map:match -
file:/C:/OsrDev/xenopsis/build/webapp/flow.xmap:61:38
DEBUG (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/InvokeContext:
Current Sitemap Parameters:
LEVEL 1
PARAM: '2' VALUE: 'portal/index.html'
PARAM: '0' VALUE: 'flow/xenopsis/portal/index.html'
PARAM: '1' VALUE: 'xenopsis'
INFO (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/RedirectToURINode: Redirecting to
'cocoon:/xenopsis/flow/portal/index.html' at map:redirect-to -
file:/C:/OsrDev/xenopsis/build/webapp/flow.xmap:62:54
INFO (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/ForwardRedirector: Redirecting to
'cocoon:/xenopsis/flow/portal/index.html'
DEBUG (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/EnvironmentWrapper: Setting uri (prefix=null,
uris=xenopsis/flow/portal/index.html)
DEBUG (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/PreparableMatchNode: Matcher 'wildcard' matched prepared
pattern '**' at map:match -
file:/C:/OsrDev/xenopsis/build/webapp/sitemap.xmap:258:31
DEBUG (2005-11-23) 17:17.52:125 [sitemap] (/xenopsis/portal/index.html)
PoolThread-4/InvokeContext:
Current Sitemap Parameters:
LEVEL 2
PARAM: '0' VALUE: 'xenopsis/flow/portal/index.html'
PARAM: '1' VALUE: 'xenopsis/flow/portal/index.html'
LEVEL 1
PARAM: '../2' VALUE: 'portal/index.html'
PARAM: '../0' VALUE: 'flow/xenopsis/portal/index.html'
PARAM: '../1' VALUE: 'xenopsis'
I observed the same behaviour for uri's used in sendPage and not starting
with a '/'. They were also redirected to the root sitemap.
I didn't make any modifications in our sitemaps or in our java scripts
during the port. They have been ported unchanged from 2.1.6 to 2.1.8.
What am I doing wrong? Or is this a bug?
Rob Berens
Osirion B.V.
The Netherlands
E-mail: [EMAIL PROTECTED]
--
Antonio
Re: Strange caching issue: need to reload twice
2005/11/3, Sylvain Wallez [EMAIL PROTECTED]:
Hmm... could this be related to the refresh delay of the directory
generator[1]?
What happens if you add map:parameter name=refreshDelay value=0/
in the generate type=directory ?
Sylvain, we tested value=0, and got the same effect.
Going slightly further, we tried with value=-1, and amazingly
enough, it worked.
AFAICS, this must be a bug somewhere, as Cocoon is not refreshing at
the first attempt even after an amount of time far longer than one
second (except with value=-1). We have little knowledge on Cocoon
internals, but we were looking into the DirectoryGenerator (and
DirValidity) and found nothing strange.
Hello,
I finally found something strange in DirectoryGenerator that could
explain the bug. In DirValidity we added some traces:
public int isValid() {
if (System.currentTimeMillis() = expiry) {
logger.debug(this + : isValid() == 1 (not expired));
return 1;
}
expiry = System.currentTimeMillis() + delay; /* *
SHOULD THIS LINE BE REMOVED? !!! * */
int len = files.size();
for (int i = 0; i len; i++) {
File f = (File)files.get(i);
if (!f.exists()) {
logger.debug(this + : isValid() == -1 (file
+f+ removed));
return -1; // File was removed
}
long oldDate = ((Long)fileDates.get(i)).longValue();
long newDate = f.lastModified();
if (oldDate != newDate) {
logger.debug(this + : isValid() == -1 (different
dates for +f+: +oldDate+!=+newDate+));
return -1;
}
}
// all content is up to date: update the expiry date
expiry = System.currentTimeMillis() + delay;
logger.debug(this + : isValid() == 1 (all valid));
return 1;
}
I think the tagged line should be removed. I can't see why it is
there, and I think it is responsible for the harm. When reloading
after changing a file, we get:
[sitemap.generator.directory]
[EMAIL PROTECTED]
Expiry: 1131363743861 - Delay: 1000: isValid() == -1 (different dates
for /home/fiol/ficheros-intranet/compartido/paginas/actualidad/resumen-noticias:
1131037742000!=1131363738000)
[sitemap.generator.directory]
[EMAIL PROTECTED]
Expiry: 1131363743861 - Delay: 1000: isValid() == 1 (not expired)
So apparently isValid is called twice, with inconsistent results
(first is OK, second is wrong, unless *I* am wrong ;-).
Aside from that, is the recycle method called before calling
generate() if cache is invalid? Supposing it is not, how is the
DirValidity refreshed with new files? More specifically, how are old
ones removed? There is no point in the code where this.validity is
made null other than the recycle method.
As I told you, I know very little about Cocoon internals, but there
seems to be something broken here.
--
Antonio
Re: [Vote] Releasing on friday
2005/11/3, Pier Fumagalli [EMAIL PROTECTED]: On 3 Nov 2005, at 05:47, Carsten Ziegeler wrote: Please cast your votes for releasing 2.1.8 on friday, 4th of November. (if we vote to not release on friday, I can do the release on any day in the next week). What about these three issues targeted for 2.1.8 ??? http://issues.apache.org/jira/secure/IssueNavigator.jspa? pid=12310170resolution=-1fixfor=12310601sorter/ field=issuekeysorter/order=DESCtempMax=25reset=true Unfortunately I'm under deadline and have no time to dig into them ATM. I could not access JIRA (Bad Gateway), but I am about to open a JIRA ticket concerning a caching issue which is quite important (a.k.a. release-critical) for the project I am working on. I do not know if it is critical for Cocoon, possibly not, as it is already present in 2.1.7. But it would be nice if a knowledgeable Cocoon developer looked quickly into the issue to check if it is important for Cocoon or not or if I am doing something obviously wrong. (Big thanks!!) The post describing the issue is on the users list, archived on http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=113102299909051w=2 Thank you in advance. -- Antonio
Re: [RT] seven good reasons to close down users@cocoon.apache.org
In my experience, it doesn't matter which list I ask for help on, it still gets ignored. That sounds really frustrated.Sorry about that. My experience (although probably not objectively realistic, and biased by bad experiences) is that my first request for help is usually answered, even by a few people, but without fully solving the problem (blame me: my first post contains most certainly insufficient information), and the second round is unanswered. So I usually get insightful answers which help me continue my research (good), but that does not necessarily means the problem is solved (bad). At most, what I tend to get is a kind of workaround (not too bad, but could be better). Maybe it just did not ringa bell when people read it. That's the strange point about my feeling. It seems to ring the bell the first time, but not loud enough to follow up. In the end it probably comesdown to how much time a developercan spend on tracking down the bug you are seeing.If you can reduce that timeyou are more likely to get ananswer. I try, but it is not always easy, if you don't have enough knowledge about internals. OTOH, I know many users (myself included) seldom try to help others, probably because of lack of time. But if users don't have time, why should developers?-- Antonio
Fwd: document(...) broken when using xsltc
Hello,
I have not reveived any useful tips from the users mailing lists. As
this might be a cocoon bug, or else a XSLTC bug, I am forwarding this
to [EMAIL PROTECTED]
Can anyone please help me find if there is a problem in my XSLT code or
point me to somewhere to look for and try to repair the bug in cocoon
or XSLTC.
Thank you very much.
--
Antonio Fiol-- Forwarded message --From: Antonio Fiol Bonnín [EMAIL PROTECTED]
Date: 28-jul-2005 9:32Subject: Re: document(...) broken when using xsltcTo: users@cocoon.apache.org2005/7/27, Joerg Heinicke
[EMAIL PROTECTED]:
On 27.07.2005 15:54, Antonio Fiol Bonnín wrote: I have been changing my transforms to execute with XSLTC instead of interpreted Xalan. However, some of them did not work properly, showing erratic behaviour, or even throwing NullPointerException.
In most cases (if not all), I have tracked the problem to usage of the document() function to get information from another source document. When this function is used, the context node is lost, and thus strange things
happen. When I say the context node is lost, I mean that AFTER the call to document(): - any xpath expressions I've tried lead to erratic behaviour AND - in some cases, the flow of pattern applying gets wrong (usually aborting
an apply-templates before applying to all the selected elements, and possibly adding spurious non-empty text nodes on the output). Has anyone also found this problem? If so, is there another solution apart
from not using document() or not using xsltc? Is it a xsltc bug, a cocoon bug or not a bug at all?Are you sure you have only retrieved a node using document() and notswitched the context to the other document?
Well, I think so...
This is one of the failing templates:
xsl:template match=* mode=cell
xsl:variable name=nombrehtml:xsl:value-of select=name()//xsl:variable
xsl:choose
xsl:when test=document('')/xsl:stylesheet/xsl:template[contains(@match,$nombre) and @mode='inline']
xsl:apply-templates select=. mode=inline/
/xsl:when
xsl:otherwise
xsl:apply-templates select=. mode=block/
/xsl:otherwise
/xsl:choose
/xsl:template
The intention of this template is doing a sort of reflection upon the
stylesheet. Adding e.g. an xsl:comment before both
xsl:apply-templates shows that the right
xsl:apply-templates is executed. However, it is executed
against the xsl:apply-templates element itself!! which is not
the intended behaviour.
In a particular case (which I have not been able to track down to a simple example), it even leads to a NullPointerException.
Re: [CForms] Stylesheets incompatible with Saxon 8
2) we keep the change and we advise people to use a wrapper stylesheet that declares the parameter ... not ideal. I don't know how many people use individualstylesheets directly, but I suspect it's quite a few. Hi, I'd suggest keeping the change, creating different XSL files, and providing the wrapper stylesheets in files with the same names the real ones used to have. This way, it would be backwards compatible and the problem would be fixed. -- Antonio
Suggestion for XHTMLSerializer
Hello, I am finding a problem with empty elements when serving content with the text/html content type on Firefox. For example, collapsed empty div elements cause havoc in firefox. A possible workaround would be implementing the compatibility guidelines indicated in the W3C recommendations. In particular, I would add the same check already present for style, script and textarea for any element whose end tag is required in HTML 4.01. Would a patch for this be welcome? Yours, -- Antonio
Re: Suggestion for XHTMLSerializer
Maybe I read the code the wrong way. What I understood was:
public void endElementImpl(String uri, String local, String qual) throws SAXException {
[...]
if (XHTML1_NAMESPACE.equals(uri)) {
if ((local.equalsIgnoreCase(textarea)) ||
(local.equalsIgnoreCase(script)) ||
(local.equalsIgnoreCase(style))) {
this.closeElement(false); // This line should cause the [script] to
become [script]
} else if (local.equalsIgnoreCase(head)) {
[...]
}
}
super.endElementImpl(uri,
local, qual); // And thus this line should close the element with
[/script]
}
So my proposal would be to add a line like
(local.equalsIgnoreCase(div)) ||
for each element that should share this behaviour.
BTW, the source I am looking at is the one in Cocoon 2.1.7. I
checked on
http://svn.apache.org/repos/asf/cocoon/blocks/serializers/trunk/java/org/apache/cocoon/components/serializers/XHTMLSerializer.java
and the relevant part of the code is the same.
--
Antonio
2005/8/2, Kees Broenink [EMAIL PROTECTED]:
Hello,Adding to this is an issue with IE and the script tag. I did notsearch the mail archive nor bugzilla, so maybe it is already addressedfor the next release.The xhtml serializer will change
script type=text/_javascript_ src="">intoscript type=text/_javascript_ src="">This will break loading the JS in IE.
Kees-Oorspronkelijk bericht-----Van: Antonio Fiol Bonnín [mailto:[EMAIL PROTECTED]]Verzonden: Tuesday, August 02, 2005 11:26 AMAan:
dev@cocoon.apache.orgOnderwerp: Suggestion for XHTMLSerializerHello,I am finding a problem with empty elements when serving content with thetext/html content type on Firefox. For example, collapsed empty div
elements cause havoc in firefox. A possible workaround would beimplementing the compatibility guidelines indicated in the W3Crecommendations.In particular, I would add the same check already present for style,
script and textarea for any element whose end tag is required in HTML4.01.Would a patch for this be welcome?Yours,--Antonio
Posting unanswered issues from users
Hello, I know that for users issues, there is a users list, and I posted there before. However, a few issues remained unanswered and, even if I have found workarounds for my case, I think developers should be aware of them. Please forgive me if I should not be posting here. Posts follow...-- Antonio
Fwd: REPOST: row-actions move-up and move-down not working
The reason I think developers should know about this is:
- move-up and move-down seemed to move rows up and down on the form, but changes in the order of rows were not saved to XML.
- Even binding a field called order to the position brought in
strange results, as the move-up and move-down made the unmapped parts
of the XML to be swapped. See the following example for the meaning of
this:
a
b order=1
boundabc/bound
unbound
unbound-child id=1 //unbound
/b
b order=2
bounddef/bound
unbound
unbound child id=2 /
/unbound
/b
/a
desired effect is:
a
b order=1
bounddef/bound
unbound
unbound child id=2 /
/unbound
/b
b order=2
boundabc/bound
unbound
unbound-child id=1 /
/unbound
/b
/a
or maybe the following could be acceptable, as I can later sort by @order:
a
b order=2
boundabc/bound
unbound
unbound-child id=1 /
/unbound
/b
b order=1
boundabc/bound
unbound
unbound child id=2 /
/unbound
/b
/a
But definitely not:
a
b order=1
bounddef/bound
unbound
unbound-child id=1 /!-- This corresponds to abc, not def !!! --
/unbound
/b
b order=2
boundabc/bound
unbound
unbound child id=2 /!-- This corresponds to abc, not def !!! --
/unbound
/b
/a
Hope
-- Forwarded message --From: Antonio Fiol Bonnín
[EMAIL PROTECTED]
Date: 27-jun-2005 10:24Subject: move-up and move-down not workingTo: users@cocoon.apache.org
Hello,
I am using a repeater with move-up and move-down row-action buttons.
Adding, deleting, and modifying works perfectly. move-up and move-down do not work.
Can anyone help me track the problem down?
Note: The componentes empty element is filled with persona elements
by another form. The other elements on the empty grupo template are
mapped to the fields I removed for simplicity.
Thank you very much.-- Antonio
---
definition:
fd:form xmlns:fd=http://apache.org/cocoon/forms/1.0#definition xmlns:xi=
http://www.w3.org/2001/XInclude
fd:widgets
fd:repeater id=grupos
fd:widgets
fd:output id=id
fd:datatype base=long /
/fd:output
fd:field id=nombre required=true
fd:labelNombre/fd:label
fd:datatype base=string/
fd:validation
fd:length min=2 /
/fd:validation
/fd:field
!-- Several other fields --
fd:booleanfield id=select
fd:labelSel./fd:label
/fd:booleanfield
fd:row-action id=subir action-command=move-up
fd:labelSubir/fd:label
/fd:row-action
fd:row-action id=bajar action-command=move-down
fd:labelBajar/fd:label
/fd:row-action
/fd:widgets
/fd:repeater
fd:repeater-action id=addgrupo action-command=add-row repeater=grupos
fd:labelAñadir grupo/fd:label
/fd:repeater-action
fd:repeater-action id=delgrupo action-command=delete-rows repeater=grupos select=select
fd:labelEliminar grupos seleccionadas/fd:label
/fd:repeater-action
/fd:widgets
/fd:form
-
binding:
fb:context
xmlns:fb=http://apache.org/cocoon/forms/1.0#binding
xmlns:fd=http://apache.org/cocoon/forms/1.0#definition
path=/
fb:repeater id=grupos
parent-path=grupos
row-path=grupo
fb:identity
fb:value id=id path=@id
fd:convertor datatype=long /
/fb:value
/fb:identity
fb:on-bind
fb:value id=id path=@id direction=load
fd:convertor datatype=long /
/fb:value
fb:_javascript_ id=id path=@id direction=save
fb:save-form
var formValue = widget.getValue();
if(formValue 0) {
jxpathPointer.setValue(formValue);
} else {
jxpathPointer.setValue(new
Packages.java.lang.Long(Packages.java.lang.System.currentTimeMillis()).toString());
Packages.java.lang.Thread.sleep(5); // Garantiza que
System.currentTimeMillis() sea único.
}
/fb:save-form
/fb:_javascript_
fb:value id=nombre path=datos/nombre /
!-- Other fb:value for other fields --
/fb:on-bind
fb:on-delete-row
fb:delete-node /
/fb:on-delete-row
fb:on-insert-row
fb:insert-node
grupo id=
datos
nombre/
tipo/
padre id=/
descripcion/
plantas/
extension/
telefonoDirecto/
fax/
/datos
componentes/
/grupo
/fb:insert-node
/fb:on-insert-row
/fb:repeater
/fb:context
flow:
function grupos(form) {
var datos = leerDatos(xml/forms/datos/grupos.xml);
form.load(datos);
form.showForm(grupos-form-display-pipeline);
form.save(datos);
grabarDatos(xml/forms/datos/grupos.xml, xml/forms/datos/grupos.xml.tmp, datos);
cocoon.sendPage(grupos-form-success-pipeline);
}
grabarDatos is a function streaming the XML to a tmp file and then moving it on success to the real file.
leerDatos reads the XML file into a DOM.
-- Antonio
Fwd: LDAP transformer / Content aggregation / Cacheability
Reason for posting to dev@: - Possible existence of a bug (although I hope it is a user error and you can help me solve it) Yours, -- Antonio-- Forwarded message --From: Antonio Fiol Bonnín [EMAIL PROTECTED] Date: 11-jul-2005 14:16Subject: LDAP transformer / Content aggregation / CacheabilityTo: users@cocoon.apache.orgHello, I am using the LDAP transformer, which, AFAIK, is not cacheable. However, I use the result of it, after a XSLT transformation, in a part of an aggregate. See the sitemap fragment below for details. I am observing a strange result: if the aggregate is in a type=caching pipeline, the result of the LDAP transform is cached. Can anyone please confirm the behaviour, the reason for it and/or the existence of a bug? map:pipeline type=caching map:match pattern=datos/directorio/lista-personas-1 map:generate src=""> map:transform type=ldap / map:serialize / /map:match map:match pattern=datos/directorio/lista-personas-2 map:generate src=""> map:transform type=ldap / map:transform src="" / map:serialize / /map:match /map:pipeline map:pipeline type=noncaching map:match pattern=datos/directorio/lista-personas map:aggregate element=listas map:part src="" / map:part src="" / /map:aggregate map:serialize / /map:match /map:pipeline Thanks in advance. -- Antonio
Re: Custom extensions - to be made available if possible
Hello, We're making progress with the PDF Generator. A skeleton is already built. A decision is necessary: Which PDF reading library is to be used? As I said in a previous e-mail (Sep 10), we downloaded PDF box (www.pdfbox.org), but it seems to us a bit hard to use. It seems to have a viewer, and so it seems to draw on a Graphics. This could be used combined with Batik to generate SVG... but that seems a bit overkill. We also found Etymon PJX (www.etymon.com/epub.html), but it's like the hard part of pdfbox, but without the easier part concerning the Graphics. Does anyone have any other options worth considering? Please, someone share good/bad experiences with PDF reading/parsing products. Thank you very much. Antonio Fiol
Re: Custom extensions - to be made available if possible
As I said in a previous e-mail (Sep 10), we downloaded PDF box (www.pdfbox.org), but it seems to us a bit hard to use. This project uses the BSD license. I think this can be a good candidate for integration with Cocoon. Because of the BSD license, We can be able to include the code and distribute the library as part of the cocon releases. Understood. For now, we continue on this line, at least today. It seems to have a viewer, and so it seems to draw on a Graphics. This could be used combined with Batik to generate SVG... but that seems a bit overkill. I still believe that this sort of SVG generation is overkill. Does anyone agree that a PDF operation processor that spits SVG may be simpler to achieve? Most importantly, I reckon this approach allows us to generate simple SVG without bells and whistles (e.g. only positioned text on a correctly sized page), and improve it with time. We also found Etymon PJX (www.etymon.com/epub.html), but it's like the hard part of pdfbox, but without the easier part concerning the Graphics. This one is GPL. The integration with Cocoon will be more dificult. Same case as Hibernate. OK. Difficult to use + Difficult license integration = Discarded. OF course this is just from the license POV. I have not experience with neither of them. Sorry, but... What POV? A google search por POV or POV PDF leaded to povray and many point of view. Thank you very much. Antonio Fiol
Re: Custom extensions - to be made available if possible
Sorry, but... What POV? A google search por POV or POV PDF leaded to povray and many point of view. Please ignore this. I should re-read my messages before hitting send.
Re: Impress your boss: Cocoon success stories
I'd be grateful if you could send me that presentation for my boss. We're on the why do you say you want this thing called cocoon in the project? stage at the moment. Thank you very much. Antonio Fiol On Mon, 13 Sep 2004 19:11:25 +0200, Gianugo Rabellino [EMAIL PROTECTED] wrote: This is the title of my upcoming presentation at the next Cocoon GetTogether in Gent (http://www.orixo.com/events/gt2004/). This isn't going to be the usual presentation, and I need your help to make it happen.
Re: Custom extensions - to be made available if possible
I've been looking into PDF box. Any opinions on that?
Custom extensions - to be made available if possible
Hello, We have started developing two extensions for cocoon, and we would like to know if the core team would be interested in getting them into the trunk, and optionally in maintaining them in the future. The extensions are: - A transformer that connects via HTTP POST and sends its XML input to the server, and returns the XML returned from the server to the pipeline. This is similar to the SOAP thing, but without the envelope, and with a predefined (configured in the sitemap) URL. - An extension to the Cocoon Lucene searching system (or something different, yet pending design), so that non-XML content can also be indexed. In particular, we are interested on PDF, but we are designing it as generic as possible. BTW, your opinion may be very valueble for the design. Let me explain the two approaches we have thought of: 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 than pleasure, and option (b) seems cleaner to a certain point. Option (b) would allow to follow links in the PDF file, if developed to that point. However, option (b) implies choosing a format for its output (which?), and also poses some problems wrt. the sitemap. Until now, we have a pipeline using a reader to read pdf files (static, from disk). And we would need a generator to be invoked instead for the content and links views. How can we do that? Maybe with a selector? But that does not seem very clean. Any hints there? Any other options? Any general comments? What about making these into the trunk once they are tested? Yours sincerely, Antonio Fiol
Re: Custom extensions - to be made available if possible
How are your PDFs generated? Are they generated by Cocoon? If so, you should index the raw data, before you serialize to PDF. Just a thought. Thanks, but PDFs already exist (and their origin is varying). Most of them are generated from Word documents. But the only thing I have is the PDF file.
Re: Custom extensions - to be made available if possible
b) Creating a PDFGenerator (in the cocoon sense of generator, of course). ... and also poses some problems wrt. the sitemap. Until now, we have a pipeline using a reader to read pdf files (static, from disk). And we would need a generator to be invoked instead for the content and links views. How can we do that? Maybe with a selector? But that does not seem very clean. Any hints there? I'm not sure. It might work. I hope someone else can help you with that. [...] 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?). Can anyone please shed some light into the sitemap issue? The issue, in a few words is: How can I turn a pipeline which serves static PDFs into one that serves static PDFs unless cocoon-view=content or cocoon-view=links. Yours sincerely, Antonio Fiol
Re: Custom extensions - to be made available if possible
I have implemented something like that, see: http://issues.apache.org/bugzilla/show_bug.cgi?id=24402. It is not yet part of Cocoon as we have differing opinions about the design as you can see in the Bugzilla entry and also in the thread: http://marc.theaimsgroup.com/?t=10908512634r=1w=2. Thank you Daniel. My approach was, in fact, much simpler. It is a very simple transformer. You can configure (in the sitemap, src attribute for the transform element) the URL to post to. Everything in the input is posted. The response is piped back alone, without anything around. Of course, your approach is probably much better. Yours, Antonio Fiol
