Hst parameter definition/inheritance from mount

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Hst parameter definition/inheritance from mount

Woonsan Ko-3

Hi,

I can let parameters inherited from sitemapitem to component configuration, but not from a mount even though a mount can have hst:parameternames and hst:parametervalues.
Is it a bug or something to improve?

Regards,

Woonsan


_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/forums.html
Ard
Reply | Threaded
Open this post in threaded view
|

Re: Hst parameter definition/inheritance from mount

Ard
Op 30 nov. 2012 23:38 schreef "Woonsan Ko" <[hidden email]> het volgende:
>
> Hi,
>
> I can let parameters inherited from sitemapitem to component configuration, but not from a mount even though a mount can have hst:parameternames and hst:parametervalues.

Well I am not sure the above is 100% correct. Let me explain to avoid
confusion:

1) Component configurations that reference another one get the
parameter names and values that it does not have itself already
inherited from the hst component it inherits. (it also inherits all
other properties that it did not define itself)
2) Next to inheritance, there is also when all inheritance is
resolved, a parameter push down from ancestor to descendant
components: Thus ancestors add to descendant parameter names that the
descendants do not have *and* override them. I regret I made this
choice like 4 to 5 years ago. It doesn't play well with the
drag-droppable hst containercomponentitems : Hence, also for this
specific type, the pushing down of parameters is not done for
hst:containercomponentitem. I am sorry about the confusion, at the
time the pushing down seemed like a nice plan :)
3) Hst component parameter values can have explicit values, like
"foo", "bar", "10" but also i can contain property placeholders, for
example "${1}" (first matched sitemap item wildcard for current
request), or "${2}". However, a property placeholder like ${name} or
${year} is also supported : This does a look up in the matched sitemap
item, whether that one contains a hst:parameter name 'name' or 'year',
and substitutes ${name} or ${year} with the parameter value of the
sitemap item. The parameter value of the sitemap item can of course
also contain ${1} kind of place holders

So, if the above is what you mean with sitemap item parameter
inheritance, then you are correct, but I don't think it is real
inheritance...obviously I do not have a better name for it though :)

> Is it a bug or something to improve?

I am not sure about your use case. It is not a bug as that is was
unintentional behavior. I personally see no added value in having hst
components 'inherit' from mounts. What does this mean? Obviously, as
explained above, also sitemap items parameters are not really
inherited : You can just reference them from a hst component. Where
there might be a thin use case for sitemap items because you can refer
to property placeholders, this use case completely vanishes for mounts
as we do not support wildcards for mount.

If you want to use some mount parameter in your hst component you have
now two options:

1) Fetch the properties directly from the Mount object (is it
getProperty(String name) from the top of my head?)
2) Use channel manager properties, see [1]

The channel properties can be edited in the channel manager template
composer mode, the mount properties can't

Hope this helps explain why I don't consider it a bug. Also not sure
about your use case, perhaps you have some use case that cannot be met
with getPropery or channel properties

Regards Ard

[1] http://www.onehippo.org/7_7/library/concepts/channels/additional-channel-information.html

>
> Regards,
>
> Woonsan
>
>
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/forums.html
_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/forums.html
Reply | Threaded
Open this post in threaded view
|

Re: Hst parameter definition/inheritance from mount

Woonsan Ko-3

Thank you very much for the descriptive answers.
I understand all your points and I think I meant param referencing, not inheritance.
Anyway my usecase is to configure a param in a mount and use it in relativecontentpath in a sitemapitem configuration. Then I can share almost redundant sitemaps for multiple mounts.

Regards,

Woonsan
(Sent from my mobile phone. Apologies for any typos.)

On Dec 2, 2012 5:01 AM, "Ard Schrijvers" <[hidden email]> wrote:
Op 30 nov. 2012 23:38 schreef "Woonsan Ko" <[hidden email]> het volgende:
>
> Hi,
>
> I can let parameters inherited from sitemapitem to component configuration, but not from a mount even though a mount can have hst:parameternames and hst:parametervalues.

Well I am not sure the above is 100% correct. Let me explain to avoid
confusion:

1) Component configurations that reference another one get the
parameter names and values that it does not have itself already
inherited from the hst component it inherits. (it also inherits all
other properties that it did not define itself)
2) Next to inheritance, there is also when all inheritance is
resolved, a parameter push down from ancestor to descendant
components: Thus ancestors add to descendant parameter names that the
descendants do not have *and* override them. I regret I made this
choice like 4 to 5 years ago. It doesn't play well with the
drag-droppable hst containercomponentitems : Hence, also for this
specific type, the pushing down of parameters is not done for
hst:containercomponentitem. I am sorry about the confusion, at the
time the pushing down seemed like a nice plan :)
3) Hst component parameter values can have explicit values, like
"foo", "bar", "10" but also i can contain property placeholders, for
example "${1}" (first matched sitemap item wildcard for current
request), or "${2}". However, a property placeholder like ${name} or
${year} is also supported : This does a look up in the matched sitemap
item, whether that one contains a hst:parameter name 'name' or 'year',
and substitutes ${name} or ${year} with the parameter value of the
sitemap item. The parameter value of the sitemap item can of course
also contain ${1} kind of place holders

So, if the above is what you mean with sitemap item parameter
inheritance, then you are correct, but I don't think it is real
inheritance...obviously I do not have a better name for it though :)

> Is it a bug or something to improve?

I am not sure about your use case. It is not a bug as that is was
unintentional behavior. I personally see no added value in having hst
components 'inherit' from mounts. What does this mean? Obviously, as
explained above, also sitemap items parameters are not really
inherited : You can just reference them from a hst component. Where
there might be a thin use case for sitemap items because you can refer
to property placeholders, this use case completely vanishes for mounts
as we do not support wildcards for mount.

If you want to use some mount parameter in your hst component you have
now two options:

1) Fetch the properties directly from the Mount object (is it
getProperty(String name) from the top of my head?)
2) Use channel manager properties, see [1]

The channel properties can be edited in the channel manager template
composer mode, the mount properties can't

Hope this helps explain why I don't consider it a bug. Also not sure
about your use case, perhaps you have some use case that cannot be met
with getPropery or channel properties

Regards Ard

[1] http://www.onehippo.org/7_7/library/concepts/channels/additional-channel-information.html

>
> Regards,
>
> Woonsan
>
>
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/forums.html
_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/forums.html

_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/forums.html
Ard
Reply | Threaded
Open this post in threaded view
|

Re: Hst parameter definition/inheritance from mount

Ard
On Mon, Dec 3, 2012 at 1:40 PM, Woonsan Ko <[hidden email]> wrote:
> Thank you very much for the descriptive answers.
> I understand all your points and I think I meant param referencing, not
> inheritance.
> Anyway my usecase is to configure a param in a mount and use it in
> relativecontentpath in a sitemapitem configuration. Then I can share almost
> redundant sitemaps for multiple mounts.

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'

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

Regards Ard

>
> Regards,
>
> Woonsan
> (Sent from my mobile phone. Apologies for any typos.)
>
> On Dec 2, 2012 5:01 AM, "Ard Schrijvers" <[hidden email]> wrote:
>>
>> Op 30 nov. 2012 23:38 schreef "Woonsan Ko" <[hidden email]> het
>> volgende:
>> >
>> > Hi,
>> >
>> > I can let parameters inherited from sitemapitem to component
>> > configuration, but not from a mount even though a mount can have
>> > hst:parameternames and hst:parametervalues.
>>
>> Well I am not sure the above is 100% correct. Let me explain to avoid
>> confusion:
>>
>> 1) Component configurations that reference another one get the
>> parameter names and values that it does not have itself already
>> inherited from the hst component it inherits. (it also inherits all
>> other properties that it did not define itself)
>> 2) Next to inheritance, there is also when all inheritance is
>> resolved, a parameter push down from ancestor to descendant
>> components: Thus ancestors add to descendant parameter names that the
>> descendants do not have *and* override them. I regret I made this
>> choice like 4 to 5 years ago. It doesn't play well with the
>> drag-droppable hst containercomponentitems : Hence, also for this
>> specific type, the pushing down of parameters is not done for
>> hst:containercomponentitem. I am sorry about the confusion, at the
>> time the pushing down seemed like a nice plan :)
>> 3) Hst component parameter values can have explicit values, like
>> "foo", "bar", "10" but also i can contain property placeholders, for
>> example "${1}" (first matched sitemap item wildcard for current
>> request), or "${2}". However, a property placeholder like ${name} or
>> ${year} is also supported : This does a look up in the matched sitemap
>> item, whether that one contains a hst:parameter name 'name' or 'year',
>> and substitutes ${name} or ${year} with the parameter value of the
>> sitemap item. The parameter value of the sitemap item can of course
>> also contain ${1} kind of place holders
>>
>> So, if the above is what you mean with sitemap item parameter
>> inheritance, then you are correct, but I don't think it is real
>> inheritance...obviously I do not have a better name for it though :)
>>
>> > Is it a bug or something to improve?
>>
>> I am not sure about your use case. It is not a bug as that is was
>> unintentional behavior. I personally see no added value in having hst
>> components 'inherit' from mounts. What does this mean? Obviously, as
>> explained above, also sitemap items parameters are not really
>> inherited : You can just reference them from a hst component. Where
>> there might be a thin use case for sitemap items because you can refer
>> to property placeholders, this use case completely vanishes for mounts
>> as we do not support wildcards for mount.
>>
>> If you want to use some mount parameter in your hst component you have
>> now two options:
>>
>> 1) Fetch the properties directly from the Mount object (is it
>> getProperty(String name) from the top of my head?)
>> 2) Use channel manager properties, see [1]
>>
>> The channel properties can be edited in the channel manager template
>> composer mode, the mount properties can't
>>
>> Hope this helps explain why I don't consider it a bug. Also not sure
>> about your use case, perhaps you have some use case that cannot be met
>> with getPropery or channel properties
>>
>> Regards Ard
>>
>> [1]
>> http://www.onehippo.org/7_7/library/concepts/channels/additional-channel-information.html
>>
>> >
>> > Regards,
>> >
>> > Woonsan
>> >
>> >
>> > _______________________________________________
>> > Hippo-cms7-user mailing list and forums
>> > http://www.onehippo.org/cms7/support/forums.html
>> _______________________________________________
>> Hippo-cms7-user mailing list and forums
>> http://www.onehippo.org/cms7/support/forums.html
>
>
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/forums.html



--
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
Boston - 1 Broadway, Cambridge, MA 02142

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com
_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/forums.html
Reply | Threaded
Open this post in threaded view
|

Re: Hst parameter definition/inheritance from mount

Woonsan Ko-3
On 12/6/12 2:58 AM, Ard Schrijvers wrote:

> On Mon, Dec 3, 2012 at 1:40 PM, Woonsan Ko <[hidden email]> wrote:
>> Thank you very much for the descriptive answers.
>> I understand all your points and I think I meant param referencing, not
>> inheritance.
>> Anyway my usecase is to configure a param in a mount and use it in
>> relativecontentpath in a sitemapitem configuration. Then I can share almost
>> redundant sitemaps for multiple mounts.
>
> 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].

>
> 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}

when a mount has hst:parameter[names|values] for 'region'.

Thank you so much again!

Cheers,

Woonsan

>
> Regards Ard
>
>>
>> Regards,
>>
>> Woonsan
>> (Sent from my mobile phone. Apologies for any typos.)
>>
>> On Dec 2, 2012 5:01 AM, "Ard Schrijvers" <[hidden email]> wrote:
>>>
>>> Op 30 nov. 2012 23:38 schreef "Woonsan Ko" <[hidden email]> het
>>> volgende:
>>>>
>>>> Hi,
>>>>
>>>> I can let parameters inherited from sitemapitem to component
>>>> configuration, but not from a mount even though a mount can have
>>>> hst:parameternames and hst:parametervalues.
>>>
>>> Well I am not sure the above is 100% correct. Let me explain to avoid
>>> confusion:
>>>
>>> 1) Component configurations that reference another one get the
>>> parameter names and values that it does not have itself already
>>> inherited from the hst component it inherits. (it also inherits all
>>> other properties that it did not define itself)
>>> 2) Next to inheritance, there is also when all inheritance is
>>> resolved, a parameter push down from ancestor to descendant
>>> components: Thus ancestors add to descendant parameter names that the
>>> descendants do not have *and* override them. I regret I made this
>>> choice like 4 to 5 years ago. It doesn't play well with the
>>> drag-droppable hst containercomponentitems : Hence, also for this
>>> specific type, the pushing down of parameters is not done for
>>> hst:containercomponentitem. I am sorry about the confusion, at the
>>> time the pushing down seemed like a nice plan :)
>>> 3) Hst component parameter values can have explicit values, like
>>> "foo", "bar", "10" but also i can contain property placeholders, for
>>> example "${1}" (first matched sitemap item wildcard for current
>>> request), or "${2}". However, a property placeholder like ${name} or
>>> ${year} is also supported : This does a look up in the matched sitemap
>>> item, whether that one contains a hst:parameter name 'name' or 'year',
>>> and substitutes ${name} or ${year} with the parameter value of the
>>> sitemap item. The parameter value of the sitemap item can of course
>>> also contain ${1} kind of place holders
>>>
>>> So, if the above is what you mean with sitemap item parameter
>>> inheritance, then you are correct, but I don't think it is real
>>> inheritance...obviously I do not have a better name for it though :)
>>>
>>>> Is it a bug or something to improve?
>>>
>>> I am not sure about your use case. It is not a bug as that is was
>>> unintentional behavior. I personally see no added value in having hst
>>> components 'inherit' from mounts. What does this mean? Obviously, as
>>> explained above, also sitemap items parameters are not really
>>> inherited : You can just reference them from a hst component. Where
>>> there might be a thin use case for sitemap items because you can refer
>>> to property placeholders, this use case completely vanishes for mounts
>>> as we do not support wildcards for mount.
>>>
>>> If you want to use some mount parameter in your hst component you have
>>> now two options:
>>>
>>> 1) Fetch the properties directly from the Mount object (is it
>>> getProperty(String name) from the top of my head?)
>>> 2) Use channel manager properties, see [1]
>>>
>>> The channel properties can be edited in the channel manager template
>>> composer mode, the mount properties can't
>>>
>>> Hope this helps explain why I don't consider it a bug. Also not sure
>>> about your use case, perhaps you have some use case that cannot be met
>>> with getPropery or channel properties
>>>
>>> Regards Ard
>>>
>>> [1]
>>> http://www.onehippo.org/7_7/library/concepts/channels/additional-channel-information.html
>>>
>>>>
>>>> Regards,
>>>>
>>>> Woonsan
>>>>
>>>>
>>>> _______________________________________________
>>>> Hippo-cms7-user mailing list and forums
>>>> http://www.onehippo.org/cms7/support/forums.html
>>> _______________________________________________
>>> Hippo-cms7-user mailing list and forums
>>> http://www.onehippo.org/cms7/support/forums.html
>>
>>
>> _______________________________________________
>> Hippo-cms7-user mailing list and forums
>> http://www.onehippo.org/cms7/support/forums.html
>
>
>


--
[hidden email]     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
_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/forums.html
Ard
Reply | Threaded
Open this post in threaded view
|

Re: Hst parameter definition/inheritance from mount

Ard
On Thu, Dec 6, 2012 at 2:32 PM, Woonsan Ko <[hidden email]> wrote:

> On 12/6/12 2:58 AM, Ard Schrijvers wrote:
>>
>> On Mon, Dec 3, 2012 at 1:40 PM, Woonsan Ko <[hidden email]> wrote:
>>>
>>> Thank you very much for the descriptive answers.
>>> I understand all your points and I think I meant param referencing, not
>>> inheritance.
>>> Anyway my usecase is to configure a param in a mount and use it in
>>> relativecontentpath in a sitemapitem configuration. Then I can share
>>> almost
>>> redundant sitemaps for multiple mounts.
>>
>>
>> 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

>
> 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.

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

Regards Ard

>
> Cheers,
>
> Woonsan
>
>
>>
>> Regards Ard
>>
>>>
>>> Regards,
>>>
>>> Woonsan
>>> (Sent from my mobile phone. Apologies for any typos.)
>>>
>>> On Dec 2, 2012 5:01 AM, "Ard Schrijvers" <[hidden email]>
>>> wrote:
>>>>
>>>>
>>>> Op 30 nov. 2012 23:38 schreef "Woonsan Ko" <[hidden email]> het
>>>> volgende:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I can let parameters inherited from sitemapitem to component
>>>>> configuration, but not from a mount even though a mount can have
>>>>> hst:parameternames and hst:parametervalues.
>>>>
>>>>
>>>> Well I am not sure the above is 100% correct. Let me explain to avoid
>>>> confusion:
>>>>
>>>> 1) Component configurations that reference another one get the
>>>> parameter names and values that it does not have itself already
>>>> inherited from the hst component it inherits. (it also inherits all
>>>> other properties that it did not define itself)
>>>> 2) Next to inheritance, there is also when all inheritance is
>>>> resolved, a parameter push down from ancestor to descendant
>>>> components: Thus ancestors add to descendant parameter names that the
>>>> descendants do not have *and* override them. I regret I made this
>>>> choice like 4 to 5 years ago. It doesn't play well with the
>>>> drag-droppable hst containercomponentitems : Hence, also for this
>>>> specific type, the pushing down of parameters is not done for
>>>> hst:containercomponentitem. I am sorry about the confusion, at the
>>>> time the pushing down seemed like a nice plan :)
>>>> 3) Hst component parameter values can have explicit values, like
>>>> "foo", "bar", "10" but also i can contain property placeholders, for
>>>> example "${1}" (first matched sitemap item wildcard for current
>>>> request), or "${2}". However, a property placeholder like ${name} or
>>>> ${year} is also supported : This does a look up in the matched sitemap
>>>> item, whether that one contains a hst:parameter name 'name' or 'year',
>>>> and substitutes ${name} or ${year} with the parameter value of the
>>>> sitemap item. The parameter value of the sitemap item can of course
>>>> also contain ${1} kind of place holders
>>>>
>>>> So, if the above is what you mean with sitemap item parameter
>>>> inheritance, then you are correct, but I don't think it is real
>>>> inheritance...obviously I do not have a better name for it though :)
>>>>
>>>>> Is it a bug or something to improve?
>>>>
>>>>
>>>> I am not sure about your use case. It is not a bug as that is was
>>>> unintentional behavior. I personally see no added value in having hst
>>>> components 'inherit' from mounts. What does this mean? Obviously, as
>>>> explained above, also sitemap items parameters are not really
>>>> inherited : You can just reference them from a hst component. Where
>>>> there might be a thin use case for sitemap items because you can refer
>>>> to property placeholders, this use case completely vanishes for mounts
>>>> as we do not support wildcards for mount.
>>>>
>>>> If you want to use some mount parameter in your hst component you have
>>>> now two options:
>>>>
>>>> 1) Fetch the properties directly from the Mount object (is it
>>>> getProperty(String name) from the top of my head?)
>>>> 2) Use channel manager properties, see [1]
>>>>
>>>> The channel properties can be edited in the channel manager template
>>>> composer mode, the mount properties can't
>>>>
>>>> Hope this helps explain why I don't consider it a bug. Also not sure
>>>> about your use case, perhaps you have some use case that cannot be met
>>>> with getPropery or channel properties
>>>>
>>>> Regards Ard
>>>>
>>>> [1]
>>>>
>>>> http://www.onehippo.org/7_7/library/concepts/channels/additional-channel-information.html
>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Woonsan
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Hippo-cms7-user mailing list and forums
>>>>> http://www.onehippo.org/cms7/support/forums.html
>>>>
>>>> _______________________________________________
>>>> Hippo-cms7-user mailing list and forums
>>>> http://www.onehippo.org/cms7/support/forums.html
>>>
>>>
>>>
>>> _______________________________________________
>>> Hippo-cms7-user mailing list and forums
>>> http://www.onehippo.org/cms7/support/forums.html
>>
>>
>>
>>
>
>
> --
> [hidden email]     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
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/forums.html



--
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
Boston - 1 Broadway, Cambridge, MA 02142

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com
_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/forums.html
Reply | Threaded
Open this post in threaded view
|

Re: Hst parameter definition/inheritance from mount

Woonsan Ko-3
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
>


--
[hidden email]     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
_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/forums.html
Ard
Reply | Threaded
Open this post in threaded view
|

Re: Hst parameter definition/inheritance from mount

Ard
On Thu, Dec 6, 2012 at 3:30 PM, Woonsan Ko <[hidden email]> wrote:

> 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

Thanks for creating the issue. Do you need it urgently / in the 7.8?

Regards Ard

>
> Thank you so much!
>
> Cheers,
>
> Woonsan
>
>>
>> Regards Ard
>>
>
>
> --
> [hidden email]     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
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/forums.html



--
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
Boston - 1 Broadway, Cambridge, MA 02142

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com
_______________________________________________
Hippo-cms7-user mailing list and forums
http://www.onehippo.org/cms7/support/forums.html
Reply | Threaded
Open this post in threaded view
|

Re: Hst parameter definition/inheritance from mount

jan.groot
This post has NOT been accepted by the mailing list yet.
We want this too, as we then can reuse the sitemap.
So +1

rgds,

JG