A Markup API in the kingdom of Processwire

[Pixrael]

The recent introduction of the Markup Regions has caused some excitement in our community, mainly for the simplicity of the proposal to output our markup, but for the various opinions about how to select and modify the regions, maybe it should not be the definitive solution. Perhaps the most correct option is to think this output strategy in the "Processwire style". Something open and versatile.

The solution could be: Have the layouts files (main.php) as our "Markup Database" and then with the templates files (home.php) we can do "CRUD operations" on it before the output, using for that a jquery/processwire like API. This could be a powerful way like the current excellent API solution to manipulate the data.

Where $markup come from the layout file "_main.php", in our templates files we'll can do:

<?php $markup->find('#sidebar').prepend(' ?>
  <div class="foobarcontainer">
    <h3>Hello <?php echo $page->foo ?></h3>
    <p><?php echo $page->bar ?></p>
  </div>
<?php '); ?>

<?php if ($hidecomments) $markup->find('.comment').addclass('close'); ?>

<?php $markup->find('#sidebar .contact ul').remove(); ?>

Etc. Think about the possibilities, it will no longer be necessary to define regions, the regions are any part of the document

It's just an idea, maybe is a really hard to-do solution, but will be perfect for the Processwire ecosystem as the direct-delayed output workflow. In GitHub already are several php libraries for select DOM elements using any css selector in a jquery like style. 

[fbg13]

How will this be better than the current Markup Regions?

[LostKobrakai]

As someone maintaining a project with lots of different frontend templates I'd imagine you'd get into trouble way fast with such an approach. As soon as you've more than a few of those calls in your code base it'll get hard to reason about what's currently visible and what's not part of the markup, as you've to go through all those steps in your head. There's no scope of interaction. Each of those calls could potentially change everything in your page. I don't think it's a good idea to let you junior dev remove some class in some part of your website, which by accident could break other parts of it because the class is duplicated. With the current markup implementation you're at least bound to a (hopefully limited) number of named regions. I imagine it a bit like those early jquery webapp javascript files: a mess of spaghetti code which nobody but the creator can understand in a reasonable timeframe.

[Pixrael]

I agree with you, I was just trying to think of a way to freely act over the elements. Sorry for this crazy post ;-)

[LostKobrakai]

No problem. Just as you post your ideas I can post my concerns.