What is the best way to transform data read from the database (recordset) to HTML using templates - html

I have some data in a database which i need to use to generate an HTML file.
The format of the HTML file will always be the same, i.e. it will always look something like this
-----------------------------------------
|
[Header] |
- Advertising banner |
|
[Body] |
|
---------------------------------- |
Content column | content column | |
Content column | content column | |
Content column | content column | |
---------------------------------- |
Content column | content column | |
Content column | content column | |
---------------------------------- |
|
[Footer] |
|
- Copyright information etc |
|
-----------------------------------------
The data i will be reading from the database table will be read using JDBC. I know i can generate the HTML file by manually coding the HTML source with the tags but im sure this is not the correct way of doing it.
Is there some sort of templating mechanism where i have a template for the HTML file which could probably have placeholders for the content sections which i can then update at run time after i have read the content from the database.
I thought that XSLT was specifically created for this purpose but looking at Google it looks like XSLT is for transorming XML to other formats which is not what i want. I could probably convert the data i read from the database into XML and use XSLT but this seems like an additional unessary layer of processing.
What is the usual/common way of approaching this kind of problem?
I would prefer to use Spring/Maven but open to other suggestions.
Thanks
Edit
Also, please note that the HTML file that is generated is not for displaying on the browser/web. It is displayed in an Email. A new HTML file will be generated everyday.

My suggestion would be to use XSLT - many DB can already produce results as XML, or you can write easily code to convert your SQL query results in simple XML:
<table>
<row>
<firstColumn>...</firstColumn>
<secondColumn>...</secondColumn>
. . .
<row>
. . .
</table>
Once you have this XML using XSLT you can generate any HTML - or many other formats - in a way that is standard, well-supported and very very flexible.

Related

How to render html code from database table in Tableau

I wanted to know if it is possible to use html and render in tableau.
I am pulling data from a database table which has below columns:
Country | HTML
US | <p> this is a paragraph</P>
UK | <table><tr><td>sample1</td></tr>
| <tr><td>sample2</td></tr></table>
IN | <ul>list1</ul><ul>list2<ul>
I want to render this HTML information in tableau
How I can do so?
I am using Tableau desktop currently and soon will switch to Tableau online.
Dont store html in your database.

Complex Mail Merge (CSV to Word, CSV to PDF, or Other)

QUESTION:
How do you write an ifStatement for Word or for PDF to calculate multiple rows per matching result?
USEAGE:
What I am trying to do seems fairly straight forward and was very easy when I was able to use MS Access 15 years ago, but with Access being not a possibility anymore, I am hoping somebody has a reasonable solution.
The WHAT:
I am trying to generate Statements/Invoices from a CSV (or spreadsheet of any format) into a nice report layout. Let's say the columns look like this:
First Name | Last Name | Account | Address | Item | Description | Item Total
Jane | Smith | 123 | 111 Main St | Ice Cream | it's really cold | $100.00
This is super easy and I can do in Word within 10 minutes and make it "pretty".
BUT what if there are multiple Items per invoice?
So maybe the CSV looks like:
First Name | Last Name | Account | Address | Item | Description | Item Total
Jane | Smith | 123 | 111 Main St | Ice Cream | it's really cold | $100.00
Jane | Smith | 123 | 111 Main St | Hot Dogs | all beef, all the time | $200.00
I still want there to only be 1 invoice per person but not sure how to do an if statement in Word that would say "If there are multiple items per person, put them on a new row, then total them all together"
I would be glad to have the CSV go into a PDF fillable form if I could get the multiple rows to work - I just cannot figure that portion out.
Other options: I looked at OpenOffice "Base" but couldn't get a nice form for a very custom Report. I researched briefly on how to do something like this on AWS, but without any luck. I don't think Microsoft has anything like Access anymore
You can use Word's Catalogue/Directory Mailmerge facility for this (the terminology depends on the Word version). To see how to do so with any mailmerge data source supported by Word, check out my Microsoft Word Catalogue/Directory Mailmerge Tutorial at:
http://www.msofficeforums.com/mail-merge/38721-microsoft-word-catalogue-directory-mailmerge-tutorial.html
or:
http://www.gmayor.com/Zips/Catalogue%20Mailmerge.zip
The tutorial covers everything from list creation to the insertion & calculation of values in multi-record tables in letters. Do read the tutorial before trying to use the mailmerge document included with it.
Depending on what you're trying to achieve, the field coding for this can be complex. However, since the tutorial document includes working field codes for all of its examples, most of the hard work has already been done for you - you should be able to do little more than copy/paste the relevant field codes into your own mailmerge main document, substitute/insert your own field names and adjust the formatting to get the results you desire. For some worked examples, see the attachments to the posts at:
http://www.msofficeforums.com/mail-merge/9180-mail-merge-duplicate-names-but-different-dollar.html#post23345
http://www.msofficeforums.com/mail-merge/11436-access-word-creating-list-multiple-records.html#post30327
Another option would be to use a DATABASE field in a normal ‘letter’ mailmerge main document and a macro to drive the process. An outline of this approach can be found at: http://answers.microsoft.com/en-us/office/forum/office_2010-word/many-to-one-email-merge-using-tables/8bce1798-fbe8-41f9-a121-1996c14dca5d
Conversely, if you're using a relational database or, Excel workbook with a separate table with just a single instance of each of the grouping criteria, a DATABASE field in a normal ‘letter’ mailmerge main document could be used without the need for a macro. An outline of this approach can be found at:
https://answers.microsoft.com/en-us/msoffice/forum/msoffice_word-mso_winother-mso_2010/mail-merge-to-a-word-table-on-a-single-page/4edb4654-27e0-47d2-bd5f-8642e46fa103
For a working example, see:
http://www.msofficeforums.com/mail-merge/37844-mail-merge-using-one-excel-file-multiple.html
The problem with the DATABASE field, though, is that it won't provide the totals you're after. Nevertheless, if you're going down the macro route, it wouldn't take too much more code to append a totals row to the resulting table.
Alternatively, you may want to try one of the Many-to-One Mail Merge add-ins, from:
Graham Mayor at http://www.gmayor.com/ManyToOne.htm; or
Doug Robbins at https://onedrive.live.com/?cid=5AEDCB43615E886B&id=5AEDCB43615E886B!566
PS: While I'm cognisant of StackOverflow's preference for the substance of answers to be posted here rather than linked to, the complexity in this case is far too great to deal with that way, besides which, one can't post the actual field codes or a document containing them here.

MySQL table structure suggestions?

Hey i'm currently working on a database project and simply can't think of a good way to save my data. The data being saved changes depending on what is being saved.
My current not-so-good table is:
User-ID | XLoc | YLoc | ZLoc | Data-ID | Data (String)
The data column is currently being saved as a string (serialized depending on object being saved) then unserialized. I understand serialization is a dumb idea when it comes to a proper database, but i haven't a clue on how else i could've done this.
I was thinking about assigning "sub" tables depending on the Data-ID then joining all the tables together on a search but i feel that wont be very efficient.
So my idea would play out like:
User-ID | XLoc | YLoc | ZLoc | Data-ID | Data-Index
Data-Index | SomeObjectRelatingData | SomeObjectRelatingData
Once again i just don't know how i'd put this all together so any help at all would be EXTREMELY helpful and i'm sorry if i was vague.
Example Data:
Particle-Name(string) | Material (int)
Time(long) | MeshType (int)
This data is currently serialized like so: Time:MeshType in string format. Once the data is retrieved from the database it's deserialized then changed back into it's formal type;
All the data needs to be accessed easily and they all share the User-ID, XLoc, YLoc, ZLoc.

Is it more performant to have rows or columns in sql?

If I have to save many strings that are related and that may be dividied in different languages: What's the best way to do it?
I think I have the following options. Option 1 and 3 is the most clear solution to me. They have more columns, but result in fewer rows.
Option 2 and 4 are the most flexible ones (I could dynamically add new string_x without changing the database). They have only three columns but they will result in many rows.
Option 5 would result in many tables.
Option 1:
id | string_1 | string_2 | string_3 | string_4 | ... | string_n | lang
Option 2 *(where name would be string_1 or string_2 etc.)*
id | name | lang
Option 3
id | string_1 | string_2 | string_3 | string_4 | ... | string_n
id | lang | stringid
Option 4
id | lang | stringid
id | name
Option 5
id | string_1 | lang
id | string_2 | lang
id | ... |lang
I'm using it to store precached html values for multiple views (one line view, two lines, long description, etc.), if this is of interest.
Option 1 and 3 are not recommended, as you end up with the language (which is data) in the field name. You have to change the database design if you want to add another language.
Option 5 is not recommended, as you end up with the string identifider (which is data) in the table name. You have to change the database design if you want to add another string.
Option 2 or 4 would work fine. Option 4 is more normalised, as you don't have duplicate string names, but option 2 might be easier to work with if you enter values directly into the table view.
Having many rows in a table is not a problem, that's what the database system is built for.
Although I've not had to specifically deal with multi-language interfaces, and if that is all its purpose is, is a translation, I would to option 1, but swapped, something like
id English French German Spanish, etc...
So you would basically have a master column (such as English) as a "primary" word that is always populated, then as available, the other language columns get filled in. This way, you can keep adding as many "words" as you need, and if they get populated across all the different languages, so be it... If not, you still have a "primary" value that could be used.
It depends on a lot of other things. First of all, how many strings could there be? How many languages could there be? To simplify things, let's say if either of those numbers are greater than 5, then options 1 and 3 are infeasible.
Before I go any further, you should definitely look into implementing multi-language functionality outside of the database. In PHP you can use Gettext and put your translation data in flat files. This is a better idea for multiple reasons, the main ones being performance and ease of use with external translators.
If you absolutely must do this in a database then you should use a table structure similar to this:
id | string | language
An example entry would be:
welcome_message | Hello, World! | english
Which I think you've described in Option 2. To clarify, depending on the amount of different languages and different strings, you should use a single table with a fixed number of fields.
If you support only a few languages, you might also consider a schema in which each language is its own column:
ID EN ES FR Etc...
This is less normalized than your option 4, but it is very easy to work with. We have built our database translations like this. As we develop code, we create string resources fill in the English text. Later, a translator fills in the strings of their language.

Hard-coding URLs vs Nested Set vs Combo in Content System

I've been putting together a database to handle content produced for a site, however, thinking about the long-term, I'm unsure if I have the best system.
At present I'm using the routing method of passing everything via index.php which .htaccess routes as follows index.php?route=example/url (user sees http://www.domain.com/example/url)
At present the database is setup like below:
uid | title | content | category
--------------------------------------------------
/ | Home | aaa | 1
/example | Example | bbb | 2
/example/url | Example: URL | ccc | 2
Though I am not sure if this is the best approach, especially if I wanted to rename example to something - I'd have to rename each URL...
So I've also thought about the Nested Set method (such as http://www.phpclasses.org/package/2547-PHP-Manipulate-database-records-in-hierarchical-trees.html) though this would just show lots of different numbers in the database where I could access everything by it's node. Example below;
node | left | right | name
--------------------------
1 | 1 | 6 | Home
2 | 2 | 5 | Example
3 | 3 | 4 | URL
Then I could use the node as the uid? But I'm unsure how I could translate http://www.domain.com/example/url to the uid equalling 3...
I already do have a category column in my database at the moment, to categorise the content, though I could potentially alter this.
I'm basically looking for suggestions about how to proceed, because as the site gets more content it will be harder to change the setup - so I want to ideally get this right from day one.
Which of the two is better for scalability?
If the second, how to translate the URL to the node?
Could I somehow combine both so that the original database stores the uid as the node number, then do a join of some sort to make the uid be a url (as in 1) - then ]
^ I think I'd prefer this (the third), but unsure how to do in MySQL exactly, with some other benefits:
I could replace my category system with the parent node - which may be better
I could also then in theory store the node ID within a stats system, rather than a URL
If anyone can give some help/suggestions - I'd be grateful!
Well, if you use index.php?route=example/url, you could always do something like this:
$args = explode( '/', $_GET['route'] );
$args = filter_var_array( $_GET['route'], FILTER_SANITIZE_STRING );
Then your values of $args would be:
0 -> example
1 -> url
etc. You could then use these values to determine what template to load, and what content to grab from the database, or whatever else you're doing already.
HTH.
The nested set model probably is a good choice here. That'd result in a table layout like (id,left,right are the fields required by the nested set model, the others contain the respective content):
| id | left | right | uid | title | content | category |
More details on how to perform a particular query can be found here.
However I would not perform the look up on the database but a simple array cache:
new array('/' => array('content' => 'aaa', 'category' => 'bbbb'),
'/example/' => array(),
.....
);
This cache can be build up very easy (though expensive) and queried very easy.
On a side note: i suspect you're trying to model page content here. Maybe you should refactor you database structure then as this table would have two responsibilities (url->content mapping and content).