I am a complete novice to Drupal and module integration. I am given a task of letting the user give ratings in various ways along with their comment against a particular post. The rating will be 5 star rating. These rating will be for multiple fields such as Cleanliness(5 star rating), Communication(5 star rating) etc.
I have installed modules comment_cck, csm, token and fivestar. Just not able to put them together
How will i achieve this.
Thanks in advance
In order to use the fivestar module, you need to install voting API, and to build a view using the API, you need views.
Please follow this screencast - it should provide you with valuable info on how to use these modules. It's a little bit complex.
Related
So I have this application laid out but I am unsure on some aspects of how to go about it.
It's a website for dogs with cancer to supply a raw ketogenic diet for the user. There are other aspects of the website that I have figured out like where to hold state and such.
Where I'm a little confused on how to proceed is on the calculations for the ketogenic page shopping cart. The user can choose 1 fat source from the sources provided, one protein source and one green vegetable source. I want to make this as balanced and complete for the user for their dog- so obviously 1-protein 1 veg and 1 fat source is not balanced and complete. I need to factor in the amount of calories need per weight which I will have an input where the user can enter their dogs weight. I have done some of the math to make it complete and balanced on paper, factoring in amino acids, vitamins and minerals and the omega 6:3 ratio.
What I'm confused about is where am I going to hold all this data per se? It's a lot of data and it's based on many factors such as weight-activity, keto ratio like 1:1 or 2:1 depending what the user selects.
I obviously need a backend and need to build an API, but how would I return to the user the complete and balanced diet when so many other factors play in? Where would I store this other data? In objects? Variables? And then put it on the backend? I would greatly appreciate any help. Thanks in advance.
how are you? First of all, congrats on the great idea, I think it is great.
For starters, I think it's important for you, to lay down what technologies you'll be using.
1- Choose the technologies you are going to use. Will you use the MERN stack? React for front-end, mongo for the database, node.js for back-end with express.js as a framework?
2- Will you be the one providing all the data for the dog's diets? If not, find some website with an API for that data.
3- I am not any kind of expert on JS nor React.js, I'm just following the logic here. But does that data change? or is it always the same? I would advise you to use objects, so you can "play" with them, pass them around the classes (I would advise you to create a react class, where you store all of those objects, make sure you export that class)
4- Just lay everything out and START BUILDING!!! It sounds hella overwhelming to start such a big project, but once you get going some i's will be dotted, you will get a better understanding of what you actually are going to build.
5- Few tips, if you use an API you won't need to store the data, else store it on your database (JSON file, for example, there are great youtube tutorials on how to do so.)
Keeping this in mind, you asked where you'll be storing all that data, if you have an api, you won't store anything, if you don't, JSON is your best shot, it's really easy and intuitive to use and easy to read inside a react component.
I hope this gave you some extra clarification on what you'll need to do, in order to start.
PS: This answer is purely based on my limited React (and web dev) experience, I am no expert, let me know if there's anything else I can help you with.
As my ubiquitous language I have some phrases like :
Feature : Display A Post
In order to be able to check mistakes in a post
As an admin or customer
I want to be able to view the post
Scenario : Display Post
When : I select a post
Then : the post should be viewed
Is that a right user story? Such scenarios may have some minimal differences at UI level. Should I violate the DRY principle and repeat the feature for another role?
Different users may need different requirements over time, and I think this is the reason we usually write user stories per the user role.So should I be worry about how the requirements may change over time for different roles or I can leave a single user story (and the same test code,production code, databse ...) with multiple roles and refactor when their requirements forced me to separate them ?
I am not sure what your problem here and will try to guess. So first, your first three lines is just a description and not real steps. This enables adding custom text that will not run.
As to your other 2 steps, it is very hard to say whether they are good or not. As you might have already noticed, you are not bound by Cucumber to have a specific scenario flow. Cucumber gives you the freedom to design and write your code the way it makes more sense to YOU and YOUR business logic.
Saying that, I see no issue in repeating similar steps to test another role. In order to make the feature file a bit more DRY you can use the Scenario Outline option. It might look something like this:
Scenario Outline: Display Post as <role>
When I select a post as <role>
Then the post should be viewed
Examples:
|role |
|role1|
|role2|
In this case, two scenarios run one after another while rolevalue changes according to the Examples list.
Now, in regards to your possible changes in future. You can't always predict what will happen in future and unless continuously changing current requirements is a normal practice for you or your team, I wouldn't worry too much about this. If sometime in future current scenarios will become obsolete, you will review them and rewrite them or add new ones accordingly.
If multiple roles are required in a feature, then that means it is an epic, not a feature. It is a must to break down each feature so it only has one role, and it can deliver a single value to a single group of users.
I think the problem here is your language which needs refinement to clarify what you want to do here and why its important.
It seems to me that as an admin looking to fix mistakes in a post that what I need to is to be able to change a post.
A similar thing applies for the customer (should that be author?). If you explore what they will do when a post has been authored with a mistake then you will probably find that different roles interact in different ways. You'll start to ask questions about what happens if the customer and the admin make fixes, and how the customer responds when the admin makes a fix that the customer doesn't like and all sorts of other scenarios.
If you do this you'll probably find that most of your duplication goes away, and you'll learn lots about the differences between customer and admin behaviour in this particular context.
I chose phpbb3 for my forum. I want my user's post to be voted/rated by other members of my forum and also a user's reputation(ranking) should be changed according to his interaction with posts. Are there any built in features for these two tasks? If not what is the possibility to change the code according to my requirements? Any help is appreciated.
There aren't any built in features for reputation and ranking.
However, phpbb has a large database of user-built modifications which will definitely have what you need. See the mod database: http://www.phpbb.com/customise/db/modifications-1/?from=submenu&sid=b3bee6baf8411639512659054d6521c6
As for coding it yourself, you're certainly welcome to as far as licensing goes; but there will definitely be an existing modification which should suit your needs.
I am trying to create a N:1 relationship off another entity to Order Product. It is not an option in the pick list. I then tried to go to Order Product and create a 1:N relationship and it also does not allow it.
I am sure this is by design from Microsoft, but is there a way to achive this? I perfer not to to a 1:N or N:N as a work around since it will create grids on the form (and that does not make much sense from a UI perspective when there will only be one record).
Thank for the help!!!!
I am going to add a single line of text field and format it as a url. Then link it to the related entity by dynamically populating a URL to the entity. It is a work around but of all the possible scenarios its the best for my situation
We faced the same problem during building a solution for a client. It was a heavy restriction so in the end we just created our own order product entity and linked it via a one to many to order.
This gave us complete control over it and could add relationships as we wish.
This came at a cost unfortunately as you lose the auto calculation on order for example. This wasn't an issue however as we didn't need it or any of the price list functionality.
If this is an option for you I'd recommend doing it this way.
I think that everybody had to face the same problem in his CRM life.
For CRM, the entities, salesorderproduct... are entities used only to enumerate the products of the entity related in its name, and you can not do almost nothing, that's another problem with a workaround, that I'll try to explain, just to see if this could be the solution to creating relations with them, but I don't think so.
The problem is that you can not use the assign functionality as in other relations to copy data from one entityproduct to the lower-level entityproduct when you create custom fields, and you want to copy throught the entire workflow of sales section. In this case, there is no option to enter the "Assign" window (I use Assign because I have always worked in Spanish) and create the field mappings between them.
This could be done by searching the GUID of the "Assign" window, and copyign into any of the URLs of the "Assign" window, the window showed up, and you could do your custom mappings.
I hope this could help, although this question is too old, so I hope other that arrive here, could see more opinions :)
See you
I'm creating a Book store in Magento and am having trouble figuring out the best way to handle the Authors of a Book (which would be the product).
What I currently have is an Attribute called "authors" which is multi-select and a thousand [test] values. It's still manageable but does get a little slow when editing a product. Also, when adding an option/value to the authors attribute itself, a huge list is rendered in the HTML making this an inefficient solution.
Is there another approach I should take?
Is it possible to create an Author object (entity type?) which is associated to a product through a join table? If yes, can someone give me an explanation about how that is done or point me to some good documentation?
If I'd take the Author object approach, could that still be used in the layered navigation?
How would I show the list of all books for a single author?
Thanks in advance!
PS: I am aware of extensions like Improved Navigation but AFAIK it adds something like attributes to attributes themselves which is not what I'm looking for.
For Googlers: The same would apply for Artists of a music site or manufacturers.
If you create an author entity type, you'll just increase your work trying to add it to layered navigation, and I don't see a reason why it would be faster.
Your approach seems the best fit to the problem, given the way Magento is set up. How are you going to display 1,000 (which presumably pales in comparison to the actual list) authors in layered navigation?
Depending on the requirements, you could go the route of denormalizing the field and accepting text for it. That would still allow you to display it, search based on it, etc, but would eliminate the need to render every possible artist to manipulate the list. You could add a little code around selecting the proper artist (basically add an AJAX autocomplete to the backend field) to minimize typos as well.
Alternatively, you could write a simple utility to add a new artist to the system without some of the overhead of Magento's loading the list. To be honest, though, it seems that the lag that this has the potential to create on the frontend will probably outweigh the backend trouble.
Hope that helps!
Thanks,
Joe