[jira] Closed: (COCOON-2108) xmodule:flow-attr Does not accept document objects
[ https://issues.apache.org/jira/browse/COCOON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2108. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) 2.1.11-dev (Current SVN) Fixed in r575803 (trunk) and in r575808 (2.1.x branch). Thanks for reporting and providing patches. > xmodule:flow-attr Does not accept document objects > -- > > Key: COCOON-2108 > URL: https://issues.apache.org/jira/browse/COCOON-2108 > Project: Cocoon > Issue Type: Bug > Components: * Cocoon Core >Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) >Reporter: Hugh Sparks >Assignee: Grzegorz Kossakowski >Priority: Minor > Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) > > Attachments: Cocoon-2.2-truck-JXPathHelper.java.patch, > Cocoon-BRANCH-2.1.X-JXPathHelper.java.patch, xmodulePuzzle.txt > > > Sending document objects from flowscript back to the pipeline using > xmodule:flow-attr produces unexpected results. Also, the examples from > the documentation do not work as described: > http://cocoon.apache.org/2.1/861.daisy.html > The most common error reported is: > 'The object type: class java.lang.String could not be serialized to XML" > This issue was discussed recently on the cocoon-users mailing list. > The thread was introduced by Kazo Csaba with the subject "Sending DOM from > flowscript to pipeline." > (July 17, 2007) > He has attempted to trace this behavior in the source code and believes that a > possibly-inappropriate conversion to string occurs in some cases. > Jason Johnston suggested moving the issue to JIRA. > I've created a demonstration of this apparent bug and some related problems > in this very brief example: > http://www.csparks.com/xmodulePuzzle.txt > I hope someone can fix or explain the correct usage of xmodule:flow-attr. > Thanks to all, > -Hugh Sparks, [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Springifying CForms
Joerg Heinicke pisze: > On 14.09.2007 10:46 Uhr, Grzegorz Kossakowski wrote: > >> Speaking more generally I don't think that whiteboard is a good place. >> What I would like to see is: >> 1. You create branch (like cocoon-forms-1.0.X) in our branches folder >> 2. We release subsequent candidates for 1.0.0 from that branch and >> maintain it for reasonably short >> time making few 1.0.1, 1.0.2, ..., releases. >> 3. Meanwhile you (and others) can work on implementing new features in >> trunk and when all (or most) >> features and bug fixes for 1.1.0 are in we branch it to 1.1.X, and >> continue work in trunk on 1.2.X >> our 2.0.0. > > We used to branch as less as possible. This means we branch lazily and > only when it is needed, not eagerly. Maybe we are never going to have > 1.0.1 etc. It should be possible to create a branch from any revision > later on - that was even possible with CVS. Branching in Subversion is just making a copy of directory. You can copy directory from any revision you like. I understand your argument about branching as less as possible especially when our tools do not support very easy synchronization of branches. However, I think making svn copy is not that hard to do and would ease releasing work. Branching is a way to make things more visible, it's easier to show when we are done with particular feature set and letting our code to switch into maintenance mode. One important thing is that I would like to have short living branches (let's say max 4-5 months) and more frequent releases that make transition between minor version changes smoother. If there is other solution than branching I'm eager to listen but branching now or later is secondary detail, IMO. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Springifying CForms
On 14.09.2007 10:46 Uhr, Grzegorz Kossakowski wrote: Speaking more generally I don't think that whiteboard is a good place. What I would like to see is: 1. You create branch (like cocoon-forms-1.0.X) in our branches folder 2. We release subsequent candidates for 1.0.0 from that branch and maintain it for reasonably short time making few 1.0.1, 1.0.2, ..., releases. 3. Meanwhile you (and others) can work on implementing new features in trunk and when all (or most) features and bug fixes for 1.1.0 are in we branch it to 1.1.X, and continue work in trunk on 1.2.X our 2.0.0. We used to branch as less as possible. This means we branch lazily and only when it is needed, not eagerly. Maybe we are never going to have 1.0.1 etc. It should be possible to create a branch from any revision later on - that was even possible with CVS. Joerg
Re: pipelineComponent scope troubles
Grzegorz Kossakowski pisze:
> Giacomo Pati pisze:
>> You'll find the log for request scoped at
>> http://people.apache.org/~giacomo/request-log4j.log
>> and singleton scoped at
>> http://people.apache.org/~giacomo/singleton-console.log. Singleton scope
>> doesn't even start the app.
>
> Ok, that is all weird and definitively worth looking at. I'm just about
> creating similar setup to
> yours and debug a little.
Giacomo, I have some news. I managed to reproduce your problem by creating two
blocks and setup them
as we discussed earlier. It turned out that I was right suspecting it's a
problem with a scope but
with pipelineComponent only call scope. Your problem is as simple as the fact
that flowscript put on
different instance of OM than jx was pulling from.
It is caused by the fact that call scope (and pipelineComponent scope is meant
to be "inside" call
scope) is empty whenever new internal call to another servlet is made. That
means, when Cocoon makes
servlet:bfabric-core:/screen/{1} request OM containing status variable is not
available in a
bfabric-core. It means that call scope and whole SSF is designed to NOT share
any environmental
data, at least at this stage. I discussed it in detail in this e-mail[1] but I
got only one
response, sadly enough.
I'm almost sure that if you change scope of OM to request it's going to work.
Just make sure that
old junk is not sitting somewhere in the classpath. If it's not the case, I
must get working example
of problematic behaviour in order to help anyhow.
[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74571
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
Re: Custom Spring configuration extensions do not work in TestCases
Daniel Fagerstrom pisze: > It looks like an XML-schema error to me. Check line 33 in the > ObjectModelTemplate.xml against the schema and see if there is a problem. Thanks Daniel. Being clueless about XML-schema error while developing XML framework is a shame ;-) Nevertheless, I moved OM bean declarations back to EL module. I hope that this will not break your OSGi work. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Any JIRA administrators on board?
Carsten Ziegeler pisze: > Do you see me waving my hands? Ehm, as far as I know I'm a Jira admin, > but actually I have no clue what to do :) I don't know either, maybe ask on issue I mentioned? It's also important if you are JIRA Administrator or just Project (Cocoon) Administrator the same way as I am. I'm not sure how to check this but maybe just after clicking on Administration button you see more options than I? :) I can only edit Cocoon project. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Any JIRA administrators on board?
Do you see me waving my hands? Ehm, as far as I know I'm a Jira admin, but actually I have no clue what to do :) Carsten Grzegorz Kossakowski wrote: > Hi all, > > I'm trying to add these two new fields that we voted on[1] some time ago. You > can find current > status of my effort on INFRA-1361[2] issues. I was asked if there are JIRA > admins amongst Cocoon > developers as we will need admin rights for managing our fields (like adding > versions). > > Anyone being JIRA admin, raise your hand! > > [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74953 > [2] https://issues.apache.org/jira/browse/INFRA-1361 > -- Carsten Ziegeler [EMAIL PROTECTED]
Re: pipelineComponent scope troubles
Giacomo Pati pisze: > > You'll find the log for request scoped at > http://people.apache.org/~giacomo/request-log4j.log > and singleton scoped at > http://people.apache.org/~giacomo/singleton-console.log. Singleton scope > doesn't even start the app. Ok, that is all weird and definitively worth looking at. I'm just about creating similar setup to yours and debug a little. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Springifying CForms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Grzegorz Kossakowski wrote: > Giacomo Pati pisze: >> I don't think I can manage that until release date. > > Ok, so the problem is "sovled" partly. > >>> Since moving towards Spring is not trivial step I wouldn't like to see it >>> done for Forms 1.0.0 but >> I'm quite familiar with Spring _and_ Avalon > > I didn't have your skills in mind because I'm sure they are great. ;-) > What I did have was that it's not trivial change to Forms code and it would > be desirable to bump > version number. > >>> for 1.1.0. That raises natural question: do we want to branch Forms block? >>> I would be in favour of >>> such solution if there is no other one. >> I could copy it to whiteboard but have to sync it with changes in trunk by >> hand (without help of >> Eclipse) > > That's more problem with Subversion in general than with Eclipse, IMO. It's > said that Subversion 1.5 > will be having some improvements in that area. As for now I recommend use of > Subversive instead of > Subclipse. Despite few bugs in Subversive it has much better support for > multi-project commits, > merging, etc. > > Speaking more generally I don't think that whiteboard is a good place. What I > would like to see is: > 1. You create branch (like cocoon-forms-1.0.X) in our branches folder > 2. We release subsequent candidates for 1.0.0 from that branch and maintain > it for reasonably short > time making few 1.0.1, 1.0.2, ..., releases. > 3. Meanwhile you (and others) can work on implementing new features in trunk > and when all (or most) > features and bug fixes for 1.1.0 are in we branch it to 1.1.X, and continue > work in trunk on 1.2.X > our 2.0.0. > > This would demand a little disciple from us but I think it's good way to have > releases on time and > enough freedom for innovation. > > WDYT? Sounds like a plan :-) > >>> I think your plan is good and I will be happy to help if there are some >>> problems as I have been >>> Springifying some code in Cocoon, already. I'm curious if you want to >>> completely move away from >>> Avalon and convert whole code not only configuration handling? >> Sure, completely. > > Great! > - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG6qFcLNdJvZjjVZARAvdiAKDZFL2Bl0ufKPaTe/NXbNS+rBoEWACguxng xEHvd8VMxM2sfvcfv+VaYro= =So1G -END PGP SIGNATURE-
Any JIRA administrators on board?
Hi all, I'm trying to add these two new fields that we voted on[1] some time ago. You can find current status of my effort on INFRA-1361[2] issues. I was asked if there are JIRA admins amongst Cocoon developers as we will need admin rights for managing our fields (like adding versions). Anyone being JIRA admin, raise your hand! [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74953 [2] https://issues.apache.org/jira/browse/INFRA-1361 -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Springifying CForms
Giacomo Pati pisze: > > I don't think I can manage that until release date. Ok, so the problem is "sovled" partly. >> Since moving towards Spring is not trivial step I wouldn't like to see it >> done for Forms 1.0.0 but > > I'm quite familiar with Spring _and_ Avalon I didn't have your skills in mind because I'm sure they are great. ;-) What I did have was that it's not trivial change to Forms code and it would be desirable to bump version number. >> for 1.1.0. That raises natural question: do we want to branch Forms block? I >> would be in favour of >> such solution if there is no other one. > > I could copy it to whiteboard but have to sync it with changes in trunk by > hand (without help of > Eclipse) That's more problem with Subversion in general than with Eclipse, IMO. It's said that Subversion 1.5 will be having some improvements in that area. As for now I recommend use of Subversive instead of Subclipse. Despite few bugs in Subversive it has much better support for multi-project commits, merging, etc. Speaking more generally I don't think that whiteboard is a good place. What I would like to see is: 1. You create branch (like cocoon-forms-1.0.X) in our branches folder 2. We release subsequent candidates for 1.0.0 from that branch and maintain it for reasonably short time making few 1.0.1, 1.0.2, ..., releases. 3. Meanwhile you (and others) can work on implementing new features in trunk and when all (or most) features and bug fixes for 1.1.0 are in we branch it to 1.1.X, and continue work in trunk on 1.2.X our 2.0.0. This would demand a little disciple from us but I think it's good way to have releases on time and enough freedom for innovation. WDYT? >> I think your plan is good and I will be happy to help if there are some >> problems as I have been >> Springifying some code in Cocoon, already. I'm curious if you want to >> completely move away from >> Avalon and convert whole code not only configuration handling? > > Sure, completely. Great! -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Grzegorz Kossakowski wrote:
> Giacomo Pati pisze:
>>
>> Ok, so this is the snippet where it is used:
>>
>>
>> ${status.myTasks.size()}
>>
>>
>> As it is part of the content surrounding of that page it was included by a
>> XSLT via:
>>
>>
>>
>> which was processed by a
>>
>>
>>
>>
>>
>> and initially called by a flowscript that sets the status variable up as a
>> native Javascript Hash
>>
>> var status = { myTasks: taskManager.getTasks() };
>>
>> whereas the taskManager.getTasks() returns a List
>>
>> So the general process is that a flowscripts calls the pipeline descibed in
>> my earlier mail with a
>> hash of informations where that pipeline expands the initial xml into
>> cinclude which gets included
>> to the final page.
>
> I want to reproduce your setup so I will want to make sure that I understand
> your flow in pipelines:
>
> flowscript_function (sets status.myTasks)
> *
> o
> # generator
> # xslt (creates src="cocoon:/user-status" />)
> # cinclude
> # jx transformer <- here status.myTasks is used
> # serialize
> o [...]
Yes, this is more or less about it.
> Apart from my guesses above I would like to ask you for one more thing, could
> you set scope of OM to
> request (I hope we support standard Spring scopes) and singleton if request
> does not work. Be
> warned, that setting it to singleton is just for testing; it will screw up
> your app as soon as
> second request is processed.
You'll find the log for request scoped at
http://people.apache.org/~giacomo/request-log4j.log
and singleton scoped at
http://people.apache.org/~giacomo/singleton-console.log. Singleton scope
doesn't even start the app.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.6 (GNU/Linux)
iD8DBQFG6pyeLNdJvZjjVZARApvBAKCFU52L8V2tCB+1gerpR33fjJBqRgCeMG4C
S5nZiIbmx4d2NN/kqT14m/0=
=33/T
-END PGP SIGNATURE-
Re: Springifying CForms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Grzegorz Kossakowski wrote: > Giacomo Pati pisze: >> Hi all > > Hi Giacomo > >> If there is nobody working on the subject I'll spend a few hours on doing >> that. > > I'm very pleased to see that you want to work on this as it has been on my > wish-list for quite long > time. However, I'm not sure if you remember that we are going to have next > release in a week[1]. I > just realized that Reinhard omitted CForms on that list but I guess it was > just oversight. I don't think I can manage that until release date. > Since moving towards Spring is not trivial step I wouldn't like to see it > done for Forms 1.0.0 but I'm quite familiar with Spring _and_ Avalon > for 1.1.0. That raises natural question: do we want to branch Forms block? I > would be in favour of > such solution if there is no other one. I could copy it to whiteboard but have to sync it with changes in trunk by hand (without help of Eclipse) >> My general tactic would be to first rewrite the xconf/rules into a spring >> config so that adding new >> Widgets/Converters/Datatypes will than be easily manageable (using >> bean-maps) and than see how the >> classes have to be rewritten to follow that. >> >> Any better ideas? > > I think your plan is good and I will be happy to help if there are some > problems as I have been > Springifying some code in Cocoon, already. I'm curious if you want to > completely move away from > Avalon and convert whole code not only configuration handling? Sure, completely. > > [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74996 > - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG6plkLNdJvZjjVZARAng9AJwM19SivZka2XUWPkRR8jn3JMyx4wCfQ3uQ yHwE8uiNwovd2NimmBvnuNQ= =hPZF -END PGP SIGNATURE-
RE: CocoonGT
Hi Leszek, I'll send you a new link in private! See you in Rome Arje' > -Original Message- > From: Leszek Gawron [mailto:[EMAIL PROTECTED] > Posted At: donderdag 13 september 2007 10:26 > Posted To: Cocoon Dev List > Conversation: CocoonGT > Subject: CocoonGT > > > As something broke during registration I was not able to pay > with PayPal. Question is: what email address should I send > the money to? > [EMAIL PROTECTED] > > Second question is: does anyone play squash? Are there any > squash courts around? I might take my gear with me if > somebody wanted some evening exercise... :) > > -- > Leszek Gawron http://www.mobilebox.pl/krs.html > CTO at MobileBox Ltd. > >
Re: Custom Spring configuration extensions do not work in TestCases
It looks like an XML-schema error to me. Check line 33 in the ObjectModelTemplate.xml against the schema and see if there is a problem. /Daniel Grzegorz Kossakowski skrev: Hi, I'm struggling with a following problem. I import several configuration files from a file configuring a bean I'm testing using org.apache.cocoon.AbstractTestCase. One of imported files contains references to (our extension to Spring configs) that cannot be resolved by Spring. I get following error: testPrefixedSitemapVariable(org.apache.cocoon.components.treeprocessor.variables.PreparedVariableResolverTestCase) Time elapsed: 0.122 sec <<< ERROR! org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Failed to import bean definitions from URL location [classpath:META-INF/cocoon/spring/ObjectModelTemplate.xml] Offending resource: class path resource [org/apache/cocoon/components/treeprocessor/variables/PreparedVariableResolverTestCase.spring.xml]; nested exception is org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 33 in XML document from class path resource [META-INF/cocoon/spring/ObjectModelTemplate.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'configurator:bean-map'. Caused by: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 33 in XML document from class path resource [META-INF/cocoon/spring/ObjectModelTemplate.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'configurator:bean-map'. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'configurator:bean-map'. I'm not Spring insider and I have no clue what to do with this. Could someone help?
Custom Spring configuration extensions do not work in TestCases
Hi, I'm struggling with a following problem. I import several configuration files from a file configuring a bean I'm testing using org.apache.cocoon.AbstractTestCase. One of imported files contains references to (our extension to Spring configs) that cannot be resolved by Spring. I get following error: testPrefixedSitemapVariable(org.apache.cocoon.components.treeprocessor.variables.PreparedVariableResolverTestCase) Time elapsed: 0.122 sec <<< ERROR! org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Failed to import bean definitions from URL location [classpath:META-INF/cocoon/spring/ObjectModelTemplate.xml] Offending resource: class path resource [org/apache/cocoon/components/treeprocessor/variables/PreparedVariableResolverTestCase.spring.xml]; nested exception is org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 33 in XML document from class path resource [META-INF/cocoon/spring/ObjectModelTemplate.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'configurator:bean-map'. Caused by: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 33 in XML document from class path resource [META-INF/cocoon/spring/ObjectModelTemplate.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'configurator:bean-map'. Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'configurator:bean-map'. I'm not Spring insider and I have no clue what to do with this. Could someone help? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: pipelineComponent scope troubles
Giacomo Pati pisze:
>
>
> Ok, so this is the snippet where it is used:
>
>
> ${status.myTasks.size()}
>
>
> As it is part of the content surrounding of that page it was included by a
> XSLT via:
>
>
>
> which was processed by a
>
>
>
>
>
> and initially called by a flowscript that sets the status variable up as a
> native Javascript Hash
>
> var status = { myTasks: taskManager.getTasks() };
>
> whereas the taskManager.getTasks() returns a List
>
> So the general process is that a flowscripts calls the pipeline descibed in
> my earlier mail with a
> hash of informations where that pipeline expands the initial xml into
> cinclude which gets included
> to the final page.
I want to reproduce your setup so I will want to make sure that I understand
your flow in pipelines:
flowscript_function (sets status.myTasks)
*
o
# generator
# xslt (creates )
# cinclude
# jx transformer <- here status.myTasks is used
# serialize
o [...]
Apart from my guesses above I would like to ask you for one more thing, could
you set scope of OM to
request (I hope we support standard Spring scopes) and singleton if request
does not work. Be
warned, that setting it to singleton is just for testing; it will screw up your
app as soon as
second request is processed.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
[jira] Updated: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation
[ https://issues.apache.org/jira/browse/COCOON-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Wyles updated COCOON-2133: Attachment: ResizeOperation.patch Patch to add "allow-enlarge" parameter to imageop resize operation. > Addition of "allow-enlarge" parameter to ImageOp resize operation > - > > Key: COCOON-2133 > URL: https://issues.apache.org/jira/browse/COCOON-2133 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: ImageOp >Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) >Reporter: Robin Wyles >Priority: Minor > Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) > > Attachments: ResizeOperation.patch > > > The addition of an "allow-enlarge" parameter to the resize operation allows > the user to control whether an image should be enlarged by the operation. > This new parameter is declared in the sitemap like so: > > > > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Springifying CForms
Giacomo Pati pisze: > Hi all Hi Giacomo > If there is nobody working on the subject I'll spend a few hours on doing > that. I'm very pleased to see that you want to work on this as it has been on my wish-list for quite long time. However, I'm not sure if you remember that we are going to have next release in a week[1]. I just realized that Reinhard omitted CForms on that list but I guess it was just oversight. Since moving towards Spring is not trivial step I wouldn't like to see it done for Forms 1.0.0 but for 1.1.0. That raises natural question: do we want to branch Forms block? I would be in favour of such solution if there is no other one. > My general tactic would be to first rewrite the xconf/rules into a spring > config so that adding new > Widgets/Converters/Datatypes will than be easily manageable (using bean-maps) > and than see how the > classes have to be rewritten to follow that. > > Any better ideas? I think your plan is good and I will be happy to help if there are some problems as I have been Springifying some code in Cocoon, already. I'm curious if you want to completely move away from Avalon and convert whole code not only configuration handling? [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74996 -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
[jira] Created: (COCOON-2133) Addition of "allow-enlarge" parameter to ImageOp resize operation
Addition of "allow-enlarge" parameter to ImageOp resize operation - Key: COCOON-2133 URL: https://issues.apache.org/jira/browse/COCOON-2133 Project: Cocoon Issue Type: Improvement Components: Blocks: ImageOp Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Robin Wyles Priority: Minor Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) The addition of an "allow-enlarge" parameter to the resize operation allows the user to control whether an image should be enlarged by the operation. This new parameter is declared in the sitemap like so: -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Cocoon, a survival tool
On 9/12/07, Sylvain Wallez <[EMAIL PROTECTED]> wrote: > "Cocoon is a place to find shelter in extreeme conditions and environments"... Of course...Cocoon has been running under Windows for years ;-) -Bertrand
