In my case, there are three languages for my site. In backoffice, Product management, I have only one textarea to product description. Obviously, one description in english is not suitable to my chinese and franch site. So i add three columns in Entity product
description_en, description_fr, description_cn
than I do description_%local% to show them in View twig.
Is there another solution to do this ? thank you very much for sharing your opinion.
Yes, you can use doctrine translatable extension. Take a look at this PR as an example https://github.com/Sylius/Sylius/pull/110
Related
We like to use HTML5 microdata in a website. But we are kind of puzzled how to apply the brand to our products. According to http://schema.org/Product, the brand is an Organization.
An example: If the iPhone is a brand of Apple Inc, how do I apply this to a iPhone 3GS product page?
Edit: I saw several examples providing a simple String as the brand, e.g. http://www.affiliatetuts.com/general/adding-microdata-to-your-markup/. Is that valid?
i markedup an example for you here: http://jsfiddle.net/jalbertbowdenii/GVuUw/ passed validation here: http://validator.nu/ and i got the information from: http://store.apple.com/us/product/MC555
On the ability to include strings instead of full inline descriptions, see http://schema.org/docs/datamodel.html
"While we would like all the markup we get to follow the schema, in practice, we expect a lot of data that does not. We expect schema.org properties to be used with new types. We also expect that often, where we expect a property value of type Person, Place, Organization or some other subClassOf Thing, we will get a text string. In the spirit of "some data is better than none", we will accept this markup and do the best we can."
i'm trying to figure out the best way to do shopping cart for bicycle components. the problem that i'm encountering is that i can't just add all the components to the same model because they each have different specs (i.e. a chainring has a column for "number_of_teeth" while a fork has a column for "crown_diameter").
right now i have a table for each component but that makes it difficult to look up information for that item in that i need to have each component listed in the controller which seems redundant. am i better off just making a components model and having a "type" column then adding a "specs" column that will connect to another table, say chainring_specs, that will have all of that information?
i want to get this set up the best way possible. thank you.
Yes, in my opinion, creating a more generic components model will give your web app a lot more flexibility. I'm assuming that you'll have a database feeding this shopping cart.
Your model(s) will be shaped by the type of back-end schema that you use. A one table schema that can support all of your components will allow you to handle skus, pricing, etc. in one place. Depending on the type of complexity that you face, you might want to have the description and specs in separate tables.
Hope this helps!
As described at playframework - search module, I've installed the search-module. Of course my model consists of multiple classes. I'd now like to search for entries whose attributes consist of several tables, i.e. i'd like to search for users who have bought an article that costs more than say 500$ whereas there would be a table for customers, one for orders and one for articles.
Does anyone know how to realize this using the playframework's lucene-query-language?
thanks a lot!
The query language isn't specific to Play! You can learn about the syntax from the official Lucene documentation: http://lucene.apache.org/java/2_0_0/queryparsersyntax.html
Thx for your time!
I am currenly using sh404SEF, and it has "Title and Metas" manager. This is pretty much what I need, the only problem is that if URLs are purged so are title and Metas and it does not have place for keywords. Here is screen shot of what it looks like http://img412.imageshack.us/img412/5624/sh404titlemetasmanager.jpg
I am looking for a administrative component that will allow me to manage all the article keywords and descriptions in one place for multiple articles at a time. The components needs to update the keywords and description for the actual articles in [#__content] table, and not an overload plug-in. I looked through extensions directory, did not find what I was looking for.
You could try looking at Scribe - http://scribeseo.com/
It's paid for but pretty good for SEO/meta etc.
Basically, the below image represents the components on the homepage of a site I'm working on, which will have news components all over the place. The sql snippets envision how I think they should work, I would really appreciate some business logic advice from people who've worked with news sites before though. Here's how I envision it:
Question #1: Does the sql logic make sense? Are there any caveats/flaws that you can see?
My schema would be something like:
articles:
article_id int unsigned not null primary key,
article_permalink varchar(100),
article_name varchar(100),
article_snippet text,
article_full text
article_type tinyint(3) default 1
I would store all articles ( main featured, sub-featured, the rest ) in one table, I would categorize them by a type column, which would correspond to a number in my news_types table ( for the example I used literal text as it's easier to understand ).
Question #1.1: Is it alright to rely on one table for different types of articles?
A news article can have 3 image types:
1x original image size, which would show up only on the article's permalink page
1x main featured image, which would show up on the homepage section #1
1x sub featured image, which would show up in the homepage section #2
For now I want each article to correspond to one image and not multiple. A user can post images for the article in the article_full TEXT column though.
Question #1.2: I'm not sure how I should incorporate the article images into my schema, is it common for a schema that relies on 2 tables like this?
article_image_links:
article_id article_image_id
1 1
article_images:
article_image_id article_image_url
1 media.site.com/articles/blah.jpg
Requirements for the data:
From the way I have my sql logic, there has to be some data in order for stuff to show up..
there has to be at least one main type article
there has to be at least four featured type articles which are below the main one
Question #1.3: Should I bother creating special cases for if data is missing? For example, if there's no main featured article, should I select the latest featured, or should I make it a requirement that someone always specify a main article?
Question #1.4: In the admin, when a user goes to post, by default I'll have a dropdown which specifies the article type, normal will be pre-selected and it will have the option for main and featured. So if a user at one point decides to change the article type, he/she can do that.
Question #1.5: The way my featured and main articles work is only by the latest date. If the user wants, for example, to specify an older article for whatever reason as the main article, should I create custom logic, or just tell them to update the article date so it's later than the latest?
In regard to the question in the title there is definitely more than one way to skin a cat. What's right for one site may not be right for another. Some things that could factor into your decision are how large the site needs to be scaled (eg are there going to be dozens of articles or millions?) and who will be entering the data (eg how much idiot-proofness do you need to build in). I'll try to answer the questions as best I can based on the information you gave.
Question # 1: Yes, looks fine to me. Be sure to set your indexes (I'd put indexes on [type,date] and [category,type,date]).
Question #1.1: Yes, I would say that is alright, in fact, I would say it is preferred. If I understand the question correctly (that this is as opposed to a table for each "type") then this sets you up better for adding new types in the future if you want to.
Question #1.2: If you only want one image for each story and one story for each image I'm not seeing the advantage of splitting that up into an extra table. It seems like it's just more overhead. But I could be missing something here.
Question #1.3: That's a design decision up to you, there's no "right" answer here. It all depends on your intended uses of the system.