You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Leigh Dodds <ld...@ingenta.com> on 2002/08/12 12:13:51 UTC
Cocoon Blocks
> This was one of the core issues Cocoon Blocks should solve in the end.>
> Giacomo
As an irregular member of this list, I keep seeing 'Blocks' being mentioned
(usually as the solution to all kinds of problems! :)
Can anyone point me to some documentation, list discussion threads, or
even scratchpad stuff that describes/demonstrates what Blocks actually
are?
I'd like to get this into the Wiki.
Cheers,
L.
--
Leigh Dodds
http://weblogs.userland.com/eclectic
"Pluralitas non est ponenda sine necessitate" -- William of Ockham
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Blocks
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Friday 16 August 2002 16:59, Giacomo Pati wrote:
>. . .
> Wasn't my explanation of a skip/access/webmail block recently enough?
FYI I have added your example to the "blocks use cases" page at CocoDocoWiki:
http://outerthought.net/wiki/Wiki.jsp?page=BlocksUseCases
Hopefully having several examples/wishlists there will help.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Blocks
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Giacomo Pati wrote:
>
> On Mon, 19 Aug 2002, Carsten Ziegeler wrote:
>
> >
> > Giacomo Pati wrote:
> > > >
> > > > I'm still looking for a real example that makes use of a
> > > > 'skin block' or a 'portal block' or something like that -
> or in other
> > > > words, an example which really uses all the features (and
> ideas) of the
> > > > blocks concept and not only a part of it.
> > >
> > > Wasn't my explanation of a skip/access/webmail block recently enough?
> > >
> > Sorry, must have missed that - do you have a pointer available?
>
> Look at
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102941595120561&w=2
>
Thanks for the pointer, Giacomo.
But I must insist, that this example is far too vague for me: we have
three cobs and they all live forever happy together. point.
But how does this really look like in the sitemap?
How does the communication between the cobs take place?
Does it really work? Is it practical?
What is the drawback, perhaps performance?
I know, creating such an example is a lot of work, but currently without
that, I can't judge if blocks are really usefull. And this could help
in showing the difference between blocks and modules.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Blocks
Posted by Giacomo Pati <gi...@apache.org>.
On Mon, 19 Aug 2002, Carsten Ziegeler wrote:
>
> Giacomo Pati wrote:
> > >
> > > I'm still looking for a real example that makes use of a
> > > 'skin block' or a 'portal block' or something like that - or in other
> > > words, an example which really uses all the features (and ideas) of the
> > > blocks concept and not only a part of it.
> >
> > Wasn't my explanation of a skip/access/webmail block recently enough?
> >
> Sorry, must have missed that - do you have a pointer available?
Look at
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102941595120561&w=2
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Blocks
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Giacomo Pati wrote:
> >
> > I'm still looking for a real example that makes use of a
> > 'skin block' or a 'portal block' or something like that - or in other
> > words, an example which really uses all the features (and ideas) of the
> > blocks concept and not only a part of it.
>
> Wasn't my explanation of a skip/access/webmail block recently enough?
>
Sorry, must have missed that - do you have a pointer available?
Thanks,
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Blocks
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 16 Aug 2002, Carsten Ziegeler wrote:
> Bertrand Delacretaz wrote:
> >
> > On Friday 16 August 2002 07:58, Carsten Ziegeler wrote:
> > >. . .
> > > The blocks RT sounds great, but I'm also interested in a real example
> > > which shows the usage of blocks
> > >. . .
> >
> > I think you were talking about the inner working of Blocks, but
> > from a user
> > point of view I have written a (dream?) use-case over at CocoDocoWiki:
> > http://outerthought.net/wiki/Wiki.jsp?page=BlocksUseCases - maybe such
> > examples help reaching a common understanding?
> >
> Hmm, ok, I think this is actually the problem about blocks - everyone
> understands it in a different way - although we refer to the same RT.
>
> I think, what you describe is more a 'module feature' and not so much
> the 'big blocks concept' - although your wish list should be possible
> with the blocks concept.
>
> I'm still looking for a real example that makes use of a
> 'skin block' or a 'portal block' or something like that - or in other
> words, an example which really uses all the features (and ideas) of the
> blocks concept and not only a part of it.
Wasn't my explanation of a skip/access/webmail block recently enough?
Giacomo
>
> > (And sorry I cannot help about the fueling stations at this time
> > - maybe you
> > could move to Australia, they have them on the other side there ;-)
> >
> ROTFL
>
> Carsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Blocks
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bertrand Delacretaz wrote:
>
> On Friday 16 August 2002 07:58, Carsten Ziegeler wrote:
> >. . .
> > The blocks RT sounds great, but I'm also interested in a real example
> > which shows the usage of blocks
> >. . .
>
> I think you were talking about the inner working of Blocks, but
> from a user
> point of view I have written a (dream?) use-case over at CocoDocoWiki:
> http://outerthought.net/wiki/Wiki.jsp?page=BlocksUseCases - maybe such
> examples help reaching a common understanding?
>
Hmm, ok, I think this is actually the problem about blocks - everyone
understands it in a different way - although we refer to the same RT.
I think, what you describe is more a 'module feature' and not so much
the 'big blocks concept' - although your wish list should be possible
with the blocks concept.
I'm still looking for a real example that makes use of a
'skin block' or a 'portal block' or something like that - or in other
words, an example which really uses all the features (and ideas) of the
blocks concept and not only a part of it.
> (And sorry I cannot help about the fueling stations at this time
> - maybe you
> could move to Australia, they have them on the other side there ;-)
>
ROTFL
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Blocks
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Friday 16 August 2002 07:58, Carsten Ziegeler wrote:
>. . .
> The blocks RT sounds great, but I'm also interested in a real example
> which shows the usage of blocks
>. . .
I think you were talking about the inner working of Blocks, but from a user
point of view I have written a (dream?) use-case over at CocoDocoWiki:
http://outerthought.net/wiki/Wiki.jsp?page=BlocksUseCases - maybe such
examples help reaching a common understanding?
(And sorry I cannot help about the fueling stations at this time - maybe you
could move to Australia, they have them on the other side there ;-)
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon Blocks
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Andrew C. Oliver wrote:
>
> As I understand it Blocks are a solution to world hunger, documentation,
> complexity, the meaning of life and why
> the local bars and taxi companies in many college towns close
> simultaneously at 2:00am.
>
And does it also answer the question "Why are fueling stations always on
the wrong site of the street?" - This is a real world problem, I faced
too often in the last days.
> I'd like to see Blocks matched to WHAT they solve (Show cause and
> effect), totally what they are, how they match
> to the *blocks* implemented by other projects (Like James I
> believe)...etc.
>
The blocks RT sounds great, but I'm also interested in a real example
which shows the usage of blocks - the current description is for me
a little bit vague. It doesn't detail how communication between different
blocks really takes place etc.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Blocks
Posted by "Andrew C. Oliver" <an...@superlinksoftware.com>.
+1 -- -
As I understand it Blocks are a solution to world hunger, documentation,
complexity, the meaning of life and why
the local bars and taxi companies in many college towns close
simultaneously at 2:00am.
I'd like to see Blocks matched to WHAT they solve (Show cause and
effect), totally what they are, how they match
to the *blocks* implemented by other projects (Like James I believe)...etc.
-Andy
Leigh Dodds wrote:
>>This was one of the core issues Cocoon Blocks should solve in the end.>
>>Giacomo
>>
>>
>
>As an irregular member of this list, I keep seeing 'Blocks' being mentioned
>(usually as the solution to all kinds of problems! :)
>
>Can anyone point me to some documentation, list discussion threads, or
>even scratchpad stuff that describes/demonstrates what Blocks actually
>are?
>
>I'd like to get this into the Wiki.
>
>Cheers,
>
>L.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Blocks
Posted by "Andrew C. Oliver" <an...@superlinksoftware.com>.
But WHAT problems does it solve? Can we drill down into a bit more detail?
-andy
Bertrand Delacretaz wrote:
>On Monday 12 August 2002 12:13, Leigh Dodds wrote:
>
>
>>Can anyone point me to some documentation, list discussion threads, or
>>even scratchpad stuff that describes/demonstrates what Blocks actually
>>are?
>>
>>
>
>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2
>might be a good starting point.
>
>-Bertrand
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Blocks
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Monday 12 August 2002 12:13, Leigh Dodds wrote:
> Can anyone point me to some documentation, list discussion threads, or
> even scratchpad stuff that describes/demonstrates what Blocks actually
> are?
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2
might be a good starting point.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Blocks
Posted by Giacomo Pati <gi...@apache.org>.
On Mon, 12 Aug 2002, Leigh Dodds wrote:
> > This was one of the core issues Cocoon Blocks should solve in the end.>
> > Giacomo
>
> As an irregular member of this list, I keep seeing 'Blocks' being mentioned
> (usually as the solution to all kinds of problems! :)
>
> Can anyone point me to some documentation, list discussion threads, or
> even scratchpad stuff that describes/demonstrates what Blocks actually
> are?
One major point is that Cocoon scales good from the sitemap point of view
(root-sitemap -> sub-sitemap -> ... -> sub-sitemap) but does not on the
Component level (one single cocoon.xconf). Everybody which ever tried to
integrate a Cocoon application which comes with its own Avalon Components
into an already running Cocoon system knows what I am talking about.
You need to merge those new Components into the cocoon.xconf file for
every new application you'd like to deploy in the same Cocoon system and
this can grow into a maintainance nightmare.
The other point Cocoon Blocks (COB) will solve is modularisation. Consider
the following.
1. There is a COB interface defined about skinning application data
of defined XSchemas (navigations, menues, content) by transformations
(i.e. XSLT) into something else (i.e. HTML)
2. There is a COB interface defined about accessing mail messages which
generates defined XSchemas of mail messages and mail folders from mail
stores like IMAP, POP, mboxes or "write your own"
3. There is a COB which offers an WebMail application which depends on
- a skinning COB
- a mail message accessing COB
Now, when someone likes to deploy the WebMailCOB it uses the Cocoon COB
management application which asks for a URI to the COB to deploy. As a COB
will have meta data inside, the management console will be able to ask for
configuration data for the COB and also knows of unresolved dependancies
to other COBs. So the deployer of the WebMailCOB will be asked where the
dependant skin and access COBs are. Now, the management console could
offer implementations for them from a well known site like cob.apache.org
(URL will be configurable of course) which have been registered there. Now
you can select the Christmas skin COB and the IMAP access COB from the
list and configure them to have your WebMail ready and running.
And now you will be free to use other skin COBs in terms of minutes or you
can write your own to achieve "corporate identity". You have your mails
stored in a database and there is no COB for it? Write your own and have
them be served by the WebMailCOB.
So, Cocoon Blocks will not be "the solution to all kinds of problems" as
you might have heared. But it will ease deployment of several "modules"
into one single Cocoon system.
Stefano and I also used the term "naked Cocoon" which sould be a war file
that comes with nothing but what is needed to run the COB management
application. This enables users to start with it and deploy COBs to have
something running by Cocoon.
Hope this and the link Bertrand mentioned in an other mail in this thread
will help understand what Cocoon Blocks should solve.
Giacomo
> I'd like to get this into the Wiki.
>
> Cheers,
>
> L.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org