Custom Xpath Selector
Hi I wanted to create a Selector that would have access to the contents of the xml from a generator (similar to the below sitemap fragment). Ideally it would have access to the XML in a similar way as a transformer such as AbstractDOMTransformer does and then uses xpath on the contents. Does anybody know if there are any Selectors which work in a similar way or of an interface I can implement in my selector inorder to have access to the xml. map:select type=myselector map:generate src=content.xml/ map:when test=//result/@response-code = '500' do something when I get a 500 error /map:when /map:select Perhaps I am barking up the wrong tree and a selector is not the best solution, it would be nice to be able to do different things bassed on the contents of the xml passed through a pipeline Many Thanks Richard http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
Re: Custom Xpath Selector
On Tue, Jul 22, 2008 at 10:04 AM, Richard McKenzie
[EMAIL PROTECTED] wrote:
snip/
Perhaps I am barking up the wrong tree and a selector is not the best
solution, it would be nice to be able to do different things bassed on the
contents of the xml passed through a pipeline
If you have complicated use cases I suspect you're going to want to
use a Java transformer to inspect the XML in the pipeline and have it
make the decisions on what should be done. This can be done from flow
script by firing off the pipeline at that point and then inspecting
some returned result. I'm not sure about 2.1 but in 2.0 this looks
like
var sourceURI = run/_checkXML/;
var destinationURI = xmodule:request-attr:checkXMLresult;
var resolver = null;
var destination = null;
var output = null;
try {
resolver = cocoon.getComponent(
Packages.org.apache.cocoon.environment.SourceResolver.ROLE );
destination = resolver.resolveURI( destinationURI );
output = destination.getOutputStream();
cocoon.processPipelineTo( sourceURI, {}, output );
output.close();
if ( cocoon.request.getAttribute( checkXMLresult ) == ...) {
//see what happened in the XML checking pipeline
// Do whatever should be done based on the results...
return true;
}
}
finally {
if (destination != null) {
resolver.release( destination );
}
cocoon.releaseComponent( resolver );
}
--
Peter Hunsberger
[jira] Closed: (COCOON-2225) how to debug xslt in cocoon framework .I am using Jbuider .just let me know how to set up the breakpoints for xslt in jbuilder
[ https://issues.apache.org/jira/browse/COCOON-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke closed COCOON-2225. - Resolution: Invalid Please send your request to the users list (http://cocoon.apache.org/1275_1_1.html). We don't use Jira for support requests and it's unlikely you get an answer here. how to debug xslt in cocoon framework .I am using Jbuider .just let me know how to set up the breakpoints for xslt in jbuilder -- Key: COCOON-2225 URL: https://issues.apache.org/jira/browse/COCOON-2225 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Reporter: student cocoon framework .I am using Jbuider .just let me know how to set up the breakpoints for xslt in jbuilder as there is some important xml file that combines with my xslt and display but I am not aware of among so many important which xml it is combining .so I will be thankfulo just let me know how to debug xsl using in jbuilder2008 . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [proposal] Corona: A Cocoon subproject
On 20.07.2008 14:17, Reinhard Pötz wrote: First we should define the mission of this subproject. Corona has two main goals: 1. Become the best platform for RESTful services and RESTful web applications based on the concept of pipelines. 2. Provide a generic pipeline Java API with SAX and STaX based default implementations. We will need a one-sentence description anyway. Then the appropriate name should fall out. I lean towards Fibre or Silk. However because it might not be the pipeline API that Cocoon uses, then perhaps some other type of fibre. For example, Kapok - a fine fibrous cotton-like substance found surrounding the seeds of a tropical tree. (Australian Oxford English Dictionary). The term Java Kapok is used, but from my quick search not in the software industry. http://en.wikipedia.org/wiki/Ceiba_pentandra So my proposals are: Apache Cocoon Kapok Apache Cocoon Fibre I tend towards Apache (Cocoon) Silk because it is short and easily pronounceable (in contrast to Fibre) and doesn't sound like Klingon (Kapok). I don't know if we should add Cocoon to the name and have no strong opinion. Is it THAT different that you don't consider calling it Cocoon 3.0 at all? Joerg
AW: AW: AW: AW: Client-side validation in CForms
Hi ... well I never really used the I18N Stuff, I have to admit.
Every time I got in contact with it (currently using Cocoon 2.1.10) I
thought they were text files and no Xml files.
Regarding your Expression-Interpreter. I do have quite some experience with
parsers and interpreters, so maybe this could be a part that I could help
you with.
If we think of all Form elements as dojo widgets, we could use the dojo
query functions for finding elements, since it's a lot easier navigating in
the widget hierarchy than in the html page (dojo.byId vs. dijit.byId).
Unfortunately I am currently struggling with some issues of my current
cocoon project, but I think I will have them solved in the next few days. I
would gladly help with these client side validators, but I would rather
suggest adjusting the Server Side Sax-Generation to output the needed
information first ... without this, all client side stuff is useless, since
we can't get the validator rules to our cforms-xslt.
Chris
-Ursprüngliche Nachricht-
Von: Jeremy Quinn [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 21. Juli 2008 13:45
An: dev@cocoon.apache.org
Betreff: Re: AW: AW: AW: Client-side validation in CForms
Hi Chris
Sorry it took me so long to reply.
On 17 Jul 2008, at 16:48, Christofer Dutz wrote:
Hi Jeremy,
doesn't dojo load a i18n resource for the messages?
It does, but this may be perceived as a problem because CForms users
expect to supply all of their own i18n messages (and I personally find
some of dojo's language a bit un-natural).
I dont think it should
be a problem taking over this or getting Dojo to load our i18n
resources ...
This is most likely possible, but I have not looked into it yet.
xml-i18n resources for cocoon would have been really nice for
this ... in
the worst case I think it should be possible (it even might already
exist)
to create a resource-file-generator, that simply converts these nasty
text-form resource files to neat xml and then translate this to Dojo
i18n
resources with a simple xslt.
Are you confusing java i18n properties-type bundles with Cocoon i18n
xml message files?
Transforming Cocoon's XML bundles to Dojo's json-based format should
not be too difficult.
With the other problems ... well I agree that they might be
tricky ... but
what would the challenge be, if everything was easy? ;-)
Well, we should start with the low hanging fruit :
regExp, min, max, email, mod10, value-count etc.
I was googling for a JavaScript implementation of the XReporter
expression language, but no luck yet ;)
I have never written an interpreter before :)
But I was thinking about a simple case like this :
fd:validation
fd:range min=number1 + 1
fd:failmessageThis number should be larger than the first
number./fd:failmessage
/fd:range
/fd:validation
client-side (off the top of my head) :
var min = 0;
try {
with (this.form) min = eval(number1 + 1)
} catch e {
// could not evaluate expression
}
so 'number1' gets evaluated in the scope of this.form.
but it quickly gets nasty ..
The languages comparison operator is a single '=' not a double one :(
References to fields can be relative (../fieldname) etc. etc.
I think the main difference in my approach and the old Cocoon
approach is
not to reinvent the wheel. I never quite understood all the
double-implemention of widgets. But I have to admit the old Dojo was
missing
quite some stuff and I even had to bugfix quite a lot in the Dojo0.4
Stuff.
At the moment simply using Dojo and providing some very basic
JavaScripts
should be sufficient.
Well one of the problems is that there is a big mismatch between the
assumptions behind Dojo and CForms.
eg. number fields
Cocoon expects no smarts on the client, so a user would typically have
a converter for a form value to send a locale-formatted string
representation of the number to edit to the client :
value: 1234567.89
sends: 1,234,567.89 (en_GB)
1 234 567,89 (fr_FR)
etc.
Cocoon then expects the formatted value in return.
Dojo however, expects to send and receive un-formatted numbers,
performing l10n client-side.
This is not impossible to resolve, but it indicates some of the less-
obvious complexities :)
Thanks for your feedback
regards Jeremy
