I need to create pages on my (planned) website that each consist of multiple, independent entries records. (It's a famous quotes website - each page covers a specific topic, with multiple quotes and their authors listed for that topic.)
Is it straightforward with Django-CMS to implement this, with each quote/author being a separate database record (I need for them to be acted upon as individual entities, for purposes like voting). I'm thinking of using Django-CMS because of its categorization capabilities, built-in slug support, and because I'm merging in a Wordpress blog to the mix as well.
This is absolutely possible and there's two approaches to it:
1) Write an Apphook [1] that manages those pages and displays the quotes from the database.
2) Write a Plugin [2] that displays a single (or multiple) quotes and add one or more of those plugins to the pages.
If you're not sure which one to choose, I recommend reading http://ojii.ch/post/apphooks-vs-plugins/
[1] http://docs.django-cms.org/en/2.4.0/extending_cms/app_integration.html
[2] http://docs.django-cms.org/en/2.4.0/extending_cms/custom_plugins.html
Related
Just started using Drupal and tried to understand the core concepts. I have a developer background but I would like to use Drupal as a site builder and not digging into the code.
I'm trying to build a website which lists various vendors. One could be a Restaurant, another can be Photographer and other possible services (I have like 15 different ones).
They all have some things in common like Title, a Location (used Taxonomy/Vocabulary for that), description, image gallery, address, website, office hours and so on.
But they also have some custom fields. Restaurants can have fields like Facility options:Parking, Smoking area, etc or Capacity; Photographers can have others.
So there are lots of fields which are common for each vendor and some are are unique per each vendor.
What's the best way to implement this kind of structure as a Site builder?
I tried using Entities via ECK (Entity Construction Kit) and defining Entity types (as Vendor) and Bundles (as specific Vendors) but then I'm really limited in defining the common fields on Entity type level since Properties does not seem to be flexible in this regard, meaning that I cannot define them as normal fields and can't associate to them various widgets but only as a text input. Not sure if this a limitation of ECK or of Drupal 7 itself?
On the other hand I see the option of creating normal Content types for each kind of vendor which seems like alot of repetitive work, not sure if this is the right way (that's my only option at the moment)?
Maybe I should start learning more of Drupal and do some coding to create specific entity types? - but this means being more than a site builder. Since it will be a big project will this save me of some trouble later on or you see that I can accomplish the task easily without this extra effort?
Also by coding I'm not sure if there are easy ways of defining fields/widgets for Entity type Properties.
I would later on want to use faceting as well for filtering which will be based both on the fields which are common and unique for each vendor type, not sure if this is an important factor when creating the structure.
Any feedback is appreciated!
I have setup a Solr server, now, I have two sites that I want to index and search using SolrNet.
How do I differentiate the two sites' content in Solr?
You may want to take a look at this document: http://wiki.apache.org/solr/MultipleIndexes
I think the best approach is to use Multiple Solr Cores.
Another option is you can simply add a new field that indicates the item's Web site. For example, you can add a field called type.
Searches on website1.com would require you to filter on the type field.
&fq=type:website1.com
That way you only need to deal with one core and one schema.xml file. This works if the pages of both sites have a very similar field set, and it will make it easier to search across both sites if you plan on doing that.
http://wiki.apache.org/solr/MultipleIndexes#Flattening_Data_Into_a_Single_Index
I'm in a situation where I think I need to create my own custom search module. What I'm trying to do is make a page with a list of all my nodes in the node type - let's call it 'Beer'. So I want to be able to filter through the beers in a fashion similar to the one you find on the Apple Trailers page ( http://trailers.apple.com/ ).
I tried using Views 2 but ran it to a few problems:
I can't make the filter links like in the top of the trailers page (exclusive, just HD etc.)
The search function will only search one field (Exposed field "Beer title" but I also want it to search for manufacturer and other things.
I'm aware of a couple of solutions:
I could fix the last problem by using the Computed Field Module where I could combine the fields I want to search through. I just don't see this as a very elegant solution.
I could make my own module and create my own database queries where I apply the relevant filters (I just don't know how).
I could somehow use my already installed Solr module.
So the first solution - the easiest I guess but also kind of bad with duplicate content in my database.
The second solution - the best (maybe) - problem: I'm too dumb.
The third solution - Solr seems pretty cool but would I be able to present my beer nodes with just the title and a picture?
So I guess my question is. Which one of the three would you use? Or what other solutions could I potentially use (I'm confident there are things I haven't thought of :))?
Sounds like this could be a good use for Taxonomy not different node types. Also, Have you considered http://drupal.org/project/quicktabs ?
You could set up each "filter" as a tab that passes an argument down to a view. Then don't expose any views filters to the user.
Is tagging is the best user friendly way to categorize a subject? An example would be the tags mechanism used in this Q/A site. (StackOverflow.com). How you would Implement categories in a best user friendly way? Or hierarchical categories are the best user friendly way to present available categories?
Is there any online store use tag to categorize product categories?
What you want depends on the nature of the media being categorized.
If you're working primarily with media that is difficult to index, like images, audio, or video, then you want a loose tagging system that encourages putting as many tags as possible with each item. The more tags the merrier, because you will need to use the tags to help index the content for searching.
For something that is more easily indexed (text!), you want a much more rigid system where it may take an extra step or two to create new categories or even force users choose from pre-defined categories. You no longer need to rely on user-supplied tags for search indexing, because you can index the content directly. You are strictly doing categorization, and for categorization to have meaning you need to be sure that users are sorting things into the same categories.
Whether or not a hierarchy or tree structure is appropriate depends on how well your categories fit into a tree structure. Some things fit better than others, and many things that appear to fit a tree structure (like programming topics) turn out not to be such a good fit after all.
I say yes!
Tagging provides a many to many relationship between questions and categories. It makes them loosely coupled and so gives control as well as flexibility for categorizing things.
Tagging has the advantage that a single post can belong to more than one category. This is not possible with (conventional) hierarchical structures. Tagging is a more powerful system than hierarchical categorizing - and so it allows the users to express more.
A hierarchical structure works better if you have a single editor who will spend the time to neatly categorize everything so that a menu structure can be created.
I think tagging works well when things can/need not be strictly categorized or require a hierarchy. It's kind of a non-relational way of relating things.
If works, tags should be controlled or filtered (e.g. crystalreports vs crystal-reports).
Retiring duplicate tags & migrating subject to a proper category will require human intervention.
I don't know of any store that use tagging. Static attributes can be categorized (Electronics -> Camera -> SLR). There could be other attributes, which are dynamic (price range between x and y) & those are not tagged.
Amazon has tags as well. I think, its search option has one choice where it says "get products tagged with" & gives you a box to put in your idea of what a tag could be (which shows you a dropdown of tags, it finds matching - same as stackoverflow).
Tagging can be very useful in every case. For example, gmail applies tags to all emails. Tags could be predefined (with a fixed meaning), or user generated. Having those predefined tags is important as they work like categories, can be controlled by the store owners, and still don't force you to use a hierarchy. You can emulate a category system with tags by enforcing some specific rules on the type of allowable tags, but you can't go the other way round with hierarchical categories.
So, for example, to find all incoming emails on gmail, we can search by the inbox tag.
tag:inbox
Or to get all unread emails in the inbox, we can search by two tags:
tag:inbox && tag:unread
It's much better than trying to categorize in possibly this fashion, for example:
/Inbox
/Inbox/Unread
/Inbox/Spam
Not that anyone cares about spam (the actual ones), but spam can be unread too. So should we introduce another sub-category called Unread inside Spam, or do some other restructuring within Inbox itself?
/Inbox/Spam/Unread
Another store-specific example could be to find all SLR cameras on Amazon that uses compact flash for storage, and supports RAW, and JPEG formats, we could theoretically use:
tag:camera && tag:SLR && tag:Compact-Flash && tag:RAW-format && tag:JPEG-format
Categorization forces you to choose a hierarchy which might mean you have to pick one between two or more perfectly reasonable choices. For example, is an iPod Touch a music player, or a video player, or maybe a portable computer, or all of it?
its depend on the context, if you want to make structure clear and controllable you should force it by your pre-defined category, but if you want to make it flexible and make easier for your user tag is the best technique to manage subject, furthermore it makes search engine easier to analyse and provides better results
so my answer if you asking for user friendliness it would be tags.
How should I store (and present) the text on a website intended for worldwide use, with several languages? The content is mostly in the form of 500+ word articles, although I will need to translate tiny snippets of text on each page too (such as "print this article" or "back to menu").
I know there are several CMS packages that handle multiple languages, but I have to integrate with our existing ASP systems too, so I am ignoring such solutions.
One concern I have is that Google should be able to find the pages, even for foreign users. I am less concerned about issues with processing dates and currencies.
I worry that, left to my own devices, I will invent a way of doing this which work, but eventually lead to disaster! I want to know what professional solutions you have actually used on real projects, not untried ideas! Thanks very much.
I looked at RESX files, but felt they were unsuitable for all but the most trivial translation solutions (I will elaborate if anyone wants to know).
Google will help me with translating the text, but not storing/presenting it.
Has anyone worked on a multi-language project that relied on their own code for presentation?
Any thoughts on serving up content in the following ways, and which is best?
http://www.website.com/text/view.asp?id=12345&lang=fr
http://www.website.com/text/12345/bonjour_mes_amis.htm
http://fr.website.com/text/12345
(these are not real URLs, i was just showing examples)
Firstly put all code for all languages under one domain - it will help your google-rank.
We have a fully multi-lingual system, with localisations stored in a database but cached with the web application.
Wherever we want a localisation to appear we use:
<%$ Resources: LanguageProvider, Path/To/Localisation %>
Then in our web.config:
<globalization resourceProviderFactoryType="FactoryClassName, AssemblyName"/>
FactoryClassName then implements ResourceProviderFactory to provide the actual dynamic functionality. Localisations are stored in the DB with a string key "Path/To/Localisation"
It is important to cache the localised values - you don't want to have lots of DB lookups on each page, and we cache thousands of localised strings with no performance issues.
Use the user's current browser localisation to choose what language to serve up.
You might want to check GNU Gettext project out - at least something to start with.
Edited to add info about projects:
I've worked on several multilingual projects using Gettext technology in different technologies, including C++/MFC and J2EE/JSP, and it worked all fine. However, you need to write/find your own code to display the localized data of course.
If you are using .Net, I would recommend going with one or more resource files (.resx). There is plenty of documentation on this on MSDN.
As with most general programming questions, it depends on your needs.
For static text, I would use RESX files. For me, as .Net programmer, they are easy to use and the .Net Framework has good support for them.
For any dynamic text, I tend to store such information in the database, especially if the site maintainer is going to be a non-developer. In the past I've used two approaches, adding a language column and creating different entries for the different languages or creating a separate table to store the language specific text.
The table for the first approach might look something like this:
Article Id | Language Id | Language Specific Article Text | Created By | Created Date
This works for situations where you can create different entries for a given article and you don't need to keep any data associated with these different entries in sync (such as an Updated timestamp).
The other approach is to have two separate tables, one for non-language specific text (id, created date, created user, updated date, etc) and another table containing the language specific text. So the tables might look something like this:
First Table: Article Id | Created By | Created Date | Updated By | Updated Date
Second Table: Article Id | Language Id | Language Specific Article Text
For me, the question comes down to updating the non-language dependent data. If you are updating that data then I would lean towards the second approach, otherwise I would go with the first approach as I view that as simpler (can't forget the KISS principle).
If you're just worried about the article content being translated, and do not need a fully integrated option, I have used google translation in the past and it works great on a smaller scale.
Wonderful question.
I solved this problem for the website I made (link in my profile) with a homemade Python 3 script that translates the general template on the fly and inserts a specific content page from a language requested (or guessed by Apache from Accept-Language).
It was fun since I got to learn Python and write my own mini-library for creating content pages. One downside was that our hosting didn't have Python 3, but I made my script generate static HTML (the original one was examining User-agent) and then upload it to server. That works so far and making a new language version of the site is now a breeze :)
The biggest downside of this method is that it is time-consuming to write things from scratch. So if you want, drop me line and I'll help you use my script :)
As for the URL format, I use site.com/content/example.fr since this allows Apache to perform language negotiation in case somebody asks for /content/example and has a browser tell that it likes French language. When you do this Apache also adds .html or whatever as a bonus.
So when a request is for example and I have files
example.fr
example.en
example.vi
Apache will automatically proceed with example.vi for a person with Vietnamese-configured browser or example.en for a person with German-configured browser. Pretty useful.