A page driven design with Hippo

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

A page driven design with Hippo

Minos Chatzidakis-2
Hello to all,

We are trying to simulate a page driven design with Hippo. The site makes heavy use of the template composer, for editing and managing the templates.
To overcome the fact that the composer edits templates, we have a template per page (or a page per template), anyway it's a 1 to 1 relationship. This partly (but sufficiently) simulates a page driven design. Not all pages are templates (we reuse whenever possible).

Ok so let's talk about the homepage. Editors open channel manager and start editing the page (template), that is changing the settings of the dropped components. For a component like a 'highlights section', those settings are the paths to the documents that we want to show in that area. This entails that editors will more likely edit this template very often, like say every day. As usual, when the editor is happy with the changes he did, he presses 'publish templates'.
  • What happens if 2 editors have the channel manager open? More precisely what will happen if one of the editors is happy with his changes, so he publishes, but the the 2nd editor is halfway done? I guess his half completed changes are suddenly published. Right?
  • Is the channel manager supposed to be used simultaneously by many users? Are there warnings like in cms (like 'This document is being edited by another user' ) ?
How about the following as a possible solution:
We create a document type that holds all the parameters of a droppable component. Then we feed that document to the hst component, instead of passing the parameters individually. The component must retrieve it's settings from that document, instead of the ParametersInfo. This way:
  • There are no conflicts with publishing of the template
  • Editors can preview, publish component configuration, schedule publication
  • It supports multiuser editing
Personally I don't like that editors will manage the site via documents instead via the channel manager. But I can't find a workaround for the aforementioned problems.

Please share your thoughts!

Minos





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

Re: A page driven design with Hippo

ec@hippo
Hi Minos,

I'm a noob so please bare the probable inaccuracy: editing a document could change its workflow state to "locked for editing" (by: username stored in a property) so that no other editors (there should be a "lock breaker role")  can change the document?


Edoardo


Thu, Jun 21, 2012 at 3:49 PM, Minos Chatzidakis <[hidden email]> wrote:
Hello to all,

We are trying to simulate a page driven design with Hippo. The site makes heavy use of the template composer, for editing and managing the templates.
To overcome the fact that the composer edits templates, we have a template per page (or a page per template), anyway it's a 1 to 1 relationship. This partly (but sufficiently) simulates a page driven design. Not all pages are templates (we reuse whenever possible).

Ok so let's talk about the homepage. Editors open channel manager and start editing the page (template), that is changing the settings of the dropped components. For a component like a 'highlights section', those settings are the paths to the documents that we want to show in that area. This entails that editors will more likely edit this template very often, like say every day. As usual, when the editor is happy with the changes he did, he presses 'publish templates'.
  • What happens if 2 editors have the channel manager open? More precisely what will happen if one of the editors is happy with his changes, so he publishes, but the the 2nd editor is halfway done? I guess his half completed changes are suddenly published. Right?
  • Is the channel manager supposed to be used simultaneously by many users? Are there warnings like in cms (like 'This document is being edited by another user' ) ?
How about the following as a possible solution:
We create a document type that holds all the parameters of a droppable component. Then we feed that document to the hst component, instead of passing the parameters individually. The component must retrieve it's settings from that document, instead of the ParametersInfo. This way:
  • There are no conflicts with publishing of the template
  • Editors can preview, publish component configuration, schedule publication
  • It supports multiuser editing
Personally I don't like that editors will manage the site via documents instead via the channel manager. But I can't find a workaround for the aforementioned problems.

Please share your thoughts!

Minos





_______________________________________________
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
http://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: A page driven design with Hippo

Minos Chatzidakis-2
Yes, and that's a feature that we'll take advantage of. But when a user goes to tc, he'll actually see that the templates are being edited cause he'll have the option to publish them, though he never pressed 'Edit templates'. This can be so confusing for an editor!

Thanks


On Fri, Jun 22, 2012 at 10:43 AM, Edoardo Causarano <[hidden email]> wrote:
Hi Minos,

I'm a noob so please bare the probable inaccuracy: editing a document could change its workflow state to "locked for editing" (by: username stored in a property) so that no other editors (there should be a "lock breaker role")  can change the document?


Edoardo


Thu, Jun 21, 2012 at 3:49 PM, Minos Chatzidakis <[hidden email]> wrote:
Hello to all,

We are trying to simulate a page driven design with Hippo. The site makes heavy use of the template composer, for editing and managing the templates.
To overcome the fact that the composer edits templates, we have a template per page (or a page per template), anyway it's a 1 to 1 relationship. This partly (but sufficiently) simulates a page driven design. Not all pages are templates (we reuse whenever possible).

Ok so let's talk about the homepage. Editors open channel manager and start editing the page (template), that is changing the settings of the dropped components. For a component like a 'highlights section', those settings are the paths to the documents that we want to show in that area. This entails that editors will more likely edit this template very often, like say every day. As usual, when the editor is happy with the changes he did, he presses 'publish templates'.
  • What happens if 2 editors have the channel manager open? More precisely what will happen if one of the editors is happy with his changes, so he publishes, but the the 2nd editor is halfway done? I guess his half completed changes are suddenly published. Right?
  • Is the channel manager supposed to be used simultaneously by many users? Are there warnings like in cms (like 'This document is being edited by another user' ) ?
How about the following as a possible solution:
We create a document type that holds all the parameters of a droppable component. Then we feed that document to the hst component, instead of passing the parameters individually. The component must retrieve it's settings from that document, instead of the ParametersInfo. This way:
  • There are no conflicts with publishing of the template
  • Editors can preview, publish component configuration, schedule publication
  • It supports multiuser editing
Personally I don't like that editors will manage the site via documents instead via the channel manager. But I can't find a workaround for the aforementioned problems.

Please share your thoughts!

Minos





_______________________________________________
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 <a href="tel:%2B1%20877%20414%204776" value="+18774144776" target="_blank">+1 877 414 4776 (toll free)
Europe <a href="tel:%2B31%280%2920%20522%204466" value="+31205224466" target="_blank">+31(0)20 522 4466
http://www.onehippo.com/

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



--
With kind regards/Met vriendelijke groet,
Minos Chatzidakis

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: A page driven design with Hippo

ec@hippo
Hi Minos,

how about making the publish workflow transition only available to the lock owner? (and the - unlock, unlock & discard changes transitions only available to the users with a "lock breaker" role?) 


Best,
Edoardo

On Fri, Jun 22, 2012 at 10:58 AM, Minos Chatzidakis <[hidden email]> wrote:
Yes, and that's a feature that we'll take advantage of. But when a user goes to tc, he'll actually see that the templates are being edited cause he'll have the option to publish them, though he never pressed 'Edit templates'. This can be so confusing for an editor!

Thanks


On Fri, Jun 22, 2012 at 10:43 AM, Edoardo Causarano <[hidden email]> wrote:
Hi Minos,

I'm a noob so please bare the probable inaccuracy: editing a document could change its workflow state to "locked for editing" (by: username stored in a property) so that no other editors (there should be a "lock breaker role")  can change the document?


Edoardo


Thu, Jun 21, 2012 at 3:49 PM, Minos Chatzidakis <[hidden email]> wrote:
Hello to all,

We are trying to simulate a page driven design with Hippo. The site makes heavy use of the template composer, for editing and managing the templates.
To overcome the fact that the composer edits templates, we have a template per page (or a page per template), anyway it's a 1 to 1 relationship. This partly (but sufficiently) simulates a page driven design. Not all pages are templates (we reuse whenever possible).

Ok so let's talk about the homepage. Editors open channel manager and start editing the page (template), that is changing the settings of the dropped components. For a component like a 'highlights section', those settings are the paths to the documents that we want to show in that area. This entails that editors will more likely edit this template very often, like say every day. As usual, when the editor is happy with the changes he did, he presses 'publish templates'.
  • What happens if 2 editors have the channel manager open? More precisely what will happen if one of the editors is happy with his changes, so he publishes, but the the 2nd editor is halfway done? I guess his half completed changes are suddenly published. Right?
  • Is the channel manager supposed to be used simultaneously by many users? Are there warnings like in cms (like 'This document is being edited by another user' ) ?
How about the following as a possible solution:
We create a document type that holds all the parameters of a droppable component. Then we feed that document to the hst component, instead of passing the parameters individually. The component must retrieve it's settings from that document, instead of the ParametersInfo. This way:
  • There are no conflicts with publishing of the template
  • Editors can preview, publish component configuration, schedule publication
  • It supports multiuser editing
Personally I don't like that editors will manage the site via documents instead via the channel manager. But I can't find a workaround for the aforementioned problems.

Please share your thoughts!

Minos





_______________________________________________
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 <a href="tel:%2B1%20877%20414%204776" value="+18774144776" target="_blank">+1 877 414 4776 (toll free)
Europe <a href="tel:%2B31%280%2920%20522%204466" value="+31205224466" target="_blank">+31(0)20 522 4466
http://www.onehippo.com/

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



--
With kind regards/Met vriendelijke groet,
Minos Chatzidakis

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



--
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
http://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: A page driven design with Hippo

Minos Chatzidakis-2
Yes that could work as a safety net.
But then all editors need to be able to specify for example the items shown in the homepage.
And they don't have a 'content supervisor' role, that would visit the preview, make sure everything looks good and then decide to publish.

Maybe they should actually...



On Fri, Jun 22, 2012 at 11:17 AM, Edoardo Causarano <[hidden email]> wrote:
Hi Minos,

how about making the publish workflow transition only available to the lock owner? (and the - unlock, unlock & discard changes transitions only available to the users with a "lock breaker" role?) 


Best,
Edoardo


On Fri, Jun 22, 2012 at 10:58 AM, Minos Chatzidakis <[hidden email]> wrote:
Yes, and that's a feature that we'll take advantage of. But when a user goes to tc, he'll actually see that the templates are being edited cause he'll have the option to publish them, though he never pressed 'Edit templates'. This can be so confusing for an editor!

Thanks


On Fri, Jun 22, 2012 at 10:43 AM, Edoardo Causarano <[hidden email]> wrote:
Hi Minos,

I'm a noob so please bare the probable inaccuracy: editing a document could change its workflow state to "locked for editing" (by: username stored in a property) so that no other editors (there should be a "lock breaker role")  can change the document?


Edoardo


Thu, Jun 21, 2012 at 3:49 PM, Minos Chatzidakis <[hidden email]> wrote:
Hello to all,

We are trying to simulate a page driven design with Hippo. The site makes heavy use of the template composer, for editing and managing the templates.
To overcome the fact that the composer edits templates, we have a template per page (or a page per template), anyway it's a 1 to 1 relationship. This partly (but sufficiently) simulates a page driven design. Not all pages are templates (we reuse whenever possible).

Ok so let's talk about the homepage. Editors open channel manager and start editing the page (template), that is changing the settings of the dropped components. For a component like a 'highlights section', those settings are the paths to the documents that we want to show in that area. This entails that editors will more likely edit this template very often, like say every day. As usual, when the editor is happy with the changes he did, he presses 'publish templates'.
  • What happens if 2 editors have the channel manager open? More precisely what will happen if one of the editors is happy with his changes, so he publishes, but the the 2nd editor is halfway done? I guess his half completed changes are suddenly published. Right?
  • Is the channel manager supposed to be used simultaneously by many users? Are there warnings like in cms (like 'This document is being edited by another user' ) ?
How about the following as a possible solution:
We create a document type that holds all the parameters of a droppable component. Then we feed that document to the hst component, instead of passing the parameters individually. The component must retrieve it's settings from that document, instead of the ParametersInfo. This way:
  • There are no conflicts with publishing of the template
  • Editors can preview, publish component configuration, schedule publication
  • It supports multiuser editing
Personally I don't like that editors will manage the site via documents instead via the channel manager. But I can't find a workaround for the aforementioned problems.

Please share your thoughts!

Minos





_______________________________________________
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 <a href="tel:%2B1%20877%20414%204776" value="+18774144776" target="_blank">+1 877 414 4776 (toll free)
Europe <a href="tel:%2B31%280%2920%20522%204466" value="+31205224466" target="_blank">+31(0)20 522 4466
http://www.onehippo.com/

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



--
With kind regards/Met vriendelijke groet,
Minos Chatzidakis

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



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

US <a href="tel:%2B1%20877%20414%204776" value="+18774144776" target="_blank">+1 877 414 4776 (toll free)
Europe <a href="tel:%2B31%280%2920%20522%204466" value="+31205224466" target="_blank">+31(0)20 522 4466
http://www.onehippo.com/

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



--
With kind regards/Met vriendelijke groet,
Minos Chatzidakis

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: A page driven design with Hippo

Jeroen Hoffman
In reply to this post by Minos Chatzidakis-2


On 21-06-12 15:49, Minos Chatzidakis wrote:

> Hello to all,
>
> We are trying to simulate a page driven design with Hippo. The site makes heavy
> use of the template composer, for editing and managing the templates.
> To overcome the fact that the composer edits templates, we have a template per
> page (or a page per template), anyway it's a 1 to 1 relationship. This partly
> (but sufficiently) simulates a page driven design. Not all pages are templates
> (we reuse whenever possible).
>
> Ok so let's talk about the homepage. Editors open channel manager and start
> editing the page (template), that is changing the settings of the dropped
> components. For a component like a 'highlights section', those settings are the
> paths to the documents that we want to show in that area. This entails that
> editors will more likely edit this template very often, like say every day. As
> usual, when the editor is happy with the changes he did, he presses 'publish
> templates'.
>
>     * /What happens if 2 editors have the channel manager open? More precisely
>       what will happen if one of the editors is happy with his changes, so he
>       publishes, but the the 2nd editor is halfway done? I guess his half
>       completed changes are suddenly published. Right?/
>     * /Is the channel manager supposed to be used simultaneously by many users?
>       Are there warnings like in cms (like 'This document is being edited by
>       another user' ) ?/
>
> How about the following as a possible solution:
> We create a document type that holds all the parameters of a droppable
> component. Then we feed that document to the hst component, instead of passing
> the parameters individually. The component must retrieve it's settings from that
> document, instead of the ParametersInfo. This way:
>
>     * There are no conflicts with publishing of the template
>     * Editors can preview, *publish component configuration*, *schedule publication*
>     * It supports *multiuser editing*
>
> Personally I don't like that editors will manage the site via documents instead
> via the channel manager. But I can't find a workaround for the aforementioned
> problems.
>
> Please share your thoughts!
>

The template composer is about placing components on page templates, right? So
not necessarily about the contents of the components.

In that view a component backed by a component document somewhere is not such a
bad idea. In fact that's how we work quite a lot, the only thing the TC adds is
that placing and configuring the components is easier.


My 2 cts
Jeroen







_______________________________________________
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: A page driven design with Hippo

Ard
In reply to this post by Minos Chatzidakis-2
The strength of Hippo has always been separation of content and
presentation. That is what the imo much more limited page driven
CMS'es are for. But a page driven CMS needs to separately maintain
their mobile, tabblet, website, facebook. REST, etc versions, that is
why imo they focus on the wrong part.

Now, trying to mimic a page driven cms by mis-using the template
composer (it is called a template composer, not a page composer) will
be like trying use free text search from a sql database: Thus, using
the tool in a way it was not designed for. Whenever you do that, you
will hit the boundaries very quickly, and then will end up with a non
performing crippled set up

Ard

On Fri, Jun 22, 2012 at 11:30 AM, Minos Chatzidakis
<[hidden email]> wrote:

> Yes that could work as a safety net.
> But then all editors need to be able to specify for example the items shown
> in the homepage.
> And they don't have a 'content supervisor' role, that would visit the
> preview, make sure everything looks good and then decide to publish.
>
> Maybe they should actually...
>
>
>
> On Fri, Jun 22, 2012 at 11:17 AM, Edoardo Causarano
> <[hidden email]> wrote:
>>
>> Hi Minos,
>>
>> how about making the publish workflow transition only available to the
>> lock owner? (and the - unlock, unlock & discard changes transitions only
>> available to the users with a "lock breaker" role?)
>>
>>
>> Best,
>> Edoardo
>>
>>
>> On Fri, Jun 22, 2012 at 10:58 AM, Minos Chatzidakis
>> <[hidden email]> wrote:
>>>
>>> Yes, and that's a feature that we'll take advantage of. But when a user
>>> goes to tc, he'll actually see that the templates are being edited cause
>>> he'll have the option to publish them, though he never pressed 'Edit
>>> templates'. This can be so confusing for an editor!
>>>
>>> Thanks
>>>
>>>
>>> On Fri, Jun 22, 2012 at 10:43 AM, Edoardo Causarano
>>> <[hidden email]> wrote:
>>>>
>>>> Hi Minos,
>>>>
>>>> I'm a noob so please bare the probable inaccuracy: editing a document
>>>> could change its workflow state to "locked for editing" (by: username stored
>>>> in a property) so that no other editors (there should be a "lock breaker
>>>> role")  can change the document?
>>>>
>>>>
>>>> Edoardo
>>>>
>>>>
>>>> Thu, Jun 21, 2012 at 3:49 PM, Minos Chatzidakis
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Hello to all,
>>>>>
>>>>> We are trying to simulate a page driven design with Hippo. The site
>>>>> makes heavy use of the template composer, for editing and managing the
>>>>> templates.
>>>>> To overcome the fact that the composer edits templates, we have a
>>>>> template per page (or a page per template), anyway it's a 1 to 1
>>>>> relationship. This partly (but sufficiently) simulates a page driven design.
>>>>> Not all pages are templates (we reuse whenever possible).
>>>>>
>>>>> Ok so let's talk about the homepage. Editors open channel manager and
>>>>> start editing the page (template), that is changing the settings of the
>>>>> dropped components. For a component like a 'highlights section', those
>>>>> settings are the paths to the documents that we want to show in that area.
>>>>> This entails that editors will more likely edit this template very often,
>>>>> like say every day. As usual, when the editor is happy with the changes he
>>>>> did, he presses 'publish templates'.
>>>>>
>>>>> What happens if 2 editors have the channel manager open? More precisely
>>>>> what will happen if one of the editors is happy with his changes, so he
>>>>> publishes, but the the 2nd editor is halfway done? I guess his half
>>>>> completed changes are suddenly published. Right?
>>>>> Is the channel manager supposed to be used simultaneously by many
>>>>> users? Are there warnings like in cms (like 'This document is being edited
>>>>> by another user' ) ?
>>>>>
>>>>> How about the following as a possible solution:
>>>>> We create a document type that holds all the parameters of a droppable
>>>>> component. Then we feed that document to the hst component, instead of
>>>>> passing the parameters individually. The component must retrieve it's
>>>>> settings from that document, instead of the ParametersInfo. This way:
>>>>>
>>>>> There are no conflicts with publishing of the template
>>>>> Editors can preview, publish component configuration, schedule
>>>>> publication
>>>>> It supports multiuser editing
>>>>>
>>>>> Personally I don't like that editors will manage the site via documents
>>>>> instead via the channel manager. But I can't find a workaround for the
>>>>> aforementioned problems.
>>>>>
>>>>> Please share your thoughts!
>>>>>
>>>>> Minos
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>> http://www.onehippo.com/
>>>>
>>>> _______________________________________________
>>>> Hippo-cms7-user mailing list and forums
>>>> http://www.onehippo.org/cms7/support/forums.html
>>>
>>>
>>>
>>>
>>> --
>>> With kind regards/Met vriendelijke groet,
>>> Minos Chatzidakis
>>>
>>> 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
>>
>>
>>
>>
>> --
>> 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
>> http://www.onehippo.com/
>>
>> _______________________________________________
>> Hippo-cms7-user mailing list and forums
>> http://www.onehippo.org/cms7/support/forums.html
>
>
>
>
> --
> With kind regards/Met vriendelijke groet,
> Minos Chatzidakis
>
> 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



--
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: A page driven design with Hippo

ec@hippo
Hi Minos,

I wonder if you're looking for a way to handle these pages from the template composer:
  • building a template for a one-off page in a site
  • a small collection of similar but still significantly different pages (to the extent that identifying the underlying common template is not worth the work)
It feels similar - broadly speaking - to java anonymous inner classes, so how about introducing "anonymous templates"? These would be templates that are directly coupled to a page instance; furthermore a page copy in the composer is actually a copy of its anonymous template, which can still be promoted to a standard template for general reuse.

These anonymous templates would allow editors to copy & tweak items from the template composer without disrupting its underlying principles.


Best,
Edoardo      

On Fri, Jun 22, 2012 at 11:36 AM, Ard Schrijvers <[hidden email]> wrote:
The strength of Hippo has always been separation of content and
presentation. That is what the imo much more limited page driven
CMS'es are for. But a page driven CMS needs to separately maintain
their mobile, tabblet, website, facebook. REST, etc versions, that is
why imo they focus on the wrong part.

Now, trying to mimic a page driven cms by mis-using the template
composer (it is called a template composer, not a page composer) will
be like trying use free text search from a sql database: Thus, using
the tool in a way it was not designed for. Whenever you do that, you
will hit the boundaries very quickly, and then will end up with a non
performing crippled set up



--
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
http://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: A page driven design with Hippo

Minos Chatzidakis-2
Yes, this is the idea with the hst:page definitions, or hst:page templates.
This can be handy and indeed it helps solve my problem.

But my concern is that this whole thing is perhaps not the way to go.
Hippo cms is a template based cms and this for good reasons. Common sense says that trying to build a page driven impl on a template driven system should be hard and many issues will arise.
Hopefully there are established (?) workarounds and our system can scale enough to support a template per page. At least enough for the current needs.

Thanks





On Fri, Jun 22, 2012 at 1:45 PM, Edoardo Causarano <[hidden email]> wrote:
Hi Minos,

I wonder if you're looking for a way to handle these pages from the template composer:
  • building a template for a one-off page in a site
  • a small collection of similar but still significantly different pages (to the extent that identifying the underlying common template is not worth the work)
It feels similar - broadly speaking - to java anonymous inner classes, so how about introducing "anonymous templates"? These would be templates that are directly coupled to a page instance; furthermore a page copy in the composer is actually a copy of its anonymous template, which can still be promoted to a standard template for general reuse.

These anonymous templates would allow editors to copy & tweak items from the template composer without disrupting its underlying principles.


Best,
Edoardo      

On Fri, Jun 22, 2012 at 11:36 AM, Ard Schrijvers <[hidden email]> wrote:
The strength of Hippo has always been separation of content and
presentation. That is what the imo much more limited page driven
CMS'es are for. But a page driven CMS needs to separately maintain
their mobile, tabblet, website, facebook. REST, etc versions, that is
why imo they focus on the wrong part.

Now, trying to mimic a page driven cms by mis-using the template
composer (it is called a template composer, not a page composer) will
be like trying use free text search from a sql database: Thus, using
the tool in a way it was not designed for. Whenever you do that, you
will hit the boundaries very quickly, and then will end up with a non
performing crippled set up



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

US <a href="tel:%2B1%20877%20414%204776" value="+18774144776" target="_blank">+1 877 414 4776 (toll free)
Europe <a href="tel:%2B31%280%2920%20522%204466" value="+31205224466" target="_blank">+31(0)20 522 4466
http://www.onehippo.com/

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



--
With kind regards/Met vriendelijke groet,
Minos Chatzidakis

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: A page driven design with Hippo

ec@hippo
Hi Minos,

I think the idea is not to subvert the underlying template principle but to let users wander slightly off-course when convenient, while strictly enforcing the principles under the hood ;)

Best,
Edoardo    

On Fri, Jun 22, 2012 at 1:53 PM, Minos Chatzidakis <[hidden email]> wrote:
Yes, this is the idea with the hst:page definitions, or hst:page templates.
This can be handy and indeed it helps solve my problem.

But my concern is that this whole thing is perhaps not the way to go.
Hippo cms is a template based cms and this for good reasons. Common sense says that trying to build a page driven impl on a template driven system should be hard and many issues will arise.
Hopefully there are established (?) workarounds and our system can scale enough to support a template per page. At least enough for the current needs.

Thanks





On Fri, Jun 22, 2012 at 1:45 PM, Edoardo Causarano <[hidden email]> wrote:
Hi Minos,

I wonder if you're looking for a way to handle these pages from the template composer:
  • building a template for a one-off page in a site
  • a small collection of similar but still significantly different pages (to the extent that identifying the underlying common template is not worth the work)
It feels similar - broadly speaking - to java anonymous inner classes, so how about introducing "anonymous templates"? These would be templates that are directly coupled to a page instance; furthermore a page copy in the composer is actually a copy of its anonymous template, which can still be promoted to a standard template for general reuse.

These anonymous templates would allow editors to copy & tweak items from the template composer without disrupting its underlying principles.


Best,
Edoardo      

On Fri, Jun 22, 2012 at 11:36 AM, Ard Schrijvers <[hidden email]> wrote:
The strength of Hippo has always been separation of content and
presentation. That is what the imo much more limited page driven
CMS'es are for. But a page driven CMS needs to separately maintain
their mobile, tabblet, website, facebook. REST, etc versions, that is
why imo they focus on the wrong part.

Now, trying to mimic a page driven cms by mis-using the template
composer (it is called a template composer, not a page composer) will
be like trying use free text search from a sql database: Thus, using
the tool in a way it was not designed for. Whenever you do that, you
will hit the boundaries very quickly, and then will end up with a non
performing crippled set up



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

US <a href="tel:%2B1%20877%20414%204776" value="+18774144776" target="_blank">+1 877 414 4776 (toll free)
Europe <a href="tel:%2B31%280%2920%20522%204466" value="+31205224466" target="_blank">+31(0)20 522 4466
http://www.onehippo.com/

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



--
With kind regards/Met vriendelijke groet,
Minos Chatzidakis

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



--
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
http://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: A page driven design with Hippo

Frank van Lankvelt
In reply to this post by Ard
On Fri, Jun 22, 2012 at 11:36 AM, Ard Schrijvers
<[hidden email]> wrote:
> The strength of Hippo has always been separation of content and
> presentation. That is what the imo much more limited page driven
> CMS'es are for. But a page driven CMS needs to separately maintain
> their mobile, tabblet, website, facebook. REST, etc versions, that is
> why imo they focus on the wrong part.
>
depends on the site imo.  Hippo is particularly suited for sites with
a large amount of content, that should be presented in templates.
We have a superior solution when pages only differ in reusable content
that's shown in different ways on different channels, should be
well-known to minos and others on this list.

But there will be pages on the site for which content is not the main
driver.  The home page is an excellent example.
It shouldn't have to be hard to edit it as a page either.  The
webmaster & editor should decide who is responsible for what.

cheers, Frank

> Now, trying to mimic a page driven cms by mis-using the template
> composer (it is called a template composer, not a page composer) will
> be like trying use free text search from a sql database: Thus, using
> the tool in a way it was not designed for. Whenever you do that, you
> will hit the boundaries very quickly, and then will end up with a non
> performing crippled set up
>
> Ard
>
> On Fri, Jun 22, 2012 at 11:30 AM, Minos Chatzidakis
> <[hidden email]> wrote:
>> Yes that could work as a safety net.
>> But then all editors need to be able to specify for example the items shown
>> in the homepage.
>> And they don't have a 'content supervisor' role, that would visit the
>> preview, make sure everything looks good and then decide to publish.
>>
>> Maybe they should actually...
>>
>>
>>
>> On Fri, Jun 22, 2012 at 11:17 AM, Edoardo Causarano
>> <[hidden email]> wrote:
>>>
>>> Hi Minos,
>>>
>>> how about making the publish workflow transition only available to the
>>> lock owner? (and the - unlock, unlock & discard changes transitions only
>>> available to the users with a "lock breaker" role?)
>>>
>>>
>>> Best,
>>> Edoardo
>>>
>>>
>>> On Fri, Jun 22, 2012 at 10:58 AM, Minos Chatzidakis
>>> <[hidden email]> wrote:
>>>>
>>>> Yes, and that's a feature that we'll take advantage of. But when a user
>>>> goes to tc, he'll actually see that the templates are being edited cause
>>>> he'll have the option to publish them, though he never pressed 'Edit
>>>> templates'. This can be so confusing for an editor!
>>>>
>>>> Thanks
>>>>
>>>>
>>>> On Fri, Jun 22, 2012 at 10:43 AM, Edoardo Causarano
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Hi Minos,
>>>>>
>>>>> I'm a noob so please bare the probable inaccuracy: editing a document
>>>>> could change its workflow state to "locked for editing" (by: username stored
>>>>> in a property) so that no other editors (there should be a "lock breaker
>>>>> role")  can change the document?
>>>>>
>>>>>
>>>>> Edoardo
>>>>>
>>>>>
>>>>> Thu, Jun 21, 2012 at 3:49 PM, Minos Chatzidakis
>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>> Hello to all,
>>>>>>
>>>>>> We are trying to simulate a page driven design with Hippo. The site
>>>>>> makes heavy use of the template composer, for editing and managing the
>>>>>> templates.
>>>>>> To overcome the fact that the composer edits templates, we have a
>>>>>> template per page (or a page per template), anyway it's a 1 to 1
>>>>>> relationship. This partly (but sufficiently) simulates a page driven design.
>>>>>> Not all pages are templates (we reuse whenever possible).
>>>>>>
>>>>>> Ok so let's talk about the homepage. Editors open channel manager and
>>>>>> start editing the page (template), that is changing the settings of the
>>>>>> dropped components. For a component like a 'highlights section', those
>>>>>> settings are the paths to the documents that we want to show in that area.
>>>>>> This entails that editors will more likely edit this template very often,
>>>>>> like say every day. As usual, when the editor is happy with the changes he
>>>>>> did, he presses 'publish templates'.
>>>>>>
>>>>>> What happens if 2 editors have the channel manager open? More precisely
>>>>>> what will happen if one of the editors is happy with his changes, so he
>>>>>> publishes, but the the 2nd editor is halfway done? I guess his half
>>>>>> completed changes are suddenly published. Right?
>>>>>> Is the channel manager supposed to be used simultaneously by many
>>>>>> users? Are there warnings like in cms (like 'This document is being edited
>>>>>> by another user' ) ?
>>>>>>
>>>>>> How about the following as a possible solution:
>>>>>> We create a document type that holds all the parameters of a droppable
>>>>>> component. Then we feed that document to the hst component, instead of
>>>>>> passing the parameters individually. The component must retrieve it's
>>>>>> settings from that document, instead of the ParametersInfo. This way:
>>>>>>
>>>>>> There are no conflicts with publishing of the template
>>>>>> Editors can preview, publish component configuration, schedule
>>>>>> publication
>>>>>> It supports multiuser editing
>>>>>>
>>>>>> Personally I don't like that editors will manage the site via documents
>>>>>> instead via the channel manager. But I can't find a workaround for the
>>>>>> aforementioned problems.
>>>>>>
>>>>>> Please share your thoughts!
>>>>>>
>>>>>> Minos
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>> http://www.onehippo.com/
>>>>>
>>>>> _______________________________________________
>>>>> Hippo-cms7-user mailing list and forums
>>>>> http://www.onehippo.org/cms7/support/forums.html
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> With kind regards/Met vriendelijke groet,
>>>> Minos Chatzidakis
>>>>
>>>> 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
>>>
>>>
>>>
>>>
>>> --
>>> 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
>>> http://www.onehippo.com/
>>>
>>> _______________________________________________
>>> Hippo-cms7-user mailing list and forums
>>> http://www.onehippo.org/cms7/support/forums.html
>>
>>
>>
>>
>> --
>> With kind regards/Met vriendelijke groet,
>> Minos Chatzidakis
>>
>> 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
>
>
>
> --
> 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



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

Removing content using delta XMLs

Laurens Leeuwis
Dear Hippo dev's,

In /hippo:configuration/hippo:frontend/cms/cms-services/htmlCleanerService/cleaner.config/hippohtmlcleaner:cleanup/ there is an hippohtmlcleaner:cleanupElement (the 26th) which allows some attributes for the table element. I would like to change these attributes, from {class, border, cellspacing, cellpadding, width, align, style} to {class, cellspacing, cellpadding, width, align} (without border or style)

I tried this:

<?xml version="1.0" encoding="UTF-8"?>
<sv:node xmlns:sv="http://www.jcp.org/jcr/sv/1.0" sv:name="htmlCleanerService" xmlns:h="http://www.onehippo.org/jcr/xmlimport" h:merge="combine">
    <sv:property sv:name="jcr:primaryType" sv:type="Name">
        <sv:value>frontend:plugin</sv:value>
    </sv:property>
    <sv:node sv:name="cleaner.config" h:merge="combine">
        <sv:property sv:name="jcr:primaryType" sv:type="Name">
            <sv:value>hippohtmlcleaner:config</sv:value>
        </sv:property>
        <sv:node sv:name="hippohtmlcleaner:cleanup" h:merge="combine">
            <sv:property sv:name="jcr:primaryType" sv:type="Name">
                <sv:value>hippohtmlcleaner:cleanup</sv:value>
            </sv:property>
            <!-- border and style are removed from the table element when compared to bootstrap content -->
            <sv:node sv:name="hippohtmlcleaner:cleanupElement" h:merge="combine" h:location="child[26]">
                <sv:property sv:name="hippohtmlcleaner:attributes" sv:type="String" sv:multiple="true" h:merge="override">
                    <sv:value>class</sv:value>
                    <sv:value>cellspacing</sv:value>
                    <sv:value>cellpadding</sv:value>
                    <sv:value>width</sv:value>
                    <sv:value>align</sv:value>
                </sv:property>
            </sv:node>
        </sv:node>
    </sv:node>
</sv:node>

with in the ecm-extension:

 <sv:node sv:name="update-htmlCleaner">
        <sv:property sv:name="jcr:primaryType" sv:type="Name">
            <sv:value>hippo:initializeitem</sv:value>
        </sv:property>
        <sv:property sv:name="hippo:sequence" sv:type="Double">
            <sv:value>11048</sv:value>
        </sv:property>
        <sv:property sv:name="hippo:contentresource" sv:type="String">
            <sv:value>configuration/xinha/updateHtmlCleaner.xml</sv:value>
        </sv:property>
        <sv:property sv:name="hippo:contentroot" sv:type="String">
            <sv:value>/hippo:configuration/hippo:frontend/cms/cms-services</sv:value>
        </sv:property>
    </sv:node>

Furthermore, the 29th element contains the table htmlcleaner content as well. How do we remove this entire node using the delta XML's?


What to do?

Thanks,
Laurens






This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message
in error, please notify the sender immediately and delete all copies of this message.

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

HTML field invisible after deletion of compound type block in CMS

Robert de Vries
Dear Hippo dev's,

I just started on a Hippo project and I have no clue.

I have an issue with the Xinha HTML editor in Hippo CMS 7.7.1.

I have a document type with a so called block (compound type containing o.a. a html field) of which multiple instances are allowed.

After the following sequence every HTML field I click in edit mode gets invisible. After logging out and in everything is as usual:
  •     Open a document of the above mentioned document type.
  •     Click Edit.
  •     Delete one block.
  •     Click in another text field.
  •     Close the document without saving.
  •     Reopen the document.
  •     Delete one block.
  •     Click in another text field.
  •     Close the document without saving.
  •     Open another document containing a HTML text field.
  •     Click Edit.
  •     Click in the HTML text field and the field will render invisible.

Has someone any idea how this can be solved? 


Kind regards,

Robert de Vries

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

Re: HTML field invisible after deletion of compound type block in CMS

Laurens Leeuwis
We were running into kind of the same issue two weeks ago. Still hasn't been solved here I'm afraid.
 
Kind regards,
Laurens
 

Van: [hidden email] [[hidden email]] namens Robert de Vries [[hidden email]]
Verzonden: maandag 25 juni 2012 13:22
Aan: Hippo CMS 7 development public mailinglist
Onderwerp: [Hippo-cms7-user] HTML field invisible after deletion of compound type block in CMS

Dear Hippo dev's,

I just started on a Hippo project and I have no clue.

I have an issue with the Xinha HTML editor in Hippo CMS 7.7.1.

I have a document type with a so called block (compound type containing o.a. a html field) of which multiple instances are allowed.

After the following sequence every HTML field I click in edit mode gets invisible. After logging out and in everything is as usual:
  •     Open a document of the above mentioned document type.
  •     Click Edit.
  •     Delete one block.
  •     Click in another text field.
  •     Close the document without saving.
  •     Reopen the document.
  •     Delete one block.
  •     Click in another text field.
  •     Close the document without saving.
  •     Open another document containing a HTML text field.
  •     Click Edit.
  •     Click in the HTML text field and the field will render invisible.

Has someone any idea how this can be solved? 


Kind regards,

Robert de Vries

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message
in error, please notify the sender immediately and delete all copies of this message.


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

Re: HTML field invisible after deletion of compound type block in CMS

Frank van Lankvelt
In reply to this post by Robert de Vries
On Mon, Jun 25, 2012 at 1:22 PM, Robert de Vries
<[hidden email]> wrote:

> Dear Hippo dev's,
>
> I just started on a Hippo project and I have no clue.
>
> I have an issue with the Xinha HTML editor in Hippo CMS 7.7.1.
>
> I have a document type with a so called block (compound type containing o.a.
> a html field) of which multiple instances are allowed.
>
> After the following sequence every HTML field I click in edit mode gets
> invisible. After logging out and in everything is as usual:
>
>     Open a document of the above mentioned document type.
>     Click Edit.
>     Delete one block.
>     Click in another text field.
>     Close the document without saving.
>     Reopen the document.
>     Delete one block.
>     Click in another text field.
>     Close the document without saving.
>     Open another document containing a HTML text field.
>     Click Edit.
>     Click in the HTML text field and the field will render invisible.
>
>
> Has someone any idea how this can be solved?
>
are there any javascript errors perhaps?

cheers, Frank

>
> Kind regards,
>
> Robert de Vries
>
> _______________________________________________
> 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: Removing content using delta XMLs

Laurens Leeuwis
In reply to this post by Laurens Leeuwis
any help removing the attributes?

I've tried <sv:node sv:name="hippohtmlcleaner:cleanupElement" h:merge="combine" h:location="child[26]">
instead of <sv:node sv:name="hippohtmlcleaner:cleanupElement[26]" h:merge="combine">
as well, with no succes :(

thanks,
Laurens

________________________________________
Van: [hidden email] [[hidden email]] namens Leeuwis, Laurens [[hidden email]]
Verzonden: maandag 25 juni 2012 12:13
Aan: Hippo CMS 7 development public mailinglist
Onderwerp: [Hippo-cms7-user] Removing content using delta XMLs

Dear Hippo dev's,

In /hippo:configuration/hippo:frontend/cms/cms-services/htmlCleanerService/cleaner.config/hippohtmlcleaner:cleanup/ there is an hippohtmlcleaner:cleanupElement (the 26th) which allows some attributes for the table element. I would like to change these attributes, from {class, border, cellspacing, cellpadding, width, align, style} to {class, cellspacing, cellpadding, width, align} (without border or style)

I tried this:

<?xml version="1.0" encoding="UTF-8"?>
<sv:node xmlns:sv="http://www.jcp.org/jcr/sv/1.0" sv:name="htmlCleanerService" xmlns:h="http://www.onehippo.org/jcr/xmlimport" h:merge="combine">
    <sv:property sv:name="jcr:primaryType" sv:type="Name">
        <sv:value>frontend:plugin</sv:value>
    </sv:property>
    <sv:node sv:name="cleaner.config" h:merge="combine">
        <sv:property sv:name="jcr:primaryType" sv:type="Name">
            <sv:value>hippohtmlcleaner:config</sv:value>
        </sv:property>
        <sv:node sv:name="hippohtmlcleaner:cleanup" h:merge="combine">
            <sv:property sv:name="jcr:primaryType" sv:type="Name">
                <sv:value>hippohtmlcleaner:cleanup</sv:value>
            </sv:property>
            <!-- border and style are removed from the table element when compared to bootstrap content -->
            <sv:node sv:name="hippohtmlcleaner:cleanupElement" h:merge="combine" h:location="child[26]">
                <sv:property sv:name="hippohtmlcleaner:attributes" sv:type="String" sv:multiple="true" h:merge="override">
                    <sv:value>class</sv:value>
                    <sv:value>cellspacing</sv:value>
                    <sv:value>cellpadding</sv:value>
                    <sv:value>width</sv:value>
                    <sv:value>align</sv:value>
                </sv:property>
            </sv:node>
        </sv:node>
    </sv:node>
</sv:node>

with in the ecm-extension:

 <sv:node sv:name="update-htmlCleaner">
        <sv:property sv:name="jcr:primaryType" sv:type="Name">
            <sv:value>hippo:initializeitem</sv:value>
        </sv:property>
        <sv:property sv:name="hippo:sequence" sv:type="Double">
            <sv:value>11048</sv:value>
        </sv:property>
        <sv:property sv:name="hippo:contentresource" sv:type="String">
            <sv:value>configuration/xinha/updateHtmlCleaner.xml</sv:value>
        </sv:property>
        <sv:property sv:name="hippo:contentroot" sv:type="String">
            <sv:value>/hippo:configuration/hippo:frontend/cms/cms-services</sv:value>
        </sv:property>
    </sv:node>

Furthermore, the 29th element contains the table htmlcleaner content as well. How do we remove this entire node using the delta XML's?


What to do?

Thanks,
Laurens






This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message
in error, please notify the sender immediately and delete all copies of this message.

_______________________________________________
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: Removing content using delta XMLs

Unico Hommes
Every once in a while this question gets asked and there never seems
to be an answer. The contentdelete option was deprecated after the
introduction of delta's but the latter don't seem to provide a
substitute. I think the conclusion should either be to undeprecate
contentdelete or provide a delta instruction to do so. Until then:

hippoecm-extension.xml:
...
<sv:node sv:name="my-initialize-item">
  <sv:property sv:name="hippo:contentdelete" sv:type="String">
    <sv:value>/path/to/content/to/delete</sv:value>
  </sv:property>

--
Unico

On Tue, Jun 26, 2012 at 4:13 PM, Leeuwis, Laurens
<[hidden email]> wrote:

> any help removing the attributes?
>
> I've tried <sv:node sv:name="hippohtmlcleaner:cleanupElement" h:merge="combine" h:location="child[26]">
> instead of <sv:node sv:name="hippohtmlcleaner:cleanupElement[26]" h:merge="combine">
> as well, with no succes :(
>
> thanks,
> Laurens
>
> ________________________________________
> Van: [hidden email] [[hidden email]] namens Leeuwis, Laurens [[hidden email]]
> Verzonden: maandag 25 juni 2012 12:13
> Aan: Hippo CMS 7 development public mailinglist
> Onderwerp: [Hippo-cms7-user] Removing content using delta XMLs
>
> Dear Hippo dev's,
>
> In /hippo:configuration/hippo:frontend/cms/cms-services/htmlCleanerService/cleaner.config/hippohtmlcleaner:cleanup/ there is an hippohtmlcleaner:cleanupElement (the 26th) which allows some attributes for the table element. I would like to change these attributes, from {class, border, cellspacing, cellpadding, width, align, style} to {class, cellspacing, cellpadding, width, align} (without border or style)
>
> I tried this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <sv:node xmlns:sv="http://www.jcp.org/jcr/sv/1.0" sv:name="htmlCleanerService" xmlns:h="http://www.onehippo.org/jcr/xmlimport" h:merge="combine">
>    <sv:property sv:name="jcr:primaryType" sv:type="Name">
>        <sv:value>frontend:plugin</sv:value>
>    </sv:property>
>    <sv:node sv:name="cleaner.config" h:merge="combine">
>        <sv:property sv:name="jcr:primaryType" sv:type="Name">
>            <sv:value>hippohtmlcleaner:config</sv:value>
>        </sv:property>
>        <sv:node sv:name="hippohtmlcleaner:cleanup" h:merge="combine">
>            <sv:property sv:name="jcr:primaryType" sv:type="Name">
>                <sv:value>hippohtmlcleaner:cleanup</sv:value>
>            </sv:property>
>            <!-- border and style are removed from the table element when compared to bootstrap content -->
>            <sv:node sv:name="hippohtmlcleaner:cleanupElement" h:merge="combine" h:location="child[26]">
>                <sv:property sv:name="hippohtmlcleaner:attributes" sv:type="String" sv:multiple="true" h:merge="override">
>                    <sv:value>class</sv:value>
>                    <sv:value>cellspacing</sv:value>
>                    <sv:value>cellpadding</sv:value>
>                    <sv:value>width</sv:value>
>                    <sv:value>align</sv:value>
>                </sv:property>
>            </sv:node>
>        </sv:node>
>    </sv:node>
> </sv:node>
>
> with in the ecm-extension:
>
>  <sv:node sv:name="update-htmlCleaner">
>        <sv:property sv:name="jcr:primaryType" sv:type="Name">
>            <sv:value>hippo:initializeitem</sv:value>
>        </sv:property>
>        <sv:property sv:name="hippo:sequence" sv:type="Double">
>            <sv:value>11048</sv:value>
>        </sv:property>
>        <sv:property sv:name="hippo:contentresource" sv:type="String">
>            <sv:value>configuration/xinha/updateHtmlCleaner.xml</sv:value>
>        </sv:property>
>        <sv:property sv:name="hippo:contentroot" sv:type="String">
>            <sv:value>/hippo:configuration/hippo:frontend/cms/cms-services</sv:value>
>        </sv:property>
>    </sv:node>
>
> Furthermore, the 29th element contains the table htmlcleaner content as well. How do we remove this entire node using the delta XML's?
>
>
> What to do?
>
> Thanks,
> Laurens
>
>
>
>
>
>
> This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is
> intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to
> read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message
> in error, please notify the sender immediately and delete all copies of this message.
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Removing content using delta XMLs

Niels van Kampenhout-2
On Tue, Jun 26, 2012 at 11:27 AM, Unico Hommes <[hidden email]> wrote:
> Every once in a while this question gets asked and there never seems
> to be an answer. The contentdelete option was deprecated after the
> introduction of delta's but the latter don't seem to provide a
> substitute. I think the conclusion should either be to undeprecate
> contentdelete or provide a delta instruction to do so. Until then:

+1 for undeprecating contentdelete.

This is being used by almost every project I see (and I see a lot of
projects). It's useful functionality and working as expected, the only
complaint I always get from clients is about the "deprecated" warning.
The sooner it's undeprecated the better.

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

Re: Removing content using delta XMLs

b.vanderschans@onehippo.com
On Tue, Jun 26, 2012 at 7:06 PM, Niels van Kampenhout <[hidden email]> wrote:
On Tue, Jun 26, 2012 at 11:27 AM, Unico Hommes <[hidden email]> wrote:
> Every once in a while this question gets asked and there never seems
> to be an answer. The contentdelete option was deprecated after the
> introduction of delta's but the latter don't seem to provide a
> substitute. I think the conclusion should either be to undeprecate
> contentdelete or provide a delta instruction to do so. Until then:

+1 for undeprecating contentdelete.

This is being used by almost every project I see (and I see a lot of
projects). It's useful functionality and working as expected, the only
complaint I always get from clients is about the "deprecated" warning.
The sooner it's undeprecated the better.

 
This discussion pops up every so often. Let me explain is the contentdelete is my "fault" in the first place, because I wrote it. 

The contentdelete works on path level. Basically you specify a path "/nodeA/deleteme" and it gets deleted. So far so good. The problem arises with same name siblings which we use quite a lot in the repository. You might think you can specify "/nodeA/sns[2]" to delete the second same name sibling. But which one is the first? And which one is the second? This might differ per environment in DTAP. So deploying to acceptance may work fine and when you deploy to production you delete some valuable content and something might be broken. Unexpectedly. Which is not a good place to be.

So at first glance it might work nicely, but in practice you can and will (this has happened many times in the past) get unpredictable results. Hence we deprecated it. It's a dangerous thing to use.

So I'm -1 on undeprecating it.

We need to facilitate somehow the deletion of a node in the content bootstrap mechanism. The only way you can safely do this when specifying explicitly and uniquely  which same name sibling has to be deleted. For example "delete /nodeA/sns with property color=blue" or "delete /nodeA/sns with subnode nodeB which has property shape=square". 

I'm not sure if it is possible to do these kind of things with the delta xml format. But maybe somebody else has more knowledge in this area and can give some insight on how to go forward with the "delete issue".

Regards,
Bart



 

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

Re: Removing content using delta XMLs

Woonsan Ko-3
On 6/26/12 4:17 PM, Bart van der Schans wrote:
> We need to facilitate somehow the deletion of a node in the content
> bootstrap mechanism. The only way you can safely do this when
> specifying explicitly and uniquely  which same name sibling has to be
> deleted. For example "delete /nodeA/sns with property color=blue" or
> "delete /nodeA/sns with subnode nodeB which has property shape=square".
>
> I'm not sure if it is possible to do these kind of things with the delta
> xml format. But maybe somebody else has more knowledge in this area and
> can give some insight on how to go forward with the "delete issue".

How about supporting xpath query with a new *hippo:contentdeletebyquery*?
Then a xpath or sql query statement can be put instead of a path.

Regards,

Woonsan

--
[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
12