My project is re engineering a an HTML data grid constructing using
SQL query generated XML and XSL into an HTML table.
The content of the table is not known at deployment as the SQL used to
build the XML data is generated by the application at runtime.
Given the distaste for tables in the CSS world I am hoping someone has
a better suggestions for what the HTML should look like and what
resources might be helpful dealing with the dynamic nature of domain.
The distaste most web developers have is not for tables themselves, but their misuse - people often utilize tables for content/element positioning on a web page, which is a "no no." But no one said there's anything wrong with using tables for display of tabular data - that's what HTML tables were intended for.
So the answer depends on how the data coming from your DB is structured.
.
Use tables for something like this:
Orders:
--------------------------------------------------------
| Order ID | Product Name | Order Date | Ordered By |
--------------------------------------------------------
| 1 | blah blah | 1/1/2009 | Jane Doe |
| 2 | blah blah | 1/1/2009 | Jane Doe |
| 3 | blah blah | 1/1/2009 | Jane Doe |
.
Don't use a table for something like this:
"Hello, Jane Doe.
Your order (#2), which was received on 1/1/2009, is being processed. Sorry for the delay.
- Your friends at ABC Store"
Building on fallen888's answer, you can really do a lot with tables to structure data in HTML. A few good things I can recommend are:
Use <thead>, <tbody>, and <th> elements. Don't just make a row of "bold" <td>s.
Use the <caption> element.
Use the scope attribute to associate headers with rows or columns.
Veerle's blog has two excellent tutorials on the subject:
A CSS styled table
A CSS styled table version 2
Related
I am creating test cases on forms that could contains over 50 parameters, some of them would show up when a certain set of questions would be answered specifically.
The data tables were getting very long so I broke them into multiple data tables, each for a specific section of form.
I don't want to add every heading in the step so I want to use the data table's name instead.
Instead of:
Scenario:
.
.
.
When I fill in <title> <first name> <surname> ...
|title|first name|surname|...|
.
.
.
I want:
When I fill in <personal details>
And "personal details":
|title|first name|surname|...|
.
.
.
Is it possible to add and use the data table's name as the placeholder?
Note: I am working with Behave and Python.
It's definitely not possible using the <> syntax.
If you don't have many rows and your main concern is the readability of very wide tables then one option might be "transposing" the table like this:
When I fill in the personal details
| Field | Value |
| Title | Prof. |
| Surname | Einstein |
| ... | |
An other option could be to define the recurring set of properties in the Background like this:
Background:
Given the personal details for 'minimal personal details'
| Surname | First name |
| Doe | John |
And the personal details for 'insufficient personal details'
| First name |
| Jack |
And the personal details for 'all personal details'
...
...
When I fill in personal details using 'insufficient personal details'
The bindings of the background register their data in the context and the 'when' binding uses the data from the context.
In either case, you'll need a binding that will tolerate missing properties and catch unknown ones.
Am not sure about what you are asking but if you are using the same details in different scenarios then it is better to use Background option of Cucumber. So that it will be checked before executing every scenario.
Tables in Gherkin are a view on the real data (meaning a subset of columns and which rows are of interest). For readability reasons (and that somebody understands what you are doing), you should have at most 7 (plus/minus 2) columns. Maybe, the remaining data can be injected from configuration-files or config-profile database ?!? You basically use the provided Table columns as keys to be able select the configuration-row and to retrieve the remaining data from your configuration-profiles.
In the Translatable behaviour of the Gedmo Doctrine Extensions, it has instructions on "Personal Translations". Could someone clarify what personal translations are?
tl;dr
Personal translations are used when you want to handle the translation entity (with it's own table by yourself) instead of the default behaviour, by using a single table for all translations.
By using the default behaviour, you get a single table called ext_translations which holds all of your translation data. I'll give you an example based on the documentation of DoctrineExtensions.
Let's say we create an Article entity with 2 translatable fields - title and content. That would mean that we should have the following table structure of articles:
+----+-------+---------+
| id | title | content |
+----+-------+---------+
Now, by default the TranslatableListener sets en_us locale every time you create new entity, thus populating only articles table:
$article = new Article();
$article->setTitle('Title english');
$article->setContent('Content english');
Would lead to the following:
+----+---------------+-----------------+
| id | title | content |
+----+---------------+-----------------+
| 1 | Title english | Content english |
+----+---------------+-----------------+
By now, only articles get to be updated with new records, but when you want to translate those fields with different locale, our common table ext_translations get updated as well.
The table has the following structure:
+----+--------+---------------+---------+-------------+------------+
| id | locale | object_class | field | foreign_key | content |
+----+--------+---------------+---------+-------------+------------+
So, what happens when we update our record with some new translations:
$article->setTitle('My title');
$article->setContent('My content');
$article->setTranslatableLocale('de_de');
When we persist our updated entity, we get the following structure in ext_translations:
+----+--------+---------------+---------+-------------+------------+
| id | locale | object_class | field | foreign_key | content |
+----+--------+---------------+---------+-------------+------------+
| 1 | de_de | Bundle\Entity | title | 1 | My title |
| 2 | de_de | Bundle\Entity | content | 1 | My content |
+----+--------+---------------+---------+-------------+------------+
Now you know how the default behaviour works. It stores all of your translations (not just for single entity, all of them) in a single table.
But when you're using a personal translations you can store your (let's say for the sake of our example) Article translations to its own, separate table, article_translations.
If you are familiar with DoctrineExtensions provided by KnpLabs, then you've already seen what stands for PersonalTranslations. Link for their documentation about this subject can be found here.
Well hopes this can clarify things a bit for you. Let me know if you have more questions about this.
I am almost there with this but cannot seem to get this functionality going as planned.
I am creating a questionnaire using drupal content type. What I am trying to do is to create a table like structure as below in content type. The second and third column contain check boxes and first column data(i.e computer, internet) and first row(i.e Everyone have access , Nobody have access) are taxonomy terms . Is it possible to display like this in content type by using some modules in drupal? Anybody have any better suggestions?
| | Everyone have access | Nobody have access |
---------------------------------------------------------
| Computers | 1 | 2 |
---------------------------------------------------------
| Internet | 1 | 2 |
---------------------------------------------------------
| Fax | 1 | 2 |
---------------------------------------------------------
You can use the Term Level Field module. This module provides a field type for referencing terms with a level to an entity.
You may use Editable fields with Views module. Of course, if you didn't need such a display (table forms) you should use Views Bulk Operations modules.
If you need to do this in a node use Tableform module. But if you want to show nodes whike editing a node it is the same. A node should not be used for tasks just for content.
I have information from a database. It is one row. Now, it is old, and tables were used to display the data. It works but is ugly and hard to maintain. I'm "fixing" it. But, I don't know if it is considered tabular or not. It comes from database tables, but I don't know that what it means to be semantically correct in using a table for display.
I have several sections like this on a webpages. They are all calls to the same database, different sets of data, sectioned off in the webpage.
For example, one set is a general set of information, lastname, firstname, middle, other stats...
Next section might be address, etc.
A while back when I did asp.net forms there was a list view, I think that was similar to what I need to create (I'm using just straight html and a scripting language, no controls).
How should I be displaying the information to be semantically correct?
edit: It is one person that does not repeat.
edit: A single record, but displayed on the same page, just various SELECT statements to get that data all on the same page.
If it's tabular data (i.e. multiple records displayed underneath each other) then a <table> would probably be the best choice. If it's a view of a single record, maybe even aggregating data from multiple tables then the <table> shouldn't be your first choice.
Tabular data:
--------------------------------
| ID | Name | Description | Date |
--------------------------------
| 01 | ... | ... | ... |
| 02 | ... | ... | ... |
Not tabular data:
ID: ...
Name: ...
Description: .................
.................
.....
Date: ....
I have an ASP.Net website which uses a MySQL database for the back end. The website is an English e-commerce system, and we are looking at the possibility of translating it into about five other languages (French, Spanish etc). We will be getting human translators to perform the translation - we've looked at automated services but these aren't good enough.
The static text on the site (e.g. headings, buttons etc) can easily be served up in multiple languages via .Net's built in localization features (resx files etc).
The thing that I'm not so sure about it how best to store and retrieve the multi-language content in the database. For example, there is a products table that includes these fields...
productId (int)
categoryId (int)
title (varchar)
summary (varchar)
description (text)
features (text)
The title, summary, description and features text would need to be available in all the different languages.
Here are the two options that I've come up with...
Create additional field for each language
For example we could have titleEn, titleFr, titleEs etc for all the languages, and repeat this for all text columns. We would then adapt our code to use the appropriate field depending on the language selected. This feels a bit hacky, and also would lead to some very large tables. Also, if we wanted to add additional languages in the future it would be time consuming to add even more columns.
Use a lookup table
We could create a new table with the following format...
textId | languageId | content
-------------------------------
10 | EN | Car
10 | FR | Voiture
10 | ES | Coche
11 | EN | Bike
11 | FR | VĂ©lo
We'd then adapt our products table to reference the appropriate textId for the title, summary, description and features instead of having the text stored in the product table. This seems much more elegant, but I can't think of a simple way of getting this data out of the database and onto the page without using complex SQL statements. Of course adding new languages in the future would be very simple compared to the previous option.
I'd be very grateful for any suggestions about the best way to achieve this! Is there any "best practice" guidance out there? Has anyone done this before?
In your case, I would recommend using two tables:
Product
-------------------------------
ProductID | Price | Stock
-------------------------------
10 | 10 | 15
ProductLoc
-----------------------------------------------
ProductID | Lang | Name | Description
-----------------------------------------------
10 | EN | Bike | Excellent Bike
10 | ES | Bicicleta | Excelente bici
This way you can use:
SELECT * FROM
Product LEFT JOIN ProductLoc ON Product.ProductID = ProductLoc.ProductID
AND ProductLoc.Lang = #CurrentLang
(Left join just in case there is no record for the current lang in the ProductLoc table)
It's not good idea just to add new columns to existing table. It will be really hard to add a new language in the feature. The lookup table is much more better but I think you can have problem with performance because number of translated records.
I think best solution is to have a shared table:
products: id, categoryid,
and same tables for every language
products_en, products_de: product_id (fk), title, price, description, ...
You will just select from the shared one and join table with your language. The advantage is that you can localize even the price, category, ...