Basically I'd like to extend this demo and turn text nodes into rows with multiple columns and equal (fixed) width. Sort of a classic table with indented rows.
The tree (unordered list) looks like this at the moment:
and I'd like to add some additional columns:
You will probably get more responses and of a better quality if you explain your requirements better. Expecting people to follow a link to find out what you are trying it to achieve is a little elf conceited to be honest. After all, people are offering their time and knowledge to you for free ad out of kindness. The least you can do is make it as easy as possible to help gou. By all means refer to the link, but only as an additional point of reference.
Just saying.....
Related
So I'm building a website that contains information about a bunch of different animal species. I will have a list of 500 items, that should be able to be filtered and sorted by different criteria. For example, I will have a 'country selection' option. If Brazil is selected, the Capuchin monkey among other animals (living in Brazil) should be added to the list.
I could see myself making a list with 50 species with no problem, as the HTML would be manageable. But would having 500 items in a list with filterabilty even be possible without using some sort of database?
I was thinking of just pairing animal items from the list with certain filter criteria. For example, Capuchin monkey with "Brazil", "Mammal", "Omnivore", etc.
And when e.g. "Mammal" is selected in the filter, all animals paired with that property (all mammals of the list) is added to the list, or if not paired with the property, then removed from the list.
As you probably can tell, I'm really uneducated on how to go about creating this filterable list. Down the road I might even look into adding a search function.
After pluggin in all content, I would never need to change anything. I've read that databases should only be used if you have dynamic content.
I wouldn't list all 500 items on the same page, as that would make it very slow. I would have 10 items per page.
I don't need a solution per se. I just wish to be pushed in the right direction.
Should I look into MySQL? Can a filterable list of 500 items be possible with just HTML/CSS/Javascript? I am somewhat familiar with javascript, and have read that JSON might be able to provide the things I need.
Sorry if my question is vague or if I'm in the wrong anywhere (this is my first post). Please ask for any clarification and any advice or suggestion is greatly appreciated.
Thanks,
Manne
No you don't need a database. Have a look at this very robust jQuery plugin that will easily allow you to sort/filter/search 500 items in JavaScript alone:
https://datatables.net/
There are examples that are powered from JSON alone so I would suggest you simply store your data in a JSON file until you grow large enough that you need to change that (if you ever do).
Here is an example where the data is pulled from a .txt file:
https://datatables.net/examples/data_sources/ajax.html
This is a question of how to perform the best practice of storing data from a webpage. Like texts/image-urls/links etc.
I have an CMS were you can create web pages. Here you can edit texts/upload images. In the future it would also be nice to "add new elements", add links to a-tags etc.
I need to have a robust and flexible solution that also have good performance. In both getting/recieving this data.
Lets consider I have 1000 pages with each around 25 elements on each page that can be updated and stored in the database.
Alternative 1)
Create a table and 1 column for each element on these pages for example columns like:
title_1, title_2,image_1,image_2.
Here we have a set of columns that we can update, these we can use on the web page.
Alternative 2)
Create 1 table with the columns (id, namespace, page_id, data)
And for each element on the page I add the namespace in association with the page_id to make the data output unique. In the data I can add any kind of information; text, links etc.
What do you suggest as a good solution for this issue? I'm ofcourse also open for other alternatives.
Thanks!
I would recommend option two, with the addition of a column identifying the element id/or type, if indeed the element id is somehow comparable. That is to say, if anchor text (say) is always stored as element id = 4, then you might want an element id = 4 so that you could compare anchor texts across multiple documents.
If, on the other hand (and this is the scenario I imagine is more likely), you may have 1-25 elements on a page and each of them could be different (eg document one has three anchor texts and four images, document two has one anchor text and no images, etc) it would make sense to add an element_type_id table that stores a bit of information about the element types. This is assuming that you ever have any interest in comparing (say) images across multiple documents, or anchor texts across multiple documents, etc.
Another thing to consider: if you are likely to see the same element over and over again, it actually makes more sense to effectively parameterize those elements by way of a lookup table. So basically store each (say) unique anchor text in one table and reference its id in your actual data table.
If I may add one additional thing: SO may not be the best place for the particular question you are asking. I'm not totally sure of that and maybe I'm wrong... but I would poke around the Stack Exchange network and see if other forums more closely deal with the type of question you asking. In the very least, I'd observe that your question is fairly vague and the goal of achieving a "robust and flexible solution that also {has} good performance. In both getting/recieving this data." is not likely to be accomplished simply by asking for advice on SO. There is a LOT that goes into data architecture, and certainly many of the details I would consider important in designing this myself are not present in your questions. And if you're not sure what those details are, I am not sure if SO is really the best place to set about learning them. I think https://softwareengineering.stackexchange.com/ may be a better fit for this question.
Just my opinion, and I could be wrong. Either way, I would consider learning a bit about database normal forms (http://www.bkent.net/Doc/simple5.htm or Google it) as well as do a little research on the types of design considerations that go into building a database (an old but still good SO article on that is here: What are the most important considerations when designing a database?)
basically I have a table of keywords and posts I want tagged with attributes on the display. like I want to draw a green border if #green# is present in the post. Is there a clean way for the DB to do this internally? I am prepared to do it all in C++ by fetching the entire table of keywords and throwing it in a trie and scanning each word, but this approach seems a bit inelegant.
You are mixing storage and display concerns. There be dragons. You are looking for content like '%#green#%'. It would be better to set a bit column or some other flag as the content was inserted or updated from the application side. When reading, retrieve this information along with the content. Let your display logic do the colouring.
Take a look at "separation of concerns" (SoC) as part of the S.O.L.I.D. practices.
Hope this helps.
I have a group of emails (I hesitate to use the word list, as it may prejudice you answers), which I want to display in a tabular manner with columns of Subject, Content, Date, Action (whose value may contain a Delete button, for example).
Semantically speaking, would you use a list (<dl>, probably) or a <table> for this data? My gut feeling is that a list is most appropriate: I would describe the page as a list of emails after all - not a table of emails; furthermore, I would not put this data in a spreadsheet or perform any analysis on it. However, the fact that I want column headings makes me wonder if a <table> is more approprate.
I doubt that the design would ever be non-tabular; however, it is possible that certain columns may be restyled.
I’d go for the table. If it had just one column, I’d use the list, but—to me, at least—this is clearly tabular data, since all “rows” share the same “columns”.
(Thinking of it: if your example did not qualify for the use of a table, what else would?)
Don't worry about styling. You can use CSS to make a list look like a typical table, or a table look like a typical list. Aside from that, it's up to you. To me, especially as there are very few 'column'-like data pieces, a definition list seems more semantically and practically correct for this situation.
<table> all the way. You can put what you like in the <div> in the cell. Works for gmail (at least, for their basic html view).
I'm not sure one is better than the other, personally, I would use tables.
GMail uses a table. I wouldn't say they don't care about semantics.
You have an information that needs to be displayed in two dimensions (rows,columns), with each dimension describing something about the data (i.e. data number (row) and info (col)).
It sounds like a table to me, and also sounds like it would be better treated as such from an accessibility persective! Think of screen readers that may going to have to read the info.
I converted my company's calendar to XSL and changed all the tables to divs. It worked pretty well, but I had a lot of 8 day week bugs to work out initially owing to precarious cross-browser spacing issues. But I was reading another post regarding when to use tables v. divs and the consensus seemed to be that you should only use divs for true divisions between parts of the webpage, and only use tables for tabular data.
I'm not sure I could even have used tables with XSL but I wanted to follow up that discussion of Divs and Tables with a discussion of the ideal way to make a web calendars and maybe a union of the two.
A calendar is the perfect reason to use a table! Calendars inherently present tabular data and HTML tables are good at presenting tabular data. And HTML table markup provides nearly all the CSS hooks you need to associate CSS selectors with various parts of the table to dress it up.
I'm all for using DIVs for layout--but stick with tables for tabular data.
Here is a cool article on how to dress up tables with CSS:
http://www.smashingmagazine.com/2008/08/13/top-10-css-table-designs
I would say that a calendar is a table, therefore making the table the proper markup for its representation.
Edit: Definition 11 for "table" from answers.com says:
An orderly arrangement of data, especially one in which the data are arranged in columns and rows in an essentially rectangular form.
I think this is definitely a case for using tables. The biggest issue when using divs would be box height for each individual day. If you're styling each box with a border, they could look off if the content for one day is longer than another. The additional markup to make it look right would be more than it would take to create it with a table, so I don't think divs are worth the extra effort in this case.
It makes sense to use tables, but if you were to look at Google Calender, they seem to be using div tags. It is possible that using div tags lowers the file size, so in an enterprise environment it might be worth the 'trouble'.
Do it up in a table.
Also don't think of it as "divs vs. tables" Think of it as tables vs. a proper semantic tag with meaning. When I author pages I try to use divs as little as possible, in a lot of cases you could be using a paragraph, a list item, etc.
You might also consider an ordered list (weeks) of ordered lists (days), or simply one ordered list (days).
There are others who agree that the list approach is a good one.
Others prefer tables.
Just came across this thread after posing the same question elsewhere. While I completely agree a calendar is more of a tabular representation of data, I think there's truth in the prolific "it depends" answers. For example, I want to show a floating DIV popup when each day in the calendar is moused over. Using a table, the popup flickers as the cursor moves across the calendar since the popup is only active on the cell border and the day number in the cell itself. Using DIVs, the popup is solid (no flicker) the entire time the cursor mouses over the calendar cell.
Tables are for displaying tabular data. So I would say <table> is ideal.