You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by xweber <xw...@googlemail.com> on 2007/07/01 17:02:20 UTC
cocoon 2.2 - some more questions
hi,
actually i'm trying to get a 2.2 based thingy up and running. Based on the
existing daisy docs there are some questions "open" for me. Current
questions:
1.) the demo-application-context.xml file
what about that filename - must it reflect the package name? Or must there
only be a file ending with ..-application-context.xml. Is there only one of
this files for all packages in that block?
2.) as in the tutorials i have two or more blocks and one webapp type
folders. I fire up the webapp part with mvn jetty:run inside it.
Unfortuanatly the rcl (reloading on change) stuff did not work. Is there a
way to get it also up when started via webapp part?
Alex
--
View this message in context: http://www.nabble.com/cocoon-2.2---some-more-questions-tf4008051.html#a11382520
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: cocoon 2.2 - some more questions
Posted by Grzegorz Kossakowski <gk...@apache.org>.
xweber pisze:
> ...and another one :-)
>
> Is there a way to "trace" how the http is proceed inside sitemap & co?
>
> I have read about a profiler, but this one seems not to exists in 2.2 (so
> far).
Alex, I see that you switch from reporting things useful for _developing_ Cocoon (I mean
http://thread.gmane.org/gmane.text.xml.cocoon.devel/73739, thanks, I'm going to address your emails tomorrow) to asking question about
_using_ Cocoon.
For such questions it is much better to ask them at users mailing list (users@cocoon.apache.org) so other can benefit from answers to your
questions. Also, creating new, descriptive threads for things totally unrelated will not hurt. :)
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: cocoon 2.2 - some more questions
Posted by xweber <xw...@googlemail.com>.
...and another one :-)
Is there a way to "trace" how the http is proceed inside sitemap & co?
I have read about a profiler, but this one seems not to exists in 2.2 (so
far).
Thanks in advance
Alex
--
View this message in context: http://www.nabble.com/cocoon-2.2---some-more-questions-tf4008051.html#a11421163
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: cocoon 2.2 - some more questions
Posted by Reinhard Poetz <re...@apache.org>.
Joerg Heinicke wrote:
> On 02.07.2007 21:39, xweber wrote:
>
>> is it possible to call java directly from sitemap.xmap - so that
>> "java" is
>> the flow language? I looked up in the docs but did not find something
>> like
>> that. If its possible - is the a docs like it is for flowscript?
>
> Yes, there is a Java equivalent for flow script. It's mostly called
> javaflow. The API should actually be the same. I'm not aware of some
> documentation. But a search on both lists should reveal some comparisons.
Unfortunatly Javaflow doesn't work in trunk (AFAIK).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: cocoon 2.2 - some more questions
Posted by Joerg Heinicke <jo...@gmx.de>.
On 02.07.2007 21:39, xweber wrote:
> is it possible to call java directly from sitemap.xmap - so that "java" is
> the flow language? I looked up in the docs but did not find something like
> that. If its possible - is the a docs like it is for flowscript?
Yes, there is a Java equivalent for flow script. It's mostly called
javaflow. The API should actually be the same. I'm not aware of some
documentation. But a search on both lists should reveal some comparisons.
Joerg
Re: cocoon 2.2 - some more questions
Posted by xweber <xw...@googlemail.com>.
ok, here is one more - sorry :-)
is it possible to call java directly from sitemap.xmap - so that "java" is
the flow language? I looked up in the docs but did not find something like
that. If its possible - is the a docs like it is for flowscript?
Alex
--
View this message in context: http://www.nabble.com/cocoon-2.2---some-more-questions-tf4008051.html#a11400315
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: cocoon 2.2 - some more questions
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
>> ok, i can guess the first line - but why (and when) to exclude libs?
>> The doc
>> http://cocoon.zones.apache.org/daisy/cdocs/g1/g5/g1/g1/1298.html does not
>> give that much detailed information yet
>
> I'm not sure (I hope that Reinhard will comment) but I think that you
> include classes compiled by your IDE (first line) and thus you must
> exclude classes from JAR of block2. If we didn't do this, we would have
> every class in classpath present twice.
exactly. If you want to make sure that the JAR is not pulled from your local
repository and added to your classpath, exclude lib helps.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: cocoon 2.2 - some more questions
Posted by Grzegorz Kossakowski <gk...@apache.org>.
xweber pisze:
> wow - i am glad to know my crystalball is still working ;-)
;)
>> Most of the infrastructure is already there (especially configuration,
>> building and packaging parts).
>>
> building and packaging via maven?
Yes.
> I have discovered that ones (thanks to the
> tutorial steps)
> configuration? well - you mean the pom.xml things?
No, no. We have fairy powerful Spring configurator module, see:
http://cocoon.zones.apache.org/daisy/cdocs-spring-configurator/g1/1304.html
and info about new features (that are not documented yet):
http://thread.gmane.org/gmane.text.xml.cocoon.devel/70670
Thanks to Carsten's work you can configure almost everything using properties. This way you can get a block packaged as JAR and customize
its component definitions and dependencies very heavily. I guess it covers all configuration needs.
>> The only part still
>> under development is wiring (servlet-service-fw). With blocks polymorphism
>> (see COCOON-2038 issue) and postable source (see COCOON-2046) you
>> will get all needed tools to handle even more sophisticated set-ups.
>>
> polymorphism would be nice for the database implementation of the concrete
> drivers (backend).
That kind of polymorphism is achieved with Spring and configurator mechanism. For example, you can always configure a concrete class to use
other DB provider (also a Spring component) that you have implemented.
> For wiring beyond spring block i thought i could use
> something like "inner piplelines".
We have had a concept of internal requests for years in Cocoon. What servlet-service-fw brings new is something like that:
<map:generate src="page-template"/>
[some transformations]
<map:serialize type="servletService">
<map:paramter name="service" value="servlet:styling-block:/service/transformToHtml"/>
</map:serialize>
You define "styling-block" as block's connection, and have in styling-block you have:
<map:match pattern="service/transformToHtml">
<map:generate src="service-consumer:">
<map:transform src="some-styling.xsl"/>
<map:serialize type="html"/>
</map:match>
Ok, it's nice because you can have one block that is responsible for styling but it's not the end of story. Polymorphism begins when you
create a third block, let's call it "fancy-styling-block", and declare that "styling-block" is its super block.
Now, thanks to properties, you can change connection declared in first block, so it connects to "fancy-styling-block" instead of
"styling-block". Next you define in "fancy-styling-block" another matcher:
<map:match pattern="service/transformToHtml">
<map:generate src="service-consumer:">
<map:transform src="some-fancy-styling.xsl"/>
<map:serialize type="html"/>
</map:match>
This way you _override_ pipeline from "styling-block". Of course, you can override only a few pipelines you want to customize and leave rest
untouched.
This way you get very powerful mechanism for extending your blocks.
> yes, there are a lot of question (which is still first try to figure out
> myself).
> But here is one:
>
> rcl.properties reads like:
> com.mycompany.myBlock2.block%classes-dir=../myBlock2/target/classes
> %exclude-lib=com.mycompany:myBlock2
>
> ok, i can guess the first line - but why (and when) to exclude libs? The doc
> http://cocoon.zones.apache.org/daisy/cdocs/g1/g5/g1/g1/1298.html does not
> give that much detailed information yet
I'm not sure (I hope that Reinhard will comment) but I think that you include classes compiled by your IDE (first line) and thus you must
exclude classes from JAR of block2. If we didn't do this, we would have every class in classpath present twice.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: cocoon 2.2 - some more questions
Posted by xweber <xw...@googlemail.com>.
Grzegorz Kossakowski-3 wrote:
>
> I see. I think you have described the use case for C2.2 architecture. It's
> basically what blocks has been designed for (but not only for
> such situations).
>
wow - i am glad to know my crystalball is still working ;-)
> Most of the infrastructure is already there (especially configuration,
> building and packaging parts).
>
building and packaging via maven? I have discovered that ones (thanks to the
tutorial steps)
configuration? well - you mean the pom.xml things?
> The only part still
> under development is wiring (servlet-service-fw). With blocks polymorphism
> (see COCOON-2038 issue) and postable source (see COCOON-2046) you
> will get all needed tools to handle even more sophisticated set-ups.
>
polymorphism would be nice for the database implementation of the concrete
drivers (backend). For wiring beyond spring block i thought i could use
something like "inner piplelines".
> If you have concrete question (how to achieve x) feel free to ask, I'll be
> happy to answer them only if I can help.
>
yes, there are a lot of question (which is still first try to figure out
myself).
But here is one:
rcl.properties reads like:
com.mycompany.myBlock2.block%classes-dir=../myBlock2/target/classes
%exclude-lib=com.mycompany:myBlock2
ok, i can guess the first line - but why (and when) to exclude libs? The doc
http://cocoon.zones.apache.org/daisy/cdocs/g1/g5/g1/g1/1298.html does not
give that much detailed information yet
Alex
--
View this message in context: http://www.nabble.com/cocoon-2.2---some-more-questions-tf4008051.html#a11384177
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: cocoon 2.2 - some more questions
Posted by Grzegorz Kossakowski <gk...@apache.org>.
xweber pisze:
> well i am thinking of a portal. So there will be a core block (to manage the
> main sitemap), one or more skin blocks for final layout, some lib-blocks for
> extending the core with e.g. database, mail and that kind of functionality.
> And modules like blocks for features to the portal (the ones who will
> provide the content). That as a generic portal (combination). Now you want
> to have a concrete portal with that parts. Instead of modifying settings in
> core (and database) for the concrete informations, and what modules to use
> (maybe you do not want to have the module-tictactoe in your portal) all you
> need to do is not to set the dependency to that module in the "webapp"
> pom.xml. So that is the kind of configurations-block i had in mind.
I see. I think you have described the use case for C2.2 architecture. It's basically what blocks has been designed for (but not only for
such situations). Most of the infrastructure is already there (especially configuration, building and packaging parts). The only part still
under development is wiring (servlet-service-fw). With blocks polymorphism (see COCOON-2038 issue) and postable source (see COCOON-2046) you
will get all needed tools to handle even more sophisticated set-ups.
I plan to write docs for servlet-service-fw tomorrow and explain the big picture so everyone will know what incredible functionality it
already offers (or will offer soon) and what help is needed. The plan may change a little because my top priority is GSoC-related development.
If you have concrete question (how to achieve x) feel free to ask, I'll be happy to answer them only if I can help.
> I know there is a portal in Cocoon 2.1 and there will be one in 2.2 (at
> least i think so). Maybe that approach i have in mind is a bit more spring
> like to set the parts together. I dont even know if it possible.
I must admit I have not that my experience with portal functionality, either. I hope that others can join and comment on its status in
Cocoon 2.2.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: cocoon 2.2 - some more questions
Posted by xweber <xw...@googlemail.com>.
well i am thinking of a portal. So there will be a core block (to manage the
main sitemap), one or more skin blocks for final layout, some lib-blocks for
extending the core with e.g. database, mail and that kind of functionality.
And modules like blocks for features to the portal (the ones who will
provide the content). That as a generic portal (combination). Now you want
to have a concrete portal with that parts. Instead of modifying settings in
core (and database) for the concrete informations, and what modules to use
(maybe you do not want to have the module-tictactoe in your portal) all you
need to do is not to set the dependency to that module in the "webapp"
pom.xml. So that is the kind of configurations-block i had in mind.
I know there is a portal in Cocoon 2.1 and there will be one in 2.2 (at
least i think so). Maybe that approach i have in mind is a bit more spring
like to set the parts together. I dont even know if it possible.
Alex
--
View this message in context: http://www.nabble.com/cocoon-2.2---some-more-questions-tf4008051.html#a11383411
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: cocoon 2.2 - some more questions
Posted by Grzegorz Kossakowski <gk...@apache.org>.
xweber pisze:
>
>
>> If you follow tutorials really carefully RCL plug-in must work for you, it
>> has been tested rather thoroughly.
>>
>
> Yes for Block(s) the RCL is working. Seems I am still struggeling how to pu
> the parts together :-)
>
> archetype webapp is the last part in development. I thought I could use it
> as a kind of "config" holder for my other blocks (e.g. property files for
> other blocks)- which should be tied together for a plugin like structure. So
> for me it seems I am in the need to have this config-part to be a block
> archetype - because I can use the RCL feature of it for development.
What kind of configuration do have in mind? If it's an application-specific configuration (properties) the idea to tweak them in webapp is
quite reasonable. Still I don't understand why do you want to start whole application from webapp, you can develop particular blocks with
any properties you like to test.
If you provide more detailed description of what you really want to achieve it will be easier to help you.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: cocoon 2.2 - some more questions
Posted by xweber <xw...@googlemail.com>.
> If you follow tutorials really carefully RCL plug-in must work for you, it
> has been tested rather thoroughly.
>
Yes for Block(s) the RCL is working. Seems I am still struggeling how to pu
the parts together :-)
archetype webapp is the last part in development. I thought I could use it
as a kind of "config" holder for my other blocks (e.g. property files for
other blocks)- which should be tied together for a plugin like structure. So
for me it seems I am in the need to have this config-part to be a block
archetype - because I can use the RCL feature of it for development.
Alex
--
View this message in context: http://www.nabble.com/cocoon-2.2---some-more-questions-tf4008051.html#a11382998
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: cocoon 2.2 - some more questions
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> xweber pisze:
>> hi,
>>
>> actually i'm trying to get a 2.2 based thingy up and running. Based on
>> the
>> existing daisy docs there are some questions "open" for me. Current
>> questions:
>>
>> 1.) the demo-application-context.xml file
>> what about that filename - must it reflect the package name? Or must
>> there
>> only be a file ending with ..-application-context.xml. Is there only
>> one of
>> this files for all packages in that block?
>
> You can choose filename whatever you like. The only requirement is its
> location, it must be located at MEA-INF/cocoon/spring since all Spring
> configuration is read from there by default.
IIRC the .xml suffix is mandatory.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: cocoon 2.2 - some more questions
Posted by Grzegorz Kossakowski <gk...@apache.org>.
xweber pisze:
> hi,
>
> actually i'm trying to get a 2.2 based thingy up and running. Based on the
> existing daisy docs there are some questions "open" for me. Current
> questions:
>
> 1.) the demo-application-context.xml file
> what about that filename - must it reflect the package name? Or must there
> only be a file ending with ..-application-context.xml. Is there only one of
> this files for all packages in that block?
You can choose filename whatever you like. The only requirement is its location, it must be located at MEA-INF/cocoon/spring since all
Spring configuration is read from there by default.
> 2.) as in the tutorials i have two or more blocks and one webapp type
> folders. I fire up the webapp part with mvn jetty:run inside it.
> Unfortuanatly the rcl (reloading on change) stuff did not work. Is there a
> way to get it also up when started via webapp part?
No. Webapp (create from webapp archetype) is useful when you want to create a package of your application (e.g. a WAR file that can be
dropped in Tomcat's working directory). Of course, you can use it also for starting your application but since we have a RCL plug-in it is
not advised to use webapp for development.
If you follow tutorials really carefully RCL plug-in must work for you, it has been tested rather thoroughly.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/