Hippo handle improvement for extendability

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

Hippo handle improvement for extendability

Jeroen Reijn
Administrator
Hi all,

at our project we're working on a CMS plugin that will attach a
reminder to a document. We're quite far and almost rounding it up, but
while looking at the current implementation I see room for
improvement.

The reminder information is now stored as properties on a
hippo:document by means of a workflow call. A document in the CMS has
a mixin that will cause an extra plugin to popup for the reminder.

What I think would be better to have is a separate node reminder:info
(or something similar) that is stored underneath the handle instead of
having the information stored on the actual hippo document. That way
the preview/live/draft document is not polluted with the extra
information of the reminder. However looking at the CND of a handle
it's only possible to either attach a hippo:document node or a
hippo:request node.

I gave it a shot by misusing the the hippo:request node (just for the
fun of it), but that causes issues with the current workflow plugins.
Probably trying to misuse a hippo:document node will result in similar
results.

Of course I could create a mixin that I set on all handle nodes, but
that not quite that easy as far as I could see. I don't really see an
entry point for setting hte mixin by default on every new document
handle that I create. I can change the prototype of a document but not
the handle.

Next to that it might be possible to not even store the reminders near
the document but somewhere else and use a reference or something
similar to link to a handle or document that should contain the
reminder, but I would prefer to have it closer to the document.

Maybe somebody has another nice idea for a future improvement, but
otherwise I would like to suggest to relax the hippo:handle
definition, so that developers are able to extend the hippo:handle
with any kind of custom node/information. WDYT?

Cheers,

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

Re: Hippo handle improvement for extendability

M Nair
CONTENTS DELETED
The author has deleted this message.
Ard
Reply | Threaded
Open this post in threaded view
|

Re: Hippo handle improvement for extendability

Ard
In reply to this post by Jeroen Reijn
On Wed, Aug 10, 2011 at 11:13 PM, Jeroen Reijn <[hidden email]> wrote:

> Hi all,
>
> at our project we're working on a CMS plugin that will attach a
> reminder to a document. We're quite far and almost rounding it up, but
> while looking at the current implementation I see room for
> improvement.
>
> The reminder information is now stored as properties on a
> hippo:document by means of a workflow call. A document in the CMS has
> a mixin that will cause an extra plugin to popup for the reminder.
>
> What I think would be better to have is a separate node reminder:info
> (or something similar) that is stored underneath the handle instead of
> having the information stored on the actual hippo document. That way
> the preview/live/draft document is not polluted with the extra
> information of the reminder. However looking at the CND of a handle
> it's only possible to either attach a hippo:document node or a
> hippo:request node.
>
> I gave it a shot by misusing the the hippo:request node (just for the
> fun of it), but that causes issues with the current workflow plugins.
> Probably trying to misuse a hippo:document node will result in similar
> results.
>
> Of course I could create a mixin that I set on all handle nodes, but
> that not quite that easy as far as I could see. I don't really see an
> entry point for setting hte mixin by default on every new document
> handle that I create. I can change the prototype of a document but not
> the handle.

You are already hooking into some workflow. I am not very familiar
with that part, but can't you set the mixin on the handle during the
workflow step, and then add the property you want to add?

>
> Next to that it might be possible to not even store the reminders near
> the document but somewhere else and use a reference or something
> similar to link to a handle or document that should contain the
> reminder, but I would prefer to have it closer to the document.

I would keep it close to the document : this way, you do not have to
worry about other sessions modifying the same node (area), or about
ACLs : All editors should then have to be able to write to this other
location

>
> Maybe somebody has another nice idea for a future improvement, but
> otherwise I would like to suggest to relax the hippo:handle
> definition, so that developers are able to extend the hippo:handle
> with any kind of custom node/information. WDYT?

As said, the mixin is imo a good solution, but not sure if feasible.
Relaxing the handle I am not very much against, although the type of
nodes that can be added should be constrained to some (marker) base
type : You should not be able to add any sort of node below a handle.

Last but not least, you should be very carefully in testing whether
all the filtered mirrors still work correctly when you add your own
custom nodetypes below a handle. This might break. Also you need to
think about whether this node will pop up in the virtual structures?
Also, the HST might want to bind them to a bean (although the HST is
resilient against this and probably you won't even notice it).

Either way, it is quite delicate to alter this core handle part, be
aware of the possible site effects

Regards Ard

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

Re: Hippo handle improvement for extendability

Jeroen Reijn
Administrator
In reply to this post by M Nair


On Thu, Aug 11, 2011 at 12:51 AM, M Nair <[hidden email]> wrote:
Jeroen

Not trying to step on your work ;-) but what value does a reminder add from a producers point of view ?

Don't worry :-) The client that I'm working for has this functionality right know (in a system that we're migrating) and it's used very often. The concept of this reminder story is that an editor can set a reminder on a document (with some text and a date) so that the editor (or a cluster of editors) get a reminder on their dashboard that they need to review the content of a certain page in a certain amount of time.

The added value for most content types like news, agenda, etc won't be much but for some content this can be quite useful. The system will then alert the user by means of the dashboard that their is a reminder for content in the next upcoming day, week, month, etc.
 
We have used a few CMSs before and I have not heard of any producer asking for this functionality ..

It's my first as well, but I can see the added value. 
 

Thanks

Thanks for the feedback!
 


--- On Wed, 8/10/11, Jeroen Reijn <[hidden email]> wrote:

From: Jeroen Reijn <[hidden email]>
Subject: [Hippo-cms7-user] Hippo handle improvement for extendability
To: "Hippo CMS7 user list" <[hidden email]>
Date: Wednesday, August 10, 2011, 2:13 PM

Hi all,

at our project we're working on a CMS plugin that will attach a
reminder to a document. We're quite far and almost rounding it up, but
while looking at the current implementation I see room for
improvement.

The reminder information is now stored as properties on a
hippo:document by means of a workflow call. A document in the CMS has
a mixin that will cause an extra plugin to popup for the reminder.

What I think would be better to have is a separate node reminder:info
(or something similar) that is stored underneath the handle instead of
having the information stored on the actual hippo document. That way
the preview/live/draft document is not polluted with the extra
information of the reminder. However looking at the CND of a handle
it's only possible to either attach a hippo:document node or a
hippo:request node.

I gave it a shot by misusing the the hippo:request node (just for the
fun of it), but that causes issues with the current workflow plugins.
Probably trying to misuse a hippo:document node will result in similar
results.

Of course I could create a mixin that I set on all handle nodes, but
that not quite that easy as far as I could see. I don't really see an
entry point for setting hte mixin by default on every new document
handle that I create. I can change the prototype of a document but not
the handle.

Next to that it might be possible to not even store the reminders near
the document but somewhere else and use a reference or something
similar to link to a handle or document that should contain the
reminder, but I would prefer to have it closer to the document.

Maybe somebody has another nice idea for a future improvement, but
otherwise I would like to suggest to relax the hippo:handle
definition, so that developers are able to extend the hippo:handle
with any kind of custom node/information. WDYT?

Cheers,

Jeroen
_______________________________________________
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: Hippo handle improvement for extendability

Jeroen Reijn
Administrator
In reply to this post by Ard
On Thu, Aug 11, 2011 at 8:59 AM, Ard Schrijvers
<[hidden email]> wrote:

> On Wed, Aug 10, 2011 at 11:13 PM, Jeroen Reijn <[hidden email]> wrote:
>> Hi all,
>>
>> at our project we're working on a CMS plugin that will attach a
>> reminder to a document. We're quite far and almost rounding it up, but
>> while looking at the current implementation I see room for
>> improvement.
>>
>> The reminder information is now stored as properties on a
>> hippo:document by means of a workflow call. A document in the CMS has
>> a mixin that will cause an extra plugin to popup for the reminder.
>>
>> What I think would be better to have is a separate node reminder:info
>> (or something similar) that is stored underneath the handle instead of
>> having the information stored on the actual hippo document. That way
>> the preview/live/draft document is not polluted with the extra
>> information of the reminder. However looking at the CND of a handle
>> it's only possible to either attach a hippo:document node or a
>> hippo:request node.
>>
>> I gave it a shot by misusing the the hippo:request node (just for the
>> fun of it), but that causes issues with the current workflow plugins.
>> Probably trying to misuse a hippo:document node will result in similar
>> results.
>>
>> Of course I could create a mixin that I set on all handle nodes, but
>> that not quite that easy as far as I could see. I don't really see an
>> entry point for setting hte mixin by default on every new document
>> handle that I create. I can change the prototype of a document but not
>> the handle.
>
> You are already hooking into some workflow. I am not very familiar
> with that part, but can't you set the mixin on the handle during the
> workflow step, and then add the property you want to add?

Yes you are probably right. I will have to look into that. I did not
try that before. They workflow now has already some tricky things with
jpox etc.

>
>>
>> Next to that it might be possible to not even store the reminders near
>> the document but somewhere else and use a reference or something
>> similar to link to a handle or document that should contain the
>> reminder, but I would prefer to have it closer to the document.
>
> I would keep it close to the document : this way, you do not have to
> worry about other sessions modifying the same node (area), or about
> ACLs : All editors should then have to be able to write to this other
> location

Agreed!

>
>>
>> Maybe somebody has another nice idea for a future improvement, but
>> otherwise I would like to suggest to relax the hippo:handle
>> definition, so that developers are able to extend the hippo:handle
>> with any kind of custom node/information. WDYT?
>
> As said, the mixin is imo a good solution, but not sure if feasible.
> Relaxing the handle I am not very much against, although the type of
> nodes that can be added should be constrained to some (marker) base
> type : You should not be able to add any sort of node below a handle.

Agreed. I was just wondering if that was ever handled before or that
somebody has some similar usecase.

>
> Last but not least, you should be very carefully in testing whether
> all the filtered mirrors still work correctly when you add your own
> custom nodetypes below a handle. This might break. Also you need to
> think about whether this node will pop up in the virtual structures?
> Also, the HST might want to bind them to a bean (although the HST is
> resilient against this and probably you won't even notice it).

That would have been the next step in the proces. The initial setup is
that we are using a facetnav node (in the CMS) that contains the
filtering for the reminders. But in the CMS you do not have a
difference between preview and live on a facetnav node (you get both),
so now we have the reminders twice (in case of a preview and live
document) in the CMS. We're filtering that manually now.

>
> Either way, it is quite delicate to alter this core handle part, be
> aware of the possible site effects

I was afraid of that, that's why I posted the question on the list
before I went down this path. I think I'll leave it for now, because
we don't want to do too much rework.

>
> Regards Ard

Thanks Ard!

>
>>
>> Cheers,
>>
> _______________________________________________
> 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
Ard
Reply | Threaded
Open this post in threaded view
|

Re: Hippo handle improvement for extendability

Ard
On Thu, Aug 11, 2011 at 9:35 AM, Jeroen Reijn <[hidden email]> wrote:
>
> That would have been the next step in the proces. The initial setup is
> that we are using a facetnav node (in the CMS) that contains the
> filtering for the reminders. But in the CMS you do not have a
> difference between preview and live on a facetnav node (you get both),
> so now we have the reminders twice (in case of a preview and live
> document) in the CMS. We're filtering that manually now.

This is not needed. If you first create a facetselect and access the
facetnav through this facetselect, you can see only live or preview.
Because a live document also has availability preview, you can do it
as follows:

facetselect
   hippo:facets    hippo:availability
   hippo:values    preview
   hippo:modes    single
   hippo:uuid        parent uuid of the faceted navigation node

Now accessing it in the cms through this facetselect won't return you
any doubles. The uuid cannot point to the facet nav node itself IIRC,
but must be to the parent (this is a corner case thingy)

Regards Ard

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

Re: Hippo handle improvement for extendability

Berry van Halderen
In reply to this post by Jeroen Reijn


On Wed, Aug 10, 2011 at 11:13 PM, Jeroen Reijn <[hidden email]> wrote:
Hi all,

at our project we're working on a CMS plugin that will attach a
reminder to a document. We're quite far and almost rounding it up, but
while looking at the current implementation I see room for
improvement.

The reminder information is now stored as properties on a
hippo:document by means of a workflow call. A document in the CMS has
a mixin that will cause an extra plugin to popup for the reminder.

What I think would be better to have is a separate node reminder:info
(or something similar) that is stored underneath the handle instead of
having the information stored on the actual hippo document. That way
the preview/live/draft document is not polluted with the extra
information of the reminder. However looking at the CND of a handle
it's only possible to either attach a hippo:document node or a
hippo:request node.

I gave it a shot by misusing the the hippo:request node (just for the
fun of it), but that causes issues with the current workflow plugins.
Probably trying to misuse a hippo:document node will result in similar
results.


In my point of view, its not actually a misuse of a hippo:request kind of node.  Basically the name hippo:request is a remnant from the early beginnings, it is more like a task or annotation that is stored there.  That is also why there is a split in the core type hipposys:request, which is more like an empty abstract, and the hippo:request node types, that are geared towards reviewed actions.  That certain workflows (or rather the front-end part probably, the implementations are quite strict) cannot handle it is more a problem at that site needed to be  solved. 
I would certainly go for the route to extend hipposys:request.  Putting a mixin on the handle probably leads to more problems, at certain components might not be expecting that.

\Berry

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

Re: Hippo handle improvement for extendability

Gerrit Berkouwer
In reply to this post by Jeroen Reijn
Next steps could be that we put something in place to collect the use of these reminders:

E.g.:
- how many reminders are made per month?
- how many reminders per group of editors?
- how many reminders are closed on their expiration date?
- how many reminders stay open after there expire-date and for how long?
et cetera.

This is all part of a set of metrics we want to establish around the use of the CMS, as part of the Quality-programm we set up. The metric for this could be something like "content is checked for accuracy every week"


Greetz, Gerrit

On Thu, Aug 11, 2011 at 12:51 AM, M Nair <[hidden email]> wrote:

    Jeroen

    Not trying to step on your work ;-) but what value does a reminder add from a producers point of view ?


Don't worry :-) The client that I'm working for has this functionality right know (in a system that we're migrating) and it's used very often. The concept of this reminder story is that an editor can set a reminder on a document (with some text and a date) so that the editor (or a cluster of editors) get a reminder on their dashboard that they need to review the content of a certain page in a certain amount of time.

The added value for most content types like news, agenda, etc won't be much but for some content this can be quite useful. The system will then alert the user by means of the dashboard that their is a reminder for content in the next upcoming day, week, month, etc.
 

    We have used a few CMSs before and I have not heard of any producer asking for this functionality ..


It's my first as well, but I can see the added value.
 


    Thanks


Thanks for the feedback!
 



    --- On Wed, 8/10/11, Jeroen Reijn <[hidden email]> wrote:


        From: Jeroen Reijn <[hidden email]>
        Subject: [Hippo-cms7-user] Hippo handle improvement for extendability
        To: "Hippo CMS7 user list" <[hidden email]>
        Date: Wednesday, August 10, 2011, 2:13 PM

        Hi all,

        at our project we're working on a CMS plugin that will attach a
        reminder to a document. We're quite far and almost rounding it up, but
        while looking at the current implementation I see room for
        improvement.
--
Greetz, Gerrit
Reply | Threaded
Open this post in threaded view
|

Re: Hippo handle improvement for extendability

Jeroen Reijn
Administrator
In reply to this post by Ard
On Thu, Aug 11, 2011 at 9:44 AM, Ard Schrijvers
<[hidden email]> wrote:

> On Thu, Aug 11, 2011 at 9:35 AM, Jeroen Reijn <[hidden email]> wrote:
>>
>> That would have been the next step in the proces. The initial setup is
>> that we are using a facetnav node (in the CMS) that contains the
>> filtering for the reminders. But in the CMS you do not have a
>> difference between preview and live on a facetnav node (you get both),
>> so now we have the reminders twice (in case of a preview and live
>> document) in the CMS. We're filtering that manually now.
>
> This is not needed. If you first create a facetselect and access the
> facetnav through this facetselect, you can see only live or preview.
> Because a live document also has availability preview, you can do it
> as follows:
>
> facetselect
>   hippo:facets    hippo:availability
>   hippo:values    preview
>   hippo:modes    single
>   hippo:uuid        parent uuid of the faceted navigation node
>
> Now accessing it in the cms through this facetselect won't return you
> any doubles. The uuid cannot point to the facet nav node itself IIRC,
> but must be to the parent (this is a corner case thingy)

Awesome Ard. I did not think of that. It must have been late last night ;-)

>
> Regards Ard
>
>>
>>>
> _______________________________________________
> 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
Ard
Reply | Threaded
Open this post in threaded view
|

Re: Hippo handle improvement for extendability

Ard
On Thu, Aug 11, 2011 at 9:55 AM, Jeroen Reijn <[hidden email]> wrote:

>> facetselect
>>   hippo:facets    hippo:availability
>>   hippo:values    preview
>>   hippo:modes    single
>>   hippo:uuid        parent uuid of the faceted navigation node
>>
>> Now accessing it in the cms through this facetselect won't return you
>> any doubles. The uuid cannot point to the facet nav node itself IIRC,
>> but must be to the parent (this is a corner case thingy)
>
> Awesome Ard. I did not think of that. It must have been late last night ;-)

You're welcome!

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