Raphael Luta wrote: > > "Kevin A. Burton" wrote: > > > Rapha�l Luta wrote: > > > Here what I propose: > > > - tomorrow afternoon I'll send you a diff of all the changes I made to the base > > > dist I got from CVS yesterday morning (GMT+1 time...). > > > - on monday, I'll fetch the latest CVS and try to integrate my mods in the > > > current image > > > (this will spare you the pain...). I'll send you another set of diffs monday > > > afternoon-evening against the current CVS > > > - afterwards, and depending how the demo went, I'll try to retrofit my Webmacro > > > stuff in Turbine if you're intersted in it. > > > > > > Is that OK for you ? > > > > That sounds good. I justed didn't want each other to get too far apart > > and then have to merge code back in. > > > > Hi kevin, > > I won't have diff available to send you because I modified by base CVS source > and thus I don't have anything to diff against except the current CVS image > (which I plan to do on monday). > > However here is my status and some complete files included: > - I modified the portletMarkup schema to allow parameters as discussed > before (I attach the xsd file used to generate the API). > > - I had to modify the Portlet Interface to add a call: > > public ConcreteElement getContent(Object parameter) Where do you get the object from? If you need to do this you might want to put it in a Hashtable and call PortletConfig.getParameter(String name) > so that I could pass a User object to my portlets. A user as in TurbineUser? Maybe I should put a getUser() method within PortletConfig so that they can progmatically modify their output based on who you are. > I don't consider this > satisfying but that was quickly done and allowed to pass user authentication > info to the portlet so that it could fetch user-dependent protected URL > (I modified AbstractServlet to implement the previous method so > that your portlets still compile without modification). I think you are right... As soon as Turbine authentication is done I will add getUser() > - I created a cocoon subpackage with a helper class which is used for > Cocoon transformation (org.apache.jetspeed.portal.cocoon.CocoonRenderer). > > - I defined 2 new portlets: > - CocoonPortlet which fetch a URL and tries to render it through > CocoonRenderer Cool! > - XMLPortlet which just fetch an XML file, removes any PI inside and return > that as > content Cool! > In order to implement these, I created a helper class SAXPIFilter which either > removes or inserts PI in an XML document in order to drive Cocoon (temporary > solution until the sitemap is available in Cocoon). Sweet. This is needed IMO especially with XHTML where you don't want PIs from the original document within a Portlet's content. > - I created a new PortletController XMLPortletController, which use a user-based > property to fetch its portlet description file and which skins the portlet > content > only using XML markup. Really cool. This was very needed and I am glad someone hopped on it. > - I created a new Home servlet CocoonHome, which uses XMLPortletController to > get the portlets content and then render it using a user-based stylesheet with > the > CocoonRenderer. I am in the process of turning the Home servlet into a Turbine action... this will have to be ported but I think it is a good idea! > Problems encountered: > - caching: I didn't want to work on the user-based caching issues, so I just > disabled > caching in my portlets. Good idea. It has changed since the last time you worked on it. > - ecs: since I use Cocoon as my home page renderer, all portlets output must be > well-formed XML, so I tried to modify the ECS library to allow for XHTML > compliant output > but without much success. Right. What version? I believe 1.2 explicitly addresses this problem. But i may be wrong. > I send you a bunch of files right now for review so that you can let me know > what you > are intersted in for the main JetSpeed distribution and I'll try to merge those > mods > in the main CVS tree on monday so that I can send you diffs. I am very interested in all of them. I will look over everything and get back to you. But I am really syched about all the work you have done and expect it to all get commited. This solves a lot of problems towards getting JetSpeed 1.0 final out.. > Performance aside, my demo looks quite good now (and will be even better > tomorrow.. ;) ) so > I have hope that I'll be able to contribute actively to the project on the > following > months. +1. We are lucky to have you. Thanks for you hard work dude! Kevin -- Kevin A Burton Senior Software Engineer Kendara Inc http://www.kendara.com Mobile: 408-910-6145 Linux - The revolution will NOT be televised -- -------------------------------------------------------------- Please read the FAQ! <http://java.apache.org/faq/> To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: <http://java.apache.org/main/mail.html> Problems?: [EMAIL PROTECTED]
