Parse string to view

Laracast, docs, etc.

I ment literally taking an unparsed content from the database, and throwing it inside a view and parse it like it normally works.

I cannot find anything that works with a string, but I can find functions that works with files(this is something I do not want).

I was playing a bit, for fun ~ but I would like to avoid code like this:

    public function lol($content)
    {
        ob_start();
        
        eval('?>'.\Blade::compileString($content));

        $content = ob_get_clean();

        return $content;

    }

Retrieve data in a query and display in the view like you normally would.

Please read some of the docs. You don't have to use views and resource templates, and Blade but give them a go and come up with your own methods later if you are still not convinced.

start here http://laravel.com/docs/master/views

Sorry, I suck at explaining things.

I would like to use the blade system, but instead of using view('test.file.path'), I would like to inject a string that needs to compile directly.

The view: 'test.file.path' does not exists, but the content that is normally in that file is located in the database, and that is what I would like to use.

Sorry, I suck at explaining things.

Correct!

How much of the data is in the database? Is it fully rendered? Describe more of the context.

You could for instance have a full HTML Blog post in the database and still use a view. Your view could just have a single placeholder for the content.

post.blade.php

{!! $post->body !!}

It would be a strange way to build an app though.

edit: changed tags from double braces to exclamation marks to output the raw data

He is storing blade syntax in the database and he wants it to render.

Most likely you will need to extend Laravel's View Factory and the View classes to accomplish this.

I have been playing around for a bit, what do you guys think about this approach?

        \Blade::extend(function($value) use ($page) {
            return preg_replace('/@cmsview/', $page->html , $value);
        });

It is much better than that eval goody, but still doubting, about storing it to the database vs local file storage, I can also make files on the go.

Since it is cached anyway, it does not matter whether I use the database or file, but database would have been the easiest choice.

Why do you want to do this ?

@pmall

To put it bluntly I am working an a CMS, or well, at least gathering a bit idea's before starting with the project. The blade syntax is stored in my database, and would like to use the received data the same way as calling a normal blade.

Normal way: view('test.abc.page')

What I would like view($bladeContent) --> obviously, it does not work that way.

So I would like to render the view from the database(string), instead of files.

I cant see what functionality you can implements with that. You want users to make custom blade templates ? What for ?

Well, seems like the above idea introduced me to some problems with caching, the same file is called over and over, so the caching kicks in. :P

return view('Cms::page.view') ->with('page', $page);

@pmall,

It's a CMS system, the template files are located in a database, and I would like to render it. Only authorized people is allowed there.

I think I will just use the database for the title, description etc, and a view file as resource. Guess this will be the easiest solution. Since it will introduce some probs when using it another way.

Why dont you want to just store it in views. Seems over complicated for me.

@ilaurens you might be better using twig instead of blade?

@ohffs Good suggestion, will consider this.

But since I'm getting used to the blade system, my preference would be to stay at blade since it is build in, and Twig requires a learning curve and a third party app.

@pmall Because it's easier that way. Why would I want to add an database entry and a seperate file with view data? While I can have everything at one place, in the database.

Because now I have to create, edit and remove the file, while this could easily be done, if it stayed as a bundle in the database.

Well, it's not a problem, actually, but would have loved to keep it together.

Hm...I'm still not understanding the benefit to this.

Don't content management systems typically keep the files as views and render them? The DB would just decide which file/view to render. Creating your own theme meant creating a sub-directory with files that follow that specific CMS's standards.

Personally, I feel like it would be a hassle to keep the actual views in the DB because that would slow me down in terms of coding. For example, traditionally, if I'm creating a theme for a CMS, I can just open up my text editor and get started right away. Share my theme? Just zip it up and upload. Or put it on Github. Both are very fast solutions. If it's in the DB, how exactly would I change the view? Do I have to get authenticated and then use the browser to edit it? How would I share it?

@thomaskim Incidently pressed the awnsered my question button, but well, I guess it's the most interesting post, You also said something that made me change my mind so i will keep it that way ~

You are right, it's indeed a good choice to use normal files, did not see it that far yet.

The plan was to use a good textfield with markup's so that it's easily to manage within the control panel, it's not ment so that it will keep all views inside the database, but only those used with the pages.

It seems both have their own benefits, but indeed the theme idea, I did not really think about that one, you are absolutely right!

I will continue with views based, thank you :)

I know this is an old thread but most of the comments here are totally useless. You just keep saying there's no point doing this, yadda yadda. I hate it when people post comments like that when they don't have anything of actual value to say.

Now to provide some answer to the question, this package could be what you're looking for: https://packagist.org/packages/wpb/string-blade-compiler

@Nospoon The OP clearly asked for a solution that did not involve using an external package.