RE: [Portal] future and design questions
Hi! My company is also working on the new portal engine. Our goal is to use the portal as the cocoon framework for all our webapps. We will work very soon on enhancements of the portal to build complex websites. - Work area managed by multiple menus with multiple level. - Bookmarkable portal url. - More back office. - etc. See also http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106700374115231&w=2 Portal enhancements will be given to the community. Regards, Laurent Trillaud > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Envoyà : jeudi 30 octobre 2003 16:17 > à : [EMAIL PROTECTED] > Objet : Antwort: RE: [Portal] future and design questions > > > > Hi! > > We are using the portal aswell, and did some extensions like the > ApplicationCoplet and the Cachingcoplet in > cooperation with Carsten from s&n. > > Our main goal was on application integration. That means to run any > existing webapp inside a coplet, featuring > starting a new instance of an embedded webapp. Aggregating the "normal" > portal menu with the menu of the integrated webapp. > > Also javascripts, java-applets and layers are from the embedded webapp are > reused inside the coplet. > > We are also going to implement some new features eg admin tools for > customizing and personalzation. > Maybe we could collaborate? > > regards > Manfred > > > > > [EMAIL PROTECTED] am 30.10.2003 14:23:23 > > Bitte antworten an [EMAIL PROTECTED]@inet > > An: [EMAIL PROTECTED] > Kopie: > Thema: RE: [Portal] future and design questions > > > Hi, > > thanks for your offer - it would be great if others can step > in and extend the portal. > > Now, the current version in cvs is stable and is already > used in different projects around the globe. > There is no real list of what is missing; so if you can > think of anything that you're missing just do it :) > I think in the usuability area are some things missing. > > One major think currently is the complicated configuration, > so if anyone has a good and clever idea on how to simplify > this, I would be very happy. > > Obviously, tools are missing. If you look at the old > portal engine you have some html based administration > tools. It would be great to have those as well, although > imho this isn't restricted to html based tools, e.g. > Ecplise based plugins would be great as well. > > HTH > Carsten > -Original Message- > From: ÄURDINA Michal [mailto:[EMAIL PROTECTED] > Sent: Monday, October 27, 2003 2:56 PM > To: Cocoon-dev > Subject: RE: [Portal] future and design questions > > Thank you for prompt answers! > Our team can eventually choose cocoon as portal solution > (we really have good and long-term experiences with cocoon). > Therefore we can eventually help on developing and testing > tasks and provide valuable feedback from the real world > applications environment. > For this purpose we need to know additional information about > the status of current implementation of portal-engine block. > We would like to know, how much work is left that needs to > be done. Could you please summarize those specific tasks that > are left for finishing the block to be fully functional and > eventually how much time they would take? > Thank you, > Michal > > > > > > >
Antwort: RE: [Portal] future and design questions
Hi! We are using the portal aswell, and did some extensions like the ApplicationCoplet and the Cachingcoplet in cooperation with Carsten from s&n. Our main goal was on application integration. That means to run any existing webapp inside a coplet, featuring starting a new instance of an embedded webapp. Aggregating the "normal" portal menu with the menu of the integrated webapp. Also javascripts, java-applets and layers are from the embedded webapp are reused inside the coplet. We are also going to implement some new features eg admin tools for customizing and personalzation. Maybe we could collaborate? regards Manfred [EMAIL PROTECTED] am 30.10.2003 14:23:23 Bitte antworten an [EMAIL PROTECTED]@inet An: [EMAIL PROTECTED] Kopie: Thema: RE: [Portal] future and design questions Hi, thanks for your offer - it would be great if others can step in and extend the portal. Now, the current version in cvs is stable and is already used in different projects around the globe. There is no real list of what is missing; so if you can think of anything that you're missing just do it :) I think in the usuability area are some things missing. One major think currently is the complicated configuration, so if anyone has a good and clever idea on how to simplify this, I would be very happy. Obviously, tools are missing. If you look at the old portal engine you have some html based administration tools. It would be great to have those as well, although imho this isn't restricted to html based tools, e.g. Ecplise based plugins would be great as well. HTH Carsten -Original Message- From: ĎURDINA Michal [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 2:56 PM To: Cocoon-dev Subject: RE: [Portal] future and design questions Thank you for prompt answers! Our team can eventually choose cocoon as portal solution (we really have good and long-term experiences with cocoon). Therefore we can eventually help on developing and testing tasks and provide valuable feedback from the real world applications environment. For this purpose we need to know additional information about the status of current implementation of portal-engine block. We would like to know, how much work is left that needs to be done. Could you please summarize those specific tasks that are left for finishing the block to be fully functional and eventually how much time they would take? Thank you, Michal
RE: [Portal] future and design questions
Hi, thanks for your offer - it would be great if others can step in and extend the portal. Now, the current version in cvs is stable and is already used in different projects around the globe. There is no real list of what is missing; so if you can think of anything that you're missing just do it :) I think in the usuability area are some things missing. One major think currently is the complicated configuration, so if anyone has a good and clever idea on how to simplify this, I would be very happy. Obviously, tools are missing. If you look at the old portal engine you have some html based administration tools. It would be great to have those as well, although imho this isn't restricted to html based tools, e.g. Ecplise based plugins would be great as well. HTH Carsten -Original Message- From: ĎURDINA Michal [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 2:56 PM To: Cocoon-dev Subject: RE: [Portal] future and design questions Thank you for prompt answers! Our team can eventually choose cocoon as portal solution (we really have good and long-term experiences with cocoon). Therefore we can eventually help on developing and testing tasks and provide valuable feedback from the real world applications environment. For this purpose we need to know additional information about the status of current implementation of portal-engine block. We would like to know, how much work is left that needs to be done. Could you please summarize those specific tasks that are left for finishing the block to be fully functional and eventually how much time they would take? Thank you, Michal
RE: [Portal] future and design questions
Return Receipt Your document: RE: [Portal] future and design questions was received by: Sarah Ho/CoRe at: 10/28/2003 09:21:50 AM
RE: [Portal] future and design questions
Title: RE: [Portal] future and design questions (resending because of some delivery problems) Thank you for prompt answers! Our team can eventually choose cocoon as portal solution (we really have good and long-term experiences with cocoon). Therefore we can eventually help on developing and testing tasks and provide valuable feedback from the real world applications environment. For this purpose we need to know additional information about the status of current implementation of portal-engine block. We would like to know, how much work is left that needs to be done. Could you please summarize those specific tasks that are left for finishing the block to be fully functional and eventually how much time they would take? Thank you, Michal > -Original Message- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 27, 2003 11:57 AM > To: [EMAIL PROTECTED] > Subject: RE: [Portal] future and design questions > > > > ĎURDINA Michal wrote: > > > > 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. > The portal block is a newer implementation that is in general > more flexibel > than the old one but currently lacks for example > administration tools etc. > > > > > 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=xml-cocoon-dev&m=106703524221219&w=2) > Yes, but this is only true for the portal block; the > portal-fw block is tied > to the > authentication-fw. Although it is possible with some trick to use a > different > approach with the portal-fw as well. > > > - 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? > Mainly flexibility, like choosing different authentication > mechanism etc and > implementing > the JSR-168 which will only happen for the portal block > (unless someone > steps in and > does it for the portal-fw as well, which would be very very tricky). > > > - what exactly will be implemented from JSR-168 spec to > portal engine, > what components will > > then be still used from cocoon? > Good question, I'm wondering this myself these days :) Now, > currently the > JSR-168 defines > only portlets, but not the portlet container itself (only part of the > behaviour of the > container), so it might be that the portal engine of Cocoon > stays the same. > But you > will have the abilitiy to use a JSR-168 portlet instead of a pipeline. > > > - 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? > I honestly don't know - this is something the users will > decide. Now, I hope > that the > cocoon portal engine will be JSR-168 compliant as well (soon), so when > developing portlets it > doesn't matter if you choose Cocoon or Pluto or Jetspeed or > whatever. At > least that's > the theory which I think will not always be the practice
RE: [Portal] future and design questions
Title: RE: [Portal] future and design questions Thank you for prompt answers! Our team can eventually choose cocoon as portal solution (we really have good and long-term experiences with cocoon). Therefore we can eventually help on developing and testing tasks and provide valuable feedback from the real world applications environment. For this purpose we need to know additional information about the status of current implementation of portal-engine block. We would like to know, how much work is left that needs to be done. Could you please summarize those specific tasks that are left for finishing the block to be fully functional and eventually how much time they would take? Thank you, Michal > -Original Message- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 27, 2003 11:57 AM > To: [EMAIL PROTECTED] > Subject: RE: [Portal] future and design questions > > > > ĎURDINA Michal wrote: > > > > 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. > The portal block is a newer implementation that is in general > more flexibel > than the old one but currently lacks for example > administration tools etc. > > > > > 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=xml-cocoon-dev&m=106703524221219&w=2) > Yes, but this is only true for the portal block; the > portal-fw block is tied > to the > authentication-fw. Although it is possible with some trick to use a > different > approach with the portal-fw as well. > > > - 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? > Mainly flexibility, like choosing different authentication > mechanism etc and > implementing > the JSR-168 which will only happen for the portal block > (unless someone > steps in and > does it for the portal-fw as well, which would be very very tricky). > > > - what exactly will be implemented from JSR-168 spec to > portal engine, > what components will > > then be still used from cocoon? > Good question, I'm wondering this myself these days :) Now, > currently the > JSR-168 defines > only portlets, but not the portlet container itself (only part of the > behaviour of the > container), so it might be that the portal engine of Cocoon > stays the same. > But you > will have the abilitiy to use a JSR-168 portlet instead of a pipeline. > > > - 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? > I honestly don't know - this is something the users will > decide. Now, I hope > that the > cocoon portal engine will be JSR-168 compliant as well (soon), so when > developing portlets it > doesn't matter if you choose Cocoon or Pluto or Jetspeed or > whatever. At > least that's > the theory which I think will not always be the practice: > When you develop a > portlet you >
RE: [Portal] future and design questions
> ĎURDINA Michal wrote: > > 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. The portal block is a newer implementation that is in general more flexibel than the old one but currently lacks for example administration tools etc. > > 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=xml-cocoon-dev&m=106703524221219&w=2) Yes, but this is only true for the portal block; the portal-fw block is tied to the authentication-fw. Although it is possible with some trick to use a different approach with the portal-fw as well. > - 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? Mainly flexibility, like choosing different authentication mechanism etc and implementing the JSR-168 which will only happen for the portal block (unless someone steps in and does it for the portal-fw as well, which would be very very tricky). > - what exactly will be implemented from JSR-168 spec to portal engine, what components will > then be still used from cocoon? Good question, I'm wondering this myself these days :) Now, currently the JSR-168 defines only portlets, but not the portlet container itself (only part of the behaviour of the container), so it might be that the portal engine of Cocoon stays the same. But you will have the abilitiy to use a JSR-168 portlet instead of a pipeline. > - 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? I honestly don't know - this is something the users will decide. Now, I hope that the cocoon portal engine will be JSR-168 compliant as well (soon), so when developing portlets it doesn't matter if you choose Cocoon or Pluto or Jetspeed or whatever. At least that's the theory which I think will not always be the practice: When you develop a portlet you need functionality and in some cases you find this functionality in your portlet container (in Cocoon, in Jetspeed etc.) and you will use this. From that point on you're tied to that container. But the JSR-168 helps here a lot. Anyway, personally, I think Cocoon is a good base for portal applications as it provides so many good concepts, like the avalon based architecture, the sitemap, the processing pipelines, flow, blocks (with 2.2), form handling frameworks etc that make developing complex applications alot easier. And you can use all these nice little things in your portlets as well. HTH Carsten
