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
Related
Hello Stackoverflow,
I'm writing API's for quite a bit of time right now and now it came to work with one of these bigger api's. Started wondering how to shape this API, as many times I've seen on a bigger platforms that one big entity (for example product page in shop) is loaded separately (We can see that item body loaded, but comments are still fetching etc.).
Usually what I've done was attaching comments as a relation in SQL query, so my frontend queried single API Endpoint like:
http://api.example.com/items/:id
And it returned all necessary data like seller info, photos etc.
Logically seller info and photos are small pieces of data (Item can only have 1 seller and no more than 10 photos for example), but number of comments might be way larger collection with relationship (comment author).
Does it make sense to separate one endpoint into 2 independent endpoints like:
http://api.example.com/items/:id
http://api.example.com/items/:id/comments
What are downsides of this approach? Is it common practice? Or maybe I misunderstood some concept?
One downside might be 2 request performed, but on the other hand, first endpoint should return data faster (as it's lighter than fetching n of comments), so page might be displayed faster and display spinner for comments section. This way I'll be able to paginate comments too.
Are there any improvements that might be included in this separation of endpoints? Or maybe I'm totally wrong and it should be done totally different way?
I think it is a good approach if:
The number of comments of one item can be large, because with this approach you could paginate it easier.
If you are going to need to access to the comments of one item without needing rest of item information
I think any of the previous conditions justify this decition, and yes, it is common approach.
I have a very basic, functioning, checklist application that I'd like to improve.
Essentially, it's just a list of 37,000 (and growing) items.
Right now, I have two entities:
1) Checklist: This includes the following attributes: name, numberOwned, imageName, groupName, etc - 14 in all. All are Strings
2) Keywords: This includes a single attribute: words, with a one-to-many nameKeywords relationship. This stores the normalized name for searching
My question is: Is there any reason to be using multiple entities in this type of situation? Should I remove the Keywords relationship and just add that as an additional attribute? Or should be be going the other route, minimizing the attributes and adding more entities?
I'd like to keep it as simple as possible (I'm not an experienced programmer, and the app isn't a source of revenue - it's available free on the store) - but I would like to make the searches more efficient if possible to make my users happy. Right now when a user searches for an item, it searches the normalized name in the Keyword entity, but it can take a while if they are trying to search through all items.
As usual, I apologize if this question is to vague. I'm happy to provide clarifications and code snippets as needed!
Zack
To increase the speed of search, you can use indexes for attributes, but it'll help if you can show your model of database
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 building a website for a restaurant which consists of several static pages like ‘About us’ and editable menu.
I need a CMS flexible enough to be able to add items individually (by individually, I mean adding items doesn’t equal pasting a HTML list of n products into another static page).
Each item should contain its name, description, price and category. The list of added items should be displayed using templates the way I want them to.
Can you suggest any lightweight CMS which can provide similar conditions?
There are tons of options for simple page creation. Have you considered just using one of the many free website builders out there? Then you don't even have to worry about finding hosting, just make it happen quickly and easily with one of them. For instance, take a look at Weebly (review here) or Wix. Both allow for free pages and both are incredibly easy to use. Squarespace (review here) is another solid option (and one of my favorites) but charges a small fee (which I personally think is worth it).
Weebly allows for some slick drag and drop of page elements into place as does Wix. They are what I would classify as the easiest of the batch while Squarespace provides for an excellent user interface experience.
Other options if you'd prefer something hosted on your own would depend on your experience level. I am a huge fan of Processwire and ImpressPages has come along nicely and is great little CMS too.
These are exceptions to the typical Top Three that everyone tends to recommend I know but I like to spread the word about other projects instead of the usual ones.
Cheers!
Mike
Sounds like a job for Wordpress 3.0 plus Custom Post Types UI + Verve Meta Boxes plugins. Wordpress will handle the static pages, the other two plugins will allow you to make a Menu Item post type with custom fields.
It is not exactly lightweight, but you could do it with Drupal. You can define you own content type "product", use the CCK module to add your fields (price, ...) and use the Views module to display it how you want.
Drupal has a relatively steep learning curve, so it may be overkill for this project. It is definitely flexible enough for this, though.
My web applications have pages that display many static fields.
I know that poor layout invariably leads to information overload and poor readability.
My Question:
Are there any best-practices or heuristics for laying out a screen that contains many static fields?
Ordinarily, I would reference Bill Scott and Theresa Neil's excellent book, but I can't seem to find any guidance for this issue.
Here are some guidelines that I'm inclined to follow:
Group related fields.
Position the major (or parent) fields towards the top and the left. Position the minor (or child) fields towards the bottom and right.
Don't feel obliged to fill every pixel. Consider white space if it will improve readability.
Favor progressive disclosure wherever possible.
Consider an accordion control.
Perhaps a Details on Demand approach would work well. Ask yourself which data are absolutely and immediately relevant to the user and group those, while hiding the other data. You can always provide an 'Expand' link or control that would allow a user to view the details if desired.
(It's good to see that you're looking at interface design patterns. They are often overlooked!)
I work on HR software and have faced this problem many times. One thing that we keep seeing in feedback when we introduce collapse controls or any progressive disclosure pattern really is that our users don't like the way those types of "web 2.0" (their words lol) pages don't print out. So just a reminder if your user base still insists on printing large pages of data include a print media stylesheet.
Depending on how large your set of data is I'd seriously consider a some search functionality or a sorting mechanism. Many times when the data set is large different users have different priorities and allowing customization is the only way to satisfy a wide audience.
I think you pretty much answered your own question, especially the grouping of important fields tied to progressive disclosure.