Re: [RT] Using Spring instead of ECM++
Ralph Goers schrieb: If you really can pull this off then a big +1. However Can you post a sample configuration? I'd love to see what the mixture of spring and avalon-style configuration looks like. Oh, the avalon configuration is exactly the same as we have today in trunk and the spring configuration is the default spring one. Which means we have (or can have) *two* configuration files (xconf + spring xml) which are merged by the container. And if we can ban poolables once and for all then this will greatly simplify things. However, I'd love to see some performance comparisons on some of the sample pages (including logging into the portal) before buying off on this. I'd really like to make sure that our theory that pooling doesn't buy much is really true. If it doesn't buy is performance it will buy is simplicity. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Using Spring instead of ECM++
Carsten Ziegeler wrote: Ralph Goers schrieb: And if we can ban poolables once and for all then this will greatly simplify things. However, I'd love to see some performance comparisons on some of the sample pages (including logging into the portal) before buying off on this. I'd really like to make sure that our theory that pooling doesn't buy much is really true. If it doesn't buy is performance it will buy is simplicity. True. But if it comes with a big price tag I'd like to know it. Ralph
Re: New imageop block in 2.1
* Daniel Fagerstrom: You also need to update blocks.properties with the new block. That can either be done manually or with the generate-blocks.properties task. Thank you, I was missing this bit of info. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: Resurrecting COCOON-1066
* 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/
Re: [RT] Using Spring instead of ECM++
Carsten Ziegeler wrote:
If we want to go down this road I can commit the code to the scratchpad
in the next days.
Please add it to trunk so that integration with blocks-fw and deployer becomes
simpler. (Otherwise we have to run Maven twice in order to get all projects
updated.)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[jira] Commented: (COCOON-1301) [Patch] Image Operation Reader
[ http://issues.apache.org/jira/browse/COCOON-1301?page=comments#action_12365534 ] Jean-Baptiste Quenot commented on COCOON-1301: -- Committed in 2.1, thanks for your contribution! This issue remains open until the block is added in trunk. The latter is currently in state of flux, so there might be some delay. [Patch] Image Operation Reader -- Key: COCOON-1301 URL: http://issues.apache.org/jira/browse/COCOON-1301 Project: Cocoon Type: Improvement Components: Blocks: (Undefined) Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Niclas Hedhman Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: imageop-block.zip I would like to contribute a fairly flexible and powerful Image Reader that is capable of performing a stack of Effects, such as Scaling, color manipulation, and coordination transforms (rotate, mirror and so forth), in a pluggable manner. The ImageOpReader also reads any of the graphics formats supported by javax.imageio package in JDK 1.4, including Png, Jpg and many more. Any image can be returned to the client browser in any of the supported formats. There is still a problem with the AffineTransform operations, and I am working on sorting these out, but; 1. The block is already useful to many as it is. 2. I could need some help getting the AffineTransforms to work properly. Stuff that is still left to do; * Image Operation tests. How does one test image tranforms? * JavaDocs. * User Documentation * Get Rotation Mirror transforms to work. (Problem related to clipping outside the positive coordinate system.) * More samples - The bulk are in place, but more doesn't hurt. I would *really* appreciate if the ImageOp block becomes part of the standard Cocoon 2.2 distribution. I am willing to help out maintaining it for the long term, if I am allowed to... P.S. I already have a CLA on file with the ASF. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1301) [Patch] Image Operation Reader
[ http://issues.apache.org/jira/browse/COCOON-1301?page=comments#action_12365535 ] Jean-Baptiste Quenot commented on COCOON-1301: -- I just tried scale-0.04-jpg, and I have a few questions: * is it possible to change the resampling algorithm? Current resampling looks ugly. * is it possible to change the quality of the generated JPG? We added such a parameter recently for ImageReader. [Patch] Image Operation Reader -- Key: COCOON-1301 URL: http://issues.apache.org/jira/browse/COCOON-1301 Project: Cocoon Type: Improvement Components: Blocks: (Undefined) Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Niclas Hedhman Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: imageop-block.zip I would like to contribute a fairly flexible and powerful Image Reader that is capable of performing a stack of Effects, such as Scaling, color manipulation, and coordination transforms (rotate, mirror and so forth), in a pluggable manner. The ImageOpReader also reads any of the graphics formats supported by javax.imageio package in JDK 1.4, including Png, Jpg and many more. Any image can be returned to the client browser in any of the supported formats. There is still a problem with the AffineTransform operations, and I am working on sorting these out, but; 1. The block is already useful to many as it is. 2. I could need some help getting the AffineTransforms to work properly. Stuff that is still left to do; * Image Operation tests. How does one test image tranforms? * JavaDocs. * User Documentation * Get Rotation Mirror transforms to work. (Problem related to clipping outside the positive coordinate system.) * More samples - The bulk are in place, but more doesn't hurt. I would *really* appreciate if the ImageOp block becomes part of the standard Cocoon 2.2 distribution. I am willing to help out maintaining it for the long term, if I am allowed to... P.S. I already have a CLA on file with the ASF. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: New imageop block in 2.1
Le 8 févr. 06, à 09:36, Jean-Baptiste Quenot a écrit : * Daniel Fagerstrom: You also need to update blocks.properties with the new block. That can either be done manually or with the generate-blocks.properties task. Thank you, I was missing this bit of info. I have re-added this info where it belongs, at the top of blocks.properties, by modifying gump2blocks.properties.xsl -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: New imageop block in 2.1
* Bertrand Delacretaz: Le 8 févr. 06, à 09:36, Jean-Baptiste Quenot a écrit : * Daniel Fagerstrom: You also need to update blocks.properties with the new block. That can either be done manually or with the generate-blocks.properties task. Thank you, I was missing this bit of info. I have re-added this info where it belongs, at the top of blocks.properties, by modifying gump2blocks.properties.xsl The updated blocks.properties also modifies the dependencies descriptions, which means the file has been edited by hand. So, thank you for bringing this precision, this may be helpful also to others. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: [RT] Using Spring instead of ECM++
Carsten Ziegeler wrote: What about replacing ECM++ with Spring? I've a prototype on my harddisk which sets up a Spring BeanFactory based on our current Avalon configuration files (roles and xconf with includes and property replacements). This makes all of our components real spring beans while allowing a smooth migration path. The benefit of this is that you can simply use Spring without any bridging stuff or tricks. And your Spring beans can depend on the Avalon components (and vice versa) without any problems (as there are only Spring beans). And the container is then final no longer our business, we just use the most used/known one. The prototype supports all Avalon lifecycle interfaces right now - with the exception of Poolable/Recyclable as Spring does not have a way to release a bean. We could use our Proxy based approach for thread safe poolables for compatibility while trying to bann all poolable components anyway. So what do people think? I haven't read any other replies yet but my small brain tells me to be +100 on this one. I already am in uncomfortable situation of configuring my own spring xml parser just because I cannot use cocoon's one in spring. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: A new FAQ entry?
Derek Hohls wrote: I like the idea of a categorised FAQ - a simple QA list is fine for a simple project - but Cocoon is *not* that by any measure. Can one have other categories as well? Yes, the category field is a multivalued field. Alternativley, we could just use a tags field allowing freeform tagging of the FAQ entries. However, I'm not a big fan of this approach in documentation, it tends to end up a little too unstrucutred. It would be great if we could start with the list that is already in the Wiki... if you need help creating the info for the FAQ, once the code has been setup, please post a request here. Will do - thnks, I'll wait another couple of days to see if anyone has any objections. Ross [EMAIL PROTECTED] 2006/02/07 06:03:22 PM Berin Loritsch wrote: This is really a three pronged question: 1. Do we have a project FAQ? 2. Where is it? on daisy? (assumption - there isn't a FAQ already) I use Daisy on an in-house project for documentation. One of the things we have done is create a FAQ document type which has a question and an answer part and a category field (user, developer, installation etc.) We then use the query facilities on daisy to automatically create a variety of FAQ documents. One advantage of this over having a normal document listing the faqs is that you can include each FAQ in other documents. For example, by having a field commonality wich is set to uncommon or common, we can use another query to include the common FAQs on relevant pages, e.g. the install documentation can includes the common install FAQs at the end, whilst the uncommon ones appear in only in the list of FAQs. I could set this up on the Daisy instance if you like. Perhaps just starting with the basic FAQ doc type for now. Ross
Re: A new FAQ entry?
Le 8 févr. 06, à 11:54, Ross Gardler a écrit : ...Will do - thnks, I'll wait another couple of days to see if anyone has any objections... None here - I like the idea, hoping that we'll manage to keep that faq up to date ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Forms stylesheets and CSS
Derek Hohls wrote: Helma Supported. I did create a custom stylesheet for forms that uses styled DIV containers and strips out all the nested tables [shudder]; its not straightforward, but it would be ideal to have this available to all users, so that users do not end up with reinventing the wheel. Oh great! Can you send it to me (on private mail) so that i can try to merge it with actual XSLs? Simone -- Simone Gianni
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/
[jira] Commented: (COCOON-1771) cocoon.ajax.Fader runtime error when style uses abreviated form #ccc in IE6.0sp2
[
http://issues.apache.org/jira/browse/COCOON-1771?page=comments#action_12365560
]
Upayavira commented on COCOON-1771:
---
This patch came in as anonymous, therefore we cannot accept it, as its
provenance cannot be proven. Please resubmit it while logged into jira.
cocoon.ajax.Fader runtime error when style uses abreviated form #ccc in
IE6.0sp2
Key: COCOON-1771
URL: http://issues.apache.org/jira/browse/COCOON-1771
Project: Cocoon
Type: Bug
Components: Blocks: Ajax
Versions: 2.1.8
Reporter: Eric Meyer
Assignee: Antonio Gallardo
Attachments: cocoon-ajax.js.patch, cocoon-ajax.js.patch, cocoon-ajax.js.patch
In cocoon.ajax.Fader
this.toColor =
cocoon.ajax.Fader.colorToRgb(cocoon.ajax.Fader.getBgColor(this.element));
getBgColor will return '#fff'
/** Converts a #RRGGBB color as an array of 3 ints */
cocoon.ajax.Fader.colorToRgb = function(hex) {
return [
parseInt(hex.substr(1,2),16),
parseInt(hex.substr(3,2),16),
parseInt(hex.substr(5,2),16) ];
}
Assumes that hex starts with a '#' and has 6 additional hex characters.
The corrected implementation is
/** Converts a #RRGGBB color as an array of 3 ints */
cocoon.ajax.Fader.colorToRgb = function(hex) {
var r = 255; // defaults if no match
var g = 255;
var b = 255;
var i=-1;
var colors = hex.match(/^#(\d{2})(\d{2})(\d{2})$/);
if (colors) {
r = parseInt(colors[++i]);
g = parseInt(colors[++i]);
b = parseInt(colors[++i]);
} else if (colors = hex.match(/^#(\d)(\d)(\d)$/)) {
r = parseInt(colors[++i] + colors[i]);
g = parseInt(colors[++i] + colors[i]);
b = parseInt(colors[++i] + colors[i]);
}
return [r,g,b];
}
Patch attached.
Regards,
Eric Meyer, VP, Quoin, Inc.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1772) [PATCH] AuthenticationContext: NullPointerException
[PATCH] AuthenticationContext: NullPointerException --- Key: COCOON-1772 URL: http://issues.apache.org/jira/browse/COCOON-1772 Project: Cocoon Type: Bug Components: Blocks: Authentication Framework Versions: 2.1.8 Reporter: Antonio Fiol Attachments: AuthenticationContext.java.patch, AuthenticationContext.java.patch We got a NullPointerException on AuthenticationContext. Apparently, this.getState() is returning null. We did not investigate it any further, and supposed that a null RequestState means a null applicationName, which is reasonable as we have no application configured. Patched, and it works perfectly here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1772) [PATCH] AuthenticationContext: NullPointerException
[ http://issues.apache.org/jira/browse/COCOON-1772?page=all ] Antonio Fiol updated COCOON-1772: - Attachment: AuthenticationContext.java.patch I was not asked for the license grant when creating the issue, so I repost the attachment with it. [PATCH] AuthenticationContext: NullPointerException --- Key: COCOON-1772 URL: http://issues.apache.org/jira/browse/COCOON-1772 Project: Cocoon Type: Bug Components: Blocks: Authentication Framework Versions: 2.1.8 Reporter: Antonio Fiol Attachments: AuthenticationContext.java.patch, AuthenticationContext.java.patch We got a NullPointerException on AuthenticationContext. Apparently, this.getState() is returning null. We did not investigate it any further, and supposed that a null RequestState means a null applicationName, which is reasonable as we have no application configured. Patched, and it works perfectly here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Adding patches to Jira
Upayavira (JIRA) wrote:
[ http://issues.apache.org/jira/browse/COCOON-1771?page=comments#action_12365560 ]
Upayavira commented on COCOON-1771:
---
This patch came in as anonymous, therefore we cannot accept it, as its
provenance cannot be proven. Please resubmit it while logged into jira.
How that? Can't we deactivate the possibity to add patches if you're not logged
in?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[jira] Updated: (COCOON-1771) cocoon.ajax.Fader runtime error when style uses abreviated form #ccc in IE6.0sp2
[ http://issues.apache.org/jira/browse/COCOON-1771?page=all ]
Eric Meyer updated COCOON-1771:
---
Attachment: cocoon-ajax.js.patch
Pulled in another patch that fixes a NPE in
/**
* System-wide handlers
*/
cocoon.ajax.BrowserUpdater.handlers
this may already be on the dev trunk, but it's not in the 2.1.8 release vesion.
cocoon.ajax.Fader runtime error when style uses abreviated form #ccc in
IE6.0sp2
Key: COCOON-1771
URL: http://issues.apache.org/jira/browse/COCOON-1771
Project: Cocoon
Type: Bug
Components: Blocks: Ajax
Versions: 2.1.8
Reporter: Eric Meyer
Assignee: Antonio Gallardo
Attachments: cocoon-ajax.js.patch, cocoon-ajax.js.patch,
cocoon-ajax.js.patch, cocoon-ajax.js.patch
In cocoon.ajax.Fader
this.toColor =
cocoon.ajax.Fader.colorToRgb(cocoon.ajax.Fader.getBgColor(this.element));
getBgColor will return '#fff'
/** Converts a #RRGGBB color as an array of 3 ints */
cocoon.ajax.Fader.colorToRgb = function(hex) {
return [
parseInt(hex.substr(1,2),16),
parseInt(hex.substr(3,2),16),
parseInt(hex.substr(5,2),16) ];
}
Assumes that hex starts with a '#' and has 6 additional hex characters.
The corrected implementation is
/** Converts a #RRGGBB color as an array of 3 ints */
cocoon.ajax.Fader.colorToRgb = function(hex) {
var r = 255; // defaults if no match
var g = 255;
var b = 255;
var i=-1;
var colors = hex.match(/^#(\d{2})(\d{2})(\d{2})$/);
if (colors) {
r = parseInt(colors[++i]);
g = parseInt(colors[++i]);
b = parseInt(colors[++i]);
} else if (colors = hex.match(/^#(\d)(\d)(\d)$/)) {
r = parseInt(colors[++i] + colors[i]);
g = parseInt(colors[++i] + colors[i]);
b = parseInt(colors[++i] + colors[i]);
}
return [r,g,b];
}
Patch attached.
Regards,
Eric Meyer, VP, Quoin, Inc.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Adding patches to Jira
Reinhard Poetz wrote: Upayavira (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1771?page=comments#action_12365560 ] Upayavira commented on COCOON-1771: --- This patch came in as anonymous, therefore we cannot accept it, as its provenance cannot be proven. Please resubmit it while logged into jira. How that? Can't we deactivate the possibity to add patches if you're not logged in? Yeah, I wondered about that too. Any jira admin able to look at it? Upayavira
Re: Resurrecting COCOON-1066
As far as my LDAP knowledge goes, the DN is an entry identifier. Usually identifiers appear as attributes, so this is a good idea. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
[jira] Commented: (COCOON-1771) cocoon.ajax.Fader runtime error when style uses abreviated form #ccc in IE6.0sp2
[
http://issues.apache.org/jira/browse/COCOON-1771?page=comments#action_12365584
]
Antonio Gallardo commented on COCOON-1771:
--
Upayavira, may I remove the anonymous attach?
cocoon.ajax.Fader runtime error when style uses abreviated form #ccc in
IE6.0sp2
Key: COCOON-1771
URL: http://issues.apache.org/jira/browse/COCOON-1771
Project: Cocoon
Type: Bug
Components: Blocks: Ajax
Versions: 2.1.8
Reporter: Eric Meyer
Assignee: Antonio Gallardo
Attachments: cocoon-ajax.js.patch, cocoon-ajax.js.patch,
cocoon-ajax.js.patch, cocoon-ajax.js.patch
In cocoon.ajax.Fader
this.toColor =
cocoon.ajax.Fader.colorToRgb(cocoon.ajax.Fader.getBgColor(this.element));
getBgColor will return '#fff'
/** Converts a #RRGGBB color as an array of 3 ints */
cocoon.ajax.Fader.colorToRgb = function(hex) {
return [
parseInt(hex.substr(1,2),16),
parseInt(hex.substr(3,2),16),
parseInt(hex.substr(5,2),16) ];
}
Assumes that hex starts with a '#' and has 6 additional hex characters.
The corrected implementation is
/** Converts a #RRGGBB color as an array of 3 ints */
cocoon.ajax.Fader.colorToRgb = function(hex) {
var r = 255; // defaults if no match
var g = 255;
var b = 255;
var i=-1;
var colors = hex.match(/^#(\d{2})(\d{2})(\d{2})$/);
if (colors) {
r = parseInt(colors[++i]);
g = parseInt(colors[++i]);
b = parseInt(colors[++i]);
} else if (colors = hex.match(/^#(\d)(\d)(\d)$/)) {
r = parseInt(colors[++i] + colors[i]);
g = parseInt(colors[++i] + colors[i]);
b = parseInt(colors[++i] + colors[i]);
}
return [r,g,b];
}
Patch attached.
Regards,
Eric Meyer, VP, Quoin, Inc.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1771) cocoon.ajax.Fader runtime error when style uses abreviated form #ccc in IE6.0sp2
[
http://issues.apache.org/jira/browse/COCOON-1771?page=comments#action_12365587
]
Upayavira commented on COCOON-1771:
---
No need. Just make sure that the one you use was uploaded by a known individual
who clicked the grant license button.
cocoon.ajax.Fader runtime error when style uses abreviated form #ccc in
IE6.0sp2
Key: COCOON-1771
URL: http://issues.apache.org/jira/browse/COCOON-1771
Project: Cocoon
Type: Bug
Components: Blocks: Ajax
Versions: 2.1.8
Reporter: Eric Meyer
Assignee: Antonio Gallardo
Attachments: cocoon-ajax.js.patch, cocoon-ajax.js.patch,
cocoon-ajax.js.patch, cocoon-ajax.js.patch
In cocoon.ajax.Fader
this.toColor =
cocoon.ajax.Fader.colorToRgb(cocoon.ajax.Fader.getBgColor(this.element));
getBgColor will return '#fff'
/** Converts a #RRGGBB color as an array of 3 ints */
cocoon.ajax.Fader.colorToRgb = function(hex) {
return [
parseInt(hex.substr(1,2),16),
parseInt(hex.substr(3,2),16),
parseInt(hex.substr(5,2),16) ];
}
Assumes that hex starts with a '#' and has 6 additional hex characters.
The corrected implementation is
/** Converts a #RRGGBB color as an array of 3 ints */
cocoon.ajax.Fader.colorToRgb = function(hex) {
var r = 255; // defaults if no match
var g = 255;
var b = 255;
var i=-1;
var colors = hex.match(/^#(\d{2})(\d{2})(\d{2})$/);
if (colors) {
r = parseInt(colors[++i]);
g = parseInt(colors[++i]);
b = parseInt(colors[++i]);
} else if (colors = hex.match(/^#(\d)(\d)(\d)$/)) {
r = parseInt(colors[++i] + colors[i]);
g = parseInt(colors[++i] + colors[i]);
b = parseInt(colors[++i] + colors[i]);
}
return [r,g,b];
}
Patch attached.
Regards,
Eric Meyer, VP, Quoin, Inc.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1771) cocoon.ajax.Fader runtime error when style uses abreviated form #ccc in IE6.0sp2
[ http://issues.apache.org/jira/browse/COCOON-1771?page=all ]
Antonio Gallardo updated COCOON-1771:
-
Thanks for the patch. It was applied with minor changes. Please cross check and
close the bug.
cocoon.ajax.Fader runtime error when style uses abreviated form #ccc in
IE6.0sp2
Key: COCOON-1771
URL: http://issues.apache.org/jira/browse/COCOON-1771
Project: Cocoon
Type: Bug
Components: Blocks: Ajax
Versions: 2.1.8
Reporter: Eric Meyer
Assignee: Antonio Gallardo
Attachments: cocoon-ajax.js.patch, cocoon-ajax.js.patch,
cocoon-ajax.js.patch, cocoon-ajax.js.patch
In cocoon.ajax.Fader
this.toColor =
cocoon.ajax.Fader.colorToRgb(cocoon.ajax.Fader.getBgColor(this.element));
getBgColor will return '#fff'
/** Converts a #RRGGBB color as an array of 3 ints */
cocoon.ajax.Fader.colorToRgb = function(hex) {
return [
parseInt(hex.substr(1,2),16),
parseInt(hex.substr(3,2),16),
parseInt(hex.substr(5,2),16) ];
}
Assumes that hex starts with a '#' and has 6 additional hex characters.
The corrected implementation is
/** Converts a #RRGGBB color as an array of 3 ints */
cocoon.ajax.Fader.colorToRgb = function(hex) {
var r = 255; // defaults if no match
var g = 255;
var b = 255;
var i=-1;
var colors = hex.match(/^#(\d{2})(\d{2})(\d{2})$/);
if (colors) {
r = parseInt(colors[++i]);
g = parseInt(colors[++i]);
b = parseInt(colors[++i]);
} else if (colors = hex.match(/^#(\d)(\d)(\d)$/)) {
r = parseInt(colors[++i] + colors[i]);
g = parseInt(colors[++i] + colors[i]);
b = parseInt(colors[++i] + colors[i]);
}
return [r,g,b];
}
Patch attached.
Regards,
Eric Meyer, VP, Quoin, Inc.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Adding patches to Jira
Upayavira schrieb: Reinhard Poetz wrote: Upayavira (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1771?page=comments#action_12365560 ] Upayavira commented on COCOON-1771: --- This patch came in as anonymous, therefore we cannot accept it, as its provenance cannot be proven. Please resubmit it while logged into jira. How that? Can't we deactivate the possibity to add patches if you're not logged in? Yeah, I wondered about that too. Any jira admin able to look at it? If noone changed it in the last minutes, then I think Cocoon is configured correctly. Only jira users and cocoon developers are able to create new issues while all can browse them. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: svn commit: r376023 - in /cocoon/trunk/cocoon-block-deployer/cocoon-archetype-block: ./ src/ src/main/ src/main/resources/ src/main/resources/META-INF/ src/main/resources/archetype-resources/ src/
On Wed, 8 Feb 2006, [EMAIL PROTECTED] wrote: + plugin +groupIdorg.mortbay.jetty/groupId +artifactIdmaven-jetty6-plugin/artifactId +version6.0-SNAPSHOT/version +configuration + connectors +connector implementation=org.mortbay.jetty.nio.SelectChannelConnector + port/port + maxIdleTime3/maxIdleTime +/connector + /connectors + webAppSourceDirectorytarget/cocoon-webapp/webAppSourceDirectory How's RAD possible if the webapp resides in the target directory? Does one need to kick in a mvn command to get that directory updated for every single change made to a XML/XSLT? + contextPath//contextPath + systemProperties +systemProperty + nameorg.apache.commons.logging.Log/name + valueorg.apache.commons.logging.impl.SimpleLog/value +/systemProperty + /systemProperties +/configuration + /plugin -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
RAD block development
Giacomo Pati wrote:
On Wed, 8 Feb 2006, [EMAIL PROTECTED] wrote:
webAppSourceDirectorytarget/cocoon-webapp/webAppSourceDirectory
How's RAD possible if the webapp resides in the target directory? Does
one need to kick in a mvn command to get that directory updated for
every single change made to a XML/XSLT?
With the current implementation yes, but I will change this soon:
https://issues.apache.org/jira/browse/COCOON-1759
https://issues.apache.org/jira/browse/COCOON-1760
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: building trunk
OK. I am now able to build trunk. Now what? Does anything run at the moment?
