If this title is ambiguous, feel free to change it, I don't know how to put this in a one-liner.

Let's assume you have a html template which contains some custom tags, like <text_field />. We now create a page based on a template containing more of those custom tags. When a user wants to edit the page, he sees a text field. he can input things and save it.

This looks fairly easy to set up. You either have something like a template_positions table which stores the content of those fields.

I now have a bit of a blockade keeping things as simple as possible. Assume you have the same tag given in your example, and additionally, <layout> and <repeat> tags. Here's an example how they should be used:

  <layout name="image-left">
    <image /> <text_field />

  <layout name="image-right">
    <text_field /> <image />

We now have a block which can be repeated, obviously. This means: when creting/editing a page containing such a template block, I can choose between a layout image-left and image-right which then gets inserted as content element (where content for <image /> and <text_field /> gets stored). And because this is inside a <repeat>, content elements from the given layouts can be inserted multiple times.

How do you store this? Simply said, this could be stored with the same setup I've wrote in the example above, I just need to add a parent_id or something similiar to maintain a hierarchy. but I think I am missing something. At least the relation between an inserted content element and the origin/insertion point is missing. And what happens when I update the template file?

Do I have to give every custom tag that acts as editable part of a template an identifier that matches an identifier in the template to substitue them correctly?

Or can you think of a clean solution that might be better?

  • 1
    +1 I suggest your rename your post as storing hierarchical template into a database, if I understand well. And getting rid of the tags application-design and how-to, they are too general to help people understand your problem. – KLE Aug 29 '11 at 21:27
  • thanks for your suggestion. It's not easy to describe complex things without english being your mother tongue. – pduersteler Aug 30 '11 at 6:05

for your reference you can see Active directory implementation it is pretty much the same thing. but i would prefer you must use hierarchical database for this purpose.

you problem has solution is in No-SQL database. there are many databases with key value store schema under no-SQL umbrella. Relational databases are not design for this purpose although you can use them by having parent child relationships, insertion is fine but we will face difficulties while retrieving data.

if there is no restriction on changing the database you must go with that. but if you have no option other than SQL DB as you might have been using SQL for relational purposes it would be cumbersome to have separate DB base for this purpose only.

but again don't use SQL DB for this purpose.

| improve this answer | |

It looks like most people are like me, they have trouble understanding what you want. But I will try and expose myself, maybe it can unblock your post ...

I think I understand why you consider creating many ids, and linking your elements together with them.

Storing a hierarchy in a relational database is not easy:

  • if you use just one table, there are no standard SQL way to obtain all data (but specific database have non portable solutions for this)
  • you could use several tables for the various levels, but that would be rigid and not recursive

Maybe the easiest way would be to store your hierarchy as a file (on your filesystem or in your database). A file naturally can contain hierarchical information, and you can parse into a hierarchical memory structure, so no problem (unless you need to query the relations between items).

Your file format is standard xml, so you have many tools available.

| improve this answer | |
  • 1
    Can't you just create a table for such a fragment with an ID and a ParentID or PreviousID field that has an FK to the ID field to maintain the hierachy? – Carlo Kuip Oct 29 '11 at 8:54
  • I thougth about that, reading the template and then putting the required paths into a table. But this got me other problems, mainly with the repeaters, that mixed up things. – pduersteler Jan 18 '12 at 8:10

First of all, thanks for all your answers. It is even nicer here than on stackoverflow because the answers are having more details in general and can be discussed better.

I have now found a more-or-less-solid solution for this (more-or-less because I am still experimenting with it) which I got accidentally while debugging some css.

My current solution: I use a library that internally splits it up into a hierarchical node list and returns that list as object. On this object, I can traverse and select nodes with either a css selector and also update or replace them.

Using xpath, I don't need to store hierarchical data for basic fields. There are just two fields in my table, xpath and replacement. So, rendering the template recursive also allows to nest things without having hierarchical data stored in mysql, because they are resolved via xpath. I just needed to add another table and a field for the repeat/layout path, but this basically also resolves via xpath.

(This is out of my brain because the project I am needing this is currently paused, and since I found a solution I wanted to share it).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.