Return-Path: Delivered-To: apmail-cocoon-users-archive@www.apache.org Received: (qmail 33743 invoked from network); 27 Oct 2003 10:20:05 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 27 Oct 2003 10:20:05 -0000 Received: (qmail 49344 invoked by uid 500); 27 Oct 2003 10:19:31 -0000 Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org Received: (qmail 49134 invoked by uid 500); 27 Oct 2003 10:19:30 -0000 Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: users@cocoon.apache.org Delivered-To: mailing list users@cocoon.apache.org Delivered-To: moderator for users@cocoon.apache.org Received: (qmail 49001 invoked from network); 27 Oct 2003 10:19:04 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39C73.C6DE7621" Disposition-Notification-To: =?iso-8859-2?Q?=CFURDINA_Michal?= Subject: [Portal] future and design questions Date: Mon, 27 Oct 2003 11:19:16 +0100 Message-ID: <4C47FFB0CC6A2E4D92550B89B68FC78391ECFC@s2-ba.asset-internal> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Portal] future and design questions Thread-Index: AcOb732ukdLebwRlEdiHQgADR8eo/gAhBLpA From: =?iso-8859-2?Q?=CFURDINA_Michal?= To: "Cocoon-users" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N ------_=_NextPart_001_01C39C73.C6DE7621 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable (Also in cocoon-dev, but I think answers to this may be useful also for = cocoon users): Hello! Right now I am in process of evaluating available portal solutions. = Because I am big cocoon enthusiast I took a deeper look into the cocoon = portal-fw and portal blocks.=20 I would try to summarise the main features I found when played with both = portal-framework and portal engine. Please correct me if I am wrong: - both solutions aim mostly to implement portlet container capabilities - both solutions are quite similar from the view of sitemap = configuration and coplet features - coplets provide XML feeds and are realized by sitemap pipelines = (local) or by accessing any source in the internet (defined by uri) - authentification is done by authentification-fw but this is not = required as this can be replaced by other solution i.e. by container = managed security=20 (http://marc.theaimsgroup.com/?l=3Dxml-cocoon-dev&m=3D106703524221219&w=3D= 2) - user's settings are stored in files (by means of sourcewriter = transformer) but they can be persisted by any data store by means of = specialized transformers - final HTML look is created by xsl stylesheet applied after syndicating = all coplets in layout template - other clients (PDA, WAP) can be handled by applying different xsl = stylesheet and targeting required markup - JSR-168 portlet container behaviour will be implemented in = portal-engine block to support 3rd party portlet implementations I still have some questions where I am not sure about answers: - what will be (or is) the main difference of current portal-framework = and new portal engine? What were the main issues that caused rewrite of = existing portal-fw to portal engine? - what exactly will be implemented from JSR-168 spec to portal engine, = what components will then be still used from cocoon? - what future do you see for cocoon as a portal framework when JSR-168 = compliant containers will come out (i.e. Jakarta Pluto) and what part of = portal application lifecycle should then cocoon cover? Thanks for your answers and for good job done on cocoon! Michal -- MisoD -- Michal Durdina - durdina@assetsoft.sk=20 ASSET Soft a.s., Kosicka 56, Bratislava, 821 08 Slovakia, Europe ------_=_NextPart_001_01C39C73.C6DE7621 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable [Portal] future and design questions

(Also in cocoon-dev, but I think answers to this may = be useful also for cocoon users):
Hello!

Right now I am in process of evaluating available = portal solutions. Because I am big cocoon enthusiast I took a deeper = look into the cocoon portal-fw and portal blocks.

I would try to summarise the main features I found = when played with both portal-framework and portal engine. Please correct = me if I am wrong:

- both solutions aim mostly to implement portlet = container capabilities
- both solutions are quite similar from the view of = sitemap configuration and coplet features
- coplets provide XML feeds and are realized by = sitemap pipelines (local) or by accessing any source in the internet = (defined by uri)

- authentification is done by authentification-fw but = this is not required as this can be replaced by other solution i.e. by = container managed security

(http://marc.theaimsgroup.com/?l=3Dxml-cocoon-dev&m=3D106703524= 221219&w=3D2)
- user's settings are stored in files (by means of = sourcewriter transformer) but they can be persisted by any data store by = means of specialized transformers

- final HTML look is created by xsl stylesheet applied = after syndicating all coplets in layout template
- other clients (PDA, WAP) can be handled by applying = different xsl stylesheet and targeting required markup
- JSR-168 portlet container behaviour will be = implemented in portal-engine block to support 3rd party portlet = implementations

I still have some questions where I am not sure about = answers:
- what will be (or is) the main difference of current = portal-framework and new portal engine? What were the main issues that = caused rewrite of existing portal-fw to portal engine?

- what exactly will be implemented from JSR-168 spec = to portal engine, what components will then be still used from = cocoon?

- what future do you see for cocoon as a portal = framework when JSR-168 compliant containers will come out (i.e. Jakarta = Pluto) and what part of portal application lifecycle should then cocoon = cover?

Thanks for your answers and for good job done on = cocoon!

Michal

-- MisoD --
Michal Durdina - durdina@assetsoft.sk
ASSET Soft a.s.,
Kosicka 56, Bratislava, 821 08
Slovakia, Europe

------_=_NextPart_001_01C39C73.C6DE7621--