[Hippo-cms7-user] Hst parameter definition/inheritance from mount

Woonsan Ko w.ko at onehippo.com
Thu Dec 6 15:30:12 CET 2012


On 12/6/12 8:42 AM, Ard Schrijvers wrote:
>>> You know that you can inherit common sitemap items from a common hst
>>> >>configuration, right? So, assume all your sites (mounts) have the same
>>> >>hst:root sitemap item with the same rel content path, then you can
>>> >>move hst:root to 'common' and inherit from 'common' configuration....
>>> >>
>>> >>Do you still think this is not enough for your usecase?
>>> >>
>>> >>What you suggest, is that on a hst:mount you could configure something
>>> >>like
>>> >>
>>> >>defaultnewspath = 'news'
>>> >>defaultagendapath = 'agenda'
>> >
>> >
>> >I noticed 'hst:parameternames' and 'hst:parametervalues' were available in a
>> >mount as well as sitemapitem. So, I thought 'hst:parameternames' and
>> >'hst:parametervalues' could be used to pass kind of global variable to
>> >sitemapitem and component, just like I could do it from sitemapitem to
>> >component. I don't mean ad hoc mount properties, but
>> >hst:parameter[names|values].
> ah yes, indeed.
>
>> >
>> >
>>> >>
>>> >>and that from a sitemap item news you could have
>>> >>
>>> >>hst:relativecontentpath = ${defaultnewspath}
>>> >>
>>> >>similar for agenda.
>>> >>
>>> >>Now, in case of a French site, where 'news' is called nouvelles, you
>>> >>could still reuse the same sitemapitem because on the French mount you
>>> >>would have
>>> >>
>>> >>defaultnewspath = nouvelles
>>> >>
>>> >>Is this what you suggest? I can see your point. Seems like a fine
>>> >>enhancement
>> >
>> >
>> >Yes, it is.:)
>> >But, also I thought these.
>> >
>> >hst:relativecontentpath = nouvelles_${region}
> yes, this is the same as for a hst component that uses a parameter
> name from sitemap item. That can also be for example 'year_${year}'
> where in the sitemap item there is a parameter called 'year' that has
> value ${1} where ${1} gets filled in by the request path

Indeed.

>
>> >
>> >when a mount has hst:parameter[names|values] for 'region'.
>> >
>> >Thank you so much again!
>   seems ok improvement to me. The only disadvantage (or advantage
> because then only targeting developers) is that we of course these
> days also have channel properties. Channel properties are not stored
> on the hst:mount but on channel nodes. Should we then also expose
> those in the same way? This might again be harder as channel
> properties can also be boolean, long, etc.

Ah good point. Hmm. I'm not really sure, but I guess this kind of 
variable usages in parameters are only for developers.

>
> Anyway, I am fine with only adding the feature for mount
> parameternames. WDYT? Would you mind creating a jira issue for it?

An improvement issue added:
- https://issues.onehippo.com/browse/HSTTWO-2386

Thank you so much!

Cheers,

Woonsan

>
> Regards Ard
>


-- 
w.ko at onehippo.com     www.onehippo.com
Boston - 1 Broadway, Cambridge, MA 02142
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466


More information about the Hippo-cms7-user mailing list