You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by YKPrajapati <yk...@netscape.net> on 2003/11/11 17:41:37 UTC
Using portal engine on Cocoon 2.1.2
I am slowly getting started with Cocoon 2.1.2. I have been looking into
various blocks to find out which are suitable as per my application
needs. I found the "new portal engine" (
http://localhost/cocoon/samples/portal/portal ) block provides some of
the common functionalities my application needs to have. I want to get
started with it. Right now I am going through the code and config files
of the portal engine and trying to learn but it seemed like overkilling
for the time being. Can anybody gives me more inputs about do's and
don'ts ? Also point me to those docs (if available) that will help me
getting started developing my application on top of the "new portal engine".
Thanks in advance for your help.
-YKP
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: portal engine on Cocoon 2.1.3
Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
David Geleyn wrote:
> Hi all!
>
> I'm looking at the (new) portal engine of cocoon and I
> have some questions about it:
>
> It is possible to make any coplet fullscreen, which is
> great, but how exactly do you know whether you are in
> full screen mode or not (when you are creating the
> coplet)? It would be great to know this, because it
IIRC this is handled by the renderers. The rederer gets
this information because the layout object carries this information.
The layout in turn is modified by some component
(DefaultChangeAspectDataEventSubscriber) that is
subscribed to the appropriate portal event (ChangeAspectDataEvent).
If your coplet would be subscribed to the same event, it
would be informed of this change.
> It would be great to have a coplet with some data that
> depends on request parameters. The request parameters
> are now read by all the coplets (correct me if I'm
> wrong). Is it possible to make sure that request
All request parameters are made available to all coplets.
> parameters are only processed by one coplet instance?
> Maybe I can illustrate this with an example: If you
> have a coplet that list all users and you want a
> filter option (selection list) to view only the
> administrators you have to use a request parameter.
> This parameter is also read by the other coplet
> instances. Now, If you want also an instance of the
> same coplet in the same portal view, but with only the
> 'guest users' listed, you have a problem, I assume? Or
> is there any way to avoid this?
Those coplets would need to talk to each other through the
portal event mechanism.
> It do not that that the coplets are meant to list only
> administrators or guests. Both instances should be
> able to show them both!
HTH
Chris.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
portal engine on Cocoon 2.1.3
Posted by David Geleyn <da...@yahoo.co.uk>.
Hi all!
I'm looking at the (new) portal engine of cocoon and I
have some questions about it:
It is possible to make any coplet fullscreen, which is
great, but how exactly do you know whether you are in
full screen mode or not (when you are creating the
coplet)? It would be great to know this, because it
would allow you to give different content (more
detailed) in full screen mode. So if this is already
available, how? A new URI (fullscreen-uri) in coplet
data? If not, is this planned?
It would be great to have a coplet with some data that
depends on request parameters. The request parameters
are now read by all the coplets (correct me if I'm
wrong). Is it possible to make sure that request
parameters are only processed by one coplet instance?
Maybe I can illustrate this with an example: If you
have a coplet that list all users and you want a
filter option (selection list) to view only the
administrators you have to use a request parameter.
This parameter is also read by the other coplet
instances. Now, If you want also an instance of the
same coplet in the same portal view, but with only the
'guest users' listed, you have a problem, I assume? Or
is there any way to avoid this?
It do not that that the coplets are meant to list only
administrators or guests. Both instances should be
able to show them both!
Thanks!!!
David.
________________________________________________________________________
Download Yahoo! Messenger now for a chance to win Live At Knebworth DVDs
http://www.yahoo.co.uk/robbiewilliams
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE : Using portal engine on Cocoon 2.1.2
Posted by Laurent Trillaud <lt...@jouve.fr>.
The portal engine is still in alpha stage and haven't a lot of doc.
But try this one, it's a good introduction
http://cocoon.apache.org/2.1/developing/portal/portal-block.html
Laurent Trillaud
> -----Message d'origine-----
> De : YKPrajapati [mailto:ykprajapati@netscape.net]
> Envoyé : mardi 11 novembre 2003 17:42
> À : users@cocoon.apache.org
> Objet : Using portal engine on Cocoon 2.1.2
>
> I am slowly getting started with Cocoon 2.1.2. I have been looking
into
> various blocks to find out which are suitable as per my application
> needs. I found the "new portal engine" (
> http://localhost/cocoon/samples/portal/portal ) block provides some
of
> the common functionalities my application needs to have. I want to get
> started with it. Right now I am going through the code and config
files
> of the portal engine and trying to learn but it seemed like
overkilling
> for the time being. Can anybody gives me more inputs about do's and
> don'ts ? Also point me to those docs (if available) that will help me
> getting started developing my application on top of the "new portal
> engine".
>
> Thanks in advance for your help.
>
> -YKP
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org