From michiel at trimpe.nl Wed Oct 1 14:52:11 2008 From: michiel at trimpe.nl (Michiel Trimpe) Date: Wed Oct 1 14:52:22 2008 Subject: [Hippoportal-dev] Rewriting the (xml) datasource after performing the ProfilerValve Message-ID: <990c65350810010552v1562b16fie967325eebf2a647@mail.gmail.com> Ate, Jeroen, Dennis, Is there any way to rewrite the datasource xml location after resolving the PSML? When a request resolves to 'collection.psml' we need to rewrite datasources that do not point to an XML (e.g. /content/documents/level1item) to the appropriate XML document. That way we can handle requests like www.site.name/level1item without redirecting to something like www.site.name/level1item.html At the moment all our root elements that are 'repository based' don't work because of this. Regards, Michiel Trimpe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hippo.nl/pipermail/hippoportal-dev/attachments/20081001/6b949074/attachment.htm From d.dam at onehippo.com Wed Oct 1 15:26:28 2008 From: d.dam at onehippo.com (Dennis Dam) Date: Wed Oct 1 15:26:24 2008 Subject: [Hippoportal-dev] Rewriting the (xml) datasource after performing the ProfilerValve In-Reply-To: <990c65350810010552v1562b16fie967325eebf2a647@mail.gmail.com> References: <990c65350810010552v1562b16fie967325eebf2a647@mail.gmail.com> Message-ID: <48E37A84.6010605@onehippo.com> Hi Michiel, Can you not just construct the path to the correct document in the portlet that uses the datasource? I'm assuming you want to fetch some kind of "index" document which is shown on the page generated by collection.psml. Usually we either look for a fixed name in the repository folder where the datasource points to (e.g. datasource + "/index.xml), or execute a DASL to look for a document in that folder, of a certain type (e.g. type = "introduction" or so, depends on your CMS config). hth, Dennis Michiel Trimpe wrote: > Ate, Jeroen, Dennis, > > Is there any way to rewrite the datasource xml location after > resolving the PSML? > > When a request resolves to 'collection.psml' we need to rewrite > datasources that do not point to an XML (e.g. > /content/documents/level1item) to the appropriate XML document. > > That way we can handle requests like www.site.name/level1item > without redirecting to something > like www.site.name/level1item.html > > At the moment all our root elements that are 'repository based' don't > work because of this. > > Regards, > > Michiel Trimpe > > ------------------------------------------------------------------------ > > _______________________________________________ > Hippoportal-dev mailing list > Hippoportal-dev@lists.hippo.nl > http://lists.hippo.nl/mailman/listinfo/hippoportal-dev > From jeroen at entreact.com Wed Oct 1 17:05:13 2008 From: jeroen at entreact.com (Jeroen van Maanen) Date: Wed Oct 1 17:05:55 2008 Subject: [Hippoportal-dev] Sleeping bug? Message-ID: <48E391A9.9080803@entreact.com> Shouldn't the last two arguments of the AssociationHandlerKey constructor be reversed in one of the two cases of the if statement around line 262 of BaseJetspeedPincipalManager.java: if (ref.type == JetspeedPrincipalAssociationReference.Type.FROM) { key = new AssociationHandlerKey(ref.associationName, ref.ref.getType().getName(), principalType.getName()); } else { key = new AssociationHandlerKey(ref.associationName, ref.ref.getType().getName(), principalType.getName()); } Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: jeroen.vcf Type: text/x-vcard Size: 228 bytes Desc: not available Url : http://lists.hippo.nl/pipermail/hippoportal-dev/attachments/20081001/26609262/jeroen.vcf From a.douma at onehippo.com Wed Oct 1 20:50:42 2008 From: a.douma at onehippo.com (Ate Douma) Date: Wed Oct 1 20:50:38 2008 Subject: [Hippoportal-dev] Sleeping bug? In-Reply-To: <48E391A9.9080803@entreact.com> References: <48E391A9.9080803@entreact.com> Message-ID: <48E3C682.6040908@onehippo.com> Yes! Thanks for finding and reporting this Jeroen. I've already fixed and committed it. FYI: we're shooting for completing the reimplementation of SSO, PermissionsManager and LDAP *replication* next Monday and thereafter promoting the j2-security-refactoring branch back to the trunk. Once we've completed that, we'll provide an updated Jetspeed 2.2-SNAPSHOT build through our repository/hippocms.org/maven-2 repository to make it available for custom portals based upon Hippo Portal 1.10.xx. Regards, Ate Jeroen van Maanen wrote: > Shouldn't the last two arguments of the AssociationHandlerKey > constructor be reversed in one of the two cases of the if statement > around line 262 of BaseJetspeedPincipalManager.java: > > if (ref.type == JetspeedPrincipalAssociationReference.Type.FROM) > { > key = new AssociationHandlerKey(ref.associationName, > ref.ref.getType().getName(), principalType.getName()); > } > else > { > key = new AssociationHandlerKey(ref.associationName, > ref.ref.getType().getName(), principalType.getName()); > } > > Jeroen > > _______________________________________________ > Hippoportal-dev mailing list > Hippoportal-dev@lists.hippo.nl > http://lists.hippo.nl/mailman/listinfo/hippoportal-dev -- a.douma@onehippo.com www.onehippo.com Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1(877) 41-HIPPO From jeroen at entreact.com Fri Oct 3 11:41:38 2008 From: jeroen at entreact.com (Jeroen van Maanen) Date: Fri Oct 3 11:42:13 2008 Subject: [Hippoportal-dev] How to use security objects in portlet application Message-ID: <48E5E8D2.30407@entreact.com> I implemented some extra security principals that fit into the new security model of Jetspeed and put them in the portal module of my project. I created a module for a shared JAR and put the interfaces for the new classes into the shared JAR. Now I would like to use the instances of the security context that are created in the Spring container of the portal module in the portlet application module. I tried UserManager userManager = (UserManager) componentManager.getBean(UserManager.class); But then I get NoSuchBeanDefinitionException: No bean named 'org.apache.jetspeed.security.UserManager' is defined" Apparently the portlet applcation module has its own Spring container (that makes sense :-> ). So what is the proper way to get these instances? Cheers, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: jeroen.vcf Type: text/x-vcard Size: 228 bytes Desc: not available Url : http://lists.hippo.nl/pipermail/hippoportal-dev/attachments/20081003/40b63560/jeroen.vcf From a.douma at onehippo.com Fri Oct 3 15:45:13 2008 From: a.douma at onehippo.com (Ate Douma) Date: Fri Oct 3 15:45:14 2008 Subject: [Hippoportal-dev] How to use security objects in portlet application In-Reply-To: <48E5E8D2.30407@entreact.com> References: <48E5E8D2.30407@entreact.com> Message-ID: <48E621E9.6030809@onehippo.com> Jeroen van Maanen wrote: > I implemented some extra security principals that fit into the new > security model of Jetspeed and put them in the portal module of my > project. I created a module for a shared JAR and put the interfaces for > the new classes into the shared JAR. Now I would like to use the > instances of the security context that are created in the Spring > container of the portal module in the portlet application module. I tried > > UserManager userManager = (UserManager) > componentManager.getBean(UserManager.class); > > But then I get > > NoSuchBeanDefinitionException: No bean named > 'org.apache.jetspeed.security.UserManager' is defined" > > Apparently the portlet applcation module has its own Spring container > (that makes sense :-> ). So what is the proper way to get these instances? No, you probably would want to retrieve the UserManager (or other principal managers) now through the JetspeedPrincipalManagerProvider. JetspeedPrincipalManagerProvider jpmp = ... (read on below) UserManager userManager = (UserManager) = jpmp.getManager(jpmp.getPrincipalType(JetspeedPrincipalType.USER)); The above doesn't tell you yet how to access the jpmp :) Jetspeed provides a way to access its own "services" as configured in the (portal) assembly file jetspeed-services.xml Note: the JetspeedPrincipalManagerProvider is *not* yet configured therein (which we shall fix soon) so you'll need to add it yourself in an override of the "PortalServices" (put it in a separate assembly xml under the assembly/override folder). Then, you'll need to add a custom jetspeed-portlet.xml to your portlet application WEB-INF directory containing something like this: As you can see above, I've "subscribed" to both the UserManager (which *is* by default configured on the JetspeedServices bean) and the JetspeedPrincipalManagerProvider. The name of the service "subscription" must match the key used in for the JetspeedServices bean. After an portlet application is deployed with such a jetspeed-portlet.xml (which can contain also other Jetspeed specific meta-data features), Jetspeed will make the subscribed services available through PortletContext attributes with a (namespace) prefix "cps:". So you can then access them as follows: void Portlet.init(PortletConfig config) { JetspeedPrincipalManagerProvider jpmp = (JetspeedPrincipalManagerProvider)config.getPortletContext() .getAttribute("cps:org.apache.jetspeed.security.spi.JetspeedPrincipalManagerProvider"); } HTH, Ate > > Cheers, Jeroen > > _______________________________________________ > Hippoportal-dev mailing list > Hippoportal-dev@lists.hippo.nl > http://lists.hippo.nl/mailman/listinfo/hippoportal-dev -- a.douma@onehippo.com www.onehippo.com Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1(877) 41-HIPPO From jeroen at entreact.com Fri Oct 3 16:39:19 2008 From: jeroen at entreact.com (Jeroen van Maanen) Date: Fri Oct 3 16:39:51 2008 Subject: [Hippoportal-dev] How to use security objects in portlet application In-Reply-To: <48E621E9.6030809@onehippo.com> References: <48E5E8D2.30407@entreact.com> <48E621E9.6030809@onehippo.com> Message-ID: <48E62E97.3030802@entreact.com> Ate Douma schreef: > Jeroen van Maanen wrote: >> I implemented some extra security principals that fit into the new >> security model of Jetspeed and put them in the portal module of my >> project. I created a module for a shared JAR and put the interfaces >> for the new classes into the shared JAR. Now I would like to use the >> instances of the security context that are created in the Spring >> container of the portal module in the portlet application module. I tried >> >> [...] >> >> Apparently the portlet applcation module has its own Spring container >> (that makes sense :-> ). So what is the proper way to get these >> instances? > No, you probably would want to retrieve the UserManager (or other > principal managers) now through the JetspeedPrincipalManagerProvider. > > JetspeedPrincipalManagerProvider jpmp = ... (read on below) > UserManager userManager = (UserManager) = > jpmp.getManager(jpmp.getPrincipalType(JetspeedPrincipalType.USER)); > > The above doesn't tell you yet how to access the jpmp :) > > Jetspeed provides a way to access its own "services" as configured in > the (portal) assembly file jetspeed-services.xml > Note: the JetspeedPrincipalManagerProvider is *not* yet configured > therein (which we shall fix soon) so you'll need to add it yourself in > an override of the "PortalServices" (put it in a separate assembly xml > under the assembly/override folder). > > Then, you'll need to add a custom jetspeed-portlet.xml to your portlet > application WEB-INF directory containing something like this: > > xmlns="http://portals.apache.org/jetspeed" > xmlns:js="http://portals.apache.org/jetspeed" > xmlns:dc="http://www.purl.org/dc" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://portals.apache.org/jetspeed > http://portals.apache.org/jetspeed-2/2.1/schemas/jetspeed-portlet.xsd"> > > > > name='org.apache.jetspeed.security.spi.JetspeedPrincipalManagerProvider'/> > > > I tried to subscribe to the UserManager only, but there is still no attribute on the PortletContext that provides it... Can I configure verbose logging for the class that processes jetspeed-portlet.xml? Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: jeroen.vcf Type: text/x-vcard Size: 228 bytes Desc: not available Url : http://lists.hippo.nl/pipermail/hippoportal-dev/attachments/20081003/2b0eb8aa/jeroen.vcf From w.ko at onehippo.com Fri Oct 3 16:44:36 2008 From: w.ko at onehippo.com (Woonsan Ko) Date: Fri Oct 3 16:44:38 2008 Subject: [Hippoportal-dev] How to use security objects inportlet application In-Reply-To: <48E62E97.3030802@entreact.com> References: <48E5E8D2.30407@entreact.com> <48E621E9.6030809@onehippo.com> <48E62E97.3030802@entreact.com> Message-ID: Hi Jeroen, Did you get the reference of the user manager component in the init() method of your portlet? If you do in other methods, the error can come out. Regards, Woonsan -----Original Message----- From: hippoportal-dev-bounces@lists.hippo.nl [mailto:hippoportal-dev-bounces@lists.hippo.nl] On Behalf Of Jeroen van Maanen Sent: Friday, October 03, 2008 4:39 PM To: Hippo Portal development public mailinglist Subject: Re: [Hippoportal-dev] How to use security objects inportlet application Ate Douma schreef: > Jeroen van Maanen wrote: >> I implemented some extra security principals that fit into the new >> security model of Jetspeed and put them in the portal module of my >> project. I created a module for a shared JAR and put the interfaces >> for the new classes into the shared JAR. Now I would like to use the >> instances of the security context that are created in the Spring >> container of the portal module in the portlet application module. I >> tried >> >> [...] >> >> Apparently the portlet applcation module has its own Spring container >> (that makes sense :-> ). So what is the proper way to get these >> instances? > No, you probably would want to retrieve the UserManager (or other > principal managers) now through the JetspeedPrincipalManagerProvider. > > JetspeedPrincipalManagerProvider jpmp = ... (read on below) > UserManager userManager = (UserManager) = > jpmp.getManager(jpmp.getPrincipalType(JetspeedPrincipalType.USER)); > > The above doesn't tell you yet how to access the jpmp :) > > Jetspeed provides a way to access its own "services" as configured in > the (portal) assembly file jetspeed-services.xml > Note: the JetspeedPrincipalManagerProvider is *not* yet configured > therein (which we shall fix soon) so you'll need to add it yourself in > an override of the "PortalServices" (put it in a separate assembly xml > under the assembly/override folder). > > Then, you'll need to add a custom jetspeed-portlet.xml to your portlet > application WEB-INF directory containing something like this: > > xmlns="http://portals.apache.org/jetspeed" > xmlns:js="http://portals.apache.org/jetspeed" > xmlns:dc="http://www.purl.org/dc" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://portals.apache.org/jetspeed > http://portals.apache.org/jetspeed-2/2.1/schemas/jetspeed-portlet.xsd" > > > > > > name='org.apache.jetspeed.security.spi.JetspeedPrincipalManagerProvider' /> > > > I tried to subscribe to the UserManager only, but there is still no attribute on the PortletContext that provides it... Can I configure verbose logging for the class that processes jetspeed-portlet.xml? Jeroen From a.douma at onehippo.com Fri Oct 3 16:46:10 2008 From: a.douma at onehippo.com (Ate Douma) Date: Fri Oct 3 16:46:11 2008 Subject: [Hippoportal-dev] How to use security objects in portlet application In-Reply-To: <48E62E97.3030802@entreact.com> References: <48E5E8D2.30407@entreact.com> <48E621E9.6030809@onehippo.com> <48E62E97.3030802@entreact.com> Message-ID: <48E63032.7020504@onehippo.com> Jeroen van Maanen wrote: > Ate Douma schreef: >> Jeroen van Maanen wrote: >>> I implemented some extra security principals that fit into the new >>> security model of Jetspeed and put them in the portal module of my >>> project. I created a module for a shared JAR and put the interfaces >>> for the new classes into the shared JAR. Now I would like to use the >>> instances of the security context that are created in the Spring >>> container of the portal module in the portlet application module. I >>> tried >>> >>> [...] >>> >>> Apparently the portlet applcation module has its own Spring container >>> (that makes sense :-> ). So what is the proper way to get these >>> instances? >> No, you probably would want to retrieve the UserManager (or other >> principal managers) now through the JetspeedPrincipalManagerProvider. >> >> JetspeedPrincipalManagerProvider jpmp = ... (read on below) >> UserManager userManager = (UserManager) = >> jpmp.getManager(jpmp.getPrincipalType(JetspeedPrincipalType.USER)); >> >> The above doesn't tell you yet how to access the jpmp :) >> >> Jetspeed provides a way to access its own "services" as configured in >> the (portal) assembly file jetspeed-services.xml >> Note: the JetspeedPrincipalManagerProvider is *not* yet configured >> therein (which we shall fix soon) so you'll need to add it yourself in >> an override of the "PortalServices" (put it in a separate assembly xml >> under the assembly/override folder). >> >> Then, you'll need to add a custom jetspeed-portlet.xml to your portlet >> application WEB-INF directory containing something like this: >> >> > xmlns="http://portals.apache.org/jetspeed" >> xmlns:js="http://portals.apache.org/jetspeed" >> xmlns:dc="http://www.purl.org/dc" >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="http://portals.apache.org/jetspeed >> http://portals.apache.org/jetspeed-2/2.1/schemas/jetspeed-portlet.xsd"> >> >> >> >> > name='org.apache.jetspeed.security.spi.JetspeedPrincipalManagerProvider'/> >> >> >> >> > > I tried to subscribe to the UserManager only, but there is still no > attribute on the PortletContext that provides it... Did you prefix the attribute lookup name with "cps:", e.g. getAttribute("cps:UserManager")? NB: most common service lookup attribute names are predefined in org.apache.jetspeed.CommonPortalServices.java, as part of the jetspeed-api. > > Can I configure verbose logging for the class that processes > jetspeed-portlet.xml? If a service isn't properly "subscribed" to (e.g. service unknown) AFAIK you would get an exception the deployment log You can also check the services subscribed to in the database table "JETSPEED_SERVICES". > > Jeroen > > _______________________________________________ > Hippoportal-dev mailing list > Hippoportal-dev@lists.hippo.nl > http://lists.hippo.nl/mailman/listinfo/hippoportal-dev -- a.douma@onehippo.com www.onehippo.com Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1(877) 41-HIPPO From a.douma at onehippo.com Fri Oct 3 17:03:29 2008 From: a.douma at onehippo.com (Ate Douma) Date: Fri Oct 3 17:03:28 2008 Subject: [Hippoportal-dev] How to use security objects in portlet application In-Reply-To: <48E621E9.6030809@onehippo.com> References: <48E5E8D2.30407@entreact.com> <48E621E9.6030809@onehippo.com> Message-ID: <48E63441.7050702@onehippo.com> FYI: I just committed adding the JetspeedPrincipalManagerProvider to the default jetspeed-services.xml as well as providing an entry in CommonPortletServices for it. Once we've build and uploaded new 2.2-SNAPSHOT artifacts for Jetspeed to our hippocms maven2 repository you won't need to provide this through an override configuration of your own. Regards, Ate Ate Douma wrote: > Jeroen van Maanen wrote: >> I implemented some extra security principals that fit into the new >> security model of Jetspeed and put them in the portal module of my >> project. I created a module for a shared JAR and put the interfaces >> for the new classes into the shared JAR. Now I would like to use the >> instances of the security context that are created in the Spring >> container of the portal module in the portlet application module. I tried >> >> UserManager userManager = (UserManager) >> componentManager.getBean(UserManager.class); >> >> But then I get >> >> NoSuchBeanDefinitionException: No bean named >> 'org.apache.jetspeed.security.UserManager' is defined" >> >> Apparently the portlet applcation module has its own Spring container >> (that makes sense :-> ). So what is the proper way to get these >> instances? > No, you probably would want to retrieve the UserManager (or other > principal managers) now through the JetspeedPrincipalManagerProvider. > > JetspeedPrincipalManagerProvider jpmp = ... (read on below) > UserManager userManager = (UserManager) = > jpmp.getManager(jpmp.getPrincipalType(JetspeedPrincipalType.USER)); > > The above doesn't tell you yet how to access the jpmp :) > > Jetspeed provides a way to access its own "services" as configured in > the (portal) assembly file jetspeed-services.xml > Note: the JetspeedPrincipalManagerProvider is *not* yet configured > therein (which we shall fix soon) so you'll need to add it yourself in > an override of the "PortalServices" (put it in a separate assembly xml > under the assembly/override folder). > > Then, you'll need to add a custom jetspeed-portlet.xml to your portlet > application WEB-INF directory containing something like this: > > xmlns="http://portals.apache.org/jetspeed" > xmlns:js="http://portals.apache.org/jetspeed" > xmlns:dc="http://www.purl.org/dc" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://portals.apache.org/jetspeed > http://portals.apache.org/jetspeed-2/2.1/schemas/jetspeed-portlet.xsd"> > > > > name='org.apache.jetspeed.security.spi.JetspeedPrincipalManagerProvider'/> > > > > > As you can see above, I've "subscribed" to both the UserManager (which > *is* by default configured on the JetspeedServices bean) and > the JetspeedPrincipalManagerProvider. The name of the service > "subscription" must match the key used in for the JetspeedServices bean. > > After an portlet application is deployed with such a > jetspeed-portlet.xml (which can contain also other Jetspeed specific > meta-data features), Jetspeed will make the subscribed services > available through PortletContext attributes with a (namespace) prefix > "cps:". > So you can then access them as follows: > > void Portlet.init(PortletConfig config) > { > JetspeedPrincipalManagerProvider jpmp = > (JetspeedPrincipalManagerProvider)config.getPortletContext() > > .getAttribute("cps:org.apache.jetspeed.security.spi.JetspeedPrincipalManagerProvider"); > > } > > HTH, > > Ate > >> >> Cheers, Jeroen >> >> _______________________________________________ >> Hippoportal-dev mailing list >> Hippoportal-dev@lists.hippo.nl >> http://lists.hippo.nl/mailman/listinfo/hippoportal-dev > > -- a.douma@onehippo.com www.onehippo.com Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1(877) 41-HIPPO From GvanderPloeg at iprofs.nl Tue Oct 7 14:03:05 2008 From: GvanderPloeg at iprofs.nl (Geert van der Ploeg) Date: Tue Oct 7 14:03:11 2008 Subject: [Hippoportal-dev] paging in FreeMarkerListContentPortlet Message-ID: Hello all, I have some questions regarding paging, using the portlet FreeMarkerListContentPortlet. Although paging as a whole seems to be present, there are two parts that either do not work or are not yet clear to me :-) 1. Getting 'current page' from the request, prior to filling the model does not seem to work. In Pager.java:173, this parameter is fetched from the request context's portalURL. However, this URL does not contain the request parameters at all. The only thing to configure is the name of the parameter, in portlet.xml. Right? 2. Setting the URL's in the FM template ends up with corrupt urls. What's added is just a ampersand and parameter, without any check for existing parameters. Result: paging links on a page with URL 'http://localhost:8080/my/path' will read something like '//my/path/&relatedcontentPageNr=3' - two leading slashes, making 'my' the host-part of the url - no question mark added as start of request parameters My Hippo portal /portal pac version: 1.07.00 Portlet configuration in portlet.xml: ~~~~ a relatedcontent nl.hippo.portal.cms.portlets.FreeMarkerListContentPortlet -1 text/html VIEW nl relatedcontent dasl_query WEB-INF/templates/dasl/myfreemarkertpl.ftl ViewPage /WEB-INF/templates/myFreeMarkerTemplate/myFreeMarkerTemplate.ftl pagingLimit 3 pageParameterName relatedcontentPageNr ~~~~ Thanks in advance. Regards, Geert van der Ploeg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hippo.nl/pipermail/hippoportal-dev/attachments/20081007/e76988ce/attachment.htm From michiel at trimpe.nl Tue Oct 7 16:53:26 2008 From: michiel at trimpe.nl (Michiel Trimpe) Date: Tue Oct 7 16:53:31 2008 Subject: [Hippoportal-dev] Rewriting the (xml) datasource after performing the ProfilerValve In-Reply-To: <48E37A84.6010605@onehippo.com> References: <990c65350810010552v1562b16fie967325eebf2a647@mail.gmail.com> <48E37A84.6010605@onehippo.com> Message-ID: <990c65350810070753h61ca9333yff0f8e87f482bea5@mail.gmail.com> I've analyzed the problem a bit further (your solution doesn't work for us) and I've come to the conclusion that we basically need the mapping from a SiteMapItem to a source DocumentPath to be configurable. At present there's some default logic for mapping a SiteMapItem to a DocumentPath source (adding the postfix and replacing ".html" with ".xml") and we need some extra logic there (if the resource is a collection and there is no postfix then find a document sibling with the same name). Is there any way to customize that logic? On a side note, after having implemented the Hippo Portal in our company for the past few weeks I find that the biggest problem I keep running into is the lack of extensibility / configurability, such as described above. It seems like there's been fairly little thought put into defining (and documenting) appropriate extension points and a mechanism to do so. This problem could for example be resolved by moving CMSRequestContextImpl.getSrc(SiteMapItem, CMSPortalURL, boolean) to an interface CMSSourceResolver(SiteMapItem, CMSPortalURL, CMSService, boolean) and adding the CMSSourceResolver to CMSApplicationRegistryImpl. Another option would be to add a CMSRequestContextFactory which we can configure. All in all it's been really nice to explore the Hippo Portal internals though; apart from the extensibility it's a really nicely architectured system. - Michiel Trimpe On Wed, Oct 1, 2008 at 3:26 PM, Dennis Dam wrote: > Hi Michiel, > > Can you not just construct the path to the correct document in the portlet > that uses the datasource? I'm assuming you want to fetch some kind of > "index" document which is shown on the page generated by collection.psml. > Usually we either look for a fixed name in the repository folder where the > datasource points to (e.g. datasource + "/index.xml), or execute a DASL to > look for a document in that folder, of a certain type (e.g. type = > "introduction" or so, depends on your CMS config). > > hth, > Dennis > > Michiel Trimpe wrote: > >> Ate, Jeroen, Dennis, >> >> Is there any way to rewrite the datasource xml location after resolving >> the PSML? >> >> When a request resolves to 'collection.psml' we need to rewrite >> datasources that do not point to an XML (e.g. /content/documents/level1item) >> to the appropriate XML document. >> >> That way we can handle requests like www.site.name/level1item < >> http://www.site.name/level1item> without redirecting to something like >> www.site.name/level1item.html >> >> At the moment all our root elements that are 'repository based' don't work >> because of this. >> >> Regards, >> >> Michiel Trimpe >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hippo.nl/pipermail/hippoportal-dev/attachments/20081007/c5dfae24/attachment.htm From d.dam at onehippo.com Wed Oct 8 12:23:03 2008 From: d.dam at onehippo.com (Dennis Dam) Date: Wed Oct 8 12:28:05 2008 Subject: [Hippoportal-dev] Link Rewriting features (was: Re: [HippoCMS-dev] Image asset permissions) In-Reply-To: <9e891b600810080236v2a6780c8wd4798d13db71ef67@mail.gmail.com> References: <9e891b600810070924p3bbd43f2m390afe540c71fe8e@mail.gmail.com> <48EBAF11.20902@onehippo.com> <9e891b600810080148g1ce440bbjacbf972230640178@mail.gmail.com> <48EC7B4C.4070206@onehippo.com> <9e891b600810080236v2a6780c8wd4798d13db71ef67@mail.gmail.com> Message-ID: <48EC8A07.20608@onehippo.com> Hi Shawn, the url you should get for accessing binaries from the portal should look something like this: /ourportal/binaries/site/binaries/folder1/image1.jpg where : /ourportal/binaries is the servlet path you mentioned before "site" is the identifier of the Site that is configured in hippo-portal.xml /binaries/folder1/image1.jpg is the path to the binary : this is a path relative to the .preview folder in the repository. but .. you should never create this url manually! Instead, use the url rewriting functionality provided by Hippo Portal. There are two components you can use: 1. the LinkFactory object, which you can get by calling getCMSRequestContext().getLinkFactory() from your portlet 2. the SimpleLinkRewriter object, which wraps the LinkFactory object, so it can be easily used from an XSLT or FreeMarker template. I think you need the SimpleLinkRewriter object, since you're transforming an url in your XML document to a portal url from inside an XSLT right? An instance of the SimpleLinkRewriter is passed as part of the XSLT model (XSLt parameters) by default (see the method createXSLTTransformerModel(..) in [1]). So you don't have to do pass it as a parameter, just change your XSLt to use that SimpleLinkRewriter to convert binaries urls to portal urls. Here's an example peice of XSLt code doing just that: The code uses the Xalan extension feature to use the complex object SimpleLinkRewriter. The linkrewriter will take care of rewriting repository urls ( /content/.. or /binaries/.. urls) to portal urls. But the linkrewriter is not limited to rewriting content urls, you can also rewrite sitemap urls to portal urls, e.g. : linkrewriter.rewrite("sitemap:/department1/news"); will create a portal url like /ourportal/portal/site/department1/news It's also possible to generate urls by referencing a unique ID of a sitemap item in your sitemap. E.g. if you have the following sitemap item in your sitemap: then you can create a portal url for that by calling: linkrewriter.rewrite("sitemap:id:aboutPage"); this will result in the url: /ourportal/portal/site/about Notice that the "name" attribute of the fixed-item shows up in the url. The linkrewriter is also passed as a parameter "linkrewriter" to a FreeMarker template, which is even more straightforward to use. hth Dennis [1] http://svn.hippocms.org/repos/hippo/hippo-portal/branches/PORTAL-1.10.xx-branch/hippo-portal-pac/src/main/java/nl/hippo/portal/cms/portlets/BaseContentPortlet.java PS. I cross-posted this mail to the hippo-portal-dev list, because it can be useful for other Hippo-Portal developers as well. S Kindrat wrote: > In the portal front-end. I noticed in > ${tomcat.home}/webapps/ourportal/WEB-INF/web.xml the following: > > CMSResourceServlet > /binaries/* > > > so, I took out all the proxy rules, and now, am getting a 404 error on the > image itself, a 403 error on http://servername.com:8080/ourportal/binaries/, > and 404's on everything in between (all produced by tomcat). Since the > portal should have built-in support, should I move this discussion to the > hippoportal-dev list? > > On Wed, Oct 8, 2008 at 11:20 AM, Jeroen Reijn wrote: > > >> Hi Shawn, >> >> I guess the question here is: Where do you want to render the images? >> >> - In your portal front-end? >> - In your CMS ? >> - Or somewhere else? >> >> The portal should have build-in support for rendering images from the >> repository. >> >> Regards, >> >> Jeroen >> >> >> >> >> S Kindrat wrote: >> >> >>> Right, and siteuser works fine for the portal. So I guess my question is, >>> how would I display images in the repository (for example, >>> /binaries/documents/home/testimage.jpg). I was able to access it through >>> http://:50000/assetspreview/binaries/documents/home/testimage.jpg >>> and http://:50000/binaries/documents/home/testimage.jpg, if, and >>> only if, I'm logged into the CMS. I am also able to access it directly >>> through port 60000, which has basic http authentication, and works fine >>> with >>> siteuser. >>> >>> I tried setting up a ProxyPass rule in apache, but it doesn't seem to work >>> with http://siteuser >>> :@:60000/default/files/default.preview/binaries/, >>> where it still prompts for the username and password. (I tried the >>> http://siteuser:pass@server:60000/default/ directly in a new web >>> browser (no authentication) and it works fine that way) >>> >>> These are the rules I have so far: >>> # Binaries rules >>> ProxyPass /binaries/ http://siteuser >>> :@localhost:60000/default/files/default.preview/binaries/ >>> ProxyPassReverse /binaries/ http://siteuser >>> :@localhost:60000/default/files/default.preview/binaries/ >>> # Portal application >>> ProxyPass / http://localhost:8080/ourportal/portal/ >>> ProxyPassReverse / http://localhost:8080/ourportal/portal/ >>> >>> As I said, I'm seeing no support for hard coding the user/pass into the >>> URLs >>> in the proxy rules. Am I on the right track going the route of >>> proxy/rewriting, or is there an easier way? >>> >>> Thanks >>> >>> Shawn >>> >>> On Tue, Oct 7, 2008 at 8:48 PM, Bartosz Oudekerk >> >>>> wrote: >>>> >>> S Kindrat wrote: >>> >>>> Is there any way to make the binaries public? Or have I missed >>>> >>>>> something >>>>> with regards to anonymous users? I have to admit, I have not seen >>>>> anything >>>>> about setting up an anonymous user at all with this software, so it >>>>> could >>>>> be >>>>> I've missed something. >>>>> >>>>> Using Hippo CMS 6.05.04, I have looked through all the permissions as >>>>> the >>>>> root user, and have seen nothing about anonyomous or unauthenticated. >>>>> >>>>> There is no anonymous user as such, but there's a default user called >>>>> >>>> siteuser (with passwd siteuser), which has read-only rights on the >>>> repository. That's the user you should use for your site/portal. >>>> >>>> Regards, >>>> Bartosz >>>> ******************************************** >>>> Hippocms-dev: Hippo CMS development public mailinglist >>>> >>>> Searchable archives can be found at: >>>> MarkMail: http://hippocms-dev.markmail.org >>>> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html >>>> >>>> >>>> ******************************************** >>>> >>> Hippocms-dev: Hippo CMS development public mailinglist >>> >>> Searchable archives can be found at: >>> MarkMail: http://hippocms-dev.markmail.org >>> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html >>> >>> ******************************************** >>> >> Hippocms-dev: Hippo CMS development public mailinglist >> >> Searchable archives can be found at: >> MarkMail: http://hippocms-dev.markmail.org >> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html >> >> >> > ******************************************** > Hippocms-dev: Hippo CMS development public mailinglist > > Searchable archives can be found at: > MarkMail: http://hippocms-dev.markmail.org > Nabble: http://www.nabble.com/Hippo-CMS-f26633.html > > From helpdesk at hippo.nl Wed Oct 8 12:50:59 2008 From: helpdesk at hippo.nl (JIRA (Dennis Dam)) Date: Wed Oct 8 12:50:59 2008 Subject: [Hippoportal-dev] [JIRA] Created: (PORTAL-85) Ability to override the mapping of portal url to corresponding repository source Message-ID: <20990675.1223463059193.JavaMail.jira@hat01> Ability to override the mapping of portal url to corresponding repository source -------------------------------------------------------------------------------- Key: PORTAL-85 URL: http://issues.hippo.nl/browse/PORTAL-85 Project: Hippo Portal Issue Type: Improvement Components: hippo-portal, hippo-portal-api Affects Versions: 1.07.00, 1.10.00.m02 Reporter: Dennis Dam Priority: Normal Fix For: 1.07.00, 1.10.00.m02 see the Mail from Michiel Trimpe on the hippo-portal-dev list, dated Oct. 7, 2008: I've analyzed the problem a bit further (your solution doesn't work for us) and I've come to the conclusion that we basically need the mapping from a SiteMapItem to a source DocumentPath to be configurable. At present there's some default logic for mapping a SiteMapItem to a DocumentPath source (adding the postfix and replacing ".html" with ".xml") and we need some extra logic there (if the resource is a collection and there is no postfix then find a document sibling with the same name). Is there any way to customize that logic? On a side note, after having implemented the Hippo Portal in our company for the past few weeks I find that the biggest problem I keep running into is the lack of extensibility / configurability, such as described above. It seems like there's been fairly little thought put into defining (and documenting) appropriate extension points and a mechanism to do so. This problem could for example be resolved by moving CMSRequestContextImpl.getSrc(SiteMapItem, CMSPortalURL, boolean) to an interface CMSSourceResolver(SiteMapItem, CMSPortalURL, CMSService, boolean) and adding the CMSSourceResolver to CMSApplicationRegistryImpl. Another option would be to add a CMSRequestContextFactory which we can configure. All in all it's been really nice to explore the Hippo Portal internals though; apart from the extensibility it's a really nicely architectured system. - Michiel Trimpe -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.hippo.nl/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From helpdesk at hippo.nl Wed Oct 8 12:54:58 2008 From: helpdesk at hippo.nl (JIRA (Dennis Dam)) Date: Wed Oct 8 12:55:00 2008 Subject: [Hippoportal-dev] [JIRA] Commented: (PORTAL-85) Ability to override the mapping of portal url to corresponding repository source In-Reply-To: <20990675.1223463059193.JavaMail.jira@hat01> Message-ID: <12178997.1223463298636.JavaMail.jira@hat01> [ http://issues.hippo.nl/browse/PORTAL-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39696 ] Dennis Dam commented on PORTAL-85: ---------------------------------- In general, we could provide more extension points by providing pluggable factories. For example, in this case we could add a CMSRequestContextFactory, so developers will have full controll over the CMSRequestContext. Michiel could then make his changes by extending CMSRequestContextImpl and overriding getSrc(). Ofcourse, we would have to refactor CMSRequestContextImpl somewhat, to make it extensible. > Ability to override the mapping of portal url to corresponding repository source > -------------------------------------------------------------------------------- > > Key: PORTAL-85 > URL: http://issues.hippo.nl/browse/PORTAL-85 > Project: Hippo Portal > Issue Type: Improvement > Components: hippo-portal, hippo-portal-api > Affects Versions: 1.07.00, 1.10.00.m02 > Reporter: Dennis Dam > Priority: Normal > Fix For: 1.07.00, 1.10.00.m02 > > > see the Mail from Michiel Trimpe on the hippo-portal-dev list, dated Oct. 7, 2008: > I've analyzed the problem a bit further (your solution doesn't work for us) and I've come to the conclusion that we basically need the mapping from a SiteMapItem to a source DocumentPath to be configurable. > At present there's some default logic for mapping a SiteMapItem to a DocumentPath source (adding the postfix and replacing ".html" with ".xml") and we need some extra logic there (if the resource is a collection and there is no postfix then find a document sibling with the same name). > Is there any way to customize that logic? > On a side note, after having implemented the Hippo Portal in our company for the past few weeks I find that the biggest problem I keep running into is the lack of extensibility / configurability, such as described above. It seems like there's been fairly little thought put into defining (and documenting) appropriate extension points and a mechanism to do so. > This problem could for example be resolved by moving CMSRequestContextImpl.getSrc(SiteMapItem, CMSPortalURL, boolean) to an interface CMSSourceResolver(SiteMapItem, CMSPortalURL, CMSService, boolean) and adding the CMSSourceResolver to CMSApplicationRegistryImpl. Another option would be to add a CMSRequestContextFactory which we can configure. > All in all it's been really nice to explore the Hippo Portal internals though; apart from the extensibility it's a really nicely architectured system. > - Michiel Trimpe -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.hippo.nl/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From d.dam at onehippo.com Wed Oct 8 12:55:35 2008 From: d.dam at onehippo.com (Dennis Dam) Date: Wed Oct 8 12:55:37 2008 Subject: [Hippoportal-dev] Rewriting the (xml) datasource after performing the ProfilerValve In-Reply-To: <990c65350810070753h61ca9333yff0f8e87f482bea5@mail.gmail.com> References: <990c65350810010552v1562b16fie967325eebf2a647@mail.gmail.com> <48E37A84.6010605@onehippo.com> <990c65350810070753h61ca9333yff0f8e87f482bea5@mail.gmail.com> Message-ID: <48EC91A7.6060601@onehippo.com> Hi Michiel, thanks for your feedback. Nice to see you're working so intensely with Hippo Portal and have some positive feedback on it, as well as some points of improvements. I understand what your problem is with respect to extensibility, specifically with the issue you're facing. I made a Jira issue for it: http://issues.hippo.nl/browse/PORTAL-85 Dennis Michiel Trimpe wrote: > I've analyzed the problem a bit further (your solution doesn't work > for us) and I've come to the conclusion that we basically need the > mapping from a SiteMapItem to a source DocumentPath to be configurable. > > At present there's some default logic for mapping a SiteMapItem to a > DocumentPath source (adding the postfix and replacing ".html" with > ".xml") and we need some extra logic there (if the resource is a > collection and there is no postfix then find a document sibling with > the same name). > > Is there any way to customize that logic? > > On a side note, after having implemented the Hippo Portal in our > company for the past few weeks I find that the biggest problem I keep > running into is the lack of extensibility / configurability, such as > described above. It seems like there's been fairly little thought put > into defining (and documenting) appropriate extension points and a > mechanism to do so. > > This problem could for example be resolved by moving > CMSRequestContextImpl.getSrc(SiteMapItem, CMSPortalURL, boolean) to an > interface CMSSourceResolver(SiteMapItem, CMSPortalURL, CMSService, > boolean) and adding the CMSSourceResolver to > CMSApplicationRegistryImpl. Another option would be to add a > CMSRequestContextFactory which we can configure. > > All in all it's been really nice to explore the Hippo Portal internals > though; apart from the extensibility it's a really nicely > architectured system. > > - Michiel Trimpe > > On Wed, Oct 1, 2008 at 3:26 PM, Dennis Dam > wrote: > > Hi Michiel, > > Can you not just construct the path to the correct document in the > portlet that uses the datasource? I'm assuming you want to fetch > some kind of "index" document which is shown on the page generated > by collection.psml. Usually we either look for a fixed name in the > repository folder where the datasource points to (e.g. datasource > + "/index.xml), or execute a DASL to look for a document in that > folder, of a certain type (e.g. type = "introduction" or so, > depends on your CMS config). > > hth, > Dennis > > Michiel Trimpe wrote: > > Ate, Jeroen, Dennis, > > Is there any way to rewrite the datasource xml location after > resolving the PSML? > > When a request resolves to 'collection.psml' we need to > rewrite datasources that do not point to an XML (e.g. > /content/documents/level1item) to the appropriate XML document. > > That way we can handle requests like www.site.name/level1item > > without redirecting to > something like www.site.name/level1item.html > > > > > At the moment all our root elements that are 'repository > based' don't work because of this. > > Regards, > > Michiel Trimpe > > ------------------------------------------------------------------------ > > _______________________________________________ > Hippoportal-dev mailing list > Hippoportal-dev@lists.hippo.nl > http://lists.hippo.nl/mailman/listinfo/hippoportal-dev > From skindrat at bridgesforpeace.com Wed Oct 8 13:00:20 2008 From: skindrat at bridgesforpeace.com (S Kindrat) Date: Wed Oct 8 13:00:58 2008 Subject: [Hippoportal-dev] Link Rewriting features (was: Re: [HippoCMS-dev] Image asset permissions) In-Reply-To: <48EC8A07.20608@onehippo.com> References: <9e891b600810070924p3bbd43f2m390afe540c71fe8e@mail.gmail.com> <48EBAF11.20902@onehippo.com> <9e891b600810080148g1ce440bbjacbf972230640178@mail.gmail.com> <48EC7B4C.4070206@onehippo.com> <9e891b600810080236v2a6780c8wd4798d13db71ef67@mail.gmail.com> <48EC8A07.20608@onehippo.com> Message-ID: <9e891b600810080400y2d95d3fetc0a1fc6874275690@mail.gmail.com> Wonderful! Thank you for the great information. I was able to get the image with the URL structure you provided. As far as the rest of the information goes, I'm going to have to wait until Monday to try out the XSLT and any of the other information, since we're just about to start a holiday here. I will let you know how it goes. Thanks so much! Shawn On Wed, Oct 8, 2008 at 12:23 PM, Dennis Dam wrote: > Hi Shawn, > > the url you should get for accessing binaries from the portal should look > something like this: > > /ourportal/binaries/site/binaries/folder1/image1.jpg > > where : > > /ourportal/binaries is the servlet path you mentioned before > "site" is the identifier of the Site that is configured in hippo-portal.xml > /binaries/folder1/image1.jpg is the path to the binary : this is a path > relative to the .preview folder in the repository. > > but .. you should never create this url manually! Instead, use the url > rewriting functionality provided by Hippo Portal. There are two components > you can use: > > 1. the LinkFactory object, which you can get by calling > getCMSRequestContext().getLinkFactory() from your portlet > 2. the SimpleLinkRewriter object, which wraps the LinkFactory object, so it > can be easily used from an XSLT or FreeMarker template. > > I think you need the SimpleLinkRewriter object, since you're transforming > an url in your XML document to a portal url from inside an XSLT right? An > instance of the SimpleLinkRewriter is passed as part of the XSLT model (XSLt > parameters) by default (see the method createXSLTTransformerModel(..) in > [1]). So you don't have to do pass it as a parameter, just change your XSLt > to use that SimpleLinkRewriter to convert binaries urls to portal urls. > Here's an example peice of XSLt code doing just that: > > xmlns:lw="xalan://nl.hippo.portal.cms.site.SimpleLinkRewriter" > xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" > exclude-result-prefixes="lw" > > > > > > > > > > > > select="lw:rewrite($linkrewriter,string(@href))"/> > select="$url"/> > > > > > > The code uses the Xalan extension feature to use the complex object > SimpleLinkRewriter. The linkrewriter will take care of rewriting repository > urls ( /content/.. or /binaries/.. urls) to portal urls. But the > linkrewriter is not limited to rewriting content urls, you can also rewrite > sitemap urls to portal urls, e.g. : > > linkrewriter.rewrite("sitemap:/department1/news"); > > will create a portal url like > > /ourportal/portal/site/department1/news > > > It's also possible to generate urls by referencing a unique ID of a sitemap > item in your sitemap. E.g. if you have the following sitemap item in your > sitemap: > > name="aboutPage"/> > > then you can create a portal url for that by calling: > > linkrewriter.rewrite("sitemap:id:aboutPage"); > > this will result in the url: > > /ourportal/portal/site/about > > Notice that the "name" attribute of the fixed-item shows up in the url. > > The linkrewriter is also passed as a parameter "linkrewriter" to a > FreeMarker template, which is even more straightforward to use. > > hth > Dennis > > [1] > http://svn.hippocms.org/repos/hippo/hippo-portal/branches/PORTAL-1.10.xx-branch/hippo-portal-pac/src/main/java/nl/hippo/portal/cms/portlets/BaseContentPortlet.java > > > PS. I cross-posted this mail to the hippo-portal-dev list, because it can > be useful for other Hippo-Portal developers as well. > > S Kindrat wrote: > >> In the portal front-end. I noticed in >> ${tomcat.home}/webapps/ourportal/WEB-INF/web.xml the following: >> >> CMSResourceServlet >> /binaries/* >> >> >> so, I took out all the proxy rules, and now, am getting a 404 error on the >> image itself, a 403 error on >> http://servername.com:8080/ourportal/binaries/, >> and 404's on everything in between (all produced by tomcat). Since the >> portal should have built-in support, should I move this discussion to the >> hippoportal-dev list? >> >> On Wed, Oct 8, 2008 at 11:20 AM, Jeroen Reijn >> wrote: >> >> >> >>> Hi Shawn, >>> >>> I guess the question here is: Where do you want to render the images? >>> >>> - In your portal front-end? >>> - In your CMS ? >>> - Or somewhere else? >>> >>> The portal should have build-in support for rendering images from the >>> repository. >>> >>> Regards, >>> >>> Jeroen >>> >>> >>> >>> >>> S Kindrat wrote: >>> >>> >>> >>>> Right, and siteuser works fine for the portal. So I guess my question >>>> is, >>>> how would I display images in the repository (for example, >>>> /binaries/documents/home/testimage.jpg). I was able to access it >>>> through >>>> http:// >>>> :50000/assetspreview/binaries/documents/home/testimage.jpg >>>> and http://:50000/binaries/documents/home/testimage.jpg, if, >>>> and >>>> only if, I'm logged into the CMS. I am also able to access it directly >>>> through port 60000, which has basic http authentication, and works fine >>>> with >>>> siteuser. >>>> >>>> I tried setting up a ProxyPass rule in apache, but it doesn't seem to >>>> work >>>> with http://siteuser >>>> :@:60000/default/files/default.preview/binaries/, >>>> where it still prompts for the username and password. (I tried the >>>> http://siteuser:pass@server:60000/default/ directly in a new web >>>> browser (no authentication) and it works fine that way) >>>> >>>> These are the rules I have so far: >>>> # Binaries rules >>>> ProxyPass /binaries/ http://siteuser >>>> :@localhost:60000/default/files/default.preview/binaries/ >>>> ProxyPassReverse /binaries/ http://siteuser >>>> :@localhost:60000/default/files/default.preview/binaries/ >>>> # Portal application >>>> ProxyPass / http://localhost:8080/ourportal/portal/ >>>> ProxyPassReverse / http://localhost:8080/ourportal/portal/ >>>> >>>> As I said, I'm seeing no support for hard coding the user/pass into the >>>> URLs >>>> in the proxy rules. Am I on the right track going the route of >>>> proxy/rewriting, or is there an easier way? >>>> >>>> Thanks >>>> >>>> Shawn >>>> >>>> On Tue, Oct 7, 2008 at 8:48 PM, Bartosz Oudekerk < >>>> b.oudekerk@onehippo.com >>>> >>>> >>>>> wrote: >>>>> >>>>> >>>> S Kindrat wrote: >>>> >>>> >>>>> Is there any way to make the binaries public? Or have I missed >>>>> >>>>> >>>>>> something >>>>>> with regards to anonymous users? I have to admit, I have not seen >>>>>> anything >>>>>> about setting up an anonymous user at all with this software, so it >>>>>> could >>>>>> be >>>>>> I've missed something. >>>>>> >>>>>> Using Hippo CMS 6.05.04, I have looked through all the permissions as >>>>>> the >>>>>> root user, and have seen nothing about anonyomous or unauthenticated. >>>>>> >>>>>> There is no anonymous user as such, but there's a default user called >>>>>> >>>>>> >>>>> siteuser (with passwd siteuser), which has read-only rights on the >>>>> repository. That's the user you should use for your site/portal. >>>>> >>>>> Regards, >>>>> Bartosz >>>>> ******************************************** >>>>> Hippocms-dev: Hippo CMS development public mailinglist >>>>> >>>>> Searchable archives can be found at: >>>>> MarkMail: http://hippocms-dev.markmail.org >>>>> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html >>>>> >>>>> >>>>> ******************************************** >>>>> >>>>> >>>> Hippocms-dev: Hippo CMS development public mailinglist >>>> >>>> Searchable archives can be found at: >>>> MarkMail: http://hippocms-dev.markmail.org >>>> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html >>>> >>>> ******************************************** >>>> >>>> >>> Hippocms-dev: Hippo CMS development public mailinglist >>> >>> Searchable archives can be found at: >>> MarkMail: http://hippocms-dev.markmail.org >>> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html >>> >>> >>> >>> >> ******************************************** >> Hippocms-dev: Hippo CMS development public mailinglist >> >> Searchable archives can be found at: >> MarkMail: http://hippocms-dev.markmail.org >> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html >> >> >> > > _______________________________________________ > Hippoportal-dev mailing list > Hippoportal-dev@lists.hippo.nl > http://lists.hippo.nl/mailman/listinfo/hippoportal-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hippo.nl/pipermail/hippoportal-dev/attachments/20081008/a1c53b30/attachment.htm From d.dam at onehippo.com Wed Oct 8 14:08:41 2008 From: d.dam at onehippo.com (Dennis Dam) Date: Wed Oct 8 14:08:47 2008 Subject: [Hippoportal-dev] paging in FreeMarkerListContentPortlet In-Reply-To: References: Message-ID: <48ECA2C9.7090600@onehippo.com> Hi Geert, Geert van der Ploeg wrote: > > Hello all, > > I have some questions regarding paging, using the portlet > FreeMarkerListContentPortlet. > > Although paging as a whole seems to be present, there are two parts > that either do not work or are not yet clear to me :-) > > 1. Getting 'current page' from the request, prior to filling the model > does not seem to work. > > In Pager.java:173, this parameter is fetched from the request > context's portalURL. However, this URL does not contain the request > parameters at all. The only thing to configure is the name of the > parameter, in portlet.xml. Right? > there's a difference between request parameters and portal parameters. Request parameters are not available to portlets. That's one of the reasons why Hippo Portal uses it's own mechanism for url handling. In (Hippo) portal urls, parameters start with &, like: http://localhost:8080/my/path/&relatedcontentPageNr=3 btw, you also have to configure the application property "nl.hippo.portal.ftl.template.paging" in one of the application properties files (see the bean nl.hippo.portal.app.ApplicationProperties in applicationContext.xml), e.g. : nl.hippo.portal.ftl.template.paging=WEB-INF/ftl/paging.ftl > > 2. Setting the URL's in the FM template ends up with corrupt urls. > What's added is just a ampersand and parameter, without any check for > existing parameters. > Result: paging links on a page with URL > 'http://localhost:8080/my/path' will read something like > '//my/path/&relatedcontentPageNr=3' > - two leading slashes, making 'my' the host-part of the url > - no question mark added as start of request parameters > it's a little difficult to see what's going wrong, can you show me the FreeMarker script that produces the paging html, and anything else that is relevant to paging ? > > My Hippo portal /portal pac version: 1.07.00 > Portlet configuration in portlet.xml: > ~~~~ > > a > relatedcontent > > nl.hippo.portal.cms.portlets.FreeMarkerListContentPortlet > > -1 > > text/html > VIEW > > nl > > relatedcontent > > > > dasl_query > > WEB-INF/templates/dasl/myfreemarkertpl.ftl > > > > ViewPage > > /WEB-INF/templates/myFreeMarkerTemplate/myFreeMarkerTemplate.ftl > > > > pagingLimit > 3 > > > pageParameterName > relatedcontentPageNr > > > > ~~~~ > > Thanks in advance. > > Regards, > Geert van der Ploeg > > ------------------------------------------------------------------------ > > _______________________________________________ > Hippoportal-dev mailing list > Hippoportal-dev@lists.hippo.nl > http://lists.hippo.nl/mailman/listinfo/hippoportal-dev > From nick.stolwijk at gmail.com Fri Oct 10 11:00:39 2008 From: nick.stolwijk at gmail.com (Nick Stolwijk) Date: Fri Oct 10 11:00:50 2008 Subject: [Hippoportal-dev] LinkFactory troubles Message-ID: <3a15f5ad0810100200k6ee29adk1214676f25a0ad02@mail.gmail.com> After the solution of PORTAL-79[1] we have an issue with the LinkFactory. There has been a fix to the JetspeedCMSPortalURL.java [2] to include the basePath. (See revision 13551) Whenever we rewrite an url with the LinkFactory we get a double '/' in front of the url. Browser will trip over this, because they don't see it as a relative path, but as an absolute path. We are using the LinkFactory as follows: LinkItem link = linkFactory.createLinkItem(request, response, "", doc.getPath().getRelativePath()); Are we using the LinkFactory with the wrong parameters? With regards, [1] http://issues.hippo.nl/browse/PORTAL-79 [2] http://svn.hippoforge.org/repos/hippo/hippo-portal/trunk/hippo-portal-j2/src/java/nl/hippo/portal/cms/jetspeed/JetspeedCMSPortalURL.java Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl From helpdesk at hippo.nl Fri Oct 10 12:44:59 2008 From: helpdesk at hippo.nl (JIRA (Dennis Dam)) Date: Fri Oct 10 12:49:36 2008 Subject: [Hippoportal-dev] [JIRA] Created: (PORTAL-86) Linkrewriter urls contain double / Message-ID: <24476742.1223635499069.JavaMail.jira@hat01> Linkrewriter urls contain double / ---------------------------------- Key: PORTAL-86 URL: http://issues.hippo.nl/browse/PORTAL-86 Project: Hippo Portal Issue Type: Bug Components: hippo-portal, hippo-portal-api, hippo-portal-j2 Affects Versions: 1.07.01, 1.10.00.m02 Reporter: Dennis Dam Assignee: Dennis Dam Priority: Normal -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.hippo.nl/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From helpdesk at hippo.nl Fri Oct 10 12:54:58 2008 From: helpdesk at hippo.nl (JIRA (Dennis Dam)) Date: Fri Oct 10 13:00:47 2008 Subject: [Hippoportal-dev] [JIRA] Resolved: (PORTAL-86) Linkrewriter urls contain double / In-Reply-To: <24476742.1223635499069.JavaMail.jira@hat01> Message-ID: <28505203.1223636098657.JavaMail.jira@hat01> [ http://issues.hippo.nl/browse/PORTAL-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Dam resolved PORTAL-86. ------------------------------ Fix Version/s: 1.07.01 1.10.00.m02 Resolution: Fixed solved by replacing double / in the resulting String with a single / > Linkrewriter urls contain double / > ---------------------------------- > > Key: PORTAL-86 > URL: http://issues.hippo.nl/browse/PORTAL-86 > Project: Hippo Portal > Issue Type: Bug > Components: hippo-portal, hippo-portal-api, hippo-portal-j2 > Affects Versions: 1.07.01, 1.10.00.m02 > Reporter: Dennis Dam > Assignee: Dennis Dam > Priority: Normal > Fix For: 1.07.01, 1.10.00.m02 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.hippo.nl/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From d.dam at onehippo.com Fri Oct 10 12:55:46 2008 From: d.dam at onehippo.com (Dennis Dam) Date: Fri Oct 10 13:00:59 2008 Subject: [Hippoportal-dev] LinkFactory troubles In-Reply-To: <3a15f5ad0810100200k6ee29adk1214676f25a0ad02@mail.gmail.com> References: <3a15f5ad0810100200k6ee29adk1214676f25a0ad02@mail.gmail.com> Message-ID: <48EF34B2.10901@onehippo.com> Hi Nick, Thanks for giving us the heads up, Nick. I just fixed this bug, see http://issues.hippo.nl/browse/PORTAL-86 . The bugfix will be available from version 1.07.01. regards, Dennis Nick Stolwijk wrote: > After the solution of PORTAL-79[1] we have an issue with the > LinkFactory. There has been a fix to the JetspeedCMSPortalURL.java [2] > to include the basePath. (See revision 13551) > > Whenever we rewrite an url with the LinkFactory we get a double '/' in > front of the url. Browser will trip over this, because they don't see > it as a relative path, but as an absolute path. > > We are using the LinkFactory as follows: > > LinkItem link = linkFactory.createLinkItem(request, response, "", > doc.getPath().getRelativePath()); > > Are we using the LinkFactory with the wrong parameters? > > With regards, > > [1] http://issues.hippo.nl/browse/PORTAL-79 > [2] http://svn.hippoforge.org/repos/hippo/hippo-portal/trunk/hippo-portal-j2/src/java/nl/hippo/portal/cms/jetspeed/JetspeedCMSPortalURL.java > > Nick Stolwijk > ~Java Developer~ > > Iprofs BV. > Claus Sluterweg 125 > 2012 WS Haarlem > www.iprofs.nl > _______________________________________________ > Hippoportal-dev mailing list > Hippoportal-dev@lists.hippo.nl > http://lists.hippo.nl/mailman/listinfo/hippoportal-dev > From GvanderPloeg at iprofs.nl Mon Oct 13 13:28:36 2008 From: GvanderPloeg at iprofs.nl (Geert van der Ploeg) Date: Mon Oct 13 13:28:39 2008 Subject: [Hippoportal-dev] paging in FreeMarkerListContentPortlet References: <48ECA2C9.7090600@onehippo.com> Message-ID: Dennis, Thanks for clarifying the request/portal parameter part. But then I'm still stuck with not having the paging-parameter available. getPortletParameter() should be able to retrieve this one, right? (presume that I supply a URL like: localhost:8080/my/page/&pageNr=2) Your suggestion about configuring the location of the paging-ftl makes me think that that paging ftl will automatically inserted when needed. Is this correct? If so, then my current ftl is probably incorrect, as I do an include of the paging.ftl myself (which is the default provided paging.ftl). So, the ftl for my portlet contains: <#include "../paging.ftl"/> After a review of the FreeMarkerListContentPortlet's code, I concluded that I can just specify ${paging} in my own template. Well, this renders the same HTML, so the issue of wrong URL's (href="//my/page/?pageNr=2") still exists. Regards, Geert ________________________________ From: hippoportal-dev-bounces@lists.hippo.nl on behalf of Dennis Dam Sent: Wed 2008-10-08 14:08 To: Hippo Portal development public mailinglist Subject: Re: [Hippoportal-dev] paging in FreeMarkerListContentPortlet Hi Geert, Geert van der Ploeg wrote: > > Hello all, > > I have some questions regarding paging, using the portlet > FreeMarkerListContentPortlet. > > Although paging as a whole seems to be present, there are two parts > that either do not work or are not yet clear to me :-) > > 1. Getting 'current page' from the request, prior to filling the model > does not seem to work. > > In Pager.java:173, this parameter is fetched from the request > context's portalURL. However, this URL does not contain the request > parameters at all. The only thing to configure is the name of the > parameter, in portlet.xml. Right? > there's a difference between request parameters and portal parameters. Request parameters are not available to portlets. That's one of the reasons why Hippo Portal uses it's own mechanism for url handling. In (Hippo) portal urls, parameters start with &, like: http://localhost:8080/my/path/&relatedcontentPageNr=3 btw, you also have to configure the application property "nl.hippo.portal.ftl.template.paging" in one of the application properties files (see the bean nl.hippo.portal.app.ApplicationProperties in applicationContext.xml), e.g. : nl.hippo.portal.ftl.template.paging=WEB-INF/ftl/paging.ftl > > 2. Setting the URL's in the FM template ends up with corrupt urls. > What's added is just a ampersand and parameter, without any check for > existing parameters. > Result: paging links on a page with URL > 'http://localhost:8080/my/path' will read something like > '//my/path/&relatedcontentPageNr=3' > - two leading slashes, making 'my' the host-part of the url > - no question mark added as start of request parameters > it's a little difficult to see what's going wrong, can you show me the FreeMarker script that produces the paging html, and anything else that is relevant to paging ? > > My Hippo portal /portal pac version: 1.07.00 > Portlet configuration in portlet.xml: > ~~~~ > > a > relatedcontent > > nl.hippo.portal.cms.portlets.FreeMarkerListContentPortlet > > -1 > > text/html > VIEW > > nl > > relatedcontent > > > > dasl_query > > WEB-INF/templates/dasl/myfreemarkertpl.ftl > > > > ViewPage > > /WEB-INF/templates/myFreeMarkerTemplate/myFreeMarkerTemplate.ftl > > > > pagingLimit > 3 > > > pageParameterName > relatedcontentPageNr > > > > ~~~~ > > Thanks in advance. > > Regards, > Geert van der Ploeg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8333 bytes Desc: not available Url : http://lists.hippo.nl/pipermail/hippoportal-dev/attachments/20081013/7c90b572/attachment.bin From d.dam at onehippo.com Thu Oct 16 10:26:07 2008 From: d.dam at onehippo.com (Dennis Dam) Date: Thu Oct 16 10:26:28 2008 Subject: [Hippoportal-dev] paging in FreeMarkerListContentPortlet In-Reply-To: References: <48ECA2C9.7090600@onehippo.com> Message-ID: <48F6FA9F.80403@onehippo.com> Hey Geert, Geert van der Ploeg wrote: > Dennis, > > Thanks for clarifying the request/portal parameter part. But then I'm > still stuck with not having the paging-parameter available. > getPortletParameter() should be able to retrieve this one, right? > (presume that I supply a URL like: localhost:8080/my/page/&pageNr=2) yeah it should, how did you configure the paging parameter name ("pageParameterName") ? You can use 1) a request parameter "pageParameterName" 2) a portlet preference "pageParameterName" or 3) an init param "pageParameterName" (in order of priority). You're using a portlet preference, so that should be ok, unless you're overriding that portlet preference from the PSML, or providing a portlet parameter ""pageParameterName" with the request. > > Your suggestion about configuring the location of the paging-ftl makes > me think that that paging ftl will automatically inserted when needed. > Is this correct? If so, then my current ftl is probably incorrect, as > I do an include of the paging.ftl myself (which is the default > provided paging.ftl). > So, the ftl for my portlet contains: > <#include "../paging.ftl"/> > > After a review of the FreeMarkerListContentPortlet's code, I concluded > that I can just specify ${paging} in my own template. yes, that's the preferred way of doing it. It makes it easier to reuse the code that generates paging, since the logic is usually the same for all paging portlets within one app. > Well, this renders the same HTML, so the issue of wrong URL's > (href="//my/page/?pageNr=2") still exists. I'm puzzled, since you're configuration looks fine. Can you try to debug the portlet app to see if the pageParameterName is loaded correctly ? If it is, try to see what happens in the Pager code. > > Regards, > Geert > > ------------------------------------------------------------------------ > *From:* hippoportal-dev-bounces@lists.hippo.nl on behalf of Dennis Dam > *Sent:* Wed 2008-10-08 14:08 > *To:* Hippo Portal development public mailinglist > *Subject:* Re: [Hippoportal-dev] paging in FreeMarkerListContentPortlet > > Hi Geert, > > Geert van der Ploeg wrote: > > > > Hello all, > > > > I have some questions regarding paging, using the portlet > > FreeMarkerListContentPortlet. > > > > Although paging as a whole seems to be present, there are two parts > > that either do not work or are not yet clear to me :-) > > > > 1. Getting 'current page' from the request, prior to filling the model > > does not seem to work. > > > > In Pager.java:173, this parameter is fetched from the request > > context's portalURL. However, this URL does not contain the request > > parameters at all. The only thing to configure is the name of the > > parameter, in portlet.xml. Right? > > > > there's a difference between request parameters and portal parameters. > Request parameters are not available to portlets. That's one of the > reasons why Hippo Portal uses it's own mechanism for url handling. In > (Hippo) portal urls, parameters start with &, like: > > http://localhost:8080/my/path/&relatedcontentPageNr=3 > > > btw, you also have to configure the application property > "nl.hippo.portal.ftl.template.paging" in one of the application > properties files (see the bean nl.hippo.portal.app.ApplicationProperties > in applicationContext.xml), e.g. : > > nl.hippo.portal.ftl.template.paging=WEB-INF/ftl/paging.ftl > > > > > > > 2. Setting the URL's in the FM template ends up with corrupt urls. > > What's added is just a ampersand and parameter, without any check for > > existing parameters. > > Result: paging links on a page with URL > > 'http://localhost:8080/my/path' > will read something like > > '//my/path/&relatedcontentPageNr=3' > > - two leading slashes, making 'my' the host-part of the url > > - no question mark added as start of request parameters > > > > it's a little difficult to see what's going wrong, can you show me the > FreeMarker script that produces the paging html, and anything else that > is relevant to paging ? > > > > > > My Hippo portal /portal pac version: 1.07.00 > > Portlet configuration in portlet.xml: > > ~~~~ > > > > a > > relatedcontent > > > > nl.hippo.portal.cms.portlets.FreeMarkerListContentPortlet > > > > -1 > > > > text/html > > VIEW > > > > nl > > > > relatedcontent > > > > > > > > dasl_query > > > > WEB-INF/templates/dasl/myfreemarkertpl.ftl > > > > > > > > ViewPage > > > > /WEB-INF/templates/myFreeMarkerTemplate/myFreeMarkerTemplate.ftl > > > > > > > > pagingLimit > > 3 > > > > > > pageParameterName > > relatedcontentPageNr > > > > > > > > ~~~~ > > > > Thanks in advance. > > > > Regards, > > Geert van der Ploeg > From GvanderPloeg at iprofs.nl Fri Oct 17 15:05:07 2008 From: GvanderPloeg at iprofs.nl (Geert van der Ploeg) Date: Fri Oct 17 15:05:11 2008 Subject: [Hippoportal-dev] paging in FreeMarkerListContentPortlet References: <48ECA2C9.7090600@onehippo.com> <48F6FA9F.80403@onehippo.com> Message-ID: Dennis, With some debugging i've been able to narrow down the problems. The one regarding the input of the page-parameter is due to caching: if the first request upon server-start already contains the page-parameter, it will be processed and the paging-logic then is correct. For subsequent requests, regardless of portlet-parameters, the same page will be displayed, with the same paging-logic. So that has to be sorted out. But it definitely has to do with caching. The other problem, regarding the href which contains a double leading slash (wrong link-url's), is caused at JetspeedCMSPortalURL:388, where getSitePath() and siteMapPath are joined. In my case, getSitePath() == '/' and siteMapPath == '/my/page'. Thus resulting in: '//my/page' This is intepreted by browsers as 'http://my/page'. Will keep searching... Regards, Geert ________________________________ From: hippoportal-dev-bounces@lists.hippo.nl on behalf of Dennis Dam Sent: Thu 2008-10-16 10:26 To: Hippo Portal development public mailinglist Subject: Re: [Hippoportal-dev] paging in FreeMarkerListContentPortlet Hey Geert, Geert van der Ploeg wrote: > Dennis, > > Thanks for clarifying the request/portal parameter part. But then I'm > still stuck with not having the paging-parameter available. > getPortletParameter() should be able to retrieve this one, right? > (presume that I supply a URL like: localhost:8080/my/page/&pageNr=2) yeah it should, how did you configure the paging parameter name ("pageParameterName") ? You can use 1) a request parameter "pageParameterName" 2) a portlet preference "pageParameterName" or 3) an init param "pageParameterName" (in order of priority). You're using a portlet preference, so that should be ok, unless you're overriding that portlet preference from the PSML, or providing a portlet parameter ""pageParameterName" with the request. > > Your suggestion about configuring the location of the paging-ftl makes > me think that that paging ftl will automatically inserted when needed. > Is this correct? If so, then my current ftl is probably incorrect, as > I do an include of the paging.ftl myself (which is the default > provided paging.ftl). > So, the ftl for my portlet contains: > <#include "../paging.ftl"/> > > After a review of the FreeMarkerListContentPortlet's code, I concluded > that I can just specify ${paging} in my own template. yes, that's the preferred way of doing it. It makes it easier to reuse the code that generates paging, since the logic is usually the same for all paging portlets within one app. > Well, this renders the same HTML, so the issue of wrong URL's > (href="//my/page/?pageNr=2") still exists. I'm puzzled, since you're configuration looks fine. Can you try to debug the portlet app to see if the pageParameterName is loaded correctly ? If it is, try to see what happens in the Pager code. > > Regards, > Geert > > ------------------------------------------------------------------------ > *From:* hippoportal-dev-bounces@lists.hippo.nl on behalf of Dennis Dam > *Sent:* Wed 2008-10-08 14:08 > *To:* Hippo Portal development public mailinglist > *Subject:* Re: [Hippoportal-dev] paging in FreeMarkerListContentPortlet > > Hi Geert, > > Geert van der Ploeg wrote: > > > > Hello all, > > > > I have some questions regarding paging, using the portlet > > FreeMarkerListContentPortlet. > > > > Although paging as a whole seems to be present, there are two parts > > that either do not work or are not yet clear to me :-) > > > > 1. Getting 'current page' from the request, prior to filling the model > > does not seem to work. > > > > In Pager.java:173, this parameter is fetched from the request > > context's portalURL. However, this URL does not contain the request > > parameters at all. The only thing to configure is the name of the > > parameter, in portlet.xml. Right? > > > > there's a difference between request parameters and portal parameters. > Request parameters are not available to portlets. That's one of the > reasons why Hippo Portal uses it's own mechanism for url handling. In > (Hippo) portal urls, parameters start with &, like: > > http://localhost:8080/my/path/&relatedcontentPageNr=3 > > > btw, you also have to configure the application property > "nl.hippo.portal.ftl.template.paging" in one of the application > properties files (see the bean nl.hippo.portal.app.ApplicationProperties > in applicationContext.xml), e.g. : > > nl.hippo.portal.ftl.template.paging=WEB-INF/ftl/paging.ftl > > > > > > > 2. Setting the URL's in the FM template ends up with corrupt urls. > > What's added is just a ampersand and parameter, without any check for > > existing parameters. > > Result: paging links on a page with URL > > 'http://localhost:8080/my/path' > will read something like > > '//my/path/&relatedcontentPageNr=3' > > - two leading slashes, making 'my' the host-part of the url > > - no question mark added as start of request parameters > > > > it's a little difficult to see what's going wrong, can you show me the > FreeMarker script that produces the paging html, and anything else that > is relevant to paging ? > > > > > > My Hippo portal /portal pac version: 1.07.00 > > Portlet configuration in portlet.xml: > > ~~~~ > > > > a > > relatedcontent > > > > nl.hippo.portal.cms.portlets.FreeMarkerListContentPortlet > > > > -1 > > > > text/html > > VIEW > > > > nl > > > > relatedcontent > > > > > > > > dasl_query > > > > WEB-INF/templates/dasl/myfreemarkertpl.ftl > > > > > > > > ViewPage > > > > /WEB-INF/templates/myFreeMarkerTemplate/myFreeMarkerTemplate.ftl > > > > > > > > pagingLimit > > 3 > > > > > > pageParameterName > > relatedcontentPageNr > > > > > > > > ~~~~ > > > > Thanks in advance. > > > > Regards, > > Geert van der Ploeg > _______________________________________________ Hippoportal-dev mailing list Hippoportal-dev@lists.hippo.nl http://lists.hippo.nl/mailman/listinfo/hippoportal-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 11157 bytes Desc: not available Url : http://lists.hippo.nl/pipermail/hippoportal-dev/attachments/20081017/f138526b/attachment.bin From helpdesk at hippo.nl Tue Oct 21 17:33:59 2008 From: helpdesk at hippo.nl (JIRA (Dennis Dam)) Date: Tue Oct 21 17:37:37 2008 Subject: [Hippoportal-dev] [JIRA] Created: (PORTAL-87) Update to latest stable version of hippo-repository-java-adapter Message-ID: <29183925.1224603239015.JavaMail.jira@hat01> Update to latest stable version of hippo-repository-java-adapter ---------------------------------------------------------------- Key: PORTAL-87 URL: http://issues.hippo.nl/browse/PORTAL-87 Project: Hippo Portal Issue Type: Task Components: hippo-portal Affects Versions: 1.07.01, 1.10.00.m02 Reporter: Dennis Dam Priority: Normal Fix For: 1.07.01, 1.10.00.m02 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.hippo.nl/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From helpdesk at hippo.nl Thu Oct 23 12:34:58 2008 From: helpdesk at hippo.nl (JIRA (Woonsan Ko)) Date: Thu Oct 23 12:34:59 2008 Subject: [Hippoportal-dev] [JIRA] Created: (PORTAL-88) Allow default init parameters for xslt path, content id and page size. Message-ID: <7057710.1224758098596.JavaMail.jira@hat01> Allow default init parameters for xslt path, content id and page size. ---------------------------------------------------------------------- Key: PORTAL-88 URL: http://issues.hippo.nl/browse/PORTAL-88 Project: Hippo Portal Issue Type: Improvement Components: hippo-portal-pac Affects Versions: 1.10.00m01 Reporter: Woonsan Ko Assignee: Woonsan Ko Priority: Low Fix For: 1.10.00.m02 Currently, all parameters such as xslt path, content id and page size are retrieved only via portlet preferences. If preferences are not provided, allow use default init parameters instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.hippo.nl/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From skindrat at bridgesforpeace.com Wed Oct 29 11:03:52 2008 From: skindrat at bridgesforpeace.com (S Kindrat) Date: Wed Oct 29 11:03:59 2008 Subject: [Hippoportal-dev] xsl:include placement in Hippo Portal (was: Link Rewriting features) Message-ID: <9e891b600810290303m1cfb874fqf72e804c07a9759e@mail.gmail.com> Alright! Got everything functioning as I want, so far. I have a few ideas floating around in my head, but I'd like to see if anyone has any other suggestions for where to place a common xslt file for use in any portlet. Basically, as it is now, I have an xslt named renderhtml.xslt (I'll probably rename it to something more specific before finalizing things). I only have one test portlet compiled so far, and if I write testing.xslt (the file referenced in portlet.xml) as below, everything works just fine (both xslt files are in $appserverhome/webapps/testportlet/WEB-INF/xslt/): A couple things come to mind for placing this file in a single place for all portlets to use... (I'm running on tomcat 5.5) 1. Place it in some web directory to be access through HTTP. Not a good way, imo. 2. Place it in a standard filesystem directory to be access as 'file://'. Getting better, but I don't want to mess around with directory structures or property files, if I don't have to, just in case we change servers and need to modify that kind of thing. 3. Have a deployment tool copy the file to the xslt directory of any portlet that needs it (that could get messy, quick) 4. Use a standard 'common' area. This is where I'm a little stuck... Is there such a thing within hippo portal? I was thinking if I could put it in the 'hippo-portal' or 'ourportal' webapp, that would be ideal. However, I'm not 100% sure how the href would be written, as long as its doable I could figure that out easy enough. What it comes down to, I would prefer to keep it hidden from public eyes (which is why I'd like it buried in a WEB-INF folder... somewhere), and am really hoping for something along the lines of #4... Any thoughts or suggestions? Thanks! On Wed, Oct 8, 2008 at 1:00 PM, S Kindrat wrote: > Wonderful! Thank you for the great information. > > I was able to get the image with the URL structure you provided. As far as > the rest of the information goes, I'm going to have to wait until Monday to > try out the XSLT and any of the other information, since we're just about to > start a holiday here. I will let you know how it goes. > > Thanks so much! > > Shawn > > > On Wed, Oct 8, 2008 at 12:23 PM, Dennis Dam wrote: > >> Hi Shawn, >> >> the url you should get for accessing binaries from the portal should look >> something like this: >> >> /ourportal/binaries/site/binaries/folder1/image1.jpg >> >> where : >> >> /ourportal/binaries is the servlet path you mentioned before >> "site" is the identifier of the Site that is configured in >> hippo-portal.xml >> /binaries/folder1/image1.jpg is the path to the binary : this is a path >> relative to the .preview folder in the repository. >> >> but .. you should never create this url manually! Instead, use the url >> rewriting functionality provided by Hippo Portal. There are two components >> you can use: >> >> 1. the LinkFactory object, which you can get by calling >> getCMSRequestContext().getLinkFactory() from your portlet >> 2. the SimpleLinkRewriter object, which wraps the LinkFactory object, so >> it can be easily used from an XSLT or FreeMarker template. >> >> I think you need the SimpleLinkRewriter object, since you're transforming >> an url in your XML document to a portal url from inside an XSLT right? An >> instance of the SimpleLinkRewriter is passed as part of the XSLT model (XSLt >> parameters) by default (see the method createXSLTTransformerModel(..) in >> [1]). So you don't have to do pass it as a parameter, just change your XSLt >> to use that SimpleLinkRewriter to convert binaries urls to portal urls. >> Here's an example peice of XSLt code doing just that: >> >> > xmlns:lw="xalan://nl.hippo.portal.cms.site.SimpleLinkRewriter" >> xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" >> exclude-result-prefixes="lw" >> > >> >> >> >> >> >> >> >> >> >> > select="lw:rewrite($linkrewriter,string(@href))"/> >> > select="$url"/> >> >> >> >> >> >> The code uses the Xalan extension feature to use the complex object >> SimpleLinkRewriter. The linkrewriter will take care of rewriting repository >> urls ( /content/.. or /binaries/.. urls) to portal urls. But the >> linkrewriter is not limited to rewriting content urls, you can also rewrite >> sitemap urls to portal urls, e.g. : >> >> linkrewriter.rewrite("sitemap:/department1/news"); >> >> will create a portal url like >> >> /ourportal/portal/site/department1/news >> >> >> It's also possible to generate urls by referencing a unique ID of a >> sitemap item in your sitemap. E.g. if you have the following sitemap item in >> your sitemap: >> >> > name="aboutPage"/> >> >> then you can create a portal url for that by calling: >> >> linkrewriter.rewrite("sitemap:id:aboutPage"); >> >> this will result in the url: >> >> /ourportal/portal/site/about >> >> Notice that the "name" attribute of the fixed-item shows up in the url. >> >> The linkrewriter is also passed as a parameter "linkrewriter" to a >> FreeMarker template, which is even more straightforward to use. >> >> hth >> Dennis >> >> [1] >> http://svn.hippocms.org/repos/hippo/hippo-portal/branches/PORTAL-1.10.xx-branch/hippo-portal-pac/src/main/java/nl/hippo/portal/cms/portlets/BaseContentPortlet.java >> >> >> PS. I cross-posted this mail to the hippo-portal-dev list, because it can >> be useful for other Hippo-Portal developers as well. >> >> S Kindrat wrote: >> >>> In the portal front-end. I noticed in >>> ${tomcat.home}/webapps/ourportal/WEB-INF/web.xml the following: >>> >>> CMSResourceServlet >>> /binaries/* >>> >>> >>> so, I took out all the proxy rules, and now, am getting a 404 error on >>> the >>> image itself, a 403 error on >>> http://servername.com:8080/ourportal/binaries/, >>> and 404's on everything in between (all produced by tomcat). Since the >>> portal should have built-in support, should I move this discussion to the >>> hippoportal-dev list? >>> >>> On Wed, Oct 8, 2008 at 11:20 AM, Jeroen Reijn >>> wrote: >>> >>> >>> >>>> Hi Shawn, >>>> >>>> I guess the question here is: Where do you want to render the images? >>>> >>>> - In your portal front-end? >>>> - In your CMS ? >>>> - Or somewhere else? >>>> >>>> The portal should have build-in support for rendering images from the >>>> repository. >>>> >>>> Regards, >>>> >>>> Jeroen >>>> >>>> >>>> >>>> >>>> S Kindrat wrote: >>>> >>>> >>>> >>>>> Right, and siteuser works fine for the portal. So I guess my question >>>>> is, >>>>> how would I display images in the repository (for example, >>>>> /binaries/documents/home/testimage.jpg). I was able to access it >>>>> through >>>>> http:// >>>>> :50000/assetspreview/binaries/documents/home/testimage.jpg >>>>> and http://:50000/binaries/documents/home/testimage.jpg, if, >>>>> and >>>>> only if, I'm logged into the CMS. I am also able to access it directly >>>>> through port 60000, which has basic http authentication, and works fine >>>>> with >>>>> siteuser. >>>>> >>>>> I tried setting up a ProxyPass rule in apache, but it doesn't seem to >>>>> work >>>>> with http://siteuser >>>>> >>>>> :@:60000/default/files/default.preview/binaries/, >>>>> where it still prompts for the username and password. (I tried the >>>>> http://siteuser:pass@server:60000/default/ directly in a new web >>>>> browser (no authentication) and it works fine that way) >>>>> >>>>> These are the rules I have so far: >>>>> # Binaries rules >>>>> ProxyPass /binaries/ http://siteuser >>>>> :@localhost:60000/default/files/default.preview/binaries/ >>>>> ProxyPassReverse /binaries/ http://siteuser >>>>> :@localhost:60000/default/files/default.preview/binaries/ >>>>> # Portal application >>>>> ProxyPass / http://localhost:8080/ourportal/portal/ >>>>> ProxyPassReverse / http://localhost:8080/ourportal/portal/ >>>>> >>>>> As I said, I'm seeing no support for hard coding the user/pass into the >>>>> URLs >>>>> in the proxy rules. Am I on the right track going the route of >>>>> proxy/rewriting, or is there an easier way? >>>>> >>>>> Thanks >>>>> >>>>> Shawn >>>>> >>>>> On Tue, Oct 7, 2008 at 8:48 PM, Bartosz Oudekerk < >>>>> b.oudekerk@onehippo.com >>>>> >>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>> S Kindrat wrote: >>>>> >>>>> >>>>>> Is there any way to make the binaries public? Or have I missed >>>>>> >>>>>> >>>>>>> something >>>>>>> with regards to anonymous users? I have to admit, I have not seen >>>>>>> anything >>>>>>> about setting up an anonymous user at all with this software, so it >>>>>>> could >>>>>>> be >>>>>>> I've missed something. >>>>>>> >>>>>>> Using Hippo CMS 6.05.04, I have looked through all the permissions as >>>>>>> the >>>>>>> root user, and have seen nothing about anonyomous or unauthenticated. >>>>>>> >>>>>>> There is no anonymous user as such, but there's a default user >>>>>>> called >>>>>>> >>>>>>> >>>>>> siteuser (with passwd siteuser), which has read-only rights on the >>>>>> repository. That's the user you should use for your site/portal. >>>>>> >>>>>> Regards, >>>>>> Bartosz >>>>>> ******************************************** >>>>>> Hippocms-dev: Hippo CMS development public mailinglist >>>>>> >>>>>> Searchable archives can be found at: >>>>>> MarkMail: http://hippocms-dev.markmail.org >>>>>> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html >>>>>> >>>>>> >>>>>> ******************************************** >>>>>> >>>>>> >>>>> Hippocms-dev: Hippo CMS development public mailinglist >>>>> >>>>> Searchable archives can be found at: >>>>> MarkMail: http://hippocms-dev.markmail.org >>>>> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html >>>>> >>>>> ******************************************** >>>>> >>>>> >>>> Hippocms-dev: Hippo CMS development public mailinglist >>>> >>>> Searchable archives can be found at: >>>> MarkMail: http://hippocms-dev.markmail.org >>>> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html >>>> >>>> >>>> >>>> >>> ******************************************** >>> Hippocms-dev: Hippo CMS development public mailinglist >>> >>> Searchable archives can be found at: >>> MarkMail: http://hippocms-dev.markmail.org >>> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html >>> >>> >>> >> >> _______________________________________________ >> Hippoportal-dev mailing list >> Hippoportal-dev@lists.hippo.nl >> http://lists.hippo.nl/mailman/listinfo/hippoportal-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hippo.nl/pipermail/hippoportal-dev/attachments/20081029/fcd005f3/attachment.htm