You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2005/05/26 14:34:56 UTC
[RT] Block usage
David Casal wrote:
<snip/>
> how do you see the common user approaching the development of new
> webapp, considering they might not have a senior level of development
> experience? Could you illustrate your ideal use case scenario?
<snip/>
We haven't discussed use case scenarious in a more systematic way for
quite some time. Bits and pieces have been discussed in technical
threads although not in any way that have been easy to follow for those
not involved in the specifics. What's described in
http://wiki.apache.org/cocoon/BlockIntroduction and
http://wiki.apache.org/cocoon/BlocksUseCases still holds. But Cocoon has
changed since then, new technologies have appeared and we have learnt
more by discussing and trying to implement the blocks so it could be
worthwhile to discuss the user experience of blocks again.
I'll mix up the use case with some technical details on how it might be
implemented. The terms block, bundle and plugin are synonymes in this RT.
Ok, here is my current view:
A basic scenario
================
1. A soon to become Cocoon user, downloads the "start kit" distribution
from our site.
It contains the (OSGi) kernel, the Cocoon service block (containing the
Cocoon core), a Cocoon servlet block, a (light weight) web server
block, a block deployer block, a block depoyer webapp block, a "get
started" tutorial block and some basic blocks (template, cforms, xslt,
flow, ...) that the previous blocks depends on.
2. The user double clicks the distribution and answer where to install
it and whether the tutorial webapp should be started.
It is not certain that the distribution contains all the above
physically, it might download its dependencies during this step. Those
thinking about using Maven etc can probably give a better view on this.
If the user chose to start the tutorial webapp, the kernel will be
started and the blocks listed above will be installed into the kernel
and started. The start page for the tutorial will be mounted at e.g. "/"
and will be served through the call chain: web server block -> Cocoon
servlet block -> Cocoon service block -> "Get started" tutorial block.
3. The user points the browser at http://localhost:8888/ and start to
follow the tutorial.
Here we have IMO a lot to learn from Forrest. When you have dowloaded
and installed Forrest you directly gets instructions about how to start
use it.
4. The user can chose between following a number of different wizard
like tutorials, e.g.: Minimal Cocoon app, documentation site (Forrest),
portal, CMS site (Lenya or Daisy), Spring based webapp etc.
In this step the needed blocks (including the specific tutorial/wizard)
will be dowloaded, installed and started. A user block skeleton will be
created. It should be noted that the created user block is much simpler
than what is needed today. It is a directory with a description of what
blocks the block depends on (wiring.xml and the Manifest file), a near
to empty sitemap and that is all.
5. The user start to develop the new application from the skeleton one
and have at all times a working app that can be used from the browser.
I think polymorphic extension will be a key mechanism for making it easy
for users to develop new apps. Let us say that you want to create a
documentation site. Then your skeleton block extends the Forrest block,
which allready contain an example documentation site. By extending the
Forrest block, your new this far empty, block allready delivers content.
The Forrest block is designed in such a way that everything that you
might want to change or extend: content, menues, styling, configuration
etc is available through the blocks sitemap (some of it only
internally). By overiding the URLs of these things in your own sitemap
with own content you can one step at the time adapt the default app to
your own needs. For some of the inherited resources you just want to
modify the original content. This can be done by applying a stylesheet
on "block:super:". Also components from the extended block can be overrided.
6. The new block contain some new and intersting stuff that is not
available before. After a number of refactorings it consists of a number
of blocks that are reusable and solves well defined concerns. Now the
user puts the blocks in a new project in Sourceforge (or cocoondev.org etc).
An important aspect of blocks is that they can make Cocoon development
much more scalable and distributed. To make this possible we must, IMO,
split the Cocoon core of today in a number of blocks. These blocks
should have well defined concern areas, and in some cases own release
cycles. We should also be much more carefull about what is external
interfaces and classes and what is only for internal use.
Above all we should have a lean, mean and rock stable core, containing
the basic mechanisms for the sitemap and (possibly) component management
and the minimal set of core interfaces. This is a must for creating a
stable fundament that external blocks developers can put their trust in.
--- o0o ---
I would assume that we will have an Cocoon Eclipse starting kit distro
as well. With IDE support, the user can get much more support and
guiding in the above described process. The Lepido crew will hopefully
give a view on that.
WDYT?
/Daniel
Re: [RT] Block usage
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
<snip/>
>> A basic scenario
>> ================
>>
>> 1. A soon to become Cocoon user, downloads the "start kit"
>> distribution from our site.
>>
>> It contains the (OSGi) kernel, the Cocoon service block (containing
>> the Cocoon core), a Cocoon servlet block,
>
> ok
>
>> a (light weight) web server block,
>
> you mean a block that contains e.g. Jetty or Tomcat?
Yes, there is a standard http service api in the OSGi spec, and there
are bundles based on both Jetty and Tomcat that implement that api.
> IMO this could only be an option but not a requirement. Cocoon must
> be deployable in a J2EE or servlet container.
As we have discussed before we should support both cases. What I
describe is a "start kit" distribution that helps a new user to get up
to speed. Puting a http service block in the "start kit" distro
coresponds to our current bundling of Jetty. All blocks should be
separately downloadable so that the experienced users can mix and match
as they want to.
>> a block deployer block
>
> Basically the block deployer will be a stand-alone application (Ant
> task, Maven plug-in, Eclipse plug-in, ...). Of course somebody could
> write a web interface for it which could be a cocoon block.
As you can see in my original message I proposed: a block deployer
block, a block depoyer webapp block. Web interface and functinality
should cleary be kept separately.
<snip/>
> called block.xml, no?
>
> (wiring.xml and the Manifest file), a near
Yes, block.xml.
<snip/>
> One thing to add: It must be possible that one block depends on
> another block that is under development. I want my custom projects
> requiring the latest svn version of e.g. the forms block. If the forms
> block changes, this change takes effect immediatly on my project
> without explicit deployment.
Absolutely!
/Daniel
Re: [RT] Block usage
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> David Casal wrote:
> <snip/>
>
>> how do you see the common user approaching the development of new
>> webapp, considering they might not have a senior level of development
>> experience? Could you illustrate your ideal use case scenario?
>
>
> <snip/>
>
> We haven't discussed use case scenarious in a more systematic way for
> quite some time. Bits and pieces have been discussed in technical
> threads although not in any way that have been easy to follow for those
> not involved in the specifics. What's described in
> http://wiki.apache.org/cocoon/BlockIntroduction and
> http://wiki.apache.org/cocoon/BlocksUseCases still holds. But Cocoon has
> changed since then, new technologies have appeared and we have learnt
> more by discussing and trying to implement the blocks so it could be
> worthwhile to discuss the user experience of blocks again.
>
> I'll mix up the use case with some technical details on how it might be
> implemented. The terms block, bundle and plugin are synonymes in this RT.
>
> Ok, here is my current view:
>
> A basic scenario
> ================
>
> 1. A soon to become Cocoon user, downloads the "start kit" distribution
> from our site.
>
> It contains the (OSGi) kernel, the Cocoon service block (containing the
> Cocoon core), a Cocoon servlet block,
ok
> a (light weight) web server block,
you mean a block that contains e.g. Jetty or Tomcat? IMO this could only be an
option but not a requirement. Cocoon must be deployable in a J2EE or servlet
container.
> a block deployer block
Basically the block deployer will be a stand-alone application (Ant task, Maven
plug-in, Eclipse plug-in, ...). Of course somebody could write a web interface
for it which could be a cocoon block.
, a block depoyer webapp block, a "get
> started" tutorial block and some basic blocks (template, cforms, xslt,
> flow, ...) that the previous blocks depends on.
ok
> 2. The user double clicks the distribution and answer where to install
> it and whether the tutorial webapp should be started.
>
> It is not certain that the distribution contains all the above
> physically,
we can have different distributions
> it might download its dependencies during this step. Those
> thinking about using Maven etc can probably give a better view on this.
>
> If the user chose to start the tutorial webapp, the kernel will be
> started and the blocks listed above will be installed into the kernel
> and started. The start page for the tutorial will be mounted at e.g. "/"
> and will be served through the call chain: web server block -> Cocoon
> servlet block -> Cocoon service block -> "Get started" tutorial block.
>
>
> 3. The user points the browser at http://localhost:8888/ and start to
> follow the tutorial.
>
> Here we have IMO a lot to learn from Forrest. When you have dowloaded
> and installed Forrest you directly gets instructions about how to start
> use it.
>
>
> 4. The user can chose between following a number of different wizard
> like tutorials, e.g.: Minimal Cocoon app, documentation site (Forrest),
> portal, CMS site (Lenya or Daisy), Spring based webapp etc.
>
> In this step the needed blocks (including the specific tutorial/wizard)
> will be dowloaded, installed and started. A user block skeleton will be
> created. It should be noted that the created user block is much simpler
> than what is needed today. It is a directory with a description of what
> blocks the block depends on
called block.xml, no?
(wiring.xml and the Manifest file), a near
> to empty sitemap and that is all.
>
>
> 5. The user start to develop the new application from the skeleton one
> and have at all times a working app that can be used from the browser.
>
> I think polymorphic extension will be a key mechanism for making it easy
> for users to develop new apps. Let us say that you want to create a
> documentation site. Then your skeleton block extends the Forrest block,
> which allready contain an example documentation site. By extending the
> Forrest block, your new this far empty, block allready delivers content.
> The Forrest block is designed in such a way that everything that you
> might want to change or extend: content, menues, styling, configuration
> etc is available through the blocks sitemap (some of it only
> internally). By overiding the URLs of these things in your own sitemap
> with own content you can one step at the time adapt the default app to
> your own needs. For some of the inherited resources you just want to
> modify the original content. This can be done by applying a stylesheet
> on "block:super:". Also components from the extended block can be
> overrided.
I remember one or two mails about this some months ago ;-)
>
>
> 6. The new block contain some new and intersting stuff that is not
> available before. After a number of refactorings it consists of a number
> of blocks that are reusable and solves well defined concerns. Now the
> user puts the blocks in a new project in Sourceforge (or cocoondev.org
> etc).
>
> An important aspect of blocks is that they can make Cocoon development
> much more scalable and distributed. To make this possible we must, IMO,
> split the Cocoon core of today in a number of blocks. These blocks
> should have well defined concern areas, and in some cases own release
> cycles. We should also be much more carefull about what is external
> interfaces and classes and what is only for internal use.
>
> Above all we should have a lean, mean and rock stable core, containing
> the basic mechanisms for the sitemap and (possibly) component management
> and the minimal set of core interfaces. This is a must for creating a
> stable fundament that external blocks developers can put their trust in.
ok
> --- o0o ---
>
> I would assume that we will have an Cocoon Eclipse starting kit distro
> as well. With IDE support, the user can get much more support and
> guiding in the above described process. The Lepido crew will hopefully
> give a view on that.
>
> WDYT?
One thing to add: It must be possible that one block depends on another block
that is under development. I want my custom projects requiring the latest svn
version of e.g. the forms block. If the forms block changes, this change takes
effect immediatly on my project without explicit deployment.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: [RT] Block usage
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
David Casal wrote:
> Hello Daniel,
>
> Thanks for your extremely edifying response. As with Stefano, will it be
> ok to cite some of your comments in this report? I may not cite you
> literally, but I need to credit you if I do. Would that be ok?
Sure.
> The report will be published on Techwatch:
> http://www.jisc.ac.uk/index.cfm?name=techwatch_home
>
> On 26 May 2005, at 13:34, Daniel Fagerstrom wrote:
>
> <snip>
>
>> 4. The user can chose between following a number of different wizard
>> like tutorials, e.g.: Minimal Cocoon app, documentation site
>> (Forrest), portal, CMS site (Lenya or Daisy), Spring based webapp etc.
>>
>> In this step the needed blocks (including the specific
>> tutorial/wizard) will be dowloaded, installed and started. A user
>> block skeleton will be created. It should be noted that the created
>> user block is much simpler than what is needed today. It is a
>> directory with a description of what blocks the block depends on
>> (wiring.xml and the Manifest file), a near to empty sitemap and that
>> is all.
>
> </snip>
>
> As I read from your May 20th OSGi proposal, the core and block jars are
> managed within the OSGi framework, is this correct?
Yes.
> Meaning that the
> directory a potential user is presented with is minimal because of this?
Yes, the blocks the user webapp depends on don't need to be stored
within the users webapp directory anymore.
>> 5. The user start to develop the new application from the skeleton one
>> and have at all times a working app that can be used from the browser.
>>
>> I think polymorphic extension will be a key mechanism for making it
>> easy for users to develop new apps.
>
> <snip>
>
>> Also components from the extended block can be overrided.
>
> Could you explain how?
Say that block E extends block B, block B handle the URLs /foo and /bar
and block E handle /foo. Then a user of block E (through the block:
protocol), will get /foo from E and /bar from B.
Furthermore the inheritance is polymorphic, so if the sitemap rule in B
is defining /bar in terms of (among other things) /foo by using
"block:/foo", the /foo from E will be used if /bar is used from E.
A more technical description of the block: protocol can be found in
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111265006428803&w=2.
The most comprehensive discussion about these concepts with some good
examples can be find in the, not entirelly plessant, threads:
http://marc.theaimsgroup.com/?t=111177260800002&r=1&w=2 and
http://marc.theaimsgroup.com/?t=111211349500004&r=1&w=2.
We haven't discussed component handling in any detail. But the idea is
that component names can be prefixed with the name of the block it
should be taken from. Extension and polymorphism should probably work in
the same way as for sitemap resources.
<snip/>
Reinhard answered the rest of the questions.
/Daniel
Re: [RT] Block usage
Posted by Reinhard Poetz <re...@apache.org>.
David Casal wrote:
>> 6. The new block contain some new and intersting stuff that is not
>> available before. After a number of refactorings it consists of a
>> number of blocks that are reusable and solves well defined concerns.
>> Now the user puts the blocks in a new project in Sourceforge (or
>> cocoondev.org etc).
>
>
> That's a v cool thought. Do you envision that at this point, a user who
> finds the reusable blocks in the Sourceforge project, could download
> them and run them as they are?
yes
> Meaning, would they contain Cocoon's
> core, or as you explain further, would it only contain the parts of the
> Cocoon core it needs?
It doesn't contain any parts of Cocoon core at all. It only has to compile
against Cocoon core's interfaces.
> Might it instead contain only the meta info needed
> to downloaded needed core and non-core components during install?
>
> Are you guys thinking of a central Cocoon OSGi repository all these
> externally developed block-built apps would rely on?
yes, see http://wiki.apache.org/cocoon/BlockImplementation (block deployer)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [RT] Block usage
Posted by David Casal <da...@luminas.co.uk>.
Hello Daniel,
Thanks for your extremely edifying response. As with Stefano, will it
be ok to cite some of your comments in this report? I may not cite you
literally, but I need to credit you if I do. Would that be ok?
The report will be published on Techwatch:
http://www.jisc.ac.uk/index.cfm?name=techwatch_home
On 26 May 2005, at 13:34, Daniel Fagerstrom wrote:
<snip>
> 4. The user can chose between following a number of different wizard
> like tutorials, e.g.: Minimal Cocoon app, documentation site
> (Forrest), portal, CMS site (Lenya or Daisy), Spring based webapp etc.
>
> In this step the needed blocks (including the specific
> tutorial/wizard) will be dowloaded, installed and started. A user
> block skeleton will be created. It should be noted that the created
> user block is much simpler than what is needed today. It is a
> directory with a description of what blocks the block depends on
> (wiring.xml and the Manifest file), a near to empty sitemap and that
> is all.
</snip>
As I read from your May 20th OSGi proposal, the core and block jars are
managed within the OSGi framework, is this correct? Meaning that the
directory a potential user is presented with is minimal because of
this?
> 5. The user start to develop the new application from the skeleton one
> and have at all times a working app that can be used from the browser.
>
> I think polymorphic extension will be a key mechanism for making it
> easy for users to develop new apps.
<snip>
> Also components from the extended block can be overrided.
Could you explain how?
> 6. The new block contain some new and intersting stuff that is not
> available before. After a number of refactorings it consists of a
> number of blocks that are reusable and solves well defined concerns.
> Now the user puts the blocks in a new project in Sourceforge (or
> cocoondev.org etc).
That's a v cool thought. Do you envision that at this point, a user who
finds the reusable blocks in the Sourceforge project, could download
them and run them as they are? Meaning, would they contain Cocoon's
core, or as you explain further, would it only contain the parts of the
Cocoon core it needs? Might it instead contain only the meta info
needed to downloaded needed core and non-core components during
install?
Are you guys thinking of a central Cocoon OSGi repository all these
externally developed block-built apps would rely on?
> I would assume that we will have an Cocoon Eclipse starting kit distro
> as well. With IDE support, the user can get much more support and
> guiding in the above described process. The Lepido crew will hopefully
> give a view on that.
From http://www.eclipse.org/proposals/eclipse-lepido/ :
"To this effect, there will be a Cocoon project setup wizard, that will
allow the user to choose the blocks that are to be included in the
project, also allowing also further modification of the selected blocks
during the project lifetime."
Do people here think (Sylvain?) that use of the AXE editors for the
conf files might mean, that during the setup process for a typical app
(say a portal), dependency resolutions would get solved (by download)
while the user interacts with the form? As in 'oh I'll need some CMS
functionalitiy, too'?
> WDYT?
I think it sounds great, and I thank you very much for your time.
Cheers,
David
--
David Plans Casal, Director of Research, Luminas Internet Applications
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: www.luminas.co.uk Orixo alliance: http://www.orixo.com/