You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by an...@apache.org on 2006/10/06 00:32:57 UTC
svn commit: r453409 - in /cocoon/branches/BRANCH_2_1_X:
src/java/org/apache/cocoon/components/flow/FlowHelper.java
src/java/org/apache/cocoon/components/flow/util/PipelineUtil.java status.xml
Author: antonio
Date: Thu Oct 5 15:32:56 2006
New Revision: 453409
URL: http://svn.apache.org/viewvc?view=rev&rev=453409
Log:
<action dev="AG" type="update">
Deprecate method org.apache.cocoon.components.flow.FlowHelper.unwrap(Object). This method will be removed in 2.2 release. Use org.apache.cocoon.components.flow.util.PipelineUtil.unwrap(Object) instead.
</action>
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/FlowHelper.java
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/util/PipelineUtil.java
cocoon/branches/BRANCH_2_1_X/status.xml
Modified: cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/FlowHelper.java
URL: http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/FlowHelper.java?view=diff&rev=453409&r1=453408&r2=453409
==============================================================================
--- cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/FlowHelper.java (original)
+++ cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/FlowHelper.java Thu Oct 5 15:32:56 2006
@@ -90,6 +90,7 @@
/**
* Unwrap a Rhino object (getting the raw java object) and convert undefined to null
+ * @deprecated Use {@link org.apache.cocoon.components.flow.util.PipelineUtil#unwrap(Object)}
*/
public static Object unwrap(Object obj) {
if (obj instanceof Wrapper) {
Modified: cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/util/PipelineUtil.java
URL: http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/util/PipelineUtil.java?view=diff&rev=453409&r1=453408&r2=453409
==============================================================================
--- cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/util/PipelineUtil.java (original)
+++ cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/util/PipelineUtil.java Thu Oct 5 15:32:56 2006
@@ -35,6 +35,8 @@
import org.apache.commons.io.IOUtils;
import org.apache.excalibur.source.Source;
import org.apache.excalibur.source.SourceResolver;
+import org.mozilla.javascript.Undefined;
+import org.mozilla.javascript.Wrapper;
import org.w3c.dom.Document;
import org.xml.sax.ContentHandler;
import org.xml.sax.SAXException;
@@ -102,7 +104,7 @@
// Keep the previous view data, if any (is it really necessary?), and set the new one
Object oldViewData = FlowHelper.getContextObject(objectModel);
- FlowHelper.setContextObject(objectModel, FlowHelper.unwrap(viewData));
+ FlowHelper.setContextObject(objectModel, unwrap(viewData));
Source src = null;
InputStream input = null;
@@ -139,7 +141,7 @@
Map objectModel = ContextHelper.getObjectModel(this.context);
Object oldViewData = FlowHelper.getContextObject(objectModel);
- FlowHelper.setContextObject(objectModel, FlowHelper.unwrap(viewData));
+ FlowHelper.setContextObject(objectModel, unwrap(viewData));
Source src = null;
try {
@@ -165,7 +167,7 @@
Map objectModel = ContextHelper.getObjectModel(this.context);
Object oldViewData = FlowHelper.getContextObject(objectModel);
- FlowHelper.setContextObject(objectModel, FlowHelper.unwrap(viewData));
+ FlowHelper.setContextObject(objectModel, unwrap(viewData));
Source src = null;
@@ -178,5 +180,18 @@
this.resolver.release(src);
}
}
+ }
+
+ /**
+ * Unwrap a Rhino object (getting the raw java object) and convert undefined to null
+ * @since 2.1.10
+ */
+ public static Object unwrap(Object obj) {
+ if (obj instanceof Wrapper) {
+ obj = ((Wrapper)obj).unwrap();
+ } else if (obj == Undefined.instance) {
+ obj = null;
+ }
+ return obj;
}
}
Modified: cocoon/branches/BRANCH_2_1_X/status.xml
URL: http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/status.xml?view=diff&rev=453409&r1=453408&r2=453409
==============================================================================
--- cocoon/branches/BRANCH_2_1_X/status.xml (original)
+++ cocoon/branches/BRANCH_2_1_X/status.xml Thu Oct 5 15:32:56 2006
@@ -184,6 +184,9 @@
<release version="@version@" date="@date@">
-->
<release version="2.1.10" date="TBD">
+ <action dev="AG" type="update">
+ Deprecate method org.apache.cocoon.components.flow.FlowHelper.unwrap(Object). This method will be removed in 2.2 release. Use org.apache.cocoon.components.flow.util.PipelineUtil.unwrap(Object) instead.
+ </action>
<action dev="JH" type="fix" fixes-bug="COCOON-1196">
XSP: Use namespace-uri and not the namespace-prefix to select parameters in logicsheet-util.xsl.
</action>
Re: PipelineUtil
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 8 Oct 2006, Daniel Fagerstrom wrote:
> Joerg Heinicke skrev:
>> Both approaches are probably not backwards compatible. For 2.2 this is not
>> that problem, but as long as we share blocks with 2.1 it is. I wonder how
>> long we will go this way. IMO we should decouple both before releasing 2.2
>> to clean up trunk as much as possible.
>
> Agree as well. If there is interest we should try to get out a new (last?)
> 2.1.x release. And after that 2.1.x and trunk should stop sharing code so
> that we can clean up trunk if we feel like it. It would, as an example, be a
> good idea to start de-avalonizing some of the more important blocks.
I'd support your release plan as well the de-avalonizing of
important blocks.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFKWTTLNdJvZjjVZARAqgoAKCvJod/m9zTHWxajTTSV4GYxdmdQACgkYVI
1PtJoxEUI0ECo69ZOQDZoDM=
=z6NF
-----END PGP SIGNATURE-----
Re: PipelineUtil
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Joerg Heinicke skrev:
> On 06.10.2006 11:35, Daniel Fagerstrom wrote:
>
>> For the JavaFlow the Abstract.Contunable.processPipelineTo uses
>> PipelineUtil.processToStream, it might be a good idea to copy the code
>> to JavaFlow to get rid of the dependency on Floscript.
>>
>> The PipelineUtil in its current form depends on Rhino. Mabe the non
>> Rhino dependent code could be moved to the core, but I don't know if
>> it would be worthwhile.
>
> IMO PipelineUtil is useful in different flow implementations and so
> should be moved into core. Unfortunately - as you wrote - it depends on
> the unwrap() method and so on Rhino.
>
> Two options I see:
> 1. Don't access the PipelineUtil directly, but via the FlowHelper or the
> AbstractContinuable in JavaFlow. The wrapper has to take care for
> converting objects correctly like in unwrap().
> 2. The PipelineUtil gets passed a FlowHelper instance. This instance has
> to provide an unwrap() method (or whatever is needed). This would
> enforce an interface style instead of helper classes.
>
> The second approach is cleaner and would enforce more parallelism in the
> flow implementations.
Would also prefer the second approach.
> Both approaches are probably not backwards compatible. For 2.2 this is
> not that problem, but as long as we share blocks with 2.1 it is. I
> wonder how long we will go this way. IMO we should decouple both before
> releasing 2.2 to clean up trunk as much as possible.
Agree as well. If there is interest we should try to get out a new
(last?) 2.1.x release. And after that 2.1.x and trunk should stop
sharing code so that we can clean up trunk if we feel like it. It would,
as an example, be a good idea to start de-avalonizing some of the more
important blocks.
/Daniel
PipelineUtil (was: svn commit: r453409)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 06.10.2006 11:35, Daniel Fagerstrom wrote:
> For the JavaFlow the Abstract.Contunable.processPipelineTo uses
> PipelineUtil.processToStream, it might be a good idea to copy the code
> to JavaFlow to get rid of the dependency on Floscript.
>
> The PipelineUtil in its current form depends on Rhino. Mabe the non
> Rhino dependent code could be moved to the core, but I don't know if it
> would be worthwhile.
IMO PipelineUtil is useful in different flow implementations and so
should be moved into core. Unfortunately - as you wrote - it depends on
the unwrap() method and so on Rhino.
Two options I see:
1. Don't access the PipelineUtil directly, but via the FlowHelper or the
AbstractContinuable in JavaFlow. The wrapper has to take care for
converting objects correctly like in unwrap().
2. The PipelineUtil gets passed a FlowHelper instance. This instance has
to provide an unwrap() method (or whatever is needed). This would
enforce an interface style instead of helper classes.
The second approach is cleaner and would enforce more parallelism in the
flow implementations.
Both approaches are probably not backwards compatible. For 2.2 this is
not that problem, but as long as we share blocks with 2.1 it is. I
wonder how long we will go this way. IMO we should decouple both before
releasing 2.2 to clean up trunk as much as possible.
> The main point with the move of PipelineUtil and the unwrap method, was
> that I wanted to get rid of the dependency on Rhino in core.
Yes, I know.
Jörg
Re: svn commit: r453409 - in /cocoon/branches/BRANCH_2_1_X: src/java/org/apache/cocoon/components/flow/FlowHelper.java
src/java/org/apache/cocoon/components/flow/util/PipelineUtil.java status.xml
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Joerg Heinicke skrev:
> On 06.10.2006 00:57, Antonio Gallardo wrote:
>
>>> Why actually? What has unwrap to do with pipeline processing? If it
>>> is because it is only used there then it makes only sense to move it
>>> there if you also make it private. Otherwise it is a public method
>>> and it should be seen in a more API-POV, i.e. where it makes sense
>>> in the bigger picture. Nobody will find unwrap in PipelineUtil as
>>> nobody will search there I fear.
>>
>> I tend agree with you. I just back ported the code from cocoon 2.2 to
>> make sure forms block works on cocoon 2.1. I just followed
>> recommended instructions, since I am not aware of the impact of this
>> change in the trunk. I suspect it is because the rhino dependency was
>> moved out from core to the flowscript block or so. Perhaps Daniel can
>> tell you more about the decision.
>
> Ah, ok, didn't know that original cause. But my point still stands. I
> wonder if you need the FlowHelper at all when not using flow script,
> i.e. why it is in core? On the other hand javaflow block needs
> flowscript block. Everything kind of strange, isn't it?
The FlowHelper is used in a number of places in cocoon-core and doesn't
(after the removal of unwrap) contain anything flowscript specific so it
made sense to keep it in core.
For the JavaFlow the Abstract.Contunable.processPipelineTo uses
PipelineUtil.processToStream, it might be a good idea to copy the code
to JavaFlow to get rid of the dependency on Floscript.
The PipelineUtil in its current form depends on Rhino. Mabe the non
Rhino dependent code could be moved to the core, but I don't know if it
would be worthwhile.
The main point with the move of PipelineUtil and the unwrap method, was
that I wanted to get rid of the dependency on Rhino in core.
/Daniel
Re: svn commit: r453409 - in /cocoon/branches/BRANCH_2_1_X: src/java/org/apache/cocoon/components/flow/FlowHelper.java
src/java/org/apache/cocoon/components/flow/util/PipelineUtil.java status.xml
Posted by Joerg Heinicke <jo...@gmx.de>.
On 06.10.2006 00:57, Antonio Gallardo wrote:
>> Why actually? What has unwrap to do with pipeline processing? If it is
>> because it is only used there then it makes only sense to move it
>> there if you also make it private. Otherwise it is a public method and
>> it should be seen in a more API-POV, i.e. where it makes sense in the
>> bigger picture. Nobody will find unwrap in PipelineUtil as nobody will
>> search there I fear.
>
> I tend agree with you. I just back ported the code from cocoon 2.2 to
> make sure forms block works on cocoon 2.1. I just followed recommended
> instructions, since I am not aware of the impact of this change in the
> trunk. I suspect it is because the rhino dependency was moved out from
> core to the flowscript block or so. Perhaps Daniel can tell you more
> about the decision.
Ah, ok, didn't know that original cause. But my point still stands. I
wonder if you need the FlowHelper at all when not using flow script,
i.e. why it is in core? On the other hand javaflow block needs
flowscript block. Everything kind of strange, isn't it?
Jörg
Re: svn commit: r453409 - in /cocoon/branches/BRANCH_2_1_X: src/java/org/apache/cocoon/components/flow/FlowHelper.java
src/java/org/apache/cocoon/components/flow/util/PipelineUtil.java status.xml
Posted by Antonio Gallardo <ag...@agssa.net>.
Joerg Heinicke escribió:
> On 06.10.2006 00:32, antonio@apache.org wrote:
>
>> <action dev="AG" type="update">
>> Deprecate method
>> org.apache.cocoon.components.flow.FlowHelper.unwrap(Object). This method
>> will be removed in 2.2 release. Use
>> org.apache.cocoon.components.flow.util.PipelineUtil.unwrap(Object)
>> instead.
>> </action>
>
> Why actually? What has unwrap to do with pipeline processing? If it is
> because it is only used there then it makes only sense to move it
> there if you also make it private. Otherwise it is a public method and
> it should be seen in a more API-POV, i.e. where it makes sense in the
> bigger picture. Nobody will find unwrap in PipelineUtil as nobody will
> search there I fear.
I tend agree with you. I just back ported the code from cocoon 2.2 to
make sure forms block works on cocoon 2.1. I just followed recommended
instructions, since I am not aware of the impact of this change in the
trunk. I suspect it is because the rhino dependency was moved out from
core to the flowscript block or so. Perhaps Daniel can tell you more
about the decision.
Best Regards,
Antonio Gallardo.
Re: svn commit: r453409 - in /cocoon/branches/BRANCH_2_1_X: src/java/org/apache/cocoon/components/flow/FlowHelper.java
src/java/org/apache/cocoon/components/flow/util/PipelineUtil.java status.xml
Posted by Joerg Heinicke <jo...@gmx.de>.
On 06.10.2006 00:32, antonio@apache.org wrote:
> <action dev="AG" type="update">
> Deprecate method
> org.apache.cocoon.components.flow.FlowHelper.unwrap(Object). This method
> will be removed in 2.2 release. Use
> org.apache.cocoon.components.flow.util.PipelineUtil.unwrap(Object) instead.
> </action>
Why actually? What has unwrap to do with pipeline processing? If it is
because it is only used there then it makes only sense to move it there
if you also make it private. Otherwise it is a public method and it
should be seen in a more API-POV, i.e. where it makes sense in the
bigger picture. Nobody will find unwrap in PipelineUtil as nobody will
search there I fear.
Jörg