Re: New expression language usage
Reinhard Poetz pisze:
Torsten Curdt wrote:
On 28.01.2008, at 00:53, Grzegorz Kossakowski wrote:
snip type=complicated expressions/
Have my cocoon skills gone so rusty or did I just not get the
question? What's wrong with the good old ways to referring to first
match?
map:match pattern=matching/*
map:generate src=sax-pipeline/{1}.xml/
map:match pattern=matching/*
map:generate src=sax-pipeline/{\1}.xml/
map:match pattern=matching/* name=root
map:generate src=sax-pipeline/{#root:1}.xml/
Grek, what's the suggested new syntax for these three use cases?
The same as above; the plan is to reuse existing code. It maybe quite
troublesome since the second
and third syntax is new for me...
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: New expression language usage
Reinhard Poetz pisze: Grzegorz Kossakowski wrote: Reinhard Poetz pisze: Oh gosh, you stumbled upon COCOON-2118[1] issue. Fortunately enough, at least COCOON-2117 is resolved so we can find this value in ObjectModel. Using XPath it should be something like: all/sitemap[position() = last()]/*[name()='1'] or: all/sitemap[position() = last()]/*[name()='$named$']/*[name()='1'] I don't remember if $named$ part is necessary. I must put here a BIG warning, I tested this only casually so this part of EL might have bugs. Expressions above look quite nasty so I think we'll need to get map: language done pretty quickly. (I think it should be easy) If you can't make this work, write a IT for it and I'll have a look ASAP. I think that I will wait until COCOON-2118 will be implemented ;-) No problem. Are you looking at me as at the one possibly implementing this? :-) -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Is throwing exception always good choice?
Grzegorz Kossakowski wrote:
Hello guys,
I noticed comment from Dominic Mitchell at his blog complaining[1] about the
fact that we print 30
lines long exception just to inform there is no block handling favicon.ico
browser's request.
It is caused by following snippet in DispatcherServlet:
if (servlet == null) {
throw new ServletException(No block for + req.getPathInfo());
}
Now I start to think that throwing this exception is a bad idea. It's going to
be quite casual
situation that server is requested non-existing resources and I think we
shouldn't do so much noise
about it. Why about just returning 404 response with message the same as it's
now thrown within
exception?
I'll make this change within two days if nobody complains.
+1
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: New expression language usage
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
Expressions above look quite nasty so I think we'll need to get map:
language done pretty quickly.
(I think it should be easy)
If you can't make this work, write a IT for it and I'll have a look ASAP.
I think that I will wait until COCOON-2118 will be implemented ;-)
No problem.
Are you looking at me as at the one possibly implementing this? :-)
;-)
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
[jira] Assigned: (COCOON-2118) Implement map: expression language
[ https://issues.apache.org/jira/browse/COCOON-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2118: Assignee: Grzegorz Kossakowski Implement map: expression language -- Key: COCOON-2118 URL: https://issues.apache.org/jira/browse/COCOON-2118 Project: Cocoon Issue Type: New Feature Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Implement expression language (map:) that let's you to access sitemap variables. Actually, it's already implemented in PreparedVariableResolver for years but the task is about implementing it as class imlementing org.apache.cocoon.components.expression.Expression interface. It was proposed here[1] and clarified here[2]. [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/73700 [2] http://article.gmane.org/gmane.text.xml.cocoon.devel/73760 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Is throwing exception always good choice?
Reinhard Poetz pisze: Felix Knecht wrote: Grzegorz Kossakowski schrieb: +1. Can we log the error instead? IMO it may help whenever you need to track problems only having the log files. yes, good idea (but please don't use ERROR or even higher as log level - INFO should be good enough) Same feelings here. I have it already implemented in my Git repository, seems like it's high time to commit this simple but still very desired change. :-) -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Is throwing exception always good choice?
Felix Knecht wrote:
Grzegorz Kossakowski schrieb:
Hello guys,
I noticed comment from Dominic Mitchell at his blog complaining[1]
about the fact that we print 30
lines long exception just to inform there is no block handling
favicon.ico browser's request.
It is caused by following snippet in DispatcherServlet:
if (servlet == null) {
throw new ServletException(No block for +
req.getPathInfo());
}
Now I start to think that throwing this exception is a bad idea. It's
going to be quite casual
situation that server is requested non-existing resources and I think
we shouldn't do so much noise
about it. Why about just returning 404 response with message the same
as it's now thrown within
exception?
I'll make this change within two days if nobody complains.
+1.
Can we log the error instead? IMO it may help whenever you need to track
problems only having the log files.
yes, good idea (but please don't use ERROR or even higher as log level - INFO
should be good enough)
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Is throwing exception always good choice?
Grzegorz Kossakowski schrieb:
Hello guys,
I noticed comment from Dominic Mitchell at his blog complaining[1] about the
fact that we print 30
lines long exception just to inform there is no block handling favicon.ico
browser's request.
It is caused by following snippet in DispatcherServlet:
if (servlet == null) {
throw new ServletException(No block for + req.getPathInfo());
}
Now I start to think that throwing this exception is a bad idea. It's going to
be quite casual
situation that server is requested non-existing resources and I think we
shouldn't do so much noise
about it. Why about just returning 404 response with message the same as it's
now thrown within
exception?
I'll make this change within two days if nobody complains.
+1.
Can we log the error instead? IMO it may help whenever you need to track
problems only having the log files.
Felix
Re: Is throwing exception always good choice?
+1 :-)
On Mon, 2008-01-28 at 11:41 +0100, Grzegorz Kossakowski wrote:
Hello guys,
I noticed comment from Dominic Mitchell at his blog complaining[1] about the
fact that we print 30
lines long exception just to inform there is no block handling favicon.ico
browser's request.
It is caused by following snippet in DispatcherServlet:
if (servlet == null) {
throw new ServletException(No block for + req.getPathInfo());
}
Now I start to think that throwing this exception is a bad idea. It's going
to be quite casual
situation that server is requested non-existing resources and I think we
shouldn't do so much noise
about it. Why about just returning 404 response with message the same as it's
now thrown within
exception?
I'll make this change within two days if nobody complains.
[1] http://happygiraffe.net/blog/articles/2008/01/27/trusting-your-tools
Re: Is throwing exception always good choice?
Hi Grzegorz,
I agree with you on this subject. We should bug the developers and users
with as less information as can be (unless configured in such a way). It
will only scare them. I think it's a good improvement. Go ahead!
Regards,
Jeroen
On Mon, 2008-01-28 at 11:41 +0100, Grzegorz Kossakowski wrote:
Hello guys,
I noticed comment from Dominic Mitchell at his blog complaining[1] about the
fact that we print 30
lines long exception just to inform there is no block handling favicon.ico
browser's request.
It is caused by following snippet in DispatcherServlet:
if (servlet == null) {
throw new ServletException(No block for + req.getPathInfo());
}
Now I start to think that throwing this exception is a bad idea. It's going
to be quite casual
situation that server is requested non-existing resources and I think we
shouldn't do so much noise
about it. Why about just returning 404 response with message the same as it's
now thrown within
exception?
I'll make this change within two days if nobody complains.
[1] http://happygiraffe.net/blog/articles/2008/01/27/trusting-your-tools
Re: New expression language usage
Reinhard Poetz pisze: Grzegorz Kossakowski wrote: Reinhard Poetz pisze: No problem. Are you looking at me as at the one possibly implementing this? :-) ;-) Done in r615994 and r615999. I registered implementation of map: language and created simple IT test. Everything passes here. :-) -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
