>>33026
Why in the shit are you marking up a tree like that?

Why are you inventing your own markup language?

No wonder it's difficult to parse: it makes no goddamn sense. You're marking up a tree, but your home-made language is powerful enough to markup a cyclic graph. When it comes to stuff you need to parse, "powerful" is not a good thing.

Just use JSON or XML like any normal person.

Hell, even your 'three view' would be easier to parse, as it can only represent trees.

>>33047
That's the thing. Maybe I'm overcomplicating it.

But no, it's not my own markup language. I'm just using a php array stored in a model. I wrote it like that in OP to save space, as I went way over 2k characters.

And I think I might have come with the solution myself, right now. I still haven't implemented it, but what do you think of something like this?

Array tree for the same example:
array(
__ array("top",array(
__ __ array("left",array(
__ __ __ "img1",
__ __ __ "imgG"
__ __ )), //left
__ __ array("right",array(
__ __ __ "color",
__ __ __ "size",
__ __ __ array("prices",array(
__ __ __ __ "single","mass"
__ __ __ )), //prices
__ __ __ "others"
__ __ )), //right
__ ), //top
__ array("bottom",array(
__ __ __ "description"
__ )), //bottom
)

Recursive function:

function recursivething($arrayname,$array) {
__ $recvalue = "";
__ foreach ($array as $subname=>$subvalue):
__ __ if (is_array($subvalue)):
__ __ __ $recvalue .= "<div id=\"$subname\">" . "\n";
__ __ __ $recvalue .= $this->recursivething($subname,$subvalue) . "\n";
__ __ __ $recvalue .= </div><!-- .$subname" --> . "\n";
__ __ else:
__ __ __ $recvalue = [process data];
__ __ endif;
__ endforeach;
__ return $recvalue;
}

Though I'm still not sure if it's gonna work, as I'm sleepy and I'm planning on implementing 'til tomorrow. But what do you think? Makes sense?

>>33047
>>33053
Ah, wait, found a mistake.

The array is using unkeyed arrays with two values (title and array) for the subdivs, and the recursive function is looking for keys.

So the array would be something like this:

array(
__ "top"=>array(
__ __ "left"=>array(
__ __ __ "img1",
__ __ __ "imgG"
__ __ ), //left
__ __ "right"=>array(
__ __ __ "color",
__ __ __ "size",
__ __ __ "prices"=>array(
__ __ __ __ "single","mass"
__ __ __ ), //prices
__ __ __ "others"
__ __ ), //right
__ ), //top
__ "bottom"=>array(
__ __ __ "description"
__ ), //bottom
)

What do you think?

>>33054
I think you should maybe read https://en.m.wikipedia.org/wiki/Inner-platform_effect .

Because what I'm seeing here is a massive amount of work being done to accomplish the same result as a blind string replace. I'm pretty sure you could write a regex that completely ignores the structure and just changes every instance of "div" into "array", and it'd produce the same output for the same input.

I'm guessing there's some advantage to representing the document as an array of arrays, but I'm not seeing what it is: all I'm seeing is a very convoluted way of emitting <div>s, when the whole document could just as easily be stored as xhtml.

There are preexisting libraries that work on XML, that are more than capable of finding a <div> with a given name and editing the x[ht]ml inside it; surely it would be easier to store your xml document as xml and edit it with xml tools?

>>33064
It's because it's for a CMS, not for a specific application.

I got tired of making custom views and panels with the necessary security and particularities when, overall, they're the same, but applied to different base queries. So I decided to make a CMS that contains my usual stuff, and instead of using some wizard to fill data that would have to be read from the database (and in any case would have the same requirements - most likely the div tree would be a json or serialized object), I decided to just use a config file-like array to define the queries for every subpage (for the boutique example, say, there'd be a query for searches, one for tags, one for the products themselves, one for uploading/deleting/editing data and whatnot), so that way I'd only have to create the config file in a few minutes per view, helping me make any of my usual projects in a couple of hours instead of a couple of weeks like usual.

So of course it would sound like the link you gave me. It's supposed to help me create customized replicas quickly. That's the point of the system.

>>33065
No, I think you're missing the point.

You're exposing to yourself, in a convoluted way, functionality that already exists in the language.

In effect, you're creating a wrapper around xhtml, when you could just be using xhtml.

Have a look at PHP's support for DOM manipulation, and the various templating solutions for PHP.

Your OP made it sound like you were doing this as an intellectual exercise, which is fine, but if this is actually production work, you're crazy to be reimplementing basic tools when you could just use them.

>>33074
I get what you mean, but I can't just manipulate the DOM, as I'm using a MVC framework.

The function that traverses the tree is in the model, not in the view.

And the tree is an array instead of a pure xhtml implementation because it's part of a bigger config array, that yeah, includes some stuff that feels unnecessarily repetitive like page title definitions, but also much more useful stuff, like providing context and properties to fields - for example, say, the "img" field would have a context through a "type"=>"image" property, as well as maybe width and height, and when being printed on the view (the line that goes $recvalue = [process data]; here >>33053), it wouldn't just print the value of the row like that, but it would print an image tag with the image in it, or even, as I have it right now for the ones with set width and height properties, a div with said width and height that has the image as the background, stretched, centered with no-repeat.

Same with thumbnails, which link to whatever they should, and video/audio, which show videojs and audiojs, and even titles, which show between the set heading property.

And this goes all the way to input forms too. Like, say, an image - if there's height and/or width properties defined, then the system knows it has to scale the image before saving its path to the database. And of course, this has a double advantage, as it automatically runs the necessary security functions to avoid the exploits that can happen during a form fill.

And all of that is already working.

The div tree is just an issue I ran into now that I'm running tests on it - to have a properly flowing css without the use of javascript, which should be allowed to be turned off, I can't just have a div per field just like that. More often than not, I need to group them into divs for the styling to be appropriate. And the stripped array in the OP was the way I adapted that to the bigger config array, but again, I'm fine with changing it.