Path

ez projects / ezstarrating / forum / general / feature ideas


Feature ideas

You need to be logged in to post messages in the forums. New users may register here.

Brendan Pike

Member since:
11 March 2003

Posts: 86

Thursday 27 August 2009 1:23:31 am

Ability to change vote:
I think the ability to change your rating vote is useful, there are many uses where this could be valid. For example, perhaps you give an extension rating a vote of 2 but later the author improves it so you wish to then change your rating to 4. Having this as an option would be good.

Combined multiple ratings in a single object:
For example, you might wish to rate hotels you have stayed in but with more breakdown detail. You might provide separate ratings for Food, Service, Comfort and then in the template would need the ability to summarise these and show an average combined outcome score.

Australian eZ publish specialist http://www.dbinformatics.com.au

Up

André R

Member since:
20 August 2005

Posts: 171

Thursday 27 August 2009 3:28:39 pm

Thanks for the feedback!

"Combined multiple ratings in a single object:"
This should already be possible, or so I though, but now it is:)




{fetch_starrating_stats( <object_id> )|attribute('show', 3)}





UPDATE: Changed example as code changed recently after schema changes.

--
ar

Up

Carlos Revillo

Member since:
31 January 2007

Posts: 53

Wednesday 02 September 2009 4:58:14 pm

Here are some ideas i have.

First. I would like to check if the user has rated BEFORE he can click any of the stars. if we allow them to click and then we show the message about 'what you did won't count' maybe they get upset...

Second. Thinking in accesibilitiy options, it would nice to have the possibility of voting without javascript enabled in your browser. This could easily (at least ar think so), changing the javascript:void(0) in the href for calls to a module with the params needed.

Third. It would nice to have the posibility or defining when a user will be allowed to vote again. i mean, something that 'you can't vote this again for this month' or something like that.

Thank you :).

Twitter: @crevillo
Skype ID: crevillo1976
http://www.tantacom.com
eZ Diff Squad member

Up

André R

Member since:
20 August 2005

Posts: 171

Wednesday 02 September 2009 10:57:44 pm


> First:
That should already be possible, using this:



Y.io.ez( 'ezstarrating::user_has_rated::<object_id>::<attribute_id>', { on : { success: _callBack } } );




There is a possibility to check this in template code as well, but it has been disabled since it isn't cache safe. If there is demand for having it back, then we'll re enable it. But remember that viewcache isn't pr user by default (however possible to enable in 4.1 and higher using site.ini[ContentSettings]ViewCacheTweaks[]).

> Second
hmm, would need a fairly simple starrating/rate view to do that.

> Third
Seem a bit to complex, sure suggestion above about being able to change your vote wouldn't do? (far easier to implement..)

--
ar

Up

Carlos Revillo

Member since:
31 January 2007

Posts: 53

Wednesday 02 September 2009 11:16:01 pm

Ok to all your replies. First one was related to the second one. the ajax call will do the job perflecty, but i would like to do it without javascript.

This reminds me a long talk we had some months ago about the posibility or having those viewCacheTweaks by class :). Problem with viewCacheTweaks: if we have 10.000 'article' nodes we'll have to add a entry in the ini for each one (correct me if i'm wrong).

It would be great, not only for ezstarrating but entire ezpublish, to have a way to don't cache specif parts of your template.

somekinda



{dont-cache-this}


{*code for checking if we can vote and so on}


{/dont-cache-this}




but seems too hard to be implemented...

Twitter: @crevillo
Skype ID: crevillo1976
http://www.tantacom.com
eZ Diff Squad member

Up

André R

Member since:
20 August 2005

Posts: 171

Thursday 03 September 2009 2:04:26 pm

That won't happen before we change tempalte language, and even then it will not work when the page is fully cached (page / view cache).

As for the pr class discussion, that won't happen before we have expiry data for node cache that includes meta data like class identifier.

--
ar

Up

André R

Member since:
20 August 2005

Posts: 171

Tuesday 08 September 2009 8:32:30 pm

Ability to change vote is now implemented, this is enabled by default and can be turned off with site.ini[eZStarRating]AllowChangeRating

--
ar

Up

Gaetano Giunta

Member since:
30 November 1999

Posts: 269

Thursday 24 September 2009 4:59:46 pm

+1 for adding the module view for non-ajax voting (and the corresponding hrefs on the star icons in the default template)...

Principal Consultant International Business
Member of the Community Project Board

Up

Gaetano Giunta

Member since:
30 November 1999

Posts: 269

Wednesday 21 October 2009 5:53:00 pm

Other idea: deprecate the fetch-by-starrating template operators, introduce proper fetch functions.
Not hard to do, not a lot of functionality gained, but it makes a helluva lot more sense...

Principal Consultant International Business
Member of the Community Project Board

Up

Gaetano Giunta

Member since:
30 November 1999

Posts: 269

Wednesday 21 October 2009 6:02:24 pm

also add depth support when using parent-node-id to fetch-by-starrating...

Principal Consultant International Business
Member of the Community Project Board

Up

André R

Member since:
20 August 2005

Posts: 171

Thursday 22 October 2009 10:15:32 am

"+1 for adding the module view"
Don't need a view, only need redirect support on ezjscore server calls.

"also add depth support when using parent-node-id to fetch-by-starrating... "
From inline doc:



        * 3. parent_node_id only works for list fetch, if you want tree fetch use 

        *   parent_node_path (format is like $node.path_string, as in '/1/2/144/256/').



Linq: http://svn.projects.ez.no/ezstarr...rrating/classes/ezsrratingobject.php

--
ar

Up

Gaetano Giunta

Member since:
30 November 1999

Posts: 269

Thursday 22 October 2009 10:35:37 am

@ar: thanks, i have read it and that's what I'm currently using. It still is a (little) pain because it forces me to keep the whole hierarchy of the starting node fixed (or to fetch the node again just to get it), while with node_id + depth I could be more flexible. I could also specify node X + depth 2 levels, which I cannot do right now (feel free to correct me)

Principal Consultant International Business
Member of the Community Project Board

Up

André R

Member since:
20 August 2005

Posts: 171

Thursday 22 October 2009 10:51:16 am

Yes, but then I have to fetch the node for you to figure out node path.. :P By forcing a few rules, I make sure the fetch does not do any costly operations behind the scene like normal list / tree fetches does.

--
ar

Up

You need to be logged in to post messages in the forums. New users may register here.