Re: MountTableMatcher
Unico Hommes wrote: Nice article! We do basically the same thing. Note that with MountTableMatcher you no longer need to patch the cocoon root sitemap. Why people often say so? There is no need to patch the root sitemap anyway as it is simply trying to mount whatever comes in as request URL on to the filesystem. Just deploy you app as a subdirectory of the webadd directory of Cocoon. Sure, if you need to have your start URL to be the root just copy a different welcome.xml/welcome.xslt over. It is too bad that Ant does not itself support a pluggable architecture. Now you end up replicating such a build environment in every new project. Use another one instead (Maven, Centipede) that has 'plugins'. If something changes in cocoon that impacts the build system you need to update all those separate instances. I started on a Maven plugin for cocoon some time ago exactly for this reason. But unfortunately haven't been able to work on it lately. Maybe something for CTP if that would prove to take off. We already have such Maven plugins and if CTP will start we sure will contribute. Regards, Unico -Original Message- From: Jeremy Quinn [mailto:[EMAIL PROTECTED] Sent: woensdag 19 november 2003 16:41 To: [EMAIL PROTECTED] On 17 Nov 2003, at 23:03, Geoff Howard wrote: Interesting. I'd rather integrate my build into Cocoon's, rather than the other way around, and now I can see that all I've got to do is stick files into a confpatch folder, which is really great. Sure, but some people prefer to integrate Cocoon into their build - and generally want to do so with as little building of Cocoon as possible. Either way works well. With this recent change to XConfPatchTask, I have been able to refactor the way we build our Projects 'into' Cocoon. I attempt to describe the process here:We've never ha http://wiki.cocoondev.org/Wiki.jsp?page=ProjectBuilding HTH regards Jeremy -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
RE: MountTableMatcher
Giacomo Pati wrote Unico Hommes wrote: Nice article! We do basically the same thing. Note that with MountTableMatcher you no longer need to patch the cocoon root sitemap. Why people often say so? There is no need to patch the root sitemap anyway as it is simply trying to mount whatever comes in as request URL on to the filesystem. Just deploy you app as a subdirectory of the webadd directory of Cocoon. Sure, if you need to have your start URL to be the root just copy a different welcome.xml/welcome.xslt over. When developing a site - sitemap, stylesheets, templates, etc. - I find that having to copy these each time just in order to test them is a PITA. If you decide to develop inside the webapp directory to later copy them back into the projects source tree, well this has major drawback IMO. You run the risk of losing work when you do a build clean, and there's the extra step of copying the sources back into your project's source tree. It is too bad that Ant does not itself support a pluggable architecture. Now you end up replicating such a build environment in every new project. Use another one instead (Maven, Centipede) that has 'plugins'. If something changes in cocoon that impacts the build system you need to update all those separate instances. I started on a Maven plugin for cocoon some time ago exactly for this reason. But unfortunately haven't been able to work on it lately. Maybe something for CTP if that would prove to take off. We already have such Maven plugins and if CTP will start we sure will contribute. Cool! Unico
DO NOT REPLY [Bug 24844] - XMLByteStreamCompiler.getSAXFragment() shouldn't return whole array
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24844. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24844 XMLByteStreamCompiler.getSAXFragment() shouldn't return whole array [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-20 09:26 --- grmpf what a waste! copying the whole array because we need to shrink it again :-/ ...but you are right. I missed that in my optimization delusion
Re: DO NOT REPLY [Bug 24844] New: - XMLByteStreamCompiler.getSAXFragment() shouldn't return whole array
XMLByteStreamCompiler.getSAXFragment() has been changed recently to return the whole array instead of creating a new array trimmed to the appropriate length. This causes problems for (at least) XMLByteStreamInterpreter which spews as many startDocument() events as there are zeroes at the end of the array. This causes Saxon to throw an exception. Thanks for reporting! -- Torsten
Re: MountTableMatcher
On 19 Nov 2003, at 18:37, Upayavira wrote:
Jeremy,
Splendid article. Stuff I've been thinking about a lot recently too.
Just one useful quote from the Ant manual:
property environment=env/
echo message=Number of Processors = ${env.NUMBER_OF_PROCESSORS}/
echo message=ANT_HOME is set to = ${env.ANT_HOME}/
With this, you can get at ${env.COCOON_HOME}, etc.
Thanks Upayavira
Did you read the bit earlier about the scheme having a flaw because of
no variable substitution in the xmap tag's attributes?
How difficult would it be to add this?
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
XConfPath task (was Re: MountTableMatcher)
Jeremy Quinn wrote:
On 19 Nov 2003, at 18:37, Upayavira wrote:
Jeremy,
Splendid article. Stuff I've been thinking about a lot recently too.
Just one useful quote from the Ant manual:
property environment=env/
echo message=Number of Processors = ${env.NUMBER_OF_PROCESSORS}/
echo message=ANT_HOME is set to = ${env.ANT_HOME}/
With this, you can get at ${env.COCOON_HOME}, etc.
Thanks Upayavira
Did you read the bit earlier about the scheme having a flaw because of
no variable substitution in the xmap tag's attributes?
No I didn't.
How difficult would it be to add this?
Coding-wise, pretty trivial, just wrap each string with
getProject().replaceProperties().
Before we do this, I think we should sort out a few details, following
on from a comment from Vadim.
Do we want to automatically replace properties, and remove the
replace-properties attribute? Are there any situations in which this
could cause a problem?
Similarly, are there any situations in which it could cause a problem in
the top level attributes, e.g. xpath, or include-before?
We could:
(1) Remove the replace-properties attribute, and replace properties
automatically in the content, and in the top level attributes.
(2) Leave the replace-properties attribute, and only replace properties
in the top level attributes if it is set to true.
There are other options, but these two make the most sense. What do
people think?
Regards, Upayavira
RE: MountTableMatcher
Jeremy Quinn wrote:
On 19 Nov 2003, at 18:37, Upayavira wrote:
Jeremy,
Splendid article. Stuff I've been thinking about a lot recently too.
Just one useful quote from the Ant manual:
property environment=env/
echo message=Number of Processors =
${env.NUMBER_OF_PROCESSORS}/
echo message=ANT_HOME is set to = ${env.ANT_HOME}/
With this, you can get at ${env.COCOON_HOME}, etc.
Thanks Upayavira
Did you read the bit earlier about the scheme having a flaw
because of no variable substitution in the xmap tag's attributes?
What I do is that I copy the xmap patch file to a temporary build
directory using filtering to substitute the variables and then run the
xpatch task with it.
Unico
Re: DB support in flowscript (was: XSP official position)
On 19 Nov 2003, at 12:34, Leszek Gawron wrote: Continuing II: I still cannot picture retrieving 5000 of objects via O/R and showing them on paginated view - the performance would be tragical. well ... have you tried it? there was nothing tragic about listing 3 records from Hibernate last time I tried ;) look at : Scrollable Iteration : http://www.hibernate.org/hib_docs/reference/html/manipulating- data.html#manipulating-data-s5b and Lazy Initialisation : http://www.hibernate.org/hib_docs/reference/html/ collections.html#collections-s1-7 HTH regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Introducing IOC for Java classes created in flowscript
Hi all,
Flowscript currently gives two means to use Java classes: use components
(cocoon.getComponent()) or simply create a Java object and use it (new
MyClass()). As it's not very convenient to create a new component and
install it in cocoon.xconf just to call Java code from the flow, the
second solution is often used.
But a problem comes when these Java objects need to access e.g. request
parameters, session attributes, components, etc: the only way is to pass
them the cocoon object that provides this access.
But cocoon is of class FOM_Cocoon which is very specific to the
internals of flowscript and linking code to this specific class isn't
IMO a good thing to do. Furthermore, accessing elements of the object
model through getters isn't consistent with the way it's usually done in
other Cocoon code and violates IOC.
So I added a new method to cocoon that sets up an object just as if it
were an Avalon component by honoring the various lifecycle interfaces.
Some useful lifecycle interfaces to implement are of course LogEnabled
and Serviceable, but also Contextualizable, which gives access to the
object model through the ContextHelper class.
Example:
var foo = new Foo();
cocoon.setupObject(foo);
foo.doIt(blah);
This way of setting up object respects IOC, avoids using the very
specific FOM_Cocoon class and gently educates people to the good
things provided by Avalon.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: Introducing IOC for Java classes created in flowscript
From: Sylvain Wallez Hi all, Flowscript currently gives two means to use Java classes: use components (cocoon.getComponent()) or simply create a Java object and use it (new MyClass()). As it's not very convenient to create a new component and install it in cocoon.xconf just to call Java code from the flow, the second solution is often used. yep, unfortunatly ... But a problem comes when these Java objects need to access e.g. request parameters, session attributes, components, etc: the only way is to pass them the cocoon object that provides this access. But cocoon is of class FOM_Cocoon which is very specific to the internals of flowscript and linking code to this specific class isn't IMO a good thing to do. Furthermore, accessing elements of the object model through getters isn't consistent with the way it's usually done in other Cocoon code and violates IOC. yep. when I startet to add interception capabilities to flowscript I had to copy the existing FOM_Cocoon because it had direct references to the interpreter (I think this needs some re-thinking ...) Anyway: If we once have more than one ControlFlow impl (not necessarily in the cocoon-cvs but maybe outside) this will become a problem! So I added a new method to cocoon that sets up an object just as if it were an Avalon component by honoring the various lifecycle interfaces. Some useful lifecycle interfaces to implement are of course LogEnabled and Serviceable, but also Contextualizable, which gives access to the object model through the ContextHelper class. Example: var foo = new Foo(); cocoon.setupObject(foo); foo.doIt(blah); This way of setting up object respects IOC, avoids using the very specific FOM_Cocoon class and gently educates people to the good things provided by Avalon. WDYT? I like your solution - big +1 to add it to the FOM! This also means that this object can used as Avalon components outside of flowscript, doesn't it? -- Reinhard
Re: Introducing IOC for Java classes created in flowscript
Reinhard Poetz wrote:
From: Sylvain Wallez
Hi all,
Flowscript currently gives two means to use Java classes: use components (cocoon.getComponent()) or simply create a Java object and use it (new MyClass()). As it's not very convenient to create a new component and install it in cocoon.xconf just to call Java code from the flow, the second solution is often used.
yep, unfortunatly ...
I don't agree with this unfortunately: writing and installing a
component is not an easy task for a newbie, and if it's the only
solution we provide for calling Java code from flowscript, many will
turn around and go away.
As said Alan Kay: Simple things should be simple, complex things should
be possible!
But a problem comes when these Java objects need to access e.g. request parameters, session attributes, components, etc: the only way is to pass them the cocoon object that provides this access.
But cocoon is of class FOM_Cocoon which is very specific to the internals of flowscript and linking code to this specific class isn't IMO a good thing to do. Furthermore, accessing elements of the object model through getters isn't consistent with the way it's usually done in other Cocoon code and violates IOC.
yep. when I startet to add interception capabilities to flowscript I had to copy the existing FOM_Cocoon because it had direct references to the interpreter (I think this needs some re-thinking ...) Anyway: If we once have more than one ControlFlow impl (not necessarily in the cocoon-cvs but maybe outside) this will become a problem!
Exactly. Furthermore, and because it's an internal class, the FOM_Cocoon
class exposes lots of methods that should not normally be used by
application code and potentially open the door to smart abuses.
So I added a new method to cocoon that sets up an object just as if it were an Avalon component by honoring the various lifecycle interfaces.
Some useful lifecycle interfaces to implement are of course LogEnabled and Serviceable, but also Contextualizable, which gives access to the object model through the ContextHelper class.
Example:
var foo = new Foo();
cocoon.setupObject(foo);
foo.doIt(blah);
This way of setting up object respects IOC, avoids using the very
specific FOM_Cocoon class and gently educates people to the good
things provided by Avalon.
WDYT?
I like your solution - big +1 to add it to the FOM!
This also means that this object can used as Avalon components outside of flowscript, doesn't it?
Sure! That's why I wrote that it gently educates people to Avalon.
Once people will have implemented lifecycle interfaces, the next step is
to declare the component in cocoon.xconf and move to the regular
component lookup mechanism.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Introducing IOC for Java classes created in flowscript
Le Jeudi, 20 nov 2003, à 17:49 Europe/Zurich, Sylvain Wallez a écrit : ...I don't agree with this unfortunately: writing and installing a component is not an easy task for a newbie, and if it's the only solution we provide for calling Java code from flowscript, many will turn around and go away... Just wildthinking here: I've been using BeanShell (http://www.beanshell.org/) recently, and with it you can very easily write scripts that implement java interfaces. This means that BeanShell (dunno if BSF does this too) scripts could be called from flow *and* interpreted *and* implement Avalon or Cocoon interfaces. I haven't thought about all implications but it might be a nice intermediate solution between limited interpreted stuff and full-blown java coding. ...Sure! That's why I wrote that it gently educates people to Avalon. Once people will have implemented lifecycle interfaces, the next step is to declare the component in cocoon.xconf and move to the regular component lookup mechanism... So maybe scripting Avalon interfaces could be a first step in this education? Again, just wild thoughts - fire at will ;-) -Bertrand
Re: Introducing IOC for Java classes created in flowscript
Bertrand Delacretaz wrote:
Le Jeudi, 20 nov 2003, à 17:49 Europe/Zurich, Sylvain Wallez a écrit :
...I don't agree with this unfortunately: writing and installing a
component is not an easy task for a newbie, and if it's the only
solution we provide for calling Java code from flowscript, many will
turn around and go away...
Just wildthinking here: I've been using BeanShell
(http://www.beanshell.org/) recently, and with it you can very easily
write scripts that implement java interfaces.
This means that BeanShell (dunno if BSF does this too) scripts could
be called from flow *and* interpreted *and* implement Avalon or Cocoon
interfaces. I haven't thought about all implications but it might be a
nice intermediate solution between limited interpreted stuff and
full-blown java coding.
Rhino also provides some very easy solutions to this:
- http://www.mozilla.org/rhino/tutorial.html#ImplementingInterfaces
- paragraph JavaAdapter constructor at
http://www.mozilla.org/rhino/scriptjava.html
...Sure! That's why I wrote that it gently educates people to
Avalon. Once people will have implemented lifecycle interfaces, the
next step is to declare the component in cocoon.xconf and move to the
regular component lookup mechanism...
So maybe scripting Avalon interfaces could be a first step in this
education?
Mmmh... Not sure it would be a good education ;-)
But it can certainly be useful for quick hack prototypes!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Introducing IOC for Java classes created in flowscript
Ugo Cei wrote:
Sylvain Wallez wrote:
So I added a new method to cocoon that sets up an object just as if
it were an Avalon component by honoring the various lifecycle
interfaces.
At first sight, this looks incredibly useful. Bug +1 from me!
Thanks. The main purpose is to avoid the dependency on FOM_Cocoon. Doing
it the Avalon way is an additional bonus ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: Introducing IOC for Java classes created in flowscript
From: Sylvain Wallez Reinhard Poetz wrote: From: Sylvain Wallez Hi all, Flowscript currently gives two means to use Java classes: use components (cocoon.getComponent()) or simply create a Java object and use it (new MyClass()). As it's not very convenient to create a new component and install it in cocoon.xconf just to call Java code from the flow, the second solution is often used. yep, unfortunatly ... I don't agree with this unfortunately: writing and installing a component is not an easy task for a newbie, and if it's the only solution we provide for calling Java code from flowscript, many will turn around and go away. sorry, my unfortunatly was a bit misleading. I agree with you completly in this point! As said Alan Kay: Simple things should be simple, complex things should be possible! :-) But a problem comes when these Java objects need to access e.g. request parameters, session attributes, components, etc: the only way is to pass them the cocoon object that provides this access. But cocoon is of class FOM_Cocoon which is very specific to the internals of flowscript and linking code to this specific class isn't IMO a good thing to do. Furthermore, accessing elements of the object model through getters isn't consistent with the way it's usually done in other Cocoon code and violates IOC. yep. when I startet to add interception capabilities to flowscript I had to copy the existing FOM_Cocoon because it had direct references to the interpreter (I think this needs some re-thinking ...) Anyway: If we once have more than one ControlFlow impl (not necessarily in the cocoon-cvs but maybe outside) this will become a problem! Exactly. Furthermore, and because it's an internal class, the FOM_Cocoon class exposes lots of methods that should not normally be used by application code and potentially open the door to smart abuses. So I added a new method to cocoon that sets up an object just as if it were an Avalon component by honoring the various lifecycle interfaces. Some useful lifecycle interfaces to implement are of course LogEnabled and Serviceable, but also Contextualizable, which gives access to the object model through the ContextHelper class. Example: var foo = new Foo(); cocoon.setupObject(foo); foo.doIt(blah); This way of setting up object respects IOC, avoids using the very specific FOM_Cocoon class and gently educates people to the good things provided by Avalon. WDYT? I like your solution - big +1 to add it to the FOM! This also means that this object can used as Avalon components outside of flowscript, doesn't it? Sure! That's why I wrote that it gently educates people to Avalon. Once people will have implemented lifecycle interfaces, the next step is to declare the component in cocoon.xconf and move to the regular component lookup mechanism. indeed, a very good idea! -- Reinhard
Re: Introducing IOC for Java classes created in flowscript
Le Jeudi, 20 nov 2003, à 18:12 Europe/Zurich, Sylvain Wallez a écrit : ...Rhino also provides some very easy solutions to this: - http://www.mozilla.org/rhino/tutorial.html#ImplementingInterfaces - paragraph JavaAdapter constructor at http://www.mozilla.org/rhino/scriptjava.html ok, cool, I wasn't aware of this, looks similar to what BeanShell does. The advantage with BeanShell is that the syntax *is* java - one can prototype in script and later move the code to compilable classes (just FYI - I don't mean we should switch now ;-) So maybe scripting Avalon interfaces could be a first step in this education? Mmmh... Not sure it would be a good education ;-) But it can certainly be useful for quick hack prototypes! Even more if the syntax was java! Food for thought I guess.. -Bertrand
DO NOT REPLY [Bug 24871] New: - jsp block functionality broken, running on resin 3.0.x
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24871. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24871 jsp block functionality broken, running on resin 3.0.x Summary: jsp block functionality broken, running on resin 3.0.x Product: Cocoon 2 Version: 2.1.2 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: general components AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] compiled and installed cocoon 2.1.2, running on the resin 3.0.4 application server. everything seems to be working just fine, though when trying to run jsp within cocoon i get a java null pointer exception. this bug was also confirmed by joerg heinicki on the [EMAIL PROTECTED] mailing list, see emails [EMAIL PROTECTED], [EMAIL PROTECTED], and [EMAIL PROTECTED]. the error we get is Original Exception: java.lang.NullPointerException at com.caucho.jsp.BufferedJspWriter.flushBuffer(BufferedJspWriter.java:424) at com.caucho.jsp.BufferedJspWriter.privateClose(BufferedJspWriter.java:372) at com.caucho.jsp.PageContextImpl.release(PageContextImpl.java:1014) at com.caucho.jsp.QJspFactory.freePageContext(QJspFactory.java:115) at _samples._jsp._welcome__jsp._jspService(_welcome__jsp.java:37) at com.caucho.jsp.JavaPage.service(JavaPage.java:75) at com.caucho.jsp.QServlet.service(QServlet.java:164) at org.apache.cocoon.components.jsp.JSPEngineImpl.executeJSP(JSPEngineImpl.java:122) at org.apache.cocoon.generation.JspGenerator.generate(JspGenerator.java:114) works every time :)
DO NOT REPLY [Bug 24871] - jsp block functionality broken, running on resin 3.0.x
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24871. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24871 jsp block functionality broken, running on resin 3.0.x --- Additional Comments From [EMAIL PROTECTED] 2003-11-20 20:49 --- forgot to write our cocoon.xconf for jsp processing, here it is jsp-engine logger=core.jsp-engine parameter name=servlet-class value=com.caucho.jsp.JspServlet/ parameter name=servlet-name value=*.jsp/ /jsp-engine
Re: Introducing IOC for Java classes created in flowscript
Bertrand Delacretaz wrote:
Le Jeudi, 20 nov 2003, à 18:12 Europe/Zurich, Sylvain Wallez a écrit :
...Rhino also provides some very easy solutions to this:
- http://www.mozilla.org/rhino/tutorial.html#ImplementingInterfaces
- paragraph JavaAdapter constructor at
http://www.mozilla.org/rhino/scriptjava.html
ok, cool, I wasn't aware of this, looks similar to what BeanShell does.
The advantage with BeanShell is that the syntax *is* java - one can
prototype in script and later move the code to compilable classes
(just FYI - I don't mean we should switch now ;-)
Sounds interesting. But you know the initial requirement for any
flowscript language: continuations...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Introducing IOC for Java classes created in flowscript
Sylvain Wallez wrote: Bertrand Delacretaz wrote: Le Jeudi, 20 nov 2003, à 18:12 Europe/Zurich, Sylvain Wallez a écrit : ...Rhino also provides some very easy solutions to this: - http://www.mozilla.org/rhino/tutorial.html#ImplementingInterfaces - paragraph JavaAdapter constructor at http://www.mozilla.org/rhino/scriptjava.html ok, cool, I wasn't aware of this, looks similar to what BeanShell does. The advantage with BeanShell is that the syntax *is* java - one can prototype in script and later move the code to compilable classes (just FYI - I don't mean we should switch now ;-) Sounds interesting. But you know the initial requirement for any flowscript language: continuations... If I understood Bertrands hint towards BeanShell right, it would allow the people who are affraid of writing real Java code to script an object which is then used in the flowscript we have today - not replacing the current continuation language, but easing the transition for scripters towards Java for objects to be called from the flowscript. Best regards, Michael Hartle, Hartle Klug Consulting GmbH
Re: Introducing IOC for Java classes created in flowscript
Sylvain Wallez wrote: . So I added a new method to cocoon that sets up an object just as if it were an Avalon component by honoring the various lifecycle interfaces. Some useful lifecycle interfaces to implement are of course LogEnabled and Serviceable, but also Contextualizable, which gives access to the object model through the ContextHelper class. Example: var foo = new Foo(); cocoon.setupObject(foo); foo.doIt(blah); This way of setting up object respects IOC, avoids using the very specific FOM_Cocoon class and gently educates people to the good things provided by Avalon. To make it even more avalonish, this method should instantiate object as well. So it will become: var foo = cocoon.summonObject(com.mycompany.Foo); Vadim
Re: Introducing IOC for Java classes created in flowscript
Le Vendredi, 21 nov 2003, à 02:49 Europe/Zurich, Michael Hartle a écrit : Sylvain Wallez wrote: Bertrand Delacretaz wrote: ...The advantage with BeanShell is that the syntax *is* java - one can prototype in script and later move the code to compilable classes (just FYI - I don't mean we should switch now ;-) Sounds interesting. But you know the initial requirement for any flowscript language: continuations... If I understood Bertrands hint towards BeanShell right, it would allow the people who are affraid of writing real Java code to script an object which is then used in the flowscript we have today - not replacing the current continuation language, but easing the transition for scripters towards Java for objects to be called from the flowscript. Exactly - and it would be a nice prototyping environment as well, with the ability to easily move scripted BeanShell code to java classes later on. -Bertrand
[Woody] - wd:hotkey status?
Hi: Reviewing old mails, I found we agreed to add to the woody template specification an initial tag that was called wd:hotkey http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105848333001636w=2 Please, follow the above thread. I don't know if I miss something, but I don't see it anymore. Best Regads, Antonio Gallardo
